Security & Cryptography
DropNote is built upon the principle of zero-knowledge client-side encryption. This document provides a transparent breakdown of our cryptographic implementation, server storage model, threat landscape, and deliberate technical trade-offs.
1. Client-Side Encryption Model
All note encryption and decryption operations execute entirely within the client’s web browser utilizing the native SubtleCrypto API (W3C Web Cryptography Specification). Unencrypted note contents never touch network sockets and never reach DropNote servers.
2. Cryptographic Primitives & Envelope
- Symmetric Cipher: AES-256-GCM (Galois/Counter Mode) with 128-bit authentication tag verification.
- Initialization Vector (IV): 96-bit (12-byte) cryptographically secure pseudorandom nonce generated via
crypto.getRandomValues()for each encryption. Nonces are never reused. - Key Derivation (Password Notes): PBKDF2-HMAC-SHA256 with 100,000 iterations and a unique 128-bit random salt.
- Key Composition: HKDF-SHA256 combines URL fragment entropy with password-derived key material to ensure multi-factor protection.
- Envelope Versioning: All payloads encapsulate an explicit schema version (
version: 1) to facilitate backwards-compatible cipher migrations in future releases.
3. URL Fragment Key Architecture
When a note is created, the primary symmetric key is encoded into the URL fragment:
Per RFC 3986, the fragment identifier (#...) is handled exclusively by user agents (browsers) and is never transmitted to the web server in the HTTP request line or request headers. Consequently, the server only ever receives the note identifier.
4. Server Storage & Zero Knowledge
The DropNote database stores only opaque Base64URL-encoded ciphertext, public cryptographic parameters (IV, salt, algorithm metadata), and lifecycle controls (expiration timestamp, view limit, burn-after-reading flag).
To permit creators in Guest Mode to delete notes early without accounts, a 256-bit CSPRNG deletion token is created client-side. The server stores only its SHA-256 hash (delete_token_hash). Early deletion requests are verified against this digest.
5. Expiration & Atomic Destruction
Note lifespans are verified on every single retrieval request. If Date.now() > expires_at, the server immediately wipes the ciphertext and returns an expired state.
To prevent race conditions where concurrent requests might consume a single-view or burn-after-reading note simultaneously, the server uses atomic conditional updates:
UPDATE notes
SET view_count = view_count + 1,
is_destroyed = CASE WHEN burn_after_reading = 1 OR view_count + 1 >= max_views THEN 1 ELSE is_destroyed END,
destroyed_at = CASE WHEN (burn_after_reading = 1 OR view_count + 1 >= max_views) THEN :now ELSE destroyed_at END
WHERE id = :id AND is_destroyed = 0 AND (expires_at IS NULL OR expires_at > :now) AND (max_views IS NULL OR view_count < max_views);6. Abuse Mitigation & Brute-Force Throttling
API endpoints enforce sliding window rate limits. Creation is limited to 30 requests per 5 minutes per IP. To counter brute-force password guessing against password-protected notes, access attempts are capped at 20 attempts per minute per note/IP before temporary lockout.
7. Threat Model & Limitations
Recipient Preservation
DropNote cannot prevent a recipient from capturing screenshots, copying plaintext, saving HTML, or recording camera footage of their screen once unlocked.
Endpoint Integrity
If the creator or recipient machine is infected with malware, keyloggers, or malicious browser extensions, cryptographic guarantees at the application layer can be bypassed by local host compromise.
Backup Retention Disclaimer
When a note is destroyed, the ciphertext is scrubbed from the active database table. However, like any cloud infrastructure, physical storage drive sectors or database point-in-time recovery WAL logs may hold ephemeral disk fragments until overwritten.
An r3x Project
A dedicated privacy utility operating within the r3x network.