La crittografia zero-knowledge spiegata in parole semplici

Q: Cosa vede davvero il server in un sistema zero-knowledge?

È la domanda cruciale. Un server non può mai vedere niente: servono sempre dei metadati perché il servizio funzioni. In un sistema zero-knowledge ben progettato, il server vede:

Risposta rapida. La crittografia zero-knowledge è un’architettura in cui il servizio che ospita i tuoi dati non può decrittografarli: la chiave di crittografia non lascia mai il tuo dispositivo in chiaro. Anche se il database del server viene rubato, consegnato in risposta alla richiesta di un’autorità o sfogliato da un amministratore malintenzionato, tutto ciò che contiene sono dati crittografati opachi. La usano Signal, Tutanota, Proton, Bitwarden e la sincronizzazione cloud di Filarr.

Quando un servizio cloud dice «i tuoi dati sono crittografati», di solito è vero ma raramente basta. I dati sono crittografati in transito (TLS) e a riposo (crittografia lato server con chiavi detenute dal servizio). Ma il servizio ha ancora le chiavi. Se vuole leggere i tuoi dati, può farlo. Se un tribunale glielo chiede, lo farà.

La crittografia zero-knowledge è l’architettura che lo rende impossibile per costruzione. Il servizio non può letteralmente leggere i tuoi dati, perché le chiavi per decrittografarli non lasciano mai il tuo dispositivo.

Questo articolo spiega lo zero-knowledge in parole semplici, mostra come funziona in pratica e chiarisce la confusione frequente con la crittografia end-to-end.

Cosa significa crittografia zero-knowledge?

«Zero-knowledge», in questo contesto, è un termine di marketing che prende in prestito il nome di un vero concetto crittografico (le prove a conoscenza zero) e lo usa in senso lato. Il termine tecnico più chiaro è crittografia lato client senza accesso alle chiavi lato server.

La promessa è semplice:

Il tuo dispositivo genera le chiavi di crittografia
Il tuo dispositivo crittografa i tuoi dati prima di inviarli al server
Il server conserva solo blob crittografati e non ha mai le chiavi per decrittografarli
Quando accedi da un altro dispositivo, la tua password (o un segreto derivato) decrittografa le chiavi in locale

Il risultato: il servizio non sa nulla del contenuto dei tuoi dati. Può vedere i metadati (dimensioni dei file, orari di sincronizzazione, indirizzi IP), ma il contenuto in sé gli resta opaco.

In cosa è diversa la crittografia zero-knowledge dalla normale crittografia cloud?

Quasi ogni servizio cloud oggi crittografa i dati a riposo. Dropbox, Google Drive, iCloud, OneDrive: tutti crittografano i tuoi file sui loro server. La domanda cruciale è: chi detiene la chiave?

Modello di crittografia	Il server può decrittografare?	Esempi
Solo TLS (in transito)	Sì, il server conserva il testo in chiaro	Molti piccoli servizi
Crittografia a riposo lato server	Sì, il server detiene la chiave	Dropbox, Google Drive, iCloud (per lo più)
Crittografia lato client, chiave detenuta dal server	Sì (comunque!)	Alcuni servizi «crittografati» in cui il server conserva una copia della chiave master
Zero-knowledge / E2E	No, la chiave è solo sul client	Signal, Proton, Tutanota, Bitwarden, sincronizzazione cloud di Filarr

La crittografia lato server protegge da una sola minaccia: un ladro che ruba i dischi fisici dal data center. Non protegge da chi gestisce il servizio e legge i tuoi dati, dagli hacker che violano il servizio, né dai governi che chiedono al servizio di consegnare i tuoi dati.

Lo zero-knowledge protegge da tutte e tre.

Come funziona davvero la crittografia zero-knowledge?

Il meccanismo è una catena di operazioni eseguite interamente sul tuo dispositivo. Un tipico servizio zero-knowledge per un’app di note funziona così:

SUL TUO DISPOSITIVO                             SUL SERVER
───────────────────                             ──────────

1. Inserisci la tua password
        │
        ▼
2. KDF (PBKDF2 / Argon2id)
   allunga la password in una KEK
        │
        ▼
3. Chiave di crittografia dei file (FEK)
   casuale
        │
        ▼
4. AES-256-GCM(file, FEK) ─────► blob crittografato ──► conservato come byte opachi
        │
        ▼
5. AES-256-GCM(FEK, KEK) ──────► FEK crittografata ──► conservata accanto al blob
        │
        ▼
6. La KEK non lascia mai il dispositivo
   (alcuni servizi caricano una copia
   crittografata della KEK che solo la tua
   password può sbloccare: vedi «recupero
   della chiave» più sotto)

La visione del mondo del server: un flusso di byte opachi. Anche con pieno accesso root al server, un attaccante legge rumore crittografato.

Perché la visione dell’utente abbia senso su più dispositivi, di solito viene caricata anche la KEK crittografata, ma sempre e solo in forma crittografata. Per sbloccarla su un nuovo dispositivo devi reinserire la tua password, e lo sblocco avviene sul dispositivo stesso.

Cosa vede davvero il server in un sistema zero-knowledge?

È la domanda cruciale. Un server non può mai vedere niente: servono sempre dei metadati perché il servizio funzioni. In un sistema zero-knowledge ben progettato, il server vede:

Un blob crittografato opaco per ogni file
La dimensione di ogni blob (entro un margine: alcuni sistemi aggiungono riempimento)
Gli orari di sincronizzazione (quando i blob vengono aggiornati)
L’identificativo del tuo account (di solito un’email o un nome utente)
I metadati di autenticazione (un verificatore della password, mai la password stessa)

Non vede:

Il contenuto dei file
I nomi dei file (i sistemi ben progettati crittografano anche questi)
La struttura delle cartelle (anch’essa crittografata)
I titoli delle note, i tag o qualsiasi metadato interno all’app

Le categorie che trapelano (dimensioni, tempi, email dell’account) costituiscono un rischio di canale laterale: un avversario abbastanza motivato può a volte dedurre informazioni dalle sole dimensioni. Le implementazioni zero-knowledge serie riempiono i blob fino a dimensioni standard e aggiungono variazioni casuali agli orari per attenuare il problema.

Perché lo zero-knowledge conta per i tuoi dati?

Tre scenari concreti. In un’architettura zero-knowledge:

Scenario 1: il servizio viene attaccato. Un attaccante ruba l’intero database. Ottiene blob crittografati e indirizzi email, niente di più. I blob sono inutili senza le chiavi, che stanno sui dispositivi degli utenti.

Scenario 2: il servizio riceve la richiesta di un’autorità. Un governo chiede al servizio di consegnare i dati degli utenti. Il servizio si adegua consegnando ciò che ha: blob crittografati. Nemmeno il governo può decrittografarli.

Scenario 3: un dipendente malintenzionato o negligente. Un amministratore con accesso al database prova a leggere i file degli utenti. Vede byte crittografati. Non può decrittografarli senza la password dell’utente, che il sistema non ha mai conservato.

Il servizio non può letteralmente tradirti, nemmeno se volesse o ne fosse costretto. È questo il valore dello zero-knowledge: il bisogno di fiducia è eliminato dalla matematica, non dalle promesse.

Qual è il costo della crittografia zero-knowledge?

Lo zero-knowledge ha veri compromessi ingegneristici.

1. Password persa significa dati persi. Se il servizio non può decrittografare i tuoi dati, non può nemmeno reimpostare la tua password. La maggior parte dei servizi zero-knowledge offre codici o frasi di recupero, ma se perdi sia la password sia il segreto di recupero, i tuoi dati diventano inaccessibili per sempre. È il costo di una vera privacy.

2. Le funzionalità lato server sono limitate. Il servizio non può cercare nei tuoi dati, non può generare anteprime lato server, non può far riassumere le tue note da un’IA, perché non può vedere nulla. Tutte queste funzionalità devono girare sul tuo dispositivo.

3. La sincronizzazione tra più dispositivi è più difficile. Condividere le chiavi tra i tuoi dispositivi richiede un protocollo di abbinamento accurato (di solito ECDH con derivazione HKDF). Progettarlo correttamente non è banale.

4. La collaborazione in tempo reale è più difficile. Se due utenti modificano lo stesso documento crittografato, l’unione deve avvenire lato client o tramite protocolli crittografici (i CRDT su dati crittografati sono un’area di ricerca attiva).

Sono costi accettati. La garanzia di privacy vale troppo per rinunciarvi in cambio di guadagni marginali in funzionalità.

In cosa lo zero-knowledge è diverso dalla crittografia end-to-end?

I termini vengono spesso usati come sinonimi. Si sovrappongono ma non sono identici.

La crittografia end-to-end (E2E) descrive una proprietà: solo le estremità di una comunicazione possono leggerne il contenuto. Nessun intermediario (server, provider internet) può farlo. L’esempio da manuale è Signal: un messaggio viene crittografato sul tuo telefono, passa dai server di Signal e viene decrittografato solo sul telefono del destinatario.

Lo zero-knowledge è un modello di implementazione per i servizi di archiviazione: il server conserva i tuoi dati crittografati con chiavi che non ha. Si può vedere come E2E applicata a una «comunicazione» tra il tuo io passato (quando hai caricato) e il tuo io futuro (quando scarichi su un altro dispositivo).

La maggior parte dei servizi zero-knowledge implementa anche l’E2E per la condivisione (quando condividi un file con un altro utente, le chiavi vengono scambiate da client a client senza che il server le veda). Ma puoi avere lo zero-knowledge senza condivisione (una cassaforte personale) o l’E2E senza archiviazione (un’app di chat che non conserva la cronologia).

Per un confronto più approfondito, vedi crittografia end-to-end e zero-knowledge: che differenza c’è?.

Quali app usano la crittografia zero-knowledge?

Servizi noti che implementano correttamente lo zero-knowledge:

Signal: messaggistica end-to-end
Bitwarden: gestore di password (zero-knowledge anche per l’archiviazione della cassaforte)
1Password: gestore di password
Proton (Mail, Drive, Calendar): fornitore svizzero, completamente zero-knowledge
Tutanota: email, calendario e contatti crittografati
Standard Notes: note crittografate
Cryptomator: crittografia locale per l’archiviazione cloud
Filarr: spazio di lavoro local-first con sincronizzazione cloud zero-knowledge facoltativa

Servizi che si crede comunemente siano zero-knowledge ma non lo sono: iCloud (Apple detiene le chiavi per la maggior parte dei dati, tranne gli elementi protetti dalla Protezione avanzata dei dati), Dropbox, Google Drive, OneDrive.

Come implementa Filarr lo zero-knowledge?

Filarr è uno spazio di lavoro local-first in cui lo strato di sincronizzazione cloud è zero-knowledge. L’architettura:

I file vivono prima di tutto crittografati sul tuo disco. L’app locale non ha bisogno del cloud per funzionare: è la parte local-first.
Quando attivi la sincronizzazione cloud, il tuo dispositivo crittografa ogni file con AES-256-GCM sotto la FEK del tuo account, con un valore casuale nuovo per ogni file. Vedi KEK e FEK spiegate per la gerarchia delle chiavi.
Il server conserva solo blob crittografati. I dati vivono su Cloudflare R2. Senza la tua password, i blob sono rumore.
L’abbinamento tra dispositivi usa ECDH (Diffie-Hellman su curva ellittica) con chiavi di sessione derivate tramite HKDF per condividere la tua chiave master tra i tuoi dispositivi senza mai esporla al server.
L’accesso al tuo account è passato a una chiave derivata il 16 ottobre 2026: un account nuovo, o uno che ha effettuato l’accesso da allora, invia una chiave derivata sul tuo dispositivo al posto della password. Durante una transizione di circa due mesi, un account che non ha ancora effettuato di nuovo l’accesso, o una versione meno recente di un’app, invia ancora la password via HTTPS, dove viene confrontata con un hash bcrypt e mai conservata.

Il risultato: se domani il nostro database venisse rubato, gli attaccanti otterrebbero rumore crittografato, indirizzi email e chiavi incapsulate che non possono aprire senza la tua password o la tua frase di recupero. Non potrebbero leggere un solo file. Il limite noto era l’accesso stesso, e si sta chiudendo: dal 16 ottobre 2026, l’accesso invia una chiave derivata sul tuo dispositivo. Solo un account che non ha ancora effettuato di nuovo l’accesso, o una versione meno recente dell’app, invia ancora la password durante la transizione, e un server compromesso in quel momento potrebbe intercettarla e, con essa, aprire la tua chiave. Se ricevessimo la richiesta di un’autorità, potremmo consegnare solo ciò che conserviamo, blob crittografati, e non possiamo decrittografarli.

Leggi l’architettura di sicurezza completa di Filarr per i parametri esatti e il modello di minaccia.