Sécurité chez LangReply

Ce que nous chiffrons, ce que nous détruisons, et ce que nous ne pouvons honnêtement pas garantir. Écrit sans jargon marketing.

Security at LangReply

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

1. Chiffrement au reposEncryption at rest

Les données sensibles (comptes utilisateurs, historiques de traduction, messages OTT, préférences) sont chiffrées au repos avec AES-256-GCM. La clé maîtresse réside dans /opt/yoann/secrets/langreply.key, hors du dépôt Git, avec permissions restreintes (chmod 600, propriétaire dédié).

Chaque enregistrement sensible embarque son propre IV (nonce aléatoire 96 bits) et son tag d'authentification GCM. Une altération du fichier chiffré est détectée au déchiffrement (échec cryptographique, pas de silent corruption).

Exception documentée : le fichier languages.json (liste publique des langues supportées) est explicitement exclu du chiffrement : c'est un catalogue public, pas une donnée personnelle.

Sensitive data (user accounts, translation history, OTT messages, preferences) is encrypted at rest with AES-256-GCM. The master key lives at /opt/yoann/secrets/langreply.key, outside the Git repo, with restricted permissions (chmod 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. Effacement irréversible (crypto-shredding)Irreversible erasure (crypto-shredding)

Principe

Chaque conversation OTT, chaque lot de messages sensibles, et chaque compte utilisateur possèdent une DEK (Data Encryption Key) dédiée — une clé AES-256 unique, générée aléatoirement. Les données sont chiffrées avec cette DEK ; la DEK elle-même est chiffrée par la clé maîtresse (KEK).

Pour effacer irréversiblement les données, nous détruisons la DEK. Les octets chiffrés peuvent rester présents en base ou sur disque : sans la clé, ils sont indistinguables de bruit aléatoire.

Garantie mathématique

Une DEK AES-256 a un espace de 2256 valeurs possibles — environ 1,16 × 1077. Retrouver une clé détruite par force brute est, en l'état des connaissances publiques en cryptographie et de la puissance de calcul disponible (y compris post-quantique projetée avec Grover, qui ramène à 2128), infaisable.

Concrètement : quand vous cliquez « supprimer », nous n'essayons pas d'écraser chaque octet sur chaque réplique de disque et de sauvegarde. Nous détruisons la clé. Le résultat cryptographique est équivalent — et bien plus fiable dans un système distribué.

Ce qui est réellement détruit

  • La DEK en RAM (zéroïsation immédiate).
  • La DEK chiffrée en base (UPDATE ... SET encrypted_dek = NULL + VACUUM Postgres quand applicable).
  • Les copies en cache applicatif.

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.

In plain terms: when you click "delete", we don't try to overwrite every byte on every disk replica and backup. We destroy the key. The cryptographic result is equivalent — and far more reliable in a distributed system.

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. Messages qui disparaissent (style Signal)Disappearing messages (Signal-style)

Chaque conversation OTT peut activer un délai d'auto-purge : au-delà, les messages sont détruits par crypto-shredding de leur DEK de conversation.

Durées configurables

La durée s'applique au message dès qu'il est lu par le destinataire (par défaut) ou dès qu'il est envoyé (option). Un tâcheron serveur passe toutes les 60 secondes et purge ce qui a expiré. Il n'y a pas de « fenêtre de grâce » de plusieurs heures.

La modification du délai est visible dans la conversation (message système horodaté). Ni l'expéditeur ni le destinataire ne peut « prolonger » un message déjà expiré : la clé est détruite.

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

Configurable durations

The timer starts when the message is read by the recipient (default) or when it is sent (option). A server sweeper runs every 60 seconds and purges what has expired. There is no multi-hour "grace window".

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. Purge extrême du compteNuclear account purge

Dans le portail utilisateur, le bouton « Détruire tous mes messages » déclenche la destruction immédiate de toutes les DEK associées à votre compte : conversations OTT, historique de traduction, brouillons, pièces jointes chiffrées.

L'opération est :

Une purge du compte ne supprime pas le compte lui-même (identifiant, e-mail, préférences de facturation) : pour ça, utilisez la suppression complète du compte, distincte.

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. Isolation par comptePer-account isolation

Chaque compte a sa propre DEK. Une compromission d'une DEK n'expose que les données de ce compte, pas celles des autres. La clé maîtresse (KEK) est nécessaire pour déchiffrer les DEK, mais elle ne suffit pas à lire un compte sans la DEK correspondante encore présente en base.

Les requêtes API sont scopées par account_id. Aucune route ne prend l'identifiant d'un compte en paramètre libre sans vérification d'appartenance de la session.

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. Moteur de traduction auto-hébergéSelf-hosted translation engine

La traduction principale utilise NLLB-200 1.3B hébergé sur notre propre serveur (microservice langreply-mt, port 3361). Le contenu ne quitte pas notre infrastructure pour être traduit.

Secours : en cas d'indisponibilité, un repli automatique peut solliciter Claude (Anthropic) ou MyMemory. Ces replis sont désactivables par compte pour les usages sensibles. Quand ils sont utilisés, le contenu est transmis au fournisseur tiers concerné — nous le signalons dans la réponse d'API.

Primary translation runs on NLLB-200 1.3B self-hosted on our infrastructure (microservice langreply-mt, port 3361). Content does not leave our servers to be translated.

Fallback: if the primary is unavailable, an automatic fallback may call Claude (Anthropic) or MyMemory. Fallback can be disabled per account for sensitive use. When it fires, the content is transmitted to the relevant third party — we flag it in the API response.

7. AuthentificationAuthentication

Mots de passe hachés avec bcrypt (coût 12). Sessions par cookie HttpOnly signé HMAC. 2FA disponible : TOTP (Google Authenticator, Aegis, 1Password) et OTP par SMS (Twilio, messages localisés dans la langue du destinataire).

Limitation de débit sur les endpoints d'authentification (429 après tentatives répétées). Aucun mot de passe n'est envoyé par e-mail ; les réinitialisations utilisent un lien à usage unique.

Passwords hashed with bcrypt (cost 12). 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. SauvegardesBackups

Sauvegardes chiffrées quotidiennes du volume de données. Les DEK détruites ne sont pas restaurées lors d'une restauration : une DEK détruite dans la base primaire est aussi absente des sauvegardes chiffrées après rotation (voir plus bas la limite honnête).

Rétention : 30 jours glissants, puis suppression. Les sauvegardes ne quittent pas la région d'hébergement.

Encrypted daily backups of the data volume. Destroyed DEKs are not restored during a restore: a DEK destroyed in the primary DB is also absent from encrypted backups after rotation (see the honest caveat below).

Retention: rolling 30 days, then deletion. Backups don't leave the hosting region.

9. Vos droits (GDPR / CCPA)Your rights (GDPR / CCPA)

Droit d'accès, de rectification, d'effacement, de portabilité et d'opposition. Les demandes se font par e-mail à info@anmaer.com et sont traitées sous 30 jours. L'effacement utilise la purge par crypto-shredding décrite plus haut.

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

10. Certifications — honnêteCertifications — honest

Nous ne sommes pas certifiés SOC 2, ISO 27001 ni HIPAA aujourd'hui. Nous ne le prétendrons pas tant que ce ne sera pas vrai. Les mesures décrites ici sont réellement en place ; les audits externes correspondants ne le sont pas encore.

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. Ce que nous ne garantissons pas honnêtementWhat we honestly do not guarantee

Nous préférons dire la vérité plutôt que vendre une illusion. Voici ce que le crypto-shredding ne fait pas :

  • Sauvegardes antérieures : une sauvegarde effectuée avant la destruction de la DEK contient encore la DEK chiffrée. Nos sauvegardes sont chiffrées et purgées après 30 jours, mais dans cette fenêtre, une restauration complète du système restaurerait techniquement la DEK. Nous ne restaurons jamais une sauvegarde pour ré-exposer des données qu'un utilisateur a demandé de détruire — mais nous préférons vous le dire clairement.
  • Capture d'écran côté destinataire : si vous envoyez un message qui disparaît à quelqu'un, cette personne peut prendre une photo de son écran avec un autre appareil. Aucun logiciel au monde ne peut empêcher cela. Signal ne le peut pas non plus.
  • WAL, journaux, réplicas : Postgres écrit des journaux de transactions (WAL). Un octet chiffré peut y avoir séjourné avant d'être effacé. Ces journaux sont rotés, mais pas instantanément.
  • SSD et wear-levelling : les disques SSD répartissent les écritures physiquement. Un DELETE logique n'écrase pas nécessairement le secteur physique. C'est justement pour cette raison que le crypto-shredding est plus fiable qu'un effacement physique — mais l'octet chiffré peut subsister physiquement quelque temps. Sans la clé, il reste illisible.
  • Métadonnées d'audit : nous conservons des métadonnées minimales (horodatage d'une purge, IP) pour l'audit et la lutte contre l'abus. Ces métadonnées ne contiennent pas le contenu détruit.
  • Chiffrement de bout en bout : la messagerie OTT est chiffrée au repos côté serveur, mais elle n'est pas E2EE au sens de Signal (où même le serveur ne peut pas lire). LangReply est capable, techniquement, de déchiffrer un message tant que sa DEK existe. Nous ne le faisons pas — mais nous ne pouvons pas prétendre l'inverse.

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

  • Prior backups: a backup taken before the DEK was destroyed still contains the wrapped DEK. Our backups are encrypted and rotate out after 30 days, but within that window, a full system restore would technically bring the DEK back. We never restore a backup to re-expose data a user asked to destroy — but we'd rather say it plainly.
  • 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. Signaler un problème de sécuritéReport a security issue

Divulgation coordonnée à info@anmaer.com avec objet [SECURITY]. Nous accusons réception sous 72 h et publions un correctif ou une atténuation dans un délai raisonnable selon la gravité. Aucun bug bounty formel pour l'instant ; nous mentionnons les rapporteurs qui le souhaitent.

Coordinated disclosure at info@anmaer.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.

Dernière mise à jour : 6 juillet 2026. Last updated: July 6, 2026.