Crittografia end-to-end vs zero-knowledge: qual è la differenza?

Q: Da cosa protegge ciascuna?

Risposta rapida. La crittografia end-to-end (E2EE) è una proprietà della comunicazione: solo le due estremità possono leggere il messaggio, gli intermediari no. Lo zero-knowledge è un modello di implementazione per l’archiviazione: il server conserva i tuoi dati crittografati con chiavi che non possiede. La maggior parte dei servizi moderni attenti alla privacy implementa entrambe: Signal è E2EE per la chat, Filarr è zero-knowledge per la sincronizzazione cloud. I due termini si sovrappongono ma non sono sinonimi.

I due termini vengono usati come sinonimi nei testi di marketing, negli articoli dei blog sulla sicurezza e persino negli articoli accademici. Non sono la stessa cosa.

Questo articolo dà la definizione precisa di ciascuno, mostra dove si sovrappongono e dove no, e come valutare le affermazioni sulla crittografia di qualsiasi servizio orientato alla privacy.

Cos’è la crittografia end-to-end (E2EE)?

La crittografia end-to-end è una proprietà dei sistemi di comunicazione. La definizione è semplice: solo le due estremità possono leggere il contenuto; qualsiasi sistema intermedio che gestisce il messaggio non può.

L’esempio canonico è Signal Messenger. Quando invii un messaggio:

Il tuo telefono crittografa il messaggio con una chiave che detiene il telefono del destinatario (e che i server di Signal non hanno)
Il blob crittografato transita dai server di Signal
Il telefono del destinatario lo decrittografa

I server di Signal vedono entrare byte crittografati e uscire byte crittografati. Non vedono mai il testo in chiaro. Anche se volessero, non potrebbero: le chiavi non lasciano mai i dispositivi degli utenti.

L’E2EE non riguarda solo la messaggistica. La stessa proprietà si applica a:

Chiamate vocali e video (Signal, FaceTime, WhatsApp)
Email (Proton Mail, Tutanota)
Condivisione di file (Wormhole, Magic Wormhole, OnionShare)
Modifica collaborativa (alcune alternative a Google Docs capaci di E2EE)

La caratteristica distintiva è sempre la stessa: i dati sono crittografati da un’estremità e decrittografati solo dall’altra. I server nel mezzo sono corrieri ciechi.

Cos’è la crittografia zero-knowledge?

La crittografia zero-knowledge è una proprietà dei servizi di archiviazione. La definizione: il server conserva i tuoi dati crittografati con chiavi che non possiede.

Rispetto all’E2EE, lo zero-knowledge ha una forma diversa:

L’E2EE è una proprietà di una comunicazione uno a uno o uno a molti tra utenti
Lo zero-knowledge è una proprietà del rapporto di un singolo utente con il proprio archivio cloud

L’esempio da manuale è Bitwarden. La cassaforte delle tue password è crittografata sul tuo dispositivo con una chiave derivata dalla tua password principale. La cassaforte crittografata viene caricata sui server di Bitwarden, che conservano un blob opaco. Quando accedi da un altro dispositivo, la tua password principale decrittografa la cassaforte in locale: i server di Bitwarden non la vedono mai.

Altri servizi zero-knowledge: 1Password, Proton Drive, Tutanota Calendar, la sincronizzazione cloud di Filarr, Cryptomator (abbinato a qualsiasi cloud).

Se riformuli lo zero-knowledge come una «comunicazione» tra il te stesso del passato (quando hai caricato i dati) e il te stesso del futuro (quando li scarichi su un nuovo dispositivo), diventa un caso particolare di E2EE. Ma gli schemi di implementazione, i modelli di minaccia e le sfide tecniche sono abbastanza diversi da giustificare un nome diverso.

Dove si sovrappongono E2EE e zero-knowledge?

Nella pratica, i servizi moderni attenti alla privacy spesso implementano entrambe le cose contemporaneamente.

Una tipica app di note crittografate:

Usa lo zero-knowledge per l’archiviazione personale: le tue note sono conservate crittografate sul server, e il server non può leggerle
Usa l’E2EE quando condividi una nota con un altro utente: il link di condivisione o l’invito contiene una chiave crittografata che solo il destinatario può decrittografare

Quindi un solo prodotto può essere entrambe le cose. Filarr, per esempio, è zero-knowledge per l’archiviazione (i tuoi blob crittografati stanno su Cloudflare R2 e i server di Filarr non possono leggerli) ed E2EE per la condivisione (vedi più sotto).

Dove non si sovrappongono?

Tre casi concreti.

E2EE senza zero-knowledge. Un’app di messaggistica che non conserva i messaggi sul server (o li conserva crittografati solo brevemente, per la consegna). Signal è E2EE; il server non conserva quasi nulla.

Zero-knowledge senza E2EE. Una cassaforte personale senza funzioni di condivisione o di comunicazione. Un utente di Bitwarden che lo usa da solo, un utente di Filarr che non condivide nulla: i dati sono crittografati in modo zero-knowledge sul server, ma non c’è un’«altra estremità», perché non c’è comunicazione.

Nessuna delle due. La maggior parte dei servizi cloud. Google Drive crittografa a riposo, ma le chiavi le ha Google. Dropbox lo stesso. iCloud lo stesso (tranne per gli elementi protetti dall’interruttore della Protezione avanzata dei dati di Apple, che è zero-knowledge).

Perché la distinzione conta per gli utenti?

La distinzione conta quando valuti un’affermazione sulla privacy. Considera queste frasi:

«Usiamo la crittografia end-to-end per proteggere i tuoi dati.»

Ha senso per un’app di messaggistica. Per un’app di note o un gestore di password che conserva i dati nel cloud, «crittografia end-to-end» è tecnicamente una forzatura: il termine si applica propriamente alla comunicazione. L’affermazione corretta è «zero-knowledge» o «crittografia lato client senza accesso alle chiavi lato server».

Quando i team di marketing usano «E2EE» per prodotti di archiviazione, nella pratica di solito significa la stessa cosa di zero-knowledge, ma l’uso più vago può nascondere delle lacune. Leggi la documentazione dell’architettura, non la pagina di marketing.

«I tuoi dati sono crittografati in transito e a riposo.»

Questo non dice nulla su chi detiene le chiavi. Un servizio può crittografare a riposo con chiavi che controlla: è la normale sicurezza cloud, non lo zero-knowledge. Chiedi sempre: il servizio detiene una copia della chiave di decrittografia?

«Non condivideremo mai i tuoi dati.»

Una promessa, non una garanzia. Con lo zero-knowledge o l’E2EE, il servizio letteralmente non può condividere i tuoi dati, perché non può leggerli. Senza nessuno dei due, ti fidi del fatto che il servizio mantenga la promessa anche sotto pressione legale.

Da cosa protegge ciascuna?

Minaccia	L’E2EE protegge?	Lo zero-knowledge protegge?	La crittografia lato server protegge?
Intercettazione della rete	✓	✓ (con TLS)	✓ (con TLS)
Server compromesso da hacker	✓	✓	✗ (le chiavi sono sul server)
Il gestore del servizio legge i tuoi dati	✓	✓	✗
Richiesta di un’autorità al servizio	✓	✓	✗
Dipendente con accesso al database	✓	✓	✗
Malware sul tuo dispositivo	✗	✗	✗
Password persa / chiave di recupero persa	✓ ma dati irrecuperabili	✓ ma dati irrecuperabili	✗ (il servizio può reimpostare)

E2EE e zero-knowledge offrono le stesse protezioni dalle minacce nei rispettivi ambiti. La differenza è il cosa (comunicazione contro archiviazione) e il come.

Quali domande fare prima di fidarsi di un servizio?

Una breve checklist quando un servizio dichiara E2EE o zero-knowledge:

Dov’è documentata la derivazione della chiave? Un servizio serio pubblica i parametri della sua KDF (memoria di Argon2id, iterazioni di PBKDF2) nella documentazione di sicurezza o tecnica.
Cosa vede il server? Blob crittografati, va bene. Nomi di file in chiaro? Struttura delle cartelle? Oggetti delle email? Ogni metadato che trapela è un potenziale canale laterale.
Cosa succede quando reimposti la password? Se il servizio può reimpostare la tua password e farti rientrare nei tuoi dati, non è zero-knowledge. Il vero zero-knowledge significa password persa = dati persi (recuperabili solo con il tuo codice di recupero).
Il codice è open source o sottoposto ad audit? Un’affermazione senza prova pubblica è un’affermazione di marketing. Audit indipendenti e codice aperto rendono le affermazioni verificabili.
Come funziona la condivisione? Se il servizio supporta la condivisione, il modello di condivisione dovrebbe preservare l’E2EE: il server non dovrebbe mai vedere in chiaro il contenuto condiviso.

Applica queste domande a qualsiasi servizio crittografato prima di affidargli i tuoi dati.

Dove si colloca Filarr su questa scala?

Filarr è uno spazio di lavoro local-first in cui la sincronizzazione cloud è zero-knowledge. Per riportarlo allo schema qui sopra:

Prima di tutto local-first. I tuoi file vivono crittografati sul tuo disco. Nessun server è coinvolto nel funzionamento dell’app locale: non c’è nessuna «comunicazione» né «archiviazione» che il cloud debba mediare.
Sincronizzazione cloud zero-knowledge. Quando scegli di attivare la sincronizzazione cloud, i tuoi file sono crittografati in AES-256-GCM, con la chiave del tuo account (la FEK) e un valore casuale nuovo per ogni file, e caricati come blob opachi. Il server conserva i blob crittografati, le copie della tua FEK cifrate con la tua password e con la tua frase di recupero, e un hash bcrypt che verifica il tuo accesso; non vede mai la tua FEK in chiaro né alcun contenuto dei file. Dal 16 ottobre 2026 un’app aggiornata accede con una chiave derivata dalla tua password, non con la password stessa. Durante una transizione di circa due mesi, un account che non si è ancora ricollegato, o una vecchia versione dell’app, invia ancora la password (via HTTPS), dove un server compromesso potrebbe intercettarla.
Abbinamento multi-dispositivo. Quando abbini un nuovo dispositivo, il tuo dispositivo esistente invia la tua chiave principale al nuovo dispositivo tramite uno scambio ECDH, crittografata da una chiave di sessione effimera che il server non può ricavare. Il server fa passare i byte della chiave crittografata e non vede nulla di utile.
Condivisione. Da quando questo articolo è stato pubblicato per la prima volta, Filarr ha introdotto la condivisione, ed è E2EE. Un link di condivisione porta la sua chiave dopo il #, che un browser non invia mai al server; la chiave di una cassaforte condivisa è sigillata per la coppia di chiavi personale di ogni membro, e il server la inoltra solo sigillata.

Cosa può vedere il server di Filarr: blob crittografati opachi, dimensioni dei blob, timestamp di sincronizzazione, email dell’account, le copie cifrate della tua chiave, un hash bcrypt che verifica il tuo accesso. Cosa non può vedere: contenuti dei file, nomi dei file, struttura delle cartelle, titoli delle note, i nomi delle casseforti condivise e dei link di condivisione, né la tua chiave in chiaro.

Leggi l’architettura di sicurezza completa di Filarr per i parametri precisi e il modello di minaccia dietro ogni scelta di design.