Security at LangReply

What we encrypt, what we destroy, and what we cannot honestly guarantee. Written without marketing spin.

1. Encryption at rest

Sensitive data (user accounts, translation history, OTT messages, preferences) is encrypted at rest with AES-256-GCM. The master key lives outside the Git repository, on a restricted-access volume (permissions 600, dedicated owner).

Every sensitive record carries its own IV (96-bit random nonce) and GCM auth tag. Tampering with the ciphertext is detected on decrypt (cryptographic failure, no silent corruption).

Documented exception: languages.json (the public list of supported languages) is explicitly excluded from encryption — it's a public catalog, not personal data.

2. Irreversible erasure (crypto-shredding)

Principle

Every OTT conversation, every batch of sensitive messages, and every user account has its own DEK (Data Encryption Key) — a unique, randomly generated AES-256 key. Data is encrypted with this DEK; the DEK itself is wrapped by the master key (KEK).

To irreversibly erase data, we destroy the DEK. The encrypted bytes may remain in the database or on disk: without the key, they are indistinguishable from random noise.

Mathematical guarantee

An AES-256 DEK has a keyspace of 2256 possible values — about 1.16 × 1077. Brute-forcing a destroyed key is, given the current state of public cryptography and available compute (including projected post-quantum Grover attacks, which reduce this to 2128), infeasible.

What is actually destroyed

  • The DEK in RAM (immediate zeroization).
  • The wrapped DEK in the database (UPDATE ... SET encrypted_dek = NULL + Postgres VACUUM when applicable).
  • Application-cache copies.

3. Automatically disappearing messages

Any OTT conversation can enable an auto-purge timer: past this window, messages are destroyed by crypto-shredding the conversation's DEK.

Configurable durations

If nothing is configured, no default duration applies: messages are kept until deleted manually.

The timer starts when the message is read by the recipient (default) or when it is sent (option). A server sweeper runs every 10 minutes and purges what has expired.

Timer changes are visible in the conversation (timestamped system message). Neither sender nor recipient can "extend" an already-expired message — the key is gone.

4. Nuclear account purge

In the user portal, the "Destroy all my messages" button triggers immediate destruction of every DEK tied to your account: OTT conversations, translation history, drafts, encrypted attachments.

The operation is:

An account purge does not delete the account itself (identifier, email, billing preferences) — for that, use full account deletion, which is a separate action.

5. Per-account isolation

Every account has its own DEK. Compromising one DEK exposes only that account's data, not others'. The master key (KEK) is needed to unwrap DEKs, but on its own it doesn't let anyone read an account whose DEK is no longer in the database.

API requests are scoped by account_id. No route accepts an account id as a free parameter without verifying session ownership.

6. Self-hosted translation engine

Primary translation runs on NLLB-200 1.3B (202 languages) self-hosted on our own server, in an internal microservice that is not exposed to the Internet. Content does not leave our infrastructure to be translated.

Fallback: if the primary is unavailable, an automatic fallback may call Claude (Anthropic) only. This fallback can be disabled per account for sensitive use; when it fires, the content is transmitted to Anthropic and we flag it in the API response.

The MyMemory fallback was removed on July 28, 2026: it sent content in clear text inside the URL, with no data-processing agreement. There is no third fallback: if no engine is available, the translation fails rather than being handed to an uncontracted third party.

7. Authentication

Passwords hashed with scrypt (N=16384, r=8, p=1). Sessions via HMAC-signed HttpOnly cookie. 2FA available: TOTP (Google Authenticator, Aegis, 1Password) and SMS OTP (Twilio, messages localized to the recipient's language).

Rate limiting on auth endpoints (429 after repeated attempts). No password is ever emailed; resets use a single-use link.

8. Backups

Encrypted daily backups of the data volume. Retention: rolling 14 days, then deletion.

An encrypted off-site copy (AES-256) is kept at GitHub and Backblaze (United States). OTT/SMS messages and their keys are excluded from it and never leave the European Union.

9. Your rights (GDPR / Law 25 / CCPA)

Right of access, rectification, erasure, portability and objection. Requests via privacy@langreply.com are processed within 30 days. Erasure uses the crypto-shredding described above.

10. Certifications — honest

We are not SOC 2, ISO 27001 or HIPAA certified today. We won't claim otherwise until it's true. The measures described here are actually in place; the corresponding external audits are not yet.

11. What we honestly do not guarantee

We'd rather tell the truth than sell an illusion. Here's what crypto-shredding does not do:

  • Backups: our backups exclude the message and key tables — a restore cannot re-expose a destroyed message. The trade-off we accept: if the database is lost, OTT/SMS history is not recoverable.
  • Recipient screenshots: if you send a disappearing message to someone, they can photograph their screen with another device. No software on Earth prevents that. Signal can't either.
  • WAL, logs, replicas: Postgres writes transaction logs (WAL). A ciphertext byte may have lived there before erasure. Those logs rotate, but not instantly.
  • SSDs and wear-leveling: SSDs spread writes physically. A logical DELETE doesn't necessarily overwrite the physical sector. This is precisely why crypto-shredding is more reliable than physical erasure — but the ciphertext byte may persist physically for a while. Without the key, it stays unreadable.
  • Audit metadata: we keep minimal metadata (purge timestamp, IP) for audit and abuse prevention. It does not contain the destroyed content.
  • End-to-end encryption: OTT messaging is encrypted at rest server-side, but it is not E2EE in the Signal sense (where even the server cannot read). LangReply is technically capable of decrypting a message as long as its DEK exists. We don't — but we can't claim otherwise.

12. Report a security issue

Coordinated disclosure at security@langreply.com with subject [SECURITY]. We acknowledge within 72 h and ship a fix or mitigation within a reasonable window based on severity. No formal bug bounty yet; we credit reporters who wish it.

Last updated: August 6, 2026.