Scarica Lattice Pulse

# 1 · il manifest firmato e la chiave pubblica del sito
curl -s https://lattice-network.it/downloads/latest.json -o latest.json
curl -sO https://lattice-network.it/downloads/verify-apk.mjs
curl -s https://lattice-network.it/web-manifest.json | python3 -c "import json,sys;print(json.load(sys.stdin)['pk'])" > pk.hex

# 2 · l'impronta dell'APK che hai scaricato deve coincidere
sha256sum lattice-pulse.apk

# 3 · la firma copre versione, build, indirizzo, impronta e dimensione, in quest'ordine
#     lattice-apk-v1|<versione>|<build>|<url>|<sha256>|<byte>
node verify-apk.mjs latest.json pk.hex lattice-pulse.apk

curl -O https://lattice-network.it/downloads/Dockerfile.verify
curl -O https://lattice-network.it/downloads/verify-apk.sh

docker build -t lattice-verify -f Dockerfile.verify .
docker run --rm --privileged lattice-verify 2.3.2

curl -O https://lattice-network.it/downloads/lattice-pulse-src-2.3.2.tgz
curl -O https://lattice-network.it/downloads/repro-2.3.2.json
tar xzf lattice-pulse-src-2.3.2.tgz && cd lattice-pulse-2.3.2
yarn install --frozen-lockfile
echo "sdk.dir=$ANDROID_HOME" > android/local.properties

# la nostra chiave di firma non è nell'archivio, e non ci sarà: generate la vostra.
# la firma è esclusa dal confronto, quindi non cambia il risultato.
keytool -genkeypair -keystore android/app/debug.keystore -storepass android \
  -keypass android -alias androiddebugkey -keyalg RSA -keysize 2048 \
  -validity 10000 -dname "CN=Android Debug,O=Android,C=US"

bash tools/repro-build.sh /tmp/mio.apk
python3 tools/apkrepro.py check /tmp/mio.apk ../repro-2.3.2.json

1° tentativo   11 voci diverse su 1663   librerie native e dex
2° tentativo    3 voci diverse su 1663   dex e profili ART
3° tentativo    0 voci diverse su 1663   RIPRODUCIBILE          (v2.1.0)
v2.2.0          0 voci diverse su 1662   RIPRODUCIBILE, nucleo Xray compreso
v2.3.0 build 157   1 voce diversa su 1662   resources.arsc: dentro c'era l'IP
                                            della macchina che compila
v2.3.0 build 158   0 voci diverse su 1662   RIPRODUCIBILE da un
                                            container pulito, non dalla nostra cartella

content_sha256    8cb4f342092d81a2039002ba0ca072fc6457bd06faa22e544bb588fcde0e794d
apk_sha256        48f465a7f5c9b77e53ed33b2eb6e4f9cbef4db9904533bf99a818c27d7172159
src_sha256        5aaf50101455645c11cbf68bbe3e00461e88a1548d7d071d7fc183cb855a2dc6
libv2ray.aar      ba84bad0493194eefe8c53df8085bf7e34e260483b4d92772a873cd82c07ae33   (compilato da noi)
firma APK         RSA 4096 · SHA-256 del certificato
                  45:11:53:AA:02:9A:67:B9:61:29:DA:64:76:27:3B:3D:9E:6F:A4:34:25:2F:CD:2C:8E:17:2B:9D:8D:AF:F1:C3
SOURCE_DATE_EPOCH 1757000000

Documentazione · 1 / 3

L'ecosistema Lattice

Lattice non è una singola app: è una rete con quattro pezzi, di cui solo uno è nostro e quell'uno è progettato per essere il meno informato di tutti. Qui c'è tutto quello che fa, senza sconti: se un pezzo ha un limite, il limite è scritto.

I quattro pezzi

Pezzo	Che cos'è	Chi lo controlla
Lattice Pulse	L'app Android che scarichi qui. Dentro c'è tutta la crittografia: chiavi, cifratura, decifratura, firma. Il testo in chiaro non esce mai da questo perimetro.	Il tuo telefono
Il relay	Il nostro server (Rust/Axum + MongoDB). Fa il postino di buste chiuse e il tabellone dove depositare la propria chiave pubblica. Non ha le chiavi private di nessuno.	Noi — ma cieco
Nodo Sovrano	La rete mesh fra telefoni vicini: Wi-Fi, Wi-Fi Direct e Bluetooth LE. Instrada a cipolla su 4 salti ibridi (ML-KEM-768 + X25519 per strato), con pacchetti tutti della stessa dimensione, e dentro trasporta le stesse buste del triplo ratchet. Funziona a internet spento. sperimentale	Nessuno: sono i telefoni
Canale on-premise	Per le aziende: lo stesso relay installato sui server del cliente, così le buste non passano nemmeno da noi.	Il cliente

Cosa sa fare l'app

Funzione	Come è protetta
Chat 1 a 1	Cifratura end-to-end con triplo ratchet ibrido: una chiave nuova per ogni messaggio, una chiave nuova su curva X25519 a ogni cambio di turno e una radice nuova ML-KEM-768 ogni pochi turni. Per leggere una riga servono rotte entrambe le matematiche. Chi copia il tuo telefono viene tagliato fuori dopo un solo scambio.
Gruppi	Una busta cifrata per ciascun destinatario (nessuna chiave di gruppo condivisa da revocare): chi esce dal gruppo non riceve più nulla, senza rinegoziare niente.
Canali broadcast	Chiave di canale AES-256 imbustata con ML-KEM-768 per ogni iscritto. Il server distribuisce il testo cifrato e non conosce la chiave.
Foto, file, note vocali	Cifrati sul telefono con AES-256-GCM prima del caricamento. Il server conserva un blocco opaco: non può generare anteprime né vedere il tipo di contenuto.
Chiamate audio/video	WebRTC punto-a-punto con DTLS-SRTP. Le offerte di sessione (SDP) sono firmate con ML-DSA-65, quindi il server non può inserirsi come terzo ascoltatore. Se la rete impone un relay, il TURN vede pacchetti cifrati.
Verifica del contatto	QR code e numero di sicurezza a 60 cifre derivato dalle impronte delle due identità: se i numeri combaciano, nessuno si è messo in mezzo.
PIN, PIN di panico, autodistruzione	Il database locale è cifrato con una chiave legata al dispositivo. Il PIN di panico sblocca un profilo innocuo e cancella il vero. Con l'autodistruzione le chiavi vengono azzerate e i dispositivi revocati sul server.
Backup cifrato	Archivio esportabile, chiave derivata dalla tua password con scrypt (N=2¹⁴, r=8, p=1) e contenuto in AES-256-GCM. La password non lascia il telefono e non esiste alcun recupero: se la perdi, il backup è definitivamente illeggibile.
Nodo Sovrano, Ponte, Corriere	Chat sulla mesh senza internet, con lo stesso triplo ratchet delle chat via server: una chiave nuova per ogni messaggio anche qui. Se un vicino ha rete la tua busta esce da lui (Ponte); se nessuno ce l'ha, un vicino la porta con sé sigillata e la consegna quando ritrova la rete (Corriere).
Aggiornamenti	Nessun Play Store. Il manifest latest.json è firmato con ML-DSA-65: l'app rifiuta ogni APK la cui firma o impronta SHA-256 non combacia.

Documentazione · 2 / 3

Cosa protegge, e cosa no

Un modello di minaccia serve a poco se elenca solo le vittorie. Questa tabella dice, per ogni avversario, se Lattice regge ✔, se regge in parte ~ o se non vi protegge ✘.

Avversario	Esito	Perché
Chi ascolta la rete (Wi-Fi, operatore, ISP)	✔	Tutto è dentro TLS e, sotto, già cifrato end-to-end. Il traffico è indistinguibile dal rumore e le dimensioni sono normalizzate.
Il nostro server, o chi ce lo sequestra	✔	Il server non ha chiavi private: conserva buste opache e chiavi pubbliche. Nessun IP registrato, nessun log dei contenuti, nessuna rubrica caricata, nessun hash di password da rubare. Quello che sa lo trovate due righe più sotto, alla voce grafo sociale.
Un computer quantistico (anche fra 15 anni)	✔	Nessuna curva ellittica nella riservatezza dei messaggi: chiavi e sessioni usano ML-KEM-768, le firme ML-DSA-65. Chi registra oggi il traffico per decifrarlo domani non ci riesce.
Uno che si mette in mezzo (MITM sulle chiavi)	~	Le chiavi pubbliche arrivano dal nostro tabellone: se il server mentisse, potrebbe darvi una chiave sbagliata. È esattamente per questo che esiste il numero di sicurezza: verificate il contatto una volta e l'inganno diventa impossibile.
Chi ti prende il telefono sbloccato in mano	✘	Nessuna crittografia salva un dispositivo già aperto. Mitigazioni: PIN, PIN di panico, blocco automatico, autodistruzione.
Chi vuole ricostruire il tuo grafo sociale	~	Per consegnare un messaggio il relay deve sapere a chi consegnarlo: nei record nuovi l'indirizzo di chi scrive non c'è più (resta solo un indice fra i partecipanti), ma la coppia che conversa il server la conosce. Non i contenuti, non i nomi dei gruppi, non gli allegati: chi parla con chi. Chi non vuole nemmeno questo ha tre strade reali, tutte già nel prodotto: la cassetta postale anonima (qui sotto), il canale on-premise dove il relay è vostro, e il Nodo Sovrano dove non c'è nessun relay. Lo scriviamo perché è l'unica cosa che il nostro server sa di voi.
Chi vuole sapere che usi Lattice	✘	Il tuo indirizzo IP contatta un nostro server: chi osserva la tua linea vede che parli con lattice-network.it. Il contenuto no, il fatto sì. Il tunnel offuscato riduce il problema ma non lo elimina.
Analisi dei tempi sulla mesh locale	~	Su una Wi-Fi condivisa un osservatore può seguire in parte le cadenze degli inoltri. Le abbiamo rese casuali e aggiungiamo traffico di copertura, e da questa versione nemmeno la destinazione di uno strato è più leggibile senza rompere due matematiche — ma il problema dei tempi non è risolto: per questo il Nodo Sovrano resta sperimentale.
Chi ti costringe a consegnare la password	✘	Nessun software risolve la coercizione. Il PIN di panico è una risposta parziale e va preparata prima, non dopo.

Cosa non promettiamo: non abbiamo ancora un audit esterno indipendente pubblicato, e la nostra crittografia non è ibrida (non affianca cioè una curva classica a ML-KEM). Sono le due cose su cui stiamo lavorando, e le trovate scritte anche nella roadmap qui sotto.

Documentazione · 3 / 3

Specifiche del protocollo

Questa è la specifica reale, quella che corrisponde al codice pubblicato in questa versione. Ogni numero qui sotto è verificabile: sono le stesse costanti che trovate nei moduli crypto.js, ratchetCore.js e mesh/onion.js dentro l'APK.

Primitive crittografiche

Scopo	Algoritmo	Parametri
Apertura sessione	ML-KEM-1024 (FIPS 203)	pk 1568 B · ct 1568 B — NIST livello 5, il massimo previsto dallo standard. Protegge la radice, cioè il segreto più longevo: si paga una volta per sessione
Passo del ratchet	ML-KEM-768 (FIPS 203)	pk 1184 B · ct 1088 B · segreto 32 B — NIST livello 3, rifatto ogni pochi turni: qui il parametro alto sarebbe banda buttata
Firme	ML-DSA-65 (FIPS 204)	pk 1952 B · firma 3309 B — NIST livello 3
Cifratura autenticata	AES-256-GCM	IV 96 bit casuale · tag 128 bit · AAD sull'intestazione
Derivazione di chiavi	HKDF-SHA-256	etichette di dominio separate per radice, catena e aggancio
Impronte e ID	SHA-256 / SHA-512	ID nodo mesh = primi 16 B di SHA-256(pk)
Password del backup	scrypt	N=2¹⁴, r=8, p=1 → 32 B

Nessun RSA, nessun Diffie-Hellman su curve nella riservatezza dei messaggi. La libreria è @noble/post-quantum, implementazione pura in JavaScript senza codice nativo opaco.

Identità e accesso

L'identità di un utente è una coppia di chiavi ML-DSA-65 generata sul telefono: la privata non viene mai trasmessa, e sta nel file chiave che l'utente custodisce. L'accesso non usa password: il server manda un nonce casuale, il telefono lo firma, il server verifica la firma con la chiave pubblica che ha in archivio. Non esiste quindi alcun hash di password da rubare, e un archivio del server compromesso non permette a nessuno di autenticarsi come voi.

Ogni telefono registra inoltre una propria chiave di dispositivo ML-KEM-768 più un fondo di chiavi usa-e-getta. Un dispositivo revocato o inattivo viene ripulito automaticamente insieme alle sue chiavi orfane.

Handshake ibrido (in stile PQXDH)

L'apertura di una sessione mescola due segreti di natura diversa: un'incapsulazione ML-KEM-768 sulla chiave d'identità post-quantistica del destinatario e un Diffie-Hellman X25519 effimero contro la sua chiave d'identità su curva. I due segreti vengono concatenati e passati a HKDF: per ricostruire la radice bisogna rompere entrambi i mondi, i reticoli e le curve ellittiche. È la ragione per cui esiste PQXDH, ed è la ragione per cui l'abbiamo adottato: ML-KEM è una primitiva del 2024, e non riteniamo prudente appoggiarci solo a lei.

La radice iniziale è inoltre legata alla trascrizione: dipende dall'identità di chi riceve, dall'identificativo della chiave usa-e-getta consumata, dai cifrati e dal dispositivo mittente. Un incapsulamento catturato non è riutilizzabile in nessun altro contesto — niente unknown key-share, niente riuso in una sessione diversa.

La chiave usa-e-getta viene distrutta nell'istante in cui ha aperto la sessione, non dopo giorni. È la differenza fra forward secrecy adesso e forward secrecy fra una settimana.

E l'apertura usa ML-KEM-1024, il livello NIST 5: il parametro più alto che lo standard definisce. Non è simmetria estetica, è dove va messo il margine — la radice sopravvive a tutta la conversazione, mentre un passo del ratchet vive pochi turni e lì il livello 3 è la scelta giusta. La chiave di livello 5 nasce dallo stesso segreto d'identità con un'etichetta diversa: niente in più da custodire, e il numero di sicurezza non cambia, così chi si è già verificato non vede falsi allarmi. Il livello dichiarato è coperto dal dato autenticato della busta: farlo scendere per strada fa fallire la decifratura, non declassa la sessione in silenzio. Con chi ha una versione precedente si resta a 768, come prima.

Apertura della sessione
  ss1   = ML-KEM-1024.Encaps(IK_kem_destinatario)        -> ct1   (livello NIST 5)
  ss2   = X25519(eph_mittente, IK_curva_destinatario)    -> epk
  tr    = "…init-v2" | H(IK_kem_dest ‖ IK_curva_dest) | pk_id | ct1 | epk | dev_mittente
  rk    = HKDF-SHA256(ikm = ss1 ‖ ss2, info = tr)

Triplo ratchet ibrido

Tre catene lavorano insieme, e ognuna risolve un problema diverso.

Catena	Cadenza	Che cosa garantisce
Simmetrica HKDF-SHA-256	ogni messaggio	Forward secrecy. La chiave del messaggio viene usata una volta e cancellata: quella di ieri non esiste più da nessuna parte.
Su curva X25519	ogni cambio di turno	Post-compromise security continua. Chi ha copiato il telefono viene tagliato fuori dopo un solo scambio. Costa 32 byte: si può fare sempre.
Post-quantistica ML-KEM-768	ogni pochi turni	Rinnovo post-quantistico. Costa 2,6 KB fra chiave e cifrato: farlo per scrivere «ok» sarebbe uno spreco. La sua eredità resta però dentro la radice per sempre.

Turno nuovo (a ogni cambio di direzione)
  (xpk, xsk)  = X25519.KeyGen()                          -> xpk nell'intestazione (32 B)
  ssX         = X25519(xsk, xpk_altro)
  ssKem       = ML-KEM-768.Encaps(pk_altro)              -> solo nei turni post-quantistici
  rk' , ck    = HKDF-SHA256(ikm = ssKem ‖ ssX, salt = rk, info = "…root-v2", 64 B)

Ogni messaggio
  ck' , mk    = HKDF-SHA256(ck, info = "…chain-v2", 64 B)
  busta       = AES-256-GCM(mk, iv, AAD = intera intestazione).Encrypt(testo)
  mk viene usata una volta sola e cancellata

Una precisazione che conta, e la diciamo per non essere fraintesi: la riservatezza è sempre ibrida, anche nei turni in cui il passo ML-KEM non viene rifatto, perché il suo segreto è già cotto dentro la radice e la radice non dimentica nulla. Quello che è rado è soltanto la velocità di rinnovo post-quantistica, cioè quanto tempo un intruso post-quantistico resta dentro dopo aver copiato il telefono: al massimo tre turni o venti minuti, non uno solo. Contro un intruso classico il taglio resta immediato, a ogni singolo turno.

Intestazione: perché i byte sono un problema di sicurezza

Una chiave pubblica ML-KEM-768 pesa 1184 byte, un cifrato 1088. Trasmetterli in ogni messaggio, in esadecimale, portava una riga di testo a 11.477 byte. Quando una busta del genere deve viaggiare sulla mesh — cioè con il Ponte o il Corriere, dove un pacchetto è di 8192 byte fissi con 3652 byte utili — significava spezzare un singolo messaggio in quattro pacchetti, ognuno con quattro salti: sedici trasmissioni radio per dire «arrivo». Più frammenti, più probabilità di perderne uno, più occasioni per un osservatore.

Messaggio di testo	Peso	Pacchetti mesh
Ratchet precedente (v1)	11.477 byte	4
Triplo ratchet, turno post-quantistico	3.259 byte	1
Triplo ratchet, turno normale	191 byte	1

Come: la chiave ML-KEM non viaggia più in ogni messaggio ma si richiama con un'impronta da 8 byte, e tutto passa da esadecimale a base64. E una proprietà che ci teniamo stretta: ogni messaggio porta con sé tutto il necessario per aprirsi. Non esiste un «messaggio chiave» che, perdendosi, blocca la catena — i messaggi possono arrivare in qualunque ordine, che è esattamente quello che succede su una radio.

Fuori ordine e perdite: fino a 300 messaggi possono essere scavalcati in un colpo e 600 chiavi restano da parte per i ritardatari. Una sessione desincronizzata viene riagganciata automaticamente dalla catena di guarigione, invece di lasciare messaggi illeggibili.

Compatibilità fra versioni

Ogni dispositivo annuncia le proprie capacità. Se il telefono dell'altro sa fare l'ibrido e la sua chiave su curva è disponibile, si usa il triplo ratchet (rat2). Altrimenti si scende al ratchet post-quantistico puro (rat1), che è ciò che c'era prima — mai a nulla di più debole, e mai al silenzio. Chi ha una versione molto vecchia riceve ancora le buste a chiave usa-e-getta. Il livello effettivo di ogni chat è scritto nella schermata di verifica del contatto, dentro l'app: non ve lo chiediamo per fede.

Gruppi e canali

I gruppi non usano una chiave condivisa: ogni messaggio viene cifrato una volta per ciascun destinatario con la sua sessione a doppio ratchet. Costa più banda, ma dà due proprietà che una chiave di gruppo non può dare: chi esce non può leggere il futuro senza che si debba rinegoziare nulla, e la compromissione di un membro non espone gli altri. I canali broadcast, dove i destinatari sono migliaia, usano invece una chiave AES-256 di canale imbustata con ML-KEM-768 per ogni iscritto.

Mesh: instradamento a cipolla ibrida (v3)

Con il Nodo Sovrano attivo i telefoni si trovano da soli su Wi-Fi (UDP broadcast), Wi-Fi Direct e Bluetooth LE, e si scambiano pacchetti senza alcun server. Le chiavi mesh — sia quella ML-KEM sia quella su curva — sono derivate dall'identità: nessuna chiave in più da custodire. L'ID pubblico di un nodo resta un'impronta a 16 byte della sola chiave ML-KEM, così un telefono aggiornato e uno vecchio continuano a riconoscersi e la rete non si spacca in due.

Formato del pacchetto — invariabile
  dimensione        8192 byte, sempre, per ogni tratta
  salti             4 (3 relay + il nodo che consegna)
  per strato        ct ML-KEM-768 1088 B + curva effimera X25519 32 B + IV 12 B
                    cifrato: next(16) + flag(1) + len(2) + tag(16)
  chiave di strato  HKDF-SHA256( ss_MLKEM ‖ ss_X25519 , info = "…mesh-onion-v3" )
  contenuto utile   3524 byte, sempre a lunghezza fissa
  riempimento       byte casuali, indistinguibili dal cifrato

Ogni relay sa esattamente due cose: da chi ha ricevuto lo strato e a quale ID consegnarlo. Non sa quanti salti sono passati, quanti ne restano, quanto è lungo il messaggio, né chi sia il mittente. E da questa versione, per sapere anche solo a chi è diretto uno strato servono rotte entrambe le matematiche: chi registra oggi il traffico radio per ricostruirlo domani con un computer quantistico deve anche rompere le curve ellittiche, e viceversa. Il prezzo è 32 byte per strato — 128 su 8192, cioè 128 byte di contenuto utile in meno. Le cadenze di inoltro sono randomizzate e viene generato traffico di copertura per attenuare l'analisi dei tempi.

Se anche un solo salto del percorso ha una versione precedente dell'app, l'intero pacchetto scende alla cipolla post-quantistica pura: un percorso a geometria mista non esiste, sarebbe un pacchetto con due forme diverse. Un nodo aggiornato apre comunque anche gli strati vecchio stile.

Il triplo ratchet viaggia anche sulla mesh

Fino alla versione 1.8.0 questo era il punto più debole di tutto il sistema, e lo scrivevamo: sulla rete locale il testo era protetto soltanto dalla chiave mesh del destinatario, che nasce dalla sua identità e non ruota mai. Nessuna forward secrecy, nessuna auto-guarigione: chi avesse copiato un telefono avrebbe letto tutto il traffico mesh passato e futuro.

Adesso dentro la cipolla c'è la stessa busta del triplo ratchet ibrido che passerebbe dal server. Una chiave nuova per ogni messaggio, una curva nuova a ogni turno, una radice post-quantistica rinnovata. È diventato possibile solo grazie all'intestazione snella della 1.8.0: una busta a regime pesa ~200 byte invece di 11,5 KB, e in un pacchetto mesh ci sta. Prima non ci sarebbe entrata.

Quando la busta non ci sta — succede al primo messaggio, quello che porta l'aggancio della sessione, perché contiene tre pezzi di materiale crittografico — viene spezzata in pezzi, ognuno dentro la sua cipolla e per la sua strada, e ricomposta a destinazione. I pezzi vivono solo in memoria e scadono in cinque minuti: sul telefono non resta nulla. Per i relay sono pacchetti da 8192 byte come tutti gli altri.

Cosa resta fuori, e lo diciamo: sulla mesh viaggia il testo. Foto, file e note vocali richiedono ancora il server. E se una sessione ratchet non esiste ancora — un contatto con cui non si è mai scambiato niente, e nessuna rete per aprirla — il messaggio parte comunque col formato precedente invece di restare a terra: mai il silenzio, mai qualcosa di più debole di quello che c'era prima.

Ponte Internet e Corriere Offline

Servono a un caso preciso: tu non hai rete, il destinatario è lontano. La busta è già cifrata punto-a-punto, quindi può viaggiare in mano a chiunque.

Situazione	Cosa accade
Ponte un vicino ha internet	La busta parte sulla mesh come cipolla a 4 salti verso quel vicino, che la spinge al relay con un ticket anonimo prenotato in precedenza dal mittente. Consegna immediata.
Corriere nessuno ha internet	La busta viene affidata a un vicino qualsiasi, che la prende in custodia sigillata e la consegna appena ritrova una connessione: anche ore dopo, anche chilometri più in là.

Cosa non può fare chi vi trasporta: leggere il messaggio (è cifrato per il destinatario), sapere chi sia il mittente o il destinatario (non appaiono nel pacchetto), alterare la busta (l'AAD del ratchet non tornerebbe), o fingere di aver consegnato. Nel suo telefono resta solo un numero: quanti pacchetti sta portando. Il ticket è un gettone di spedizione anonimo che non contiene l'identità di chi lo ha chiesto. Limiti volutamente severi perché nessuno possa usare il vostro telefono come deposito: massimo 20 pacchetti in custodia, scadenza a 24 ore, poi vengono buttati. Gli allegati non passano da qui: restano al server, la mesh trasporta solo testo.

Sigillo del mittente: la cassetta postale anonima

Alla voce «grafo sociale» qui sopra abbiamo scritto che il relay conosce la coppia che conversa. Questa è la risposta, e non è una promessa: è una modalità che si accende.

Con la cassetta anonima i messaggi non partono più a nome del tuo account. Vengono depositati a un indirizzo casuale — una cassetta che non è collegata alla tua identità — usando gettoni monouso che il tuo contatto ti consegna dentro la chat già cifrata. Il deposito avviene senza autenticarsi: il server non ha nulla a cui associarlo.

Cosa il server vede di un deposito
Il testo del messaggio	✘ mai
L'indirizzo Lattice di chi scrive	✘ mai
L'indirizzo Lattice di chi riceve	✘ mai
L'identificativo della conversazione	✘ mai
L'identificativo del dispositivo	✘ mai
Che due account Lattice si stiano parlando	✘ mai
Un gettone monouso e un blocco opaco	✔ questo, e nient'altro

Due depositi consecutivi non hanno un solo byte in comune: gettone diverso, incapsulazione diversa, cifrato diverso, e nessun campo che permetta di metterli in fila. Un gettone speso non si può riusare. Le notifiche sono agganciate alla cassetta e non alla tua identità, quindi il telefono si sveglia senza che il server sappia di chi è l'account.

Fino alla versione 2.0.0 questa modalità aveva un prezzo che abbiamo sempre dichiarato: dentro la busta anonima viaggiava la cifratura a colpo singolo, quindi accenderla significava rinunciare al ratchet. Adesso dentro il deposito c'è la stessa busta del triplo ratchet ibrido di tutte le altre chat: chiave nuova per ogni messaggio, curva nuova a ogni turno, auto-guarigione. Accenderla non costa più nulla in robustezza.

Cosa resta visibile, perché va detto: il primo scambio di gettoni passa dalla chat normale. Il server vede una volta che vi siete scritti, e da quel momento in poi la conversazione diventa opaca e ogni messaggio successivo è inaccostabile agli altri. È una modalità da accendere su entrambi i telefoni, in «PIN app e autodistruzione»: la teniamo volontaria perché cambia il modo in cui i messaggi vengono consegnati, e una cosa così non si accende alle spalle di chi la usa.

Rotazione delle chiavi d'aggancio

Il problema: la chiave con cui gli altri aprono una conversazione nuova con voi protegge la radice di quella conversazione, cioè il segreto più longevo che esiste, e resta esposta su un tabellone pubblico per tutta la sua vita. Ma non si può cambiare l'identità per ricambiarla: il numero di sicurezza cambierebbe, e ogni contatto che vi ha verificato vedrebbe un allarme. È il motivo per cui, in pratica, nessuno la ruota mai.

La soluzione è separare le due cose. L'identità — ML-DSA-65 per le firme, la ML-KEM-768 e la curva X25519 su cui si calcolano numero di sicurezza e codice QR — resta ferma alla generazione 0 per sempre. Accanto, si pubblica una coppia di chiavi d'aggancio (X25519 + ML-KEM-1024) che porta un contatore di generazione e si ricambia da sola ogni trenta giorni, oppure a mano quando volete, da «Chiavi d'aggancio» nelle impostazioni.

Ogni generazione è derivata dal segreto d'identità con una separazione di dominio sul numero di generazione: non se ne conserva nessuna, si rifanno quando servono. Sul filo non viaggia quale generazione è stata usata: chi riceve prova la corrente e le sei precedenti (circa mezzo anno per chi è stato offline) e vince quella che apre. Serve una nota, perché è un errore facile: ML-KEM non fallisce mai la decapsulazione — con la chiave sbagliata restituisce un segreto pseudocasuale, senza dire niente. Quindi la generazione giusta non si riconosce dalla decapsulazione, ma solo aprendo per davvero il primo messaggio: il tentativo si fa su una copia dello stato, e nessun campo in più finisce nella busta. Un tentativo in più su una conversazione nuova, zero informazioni regalate a chi guarda.

Il limite, detto chiaro: siccome le generazioni sono derivate dal segreto d'identità, chi rubasse il vostro file chiave otterrebbe tutte le generazioni, passate e future. La rotazione accorcia la vita di una chiave pubblicata e riduce quanto vale registrare traffico oggi sperando di romperlo domani; non sostituisce la custodia del file chiave, e non difende un telefono già compromesso. Contro quello lavora il ratchet, che ricambia le chiavi a ogni turno.

Gruppi sulla mesh

Il problema, in un gruppo offline, è banale e fastidioso: cinque membri, quattro a portata di radio e uno lontano. Prima non partiva niente per nessuno — la consegna era tutto-o-niente, e un solo membro assente bloccava il messaggio anche per chi era nella stessa stanza.

Adesso la consegna è per destinatario. Chi si è presentato sulla mesh riceve subito. Chi non si è mai presentato torna al ponte o alla coda, ma con solo le sue buste: ogni busta porta scritto per chi è, quindi ridurre l'elenco è esatto e nessuno riceve il messaggio due volte.

E poi il passaparola. La copia destinata a un membro che non si vede adesso viene affidata a un membro che si vede: appena quello incrocia il destinatario, gliela consegna. Non è una funzione nuova del protocollo, è la custodia del corriere applicata dentro un gruppo. Chi fa da corriere vede il nome del destinatario — ma è nel gruppo, quindi lo sapeva già — e un blocco di byte che non può leggere (il contenuto è cifrato col ratchet fra mittente e destinatario) né modificare (il sigillo è calcolato col segreto mesh di quella coppia, che lui non ha). Se la stessa copia arriva sia per via diretta sia per passaparola, il destinatario ne tiene una: il doppione si riconosce dal sigillo, identico. La custodia ha un tetto di 40 copie e scade dopo 12 ore, così nessuno può usare il telefono di un altro come magazzino.

Un dettaglio che il banco di prova ha scovato e che vale la pena raccontare, perché è il tipo di errore che si scrive senza accorgersene: il passaparola, così com'era, avrebbe potuto trasportare anche il formato precedente (v1), il cui corpo è protetto dai soli strati della cipolla. Ma il membro-corriere sbuccia il suo strato — quindi lo avrebbe letto. Adesso la custodia si affida solo alle buste del ratchet. Un messaggio in chiaro non si dà a nessuno, nemmeno a un membro del gruppo: meglio che resti in coda.

Dopo la dogana

Il caso non è ipotetico: il telefono è stato fuori dalle vostre mani. Un controllo alla frontiera, un fermo, un albergo. Chi l'ha avuto in mano può aver copiato dei file, e i file si copiano. Due cose, in particolare, valgono la fatica: lo stato delle sessioni e i segreti delle chiavi usa-e-getta non ancora consumate, che stanno sul telefono per definizione.

Un tocco, sei passaggi, in quest'ordine — e l'ordine non è arbitrario:

1. Usa-e-getta bruciate. Prima di tutto, perché sono la cosa più preziosa da copiare: il telefono dichiara al server di non possederne più nessuna, il server butta le pubbliche, e ne viene pubblicato un lotto nuovo.
2. Chiavi d'aggancio ruotate. Generazione nuova, X25519 + ML-KEM-1024. Prima di azzerare le sessioni, così le sessioni nuove nascono già sulle chiavi nuove.
3. Sessioni azzerate. Ogni conversazione riparte da una radice nuova: lo stato copiato non apre più niente da adesso in avanti.
4. Chiavi dei contatti buttate dalla cassaforte locale e riscaricate. Va insieme al punto precedente: se si buttassero le sessioni tenendo le chiavi in cassaforte, una chiave falsa infilata mentre il telefono era via resterebbe lì a fare danno.
5. Contatti verificati ricontrollati. È il passaggio che conta davvero, e viene per forza dopo il punto 4: le impronte vengono ricalcolate su chiavi appena scaricate, e ogni contatto che era verificato e ora non combacia più viene nominato.
6. File decifrati nella cache cancellati: foto, video, documenti aperti, esportazioni.

Cronologia, identità e numero di sicurezza non si toccano. Un passaggio che fallisce (niente rete) non ferma gli altri e finisce nella ricevuta col suo nome, invece di sparire.

Il limite, dichiarato dentro la schermata stessa: l'identità ML-DSA-65 non si rifà, perché cambiarla vorrebbe dire cambiare numero di sicurezza e far scattare un allarme a ogni contatto verificato. Quindi se il sospetto è che vi abbiano copiato IL FILE CHIAVE, o che il telefono sia stato modificato a livello di sistema, quel pulsante non basta: serve l'autodistruzione e un'identità nuova su un telefono diverso.

Aggiornamenti verificabili

L'APK non passa da nessuno store. Il manifest degli aggiornamenti contiene versione, dimensione e impronta SHA-256, ed è firmato con ML-DSA-65 dalla chiave di produzione: l'app scarica, ricalcola l'impronta e verifica la firma, e rifiuta il file se una delle due non combacia. Potete rifare la stessa verifica a mano con sha256sum, ed è il motivo per cui l'impronta sta scritta in cima a questa pagina.

Roadmap crittografica — cosa manca ancora

Voce	Stato	Cosa cambierebbe
Ratchet ibrido (curva + post-quantistico)	fatto · v1.8.0	X25519 accanto a ML-KEM in handshake e a ogni turno: per leggervi servono rotti entrambi.
Aggancio legato alla trascrizione	fatto · v1.8.0	La radice iniziale dipende da identità, chiave usa-e-getta e cifrati. La usa-e-getta viene distrutta all'istante, non dopo giorni.
Passo post-quantistico rado	fatto · v1.8.0	Il costo ML-KEM si paga ogni pochi turni invece che a ogni messaggio: 191 byte per una riga di testo invece di 11.477.
Cipolla mesh ibrida (v3)	fatto · v1.9.0	ML-KEM-768 + X25519 in ognuno dei quattro strati. Costo reale: 128 byte su 8192.
Ratchet sulla chat mesh	fatto · v1.9.0	Era l'ultimo punto in cui la chiave non ruotava mai. Adesso sulla mesh viaggia la stessa busta del triplo ratchet, con frammentazione quando serve.
Allegati sulla mesh	in valutazione	Note vocali e immagini spezzate in pacchetti mesh. La frammentazione ora esiste: è il pezzo che mancava.
Rotazione delle chiavi d'aggancio	fatto · v2.1.0	Curva X25519 e ML-KEM-1024 d'aggancio ruotano ogni trenta giorni, o a mano. Identità, numero di sicurezza e codice QR non si muovono: chi vi ha verificato non vede allarmi.
ML-KEM-1024 nell'aggancio	fatto · v2.0.0	Livello NIST 5 dove protegge la radice. Numero di sicurezza invariato, nessun declassamento possibile per strada.
Sigillo mittente col ratchet dentro	fatto · v2.0.0	La cassetta anonima ora trasporta il triplo ratchet invece della cifratura a colpo singolo: accenderla non costa più robustezza.
Sigillo mittente acceso di serie	dopo le prove sul campo	Cambia il modo in cui i messaggi vengono consegnati: prima va provato in mano alle persone, poi si valuta se diventi il modo normale di funzionare.
Chat di gruppo sulla mesh	fatto · v2.2.0	Consegna per destinatario invece di tutto-o-niente, e passaparola: la copia di chi non si vede la porta un membro che si vede. Sulla mesh passa solo testo, per scelta: allegati e vocali hanno bisogno dei blob sul server, e una radio locale non è il posto dove spingere megabyte. Il P2P serve a far arrivare le parole quando non c'è altro.
Compilare libv2ray.aar dal sorgente	fatto · v2.2.0	Il nucleo Xray si compila da sorgente con Go e gomobile a ogni build, e due compilazioni danno lo stesso file. Zero binari importati dentro l'APK.
Build riproducibili	fatto · v2.1.0	Due compilazioni indipendenti dello stesso sorgente danno 1.663 voci identiche byte per byte. Si pubblica il content_sha256 di ogni versione e lo strumento che dice quale voce non combacia. La differenza fra fidarsi e verificare.
Audit esterno indipendente	non ancora	Finché non c'è, l'unica garanzia che possiamo darvi è il codice verificabile e le prove automatiche che pubblichiamo. Lo diciamo, invece di far finta.