How Client-Side AES-256-GCM Encryption & URL Hash Keys Work

When sharing sensitive credentials online, "encrypted in transit" (TLS/HTTPS) is no longer enough. Standard web applications terminate TLS at the load balancer, exposing plaintext data to application servers, logs, and database backups. Here is how client-side Zero-Knowledge AES-256-GCM encryption eliminates server trust entirely.

1. The Fundamental Flaw of Server-Side Encryption

Many password sharing tools and cloud pastebins claim that your data is "encrypted at rest with AES-256." While technically true, they omit a critical detail: where the encryption happens and who holds the key. When you submit a password through a standard web form over HTTPS, your browser sends the plaintext payload to the remote server. The server then encrypts the payload using its own internal master key before writing it to a database.

This architecture introduces four severe vulnerabilities:

• Application-Layer Interception: Reverse proxies, APM monitoring agents (such as Datadog, Sentry, or New Relic), and debug loggers frequently capture request bodies before database encryption occurs.
• Shared Master Keys: If an attacker compromises the server environment variables or KMS role, every stored secret in the database can be decrypted in bulk.
• Subpoena & Insider Risk: Because the service operator possesses both the ciphertext and the decryption key, they can technically read or hand over stored secrets.
• Disk Remanence: Database write-ahead logs (WAL) and SSD snapshots persist historical copies even after a row is marked deleted.

2. How Client-Side Web Crypto API Solves Key Custody

True Zero-Knowledge architecture moves the cryptographic boundary out of the data center and directly into the sender's browser using the W3C standard window.crypto.subtle (Web Crypto API). Instead of relying on external JavaScript libraries that could be tampered with via supply-chain attacks, the Web Crypto API executes native C++/Rust cryptographic primitives compiled directly into Chromium, WebKit, and Gecko.

When you click Encrypt & Generate One-Time Link on ReaDelete, the following sequence executes locally on your device before a single network packet leaves your browser:

1. CSPRNG Key Generation: The browser calls crypto.subtle.generateKey({ name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]), drawing 256 bits of high-entropy randomness from the operating system kernel (/dev/urandom, BCryptGenRandom, or Secure Enclave).
2. Unique 96-Bit Initialization Vector (IV): A fresh 12-byte (96-bit) initialization vector is generated via crypto.getRandomValues(new Uint8Array(12)). Under NIST SP 800-38D guidelines, a 96-bit IV is the optimal length for Galois/Counter Mode (GCM) because it is processed directly into the counter block without extra GHASH compression rounds.
3. Authenticated Encryption (AEAD): The plaintext message (and optional watermarked ID image data URL) is serialized into UTF-8 bytes and passed into crypto.subtle.encrypt. AES-256-GCM produces both the ciphertext and a 128-bit Galois Message Authentication Code (GMAC tag) appended to the output.
4. Zero-Knowledge Network Transmission: Only the base64url-encoded ciphertext and iv are sent to the ReaDelete API via POST /api/notes. The 256-bit key is never included in the request body, headers, or query parameters.

3. Comparison: Transport Encryption vs. Zero-Knowledge Ephemeral Encryption

4. The RFC 3986 URL Fragment: Why the # Hash Never Leaves the Browser

A common question from security auditors is: "If the decryption key is embedded inside the shareable link, doesn't the web server see the key when the recipient clicks the link?"

The answer lies in RFC 3986 Section 3.5 (Uniform Resource Identifier: Generic Syntax). Every ReaDelete link is structured as follows:

https://readelete.com/n/Ab9xK2pQ#k8LmP4vR9zW2nQ7xT5jH1cB6yF3dG0sA8eU4iO2wP9k

• Path Component (/n/Ab9xK2pQ): Sent over HTTPS to the server to locate the encrypted RAM slot.
• Fragment Identifier (#k8LmP4vR...): Strictly local to the user agent (browser). Every major browser engine strips everything from the # character onward before constructing the HTTP GET request line.

When the recipient clicks the link and confirms decryption, the browser fetches the encrypted ciphertext via POST /api/notes/Ab9xK2pQ/burn (which simultaneously deletes the RAM entry on the server), reads window.location.hash locally in JavaScript, imports the 256-bit key into crypto.subtle, and decrypts the payload in browser memory.

5. Best Practices for Maximum Cryptographic Hygiene

Even with Zero-Knowledge client-side encryption, operational security depends on how you transmit the link. For high-value production credentials—such as root SSH keys, AWS IAM secrets, or database master passwords—combine ReaDelete's URL hash encryption with an out-of-band PIN passcode. Send the ReaDelete link via email or Slack, and send the 4-to-8 digit PIN via SMS or voice call. Because ReaDelete hashes the PIN verification and enforces rate-limited attempts prior to releasing the ciphertext, an attacker who intercepts your email or Slack workspace still cannot trigger the read or decrypt the secret.