ReaDelete AES-256-GCM • RAM-ONLY
+ Create Encrypted Link
TECHNICAL WHITEPAPER • SPECIFICATION v2.4

ReaDelete Cryptographic Architecture & Threat Model

This document details the exact cryptographic primitives, data flow, memory lifecycle, and threat model of the ReaDelete platform (readelete.com) for security auditors, DPOs, and DevSecOps engineers.

1. Cryptographic Primitives Specification

Component Specification / Standard Implementation Detail
Symmetric Cipher AES-256-GCM (NIST SP 800-38D) Native browser window.crypto.subtle.encrypt with 256-bit key and 128-bit GMAC authentication tag.
Key Entropy Source OS CSPRNG (256 bits) Generated via crypto.subtle.generateKey and exported as raw 32-byte base64url string into URL #hash.
Initialization Vector (IV) 96-bit (12-byte) Random Nonce Freshly generated per note via crypto.getRandomValues(new Uint8Array(12)); never reused.
Optional Passcode (PIN) SHA-256 Client-Side Digest Salted client-side hash verified prior to atomic burn; wrong PIN attempts do not destroy the payload.
ID Image Redaction & Watermark HTML5 2D Canvas Pixel Flattening Rendered locally into a single rasterized JPEG layer before AES-256-GCM encryption.

2. End-to-End Lifecycle of a Secret

  1. Local Composition & Redaction: The sender enters text or attaches an identity document. Redaction bars and diagonal watermarks are composited inside local browser memory.
  2. Client-Side Encryption: The payload JSON (containing the UTF-8 note text and optional flattened JPEG data URL) is encrypted with AES-256-GCM in browser memory.
  3. Ciphertext Upload: The browser sends { ciphertext, iv, ttlMinutes, hasPin, pinHash, burnAfterSeconds, blurByDefault } to POST /api/notes. The 256-bit key is never transmitted.
  4. Volatile RAM Allocation: The server stores the ciphertext inside an in-memory Map structure and returns a random note ID.
  5. Link Construction: The browser combines the note ID and the local 256-bit key into https://readelete.com/n/{id}#{key}.
  6. Crawler-Safe Inspection: When messaging apps generate link previews, GET /api/notes/{id}/status confirms existence without burning the note.
  7. Atomic Burn & Local Decryption: When the human recipient clicks Decrypt & Destroy Message Now, POST /api/notes/{id}/burn atomically deletes the ciphertext from server RAM and returns it one final time to the browser, which decrypts it using window.location.hash.

3. Threat Model & Mitigations

  • Compromised Network / TLS Inspection: Mitigated by TLS 1.3 in transit plus client-side AES-256-GCM encryption and URL fragment separation.
  • Server Memory Snapshot / Subpoena After Reading: Mitigated by immediate atomic deletion from volatile RAM upon the first read.
  • Pre-Read Link Interception: Mitigated by the single-use canary property (recipient immediately sees 410 GONE if an attacker opened it first), optional secondary PIN protection, and the sender's real-time Kill Switch.
  • Visual Shoulder Surfing / Screen Recording: Mitigated by the default Anti-Shoulder-Surf Blur Shield (allowing blind clipboard copy) and configurable 30s/60s automatic DOM screen wiping.

4. Responsible Vulnerability Disclosure

We welcome independent security review by cryptographic researchers. If you believe you have discovered a security vulnerability in ReaDelete, please contact security@readelete.com with a detailed proof of concept. We commit to acknowledging reports within 48 hours.