Client-side crypto first
Messages are encrypted in the browser using Web Crypto (AES-GCM). The server stores ciphertext and metadata.
EncSend security model
This page describes the current implementation: which data is encrypted client-side, how links and keys are handled, which access controls are active, and where the model limits are.
Keys in URL fragments
Decryption keys are transported in URL fragments like #k or #rk and are not sent to the server.
Optional password layer
Password-protected links use server-side password hashes plus additional client-side key wrapping (PBKDF2-SHA-256).
Lifetime controls
Expiry, view or submission limits, and one-time-read policies constrain access to sensitive content.
Data flow: secret send
- The browser generates 256-bit link key material.
- The message is encrypted with a random payload key via AES-GCM.
- The payload key is wrapped with an HKDF-SHA-256 key derived from the link key.
- Optionally, this wrapped key is additionally encrypted with a password-based layer (PBKDF2-SHA-256).
- The server stores only
encrypted_payload,encrypted_key, crypto metadata, and access policy fields. - After successful local decryption, the client confirms a view; with one-time-read, the secret is marked destroyed afterwards.
Data flow: secure message request
- The owner generates a request URL with a random public token.
- External senders encrypt locally in the browser with request key material from the URL fragment.
- The server stores submissions as ciphertext and enforces submission limits and expiry.
- The owner reads submissions via local decryption; plaintext is not processed server-side.
- For cross-device reading, the request key can additionally be stored as an owner-wrapped artifact.
Access control and abuse resistance
Public access tokens are generated randomly, stored only as SHA-256 hashes in the database, and validated via hash_equals.
Link passwords are never stored in plaintext and are checked against server-side hashes. Password sessions for public links are time-limited and configurable.
Rate limiting is active for critical endpoints including password checks, public submissions, login, and verification flows.
Owner-side operations are protected by authentication, verified email state, and authorization policies; sensitive recovery mutations require recent password confirmation.
Owner recovery and key vault
EncSend provides optional encrypted recovery artifacts for cross-device scenarios:
- Owner crypto profile: encrypted master key (AES-GCM), passphrase-based (PBKDF2-SHA-256).
- User key vault: encrypted backup of locally held secret and request keys.
- Owner-wrapped request keys per request and owner-wrapped secret keys per secret; request-key rotation batches include retry support.
Audit and traceability
Security-relevant actions are logged, for example link issuance, access denied, password challenge steps, submission creation, and recovery updates.
- Access-event tables persist event type, timestamp, user-agent, and contextual metadata.
- Audit logs are queryable for end users (own events) and administrators (global view).
- A dedicated migration removes IP-address columns from session and event-related tables.
Important limits of the model
- Browser security remains critical: local keys are cached in browser storage and require a hardened client environment.
- JavaScript and Web Crypto are mandatory for secure creation and local decryption flows.
- Transport security (HTTPS, reverse-proxy hardening, TLS policy) must be enforced at infrastructure level.
- Password hashing protects server-side storage but does not replace strong password choices.