EncSend EncSend
Security concept Log in
Security concept

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.

1. Client-side cryptography

Messages are encrypted in the browser using Web Crypto (AES-GCM). The server stores ciphertext and metadata.

2. Keys in URL fragments

Decryption keys are transported in URL fragments such as #k or #rk and are not sent to the server.

3. Optional password layer

Password-protected links use server-side password hashes plus additional client-side key wrapping (PBKDF2-SHA-256).

4. Lifetime controls

Expiry, view/submission limits, and one-time-read policies restrict access to sensitive content.

Data flow: secret send

  1. 1. The browser generates 256-bit link key material.
  2. 2. The message is encrypted with a random payload key via AES-GCM.
  3. 3. The payload key is wrapped with an HKDF-SHA-256 key derived from the link key.
  4. 4. Optionally, this wrapped key is additionally encrypted with a password-based layer (PBKDF2-SHA-256).
  5. 5. The server stores only encrypted_payload, encrypted_key, crypto metadata, and access policy fields.
  6. 6. After successful local decryption, the client confirms a view; with one-time read, the secret is then marked as destroyed.

Data flow: secure message request

  1. 1. The owner generates a request URL with a random public token.
  2. 2. External senders encrypt locally in the browser using request key material from the URL fragment.
  3. 3. The server stores submissions as ciphertext and enforces submission limits and expiry.
  4. 4. The owner reads submissions via local decryption; plaintext is not processed server-side.
  5. 5. 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 (default 120 minutes).
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 status, and authorization policies; sensitive recovery changes 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 stored secret/request keys.
  • Owner-wrapped request keys per request, including resumable rotation batches with 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 store the event type, timestamp, user agent, and contextual metadata.
  • Audit logs for important events.
  • 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.
Create workspace Sign in