Whitepaper tecnico e trasparenza

Ogni messaggio viene cifrato nel browser con AES-256-GCM usando una chiave di sessione generata casualmente. La chiave di sessione viene poi cifrata con la chiave pubblica RSA-OAEP 2048 di ciascun destinatario. Il server riceve e conserva solo testo cifrato e le buste delle chiavi: non ha mai accesso al contenuto in chiaro.

Il codice che esegue queste operazioni è pubblico e ispezionabile: modulo crittografico del client. La pagina serve lo stesso file usato in produzione.

Creazione. La coppia RSA-OAEP 2048 (SHA-256) viene generata sul dispositivo con crypto.subtle.generateKey del browser, usando il generatore casuale del sistema operativo. La chiave pubblica viene caricata sul server in formato JWK; la chiave privata resta locale.

Custodia. La chiave privata viene esportata in JWK e cifrata con AES-256-GCM (IV casuale a 96 bit) usando una chiave derivata dalla Master Password con PBKDF2-HMAC-SHA-256, 250.000 iterazioni e salt casuale a 128 bit. Sul server finisce solo questo blob cifrato: senza la Master Password è inutilizzabile anche per noi. L'accesso al conto identifica la persona; la Master Password o la PassKey sbloccano le chiavi.

Uso in sessione. La chiave privata decifrata vive solo nella memoria della scheda del browser per la durata della sessione (massimo 5 ore) e viene cancellata con «Blocca account», con la disconnessione o alla chiusura della pagina. In alternativa alla Master Password si può sbloccare con una PassKey (WebAuthn) del sistema operativo, che protegge il segreto tramite il chip di sicurezza del dispositivo.

Rotazione e distruzione. Generare una nuova coppia sostituisce la chiave pubblica pubblicata: i messaggi futuri usano la nuova chiave, quelli passati restano leggibili solo con la chiave precedente, che va quindi conservata (vedi «Portabilità»). Con la cancellazione del conto il blob della chiave privata e i messaggi cifrati vengono eliminati e diventano matematicamente irrecuperabili.

Conseguenza diretta e non aggirabile: se la Master Password viene persa, i messaggi già cifrati non sono recuperabili — nemmeno da noi. Non esiste alcuna chiave di riserva, di amministrazione o di recupero lato server.

Attacchi mitigati. Lettura dei messaggi da parte del gestore del servizio o di chi ottenesse una copia del database (i contenuti sono cifrati lato client); intercettazione in rete (TLS più cifratura applicativa); furto della sola password di accesso senza la Master Password; iniezione di script di terze parti (Content Security Policy stretta, niente CDN esterne per il codice); clickjacking, sniffing del tipo MIME e downgrade HTTP (HSTS); manomissione degli aggiornamenti desktop (firma Ed25519 e hash SHA-256 pubblicati).

Attacchi NON mitigati. Un dispositivo già compromesso (keylogger, malware, estensioni malevole) vede il testo in chiaro dopo lo sblocco; una Master Password debole o riutilizzata; l'analisi dei metadati di consegna (chi scrive a chi e quando), che restano necessariamente visibili al server; la posta scambiata con provider esterni, che non è end-to-end; e — poiché il codice viene servito dal nostro dominio — un attaccante che controllasse il server potrebbe in teoria consegnare codice alterato a un utente specifico. Quest'ultimo rischio è comune a ogni webmail cifrata e si riduce usando l'app desktop, i cui pacchetti sono firmati e verificabili.

Conserviamo solo i metadati strettamente necessari alla consegna e alla sicurezza: identificativi di mittente e destinatario, data e ora, dimensione del messaggio, stato di lettura e cartella. Non conserviamo oggetto in chiaro, corpo, allegati in chiaro, né cronologie di navigazione o profilazione pubblicitaria dei contenuti.

Dove risiedono i dati. Database, archivio degli allegati cifrati e sistema di autenticazione sono ospitati su infrastruttura gestita nella regione Unione Europea — Francoforte, Germania (eu-central-1). Il sito e le funzioni applicative sono serviti tramite rete di distribuzione con terminazione TLS; nessun contenuto in chiaro dei messaggi transita o viene memorizzato in questi passaggi.

Legge applicabile. Il trattamento è soggetto al GDPR (Regolamento UE 2016/679) e alla normativa italiana. Rispondiamo esclusivamente a richieste provenienti da autorità competenti secondo la legge applicabile; non possiamo consegnare contenuti dei messaggi perché non ne possediamo la chiave. Ciò che possiamo tecnicamente consegnare sono i metadati elencati al punto 4.

Log. Conserviamo log tecnici di accesso e di errore (indirizzo IP, data e ora, tipo di richiesta, esito) per la sicurezza operativa e la difesa da abusi, per un massimo di 30 giorni, dopodiché vengono eliminati — salvo legislazioni nazionali o locali più restrittive. Non correliamo i log a contenuti e non li cediamo a terzi per finalità commerciali. I log dei pagamenti sono conservati per il periodo previsto dagli obblighi fiscali.

Dalla propria casella è possibile esportare in qualsiasi momento tutti i messaggi decifrati in file .eml standard (leggibili in Thunderbird, Outlook, Apple Mail), insieme al backup della chiave pubblica e della chiave privata ancora cifrata con la Master Password. L'esportazione avviene interamente nel browser: la decifratura non passa dai nostri server. Se il servizio dovesse chiudere, i messaggi restano leggibili altrove.

I messaggi scambiati con indirizzi non MAILCRIPTY (Gmail, Outlook e simili) non possono essere protetti end-to-end, perché il destinatario non possiede una chiave del nostro sistema. Questi messaggi sono contrassegnati nell'interfaccia con l'avviso «NON CIFRATA». La protezione end-to-end vale tra caselle MAILCRIPTY e per i messaggi protetti condivisi tramite link e codice.

I pacchetti dell'app desktop pubblicati sul sito espongono il proprio hash SHA-256, verificabile prima dell'installazione, e gli aggiornamenti sono firmati con Ed25519: l'app rifiuta qualsiasi aggiornamento la cui firma non corrisponda alle chiavi pubbliche note.

Per onestà verso chi valuta il servizio: è pubblico e ispezionabile il modulo crittografico del client, ma non l'intero codice sorgente dell'applicazione, e non è stato completato un audit di sicurezza indipendente di terze parti. Chi tratta dati ad altissimo rischio deve tenerne conto nella propria valutazione. Lo stato dei lavori è descritto nella pagina Sicurezza e audit.

Ricercatori, clienti e revisori possono richiedere dettagli tecnici o segnalare vulnerabilità scrivendo a info@mailcripty.com. Rispondiamo alle segnalazioni di sicurezza con priorità.