La sicurezza in LangReply
Cosa cifriamo, cosa distruggiamo e cosa onestamente non possiamo garantire. Scritto senza gergo di marketing.
1. Cifratura a riposo
I dati sensibili (account utente, cronologie di traduzione, messaggi OTT, preferenze) sono cifrati a riposo con AES-256-GCM. La chiave principale risiede fuori dal repository Git, su un volume ad accesso limitato (permessi 600, proprietario dedicato).
Ogni record sensibile porta con sé il proprio IV (nonce casuale a 96 bit) e il tag di autenticazione GCM. Un'alterazione del testo cifrato viene rilevata in fase di decifratura (fallimento crittografico, nessuna corruzione silenziosa).
Eccezione documentata: il file languages.json (l'elenco pubblico delle lingue supportate) è esplicitamente escluso dalla cifratura: è un catalogo pubblico, non un dato personale.
2. Cancellazione irreversibile (crypto-shredding)
Principio
Ogni conversazione OTT, ogni lotto di messaggi sensibili e ogni account utente hanno una propria DEK (Data Encryption Key): una chiave AES-256 unica, generata in modo casuale. I dati sono cifrati con questa DEK; la DEK stessa è cifrata dalla chiave principale (KEK).
Per cancellare i dati in modo irreversibile, distruggiamo la DEK. I byte cifrati possono restare nel database o su disco: senza la chiave sono indistinguibili da rumore casuale.
Garanzia matematica
Una DEK AES-256 ha uno spazio di 2256 valori possibili, circa 1,16 × 1077. Ritrovare per forza bruta una chiave distrutta è, allo stato attuale delle conoscenze pubbliche in crittografia e della potenza di calcolo disponibile (inclusa la proiezione post-quantistica con Grover, che riduce a 2128), impraticabile.
Cosa viene realmente distrutto
- La DEK in RAM (azzeramento immediato).
- La DEK cifrata nel database (
UPDATE ... SET encrypted_dek = NULL+VACUUMdi Postgres quando applicabile). - Le copie nella cache applicativa.
3. Messaggi che scompaiono automaticamente
Ogni conversazione OTT può attivare un timer di auto-cancellazione: oltre quel termine i messaggi sono distrutti tramite crypto-shredding della DEK della conversazione.
Durate configurabili
- 1 ora
- 24 ore
- 7 giorni
- 30 giorni
- Disattivato
In assenza di impostazione non si applica alcuna durata predefinita: i messaggi restano finché non vengono eliminati manualmente.
Il conteggio parte quando il messaggio viene letto dal destinatario (impostazione predefinita) o quando viene inviato (opzione). Uno spazzino lato server gira ogni 10 minuti ed elimina ciò che è scaduto.
La modifica del termine è visibile nella conversazione (messaggio di sistema con marca temporale). Né il mittente né il destinatario possono «prolungare» un messaggio già scaduto: la chiave è distrutta.
4. Cancellazione totale dell'account
Nel portale utente, il pulsante «Distruggi tutti i miei messaggi» avvia la distruzione immediata di tutte le DEK collegate al tuo account: conversazioni OTT, cronologia di traduzione, bozze, allegati cifrati.
L'operazione è:
- Istantanea sul piano crittografico (la chiave sparisce in millisecondi).
- Irreversibile — non conserviamo alcuna copia di riserva delle DEK distrutte.
- Confermata con doppio consenso (password + frase di conferma).
- Registrata (metadati di audit: marca temporale, IP, user-agent) senza esporre il contenuto distrutto.
La cancellazione dei messaggi non elimina l'account in sé (identificativo, email, preferenze di fatturazione): per questo usa l'eliminazione completa dell'account, che è un'azione distinta.
5. Isolamento per account
Ogni account ha la propria DEK. La compromissione di una DEK espone solo i dati di quell'account, non quelli degli altri. La chiave principale (KEK) serve a decifrare le DEK, ma da sola non basta a leggere un account la cui DEK non è più nel database.
Le richieste API sono delimitate da account_id. Nessuna rotta accetta l'identificativo di un account come parametro libero senza verificare l'appartenenza della sessione.
6. Motore di traduzione self-hosted
La traduzione principale usa NLLB-200 1.3B (202 lingue) ospitato sul nostro server, in un microservizio interno non esposto su Internet. Il contenuto non lascia la nostra infrastruttura per essere tradotto.
Riserva: in caso di indisponibilità, un ripiego automatico può rivolgersi soltanto a Claude (Anthropic). È disattivabile per account negli usi sensibili; quando scatta, il contenuto viene trasmesso ad Anthropic e lo segnaliamo nella risposta dell'API.
Il ripiego MyMemory è stato rimosso il 28 luglio 2026: trasmetteva il contenuto in chiaro dentro l'URL, senza contratto di responsabile del trattamento. Non esiste un terzo ripiego: se nessun motore è disponibile, la traduzione fallisce invece di essere affidata a un terzo non contrattualizzato.
7. Autenticazione
Password sottoposte ad hash con scrypt (N=16384, r=8, p=1). Sessioni tramite cookie HttpOnly firmato HMAC. 2FA disponibile: TOTP (Google Authenticator, Aegis, 1Password) e OTP via SMS (Twilio, messaggi localizzati nella lingua del destinatario).
Limitazione di frequenza sugli endpoint di autenticazione (429 dopo tentativi ripetuti). Nessuna password viene inviata per email; i reimpostamenti usano un link monouso.
8. Backup
Backup cifrati quotidiani del volume dati. Conservazione: 14 giorni a scorrimento, poi cancellazione.
Una copia cifrata fuori sede (AES-256) è conservata presso GitHub e Backblaze (Stati Uniti). I messaggi OTT/SMS e le loro chiavi ne sono esclusi e non lasciano mai l'Unione europea.
9. I tuoi diritti (GDPR / Legge 25 / CCPA)
Diritto di accesso, rettifica, cancellazione, portabilità e opposizione. Le richieste si inviano per email a privacy@langreply.com e sono trattate entro 30 giorni. La cancellazione usa il crypto-shredding descritto sopra.
10. Certificazioni — onestamente
Oggi non siamo certificati SOC 2, ISO 27001 né HIPAA. Non lo sosterremo finché non sarà vero. Le misure descritte qui sono realmente in atto; gli audit esterni corrispondenti non ancora.
11. Ciò che onestamente non garantiamo
Preferiamo dire la verità piuttosto che vendere un'illusione. Ecco cosa il crypto-shredding non fa:
- Backup: i nostri backup escludono le tabelle dei messaggi e delle chiavi — un ripristino non può riesporre un messaggio distrutto. Compromesso assunto: se il database va perso, lo storico OTT/SMS non è recuperabile.
- Screenshot del destinatario: se invii un messaggio che scompare, quella persona può fotografare lo schermo con un altro dispositivo. Nessun software al mondo può impedirlo. Nemmeno Signal.
- WAL, log, repliche: Postgres scrive log delle transazioni (WAL). Un byte cifrato può esservi transitato prima della cancellazione. Questi log ruotano, ma non istantaneamente.
- SSD e wear-levelling: gli SSD distribuiscono fisicamente le scritture. Un
DELETElogico non sovrascrive necessariamente il settore fisico. È proprio per questo che il crypto-shredding è più affidabile della cancellazione fisica — ma il byte cifrato può sopravvivere fisicamente per un po'. Senza la chiave resta illeggibile. - Metadati di audit: conserviamo metadati minimi (marca temporale di una cancellazione, IP) per audit e contrasto agli abusi. Non contengono il contenuto distrutto.
- Cifratura end-to-end: la messaggistica OTT è cifrata a riposo lato server, ma non è E2EE nel senso di Signal (dove nemmeno il server può leggere). Tecnicamente LangReply è in grado di decifrare un messaggio finché la sua DEK esiste. Non lo facciamo — ma non possiamo sostenere il contrario.
12. Segnalare un problema di sicurezza
Divulgazione coordinata a security@langreply.com con oggetto [SECURITY]. Confermiamo la ricezione entro 72 h e pubblichiamo una correzione o una mitigazione in tempi ragionevoli in base alla gravità. Nessun bug bounty formale per ora; citiamo chi lo desidera.
Ultimo aggiornamento: 6 agosto 2026.