← Back to HashNotary

Security Architecture

This document describes HashNotary's security model, cryptographic foundations, and architectural decisions designed to protect user data and ensure certification integrity.

1. Zero-Knowledge Design Philosophy

HashNotary is built on a fundamental principle: we should never have access to user documents. This isn't a marketing claim — it's an architectural constraint enforced at the protocol level.

      Key Insight: The most secure data is data you never possess. If we never receive your documents, we can never leak, lose, or be compelled to surrender them.
    

2. Cryptographic Pipeline

Step 1: Client-Side Hashing

Documents are processed entirely in the user's browser using the WebCrypto API (window.crypto.subtle). The SHA-256 algorithm produces a 256-bit (32-byte) digest, represented as a 64-character hexadecimal string.

Properties of SHA-256:

Deterministic: The same file always produces the same hash
Avalanche effect: A single bit change produces a completely different hash
Collision-resistant: ~2^128 operations needed to find two files with the same hash
Irreversible: It is computationally infeasible to reconstruct a file from its hash

Step 2: Optional AES-256 Encryption

Users can optionally encrypt their files before hashing with AES-256-GCM using a user-provided password. The encryption key is derived using PBKDF2 with 100,000 iterations and a random 128-bit salt. The encrypted file can be stored in the user's vault for future verification.

Step 3: Blockchain Recording

Only the 32-byte hash is transmitted to our server, which forwards it to the Polygon smart contract. The transaction creates an immutable, timestamped record that cannot be altered by any party.

3. Infrastructure Security

Transport: All traffic encrypted via TLS 1.3 with Let's Encrypt certificates
Authentication: JWT tokens with bcrypt-hashed passwords (12 salt rounds)
Headers: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy
Rate Limiting: API rate limits to prevent abuse
CORS: Strict origin validation

4. Threat Model

Server Compromise

Impact: Minimal. Attackers would find only cryptographic hashes, not documents. Hashes cannot be reversed to obtain original files.

Man-in-the-Middle

Mitigation: TLS encryption + HSTS preload. Hash computation occurs client-side, so even intercepted traffic reveals only hashes, not documents.

Blockchain Tampering

Mitigation: Polygon inherits Ethereum's security model. Altering a seal would require controlling >51% of network validators — a practically and economically impossible feat.

5. Audit & Transparency

Our security model is designed to be verifiable:

Smart contract source code is verified on PolygonScan
Client-side hashing can be verified by inspecting browser developer tools (Network tab shows only hash transmission)
All blockchain records are publicly queryable

View Smart Contract → 🚀 Start Free