{"id":59,"date":"2026-06-11T16:45:09","date_gmt":"2026-06-11T16:45:09","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/11\/crittografia-end-to-end-nodejs\/"},"modified":"2026-06-11T16:45:09","modified_gmt":"2026-06-11T16:45:09","slug":"crittografia-end-to-end-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/11\/crittografia-end-to-end-nodejs\/","title":{"rendered":"Crittografia End-to-End in Node.js: 12 Step [2026]"},"content":{"rendered":"\n

La crittografia end-to-end<\/strong> non \u00e8 pi\u00f9 un argomento riservato ai team di Signal o WhatsApp. Nel 2026 qualsiasi sviluppatore che gestisce messaggi privati, documenti sanitari, dati finanziari o backup degli utenti deve sapere come implementarla. Questo tutorial ti guida passo dopo passo nella costruzione di un sistema di crittografia end-to-end<\/strong> funzionante in Node.js, usando libsodium<\/code>, lo scambio di chiavi X25519 e la cifratura autenticata XChaCha20-Poly1305. Al termine avrai un progetto completo, testabile e pronto a essere adattato in produzione, con una sezione finale dedicata alla migrazione post-quantum.<\/p>\n\n\n\n

Aggiornato all’11 giugno 2026. Tempo di completamento stimato: 60-90 minuti. Livello: intermedio (serve confidenza con JavaScript asincrono e con la riga di comando).<\/p>\n\n\n\n

Cos’\u00e8 la crittografia end-to-end e perch\u00e9 conta nel 2026<\/h2>\n\n\n\n

La crittografia end-to-end<\/strong> (in inglese E2EE, end-to-end encryption) garantisce che solo il mittente e il destinatario possano leggere il contenuto di un messaggio. Le chiavi di decifratura non lasciano mai i dispositivi degli utenti. Nemmeno il server che trasporta i dati, l’amministratore di sistema o un attaccante che compromette l’infrastruttura pu\u00f2 accedere al testo in chiaro. Questo \u00e8 il punto che distingue la crittografia end-to-end<\/strong> dalla classica cifratura in transito (TLS) o a riposo (cifratura del disco): in quei due casi il server vede comunque i dati in chiaro a un certo punto.<\/p>\n\n\n\n

La differenza \u00e8 sostanziale per la conformit\u00e0 normativa. Il GDPR (Regolamento UE 2016\/679) considera la cifratura una misura tecnica adeguata ai sensi dell’articolo 32, e nel 2026 le autorit\u00e0 di controllo europee la citano regolarmente nelle istruttorie sui data breach. Quando i dati esfiltrati sono cifrati end-to-end e le chiavi restano sui dispositivi, l’impatto di una violazione si riduce drasticamente, perch\u00e9 l’attaccante ottiene solo ciphertext inutilizzabile.<\/p>\n\n\n\n

I tre obiettivi che costruiremo passo dopo passo sono questi:<\/p>\n\n\n\n

    \n
  • Riservatezza<\/strong>: nessuno tranne il destinatario legge il messaggio.<\/li>\n
  • Autenticit\u00e0 e integrit\u00e0<\/strong>: il destinatario verifica che il messaggio arrivi davvero dal mittente e che non sia stato modificato di un solo bit.<\/li>\n
  • Forward secrecy<\/strong>: la compromissione di una chiave oggi non espone i messaggi scambiati ieri.<\/li>\n<\/ul>\n\n\n\n

    Per ottenere questi tre obiettivi non scriveremo primitive crittografiche a mano. La regola d’oro della crittografia applicata resta valida nel 2026: non implementare algoritmi da zero. Useremo libsodium<\/code>, la libreria moderna derivata da NaCl che espone API ad alto livello difficili da usare in modo insicuro. La documentazione ufficiale di libsodium descrive la versione 1.0.22-stable<\/code> come libreria per cifratura, decifratura, firme e hashing delle password.<\/p>\n\n\n\n

    Prerequisiti: versioni e strumenti necessari<\/h2>\n\n\n\n

    Prima di scrivere codice, verifica di avere l’ambiente corretto. Tutte le versioni qui sotto sono quelle consigliate a giugno 2026.<\/p>\n\n\n\n

    \n
    Componente<\/th>Versione minima<\/th>Versione consigliata<\/th>Note<\/th><\/tr><\/thead>
    Node.js<\/td>20 LTS<\/td>22 LTS<\/td>Necessario per ES modules e API crypto native moderne<\/td><\/tr>\n
    npm<\/td>10.x<\/td>10.x o superiore<\/td>Incluso con Node.js<\/td><\/tr>\n
    libsodium-wrappers<\/td>0.7.x<\/td>0.8.4<\/td>Wrapper JavaScript\/WebAssembly di libsodium<\/td><\/tr>\n
    libsodium (nativa)<\/td>1.0.20<\/td>1.0.22-stable<\/td>Usata internamente dal wrapper<\/td><\/tr>\n
    Editor<\/td>qualsiasi<\/td>VS Code<\/td>Con supporto ESLint consigliato<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n

    Controlla la versione di Node.js installata con un singolo comando. Se ottieni una versione inferiore alla 20, aggiorna prima di proseguire, perch\u00e9 le API crypto.webcrypto<\/code> e il supporto stabile agli ES modules sono indispensabili per il progetto.<\/p>\n\n\n\n

    $ node --version\nv22.11.0\n\n$ npm --version\n10.9.0<\/code><\/pre>\n\n\n\n
    Una nota importante sulla scelta della libreria. Node.js ha un modulo crypto<\/code> nativo capace di AES-256-GCM e di ECDH, e per molti casi d’uso basta. In questo tutorial usiamo libsodium-wrappers<\/code> perch\u00e9 espone XChaCha20-Poly1305 (nonce a 192 bit, molto pi\u00f9 tollerante alla generazione casuale) e le API crypto_kx<\/code> e crypto_box<\/code>, pensate esattamente per lo scenario end-to-end. Mostreremo comunque l’equivalente con il modulo nativo dove utile.<\/p>\n\n\n\n
    Architettura del progetto di crittografia end-to-end<\/h2>\n\n\n\n
    Prima del codice, fissiamo il modello mentale. Immagina due utenti, Alice e Bob, che vogliono scambiarsi messaggi tramite un server che non deve mai vedere il testo in chiaro. Il flusso della crittografia end-to-end<\/strong> si articola in quattro fasi.<\/p>\n\n\n\n
      \n
    1. Generazione delle chiavi<\/strong>: ogni utente genera localmente una coppia di chiavi X25519 (pubblica e privata). La chiave privata non lascia mai il dispositivo.<\/li>\n
    2. Scambio delle chiavi pubbliche<\/strong>: gli utenti si scambiano le sole chiavi pubbliche tramite il server. Da queste derivano un segreto condiviso identico su entrambi i lati, senza mai trasmetterlo.<\/li>\n
    3. Cifratura<\/strong>: il mittente cifra il messaggio con una chiave di sessione derivata dal segreto condiviso, usando XChaCha20-Poly1305.<\/li>\n
    4. Decifratura e verifica<\/strong>: il destinatario decifra e verifica contestualmente l’autenticit\u00e0 grazie al tag Poly1305 incorporato.<\/li>\n<\/ol>\n\n\n\n
      Il segreto condiviso si ottiene con la matematica delle curve ellittiche (Diffie-Hellman su Curve25519, da cui il nome X25519). La propriet\u00e0 chiave \u00e8 questa: Alice combina la propria chiave privata con la pubblica di Bob, Bob combina la propria privata con la pubblica di Alice, e i due ottengono lo stesso valore senza che quel valore transiti mai sulla rete. Le chiavi pubbliche X25519 sono lunghe 32 byte, compatte e facili da archiviare.<\/p>\n\n\n\n
      Step 1: Inizializzare il progetto e installare libsodium<\/h2>\n\n\n\n
      Crea una nuova cartella, inizializza il progetto come modulo ES e installa l’unica dipendenza necessaria. Useremo \"type\": \"module\"<\/code> per scrivere import<\/code> moderni invece di require<\/code>.<\/p>\n\n\n\n
      $ mkdir e2ee-node && cd e2ee-node\n$ npm init -y\n$ npm pkg set type=\"module\"\n$ npm install libsodium-wrappers@0.8.4\n\nadded 1 package in 1s<\/code><\/pre>\n\n\n\n
      Un dettaglio cruciale di libsodium-wrappers<\/code>: la libreria viene caricata in modo asincrono (\u00e8 compilata in WebAssembly) e devi attendere la promise sodium.ready<\/code> prima di chiamare qualsiasi funzione. Dimenticare questo passaggio \u00e8 il primo errore in assoluto di chi inizia. Creiamo un piccolo modulo di bootstrap che esporta l’istanza gi\u00e0 pronta.<\/p>\n\n\n\n
      \/\/ sodium.js\nimport _sodium from 'libsodium-wrappers';\n\nlet ready = false;\n\nexport async function getSodium() {\n  if (!ready) {\n    await _sodium.ready;\n    ready = true;\n  }\n  return _sodium;\n}<\/code><\/pre>\n\n\n\n
      Da qui in avanti ogni modulo che ha bisogno di crittografia chiamer\u00e0 await getSodium()<\/code>. In questo modo la libreria \u00e8 inizializzata una sola volta per processo, anche se la importi in pi\u00f9 file.<\/p>\n\n\n\n
      Step 2: Generare le coppie di chiavi X25519<\/h2>\n\n\n\n
      Ogni utente ha bisogno di una coppia di chiavi per lo scambio. La funzione crypto_kx_keypair<\/code> genera una chiave pubblica e una privata da 32 byte ciascuna, pensate proprio per il key exchange. Creiamo il modulo keys.js<\/code>.<\/p>\n\n\n\n
      \/\/ keys.js\nimport { getSodium } from '.\/sodium.js';\n\nexport async function generateKeyPair() {\n  const sodium = await getSodium();\n  const { publicKey, privateKey } = sodium.crypto_kx_keypair();\n  return { publicKey, privateKey };\n}\n\n\/\/ Utility: byte -> base64 per il trasporto\/archiviazione\nexport async function toBase64(bytes) {\n  const sodium = await getSodium();\n  return sodium.to_base64(bytes, sodium.base64_variants.ORIGINAL);\n}\n\nexport async function fromBase64(str) {\n  const sodium = await getSodium();\n  return sodium.from_base64(str, sodium.base64_variants.ORIGINAL);\n}<\/code><\/pre>\n\n\n\n
      La chiave pubblica pu\u00f2 essere inviata al server e condivisa con gli altri utenti senza rischi. La chiave privata, invece, deve restare sul dispositivo: salvala in un keystore sicuro (Keychain su macOS, DPAPI su Windows, libsecret su Linux) oppure cifrala con una password derivata via Argon2 prima di scriverla su disco. Non salvarla mai in chiaro in un database lato server, perch\u00e9 questo annullerebbe l’intera propriet\u00e0 end-to-end.<\/p>\n\n\n\n
      Step 3: Lo scambio di chiavi (key exchange) con crypto_kx<\/h2>\n\n\n\n
      Qui avviene la magia del Diffie-Hellman. Le funzioni crypto_kx_client_session_keys<\/code> e crypto_kx_server_session_keys<\/code> prendono la coppia di chiavi locale e la chiave pubblica della controparte, e restituiscono due chiavi di sessione da 32 byte: una per ricevere (rx<\/code>) e una per trasmettere (tx<\/code>). Il design garantisce che la chiave tx<\/code> del client corrisponda alla chiave rx<\/code> del server e viceversa.<\/p>\n\n\n\n
      \/\/ session.js\nimport { getSodium } from '.\/sodium.js';\n\n\/\/ Lato che inizia la conversazione (client)\nexport async function clientSession(myKeys, theirPublicKey) {\n  const sodium = await getSodium();\n  const { sharedRx, sharedTx } = sodium.crypto_kx_client_session_keys(\n    myKeys.publicKey,\n    myKeys.privateKey,\n    theirPublicKey\n  );\n  return { rx: sharedRx, tx: sharedTx };\n}\n\n\/\/ Lato che riceve la conversazione (server\/peer)\nexport async function serverSession(myKeys, theirPublicKey) {\n  const sodium = await getSodium();\n  const { sharedRx, sharedTx } = sodium.crypto_kx_server_session_keys(\n    myKeys.publicKey,\n    myKeys.privateKey,\n    theirPublicKey\n  );\n  return { rx: sharedRx, tx: sharedTx };\n}<\/code><\/pre>\n\n\n\n
      Attenzione alla simmetria dei ruoli: se Alice usa clientSession<\/code>, Bob deve usare serverSession<\/code>, altrimenti le chiavi rx<\/code> e tx<\/code> non combaceranno e la decifratura fallir\u00e0. \u00c8 una convenzione, non una gerarchia di sicurezza: entrambi i lati restano paritari. Nella pratica chi avvia la conversazione assume il ruolo di client.<\/p>\n\n\n\n
      Il segreto condiviso non viene mai inviato sulla rete. Sul filo viaggiano solo le due chiavi pubbliche da 32 byte. Un attaccante che intercetta entrambe le chiavi pubbliche non riesce comunque a ricavare le chiavi di sessione, perch\u00e9 il problema del logaritmo discreto su Curve25519 \u00e8 computazionalmente intrattabile per i computer classici.<\/p>\n\n\n\n
      Step 4: Cifrare i messaggi con XChaCha20-Poly1305<\/h2>\n\n\n\n
      Con la chiave di sessione possiamo cifrare. Usiamo crypto_aead_xchacha20poly1305_ietf_encrypt<\/code>, una funzione di cifratura autenticata (AEAD) che produce contemporaneamente ciphertext e tag di autenticazione. XChaCha20-Poly1305 combina lo stream cipher ChaCha20 (specificato in RFC 8439) con il MAC Poly1305, e adotta un nonce esteso a 192 bit (24 byte).<\/p>\n\n\n\n
      \/\/ cipher.js\nimport { getSodium } from '.\/sodium.js';\n\nexport async function encrypt(plaintext, key, associatedData = null) {\n  const sodium = await getSodium();\n  \/\/ Nonce a 192 bit: generato in modo casuale a ogni messaggio\n  const nonce = sodium.randombytes_buf(\n    sodium.crypto_aead_xchacha20poly1305_ietf_NPUBBYTES\n  );\n  const message = typeof plaintext === 'string'\n    ? sodium.from_string(plaintext)\n    : plaintext;\n\n  const ciphertext = sodium.crypto_aead_xchacha20poly1305_ietf_encrypt(\n    message,\n    associatedData,   \/\/ dati autenticati ma non cifrati (es. ID mittente)\n    null,             \/\/ nsec, sempre null in questa variante\n    nonce,\n    key\n  );\n\n  return { ciphertext, nonce };\n}<\/code><\/pre>\n\n\n\n
      Il parametro associatedData<\/code> (AAD, associated data) merita attenzione. Non viene cifrato, ma viene autenticato: se qualcuno lo modifica, la decifratura fallisce. \u00c8 perfetto per legare il ciphertext a metadati che devono restare in chiaro ma immutabili, come l’ID del mittente, un timestamp o il numero di sequenza del messaggio. Usarlo previene gli attacchi di sostituzione del contesto, in cui un attaccante riusa un ciphertext valido in una conversazione diversa.<\/p>\n\n\n\n
      Il nonce a 192 bit di XChaCha20 \u00e8 il motivo principale per cui lo preferiamo ad AES-256-GCM in questo scenario. Con AES-GCM il nonce \u00e8 di soli 96 bit e generarlo casualmente porta a una probabilit\u00e0 di collisione non trascurabile dopo qualche miliardo di messaggi con la stessa chiave. Con 192 bit la generazione puramente casuale \u00e8 sicura per qualsiasi volume realistico, eliminando la necessit\u00e0 di un contatore stateful.<\/p>\n\n\n\n
      Step 5: Decifrare e verificare l’autenticit\u00e0<\/h2>\n\n\n\n
      La decifratura \u00e8 speculare. La funzione crypto_aead_xchacha20poly1305_ietf_decrypt<\/code> verifica il tag Poly1305 prima di restituire il testo in chiaro: se il ciphertext, il nonce o l’AAD sono stati alterati, lancia un’eccezione e non restituisce nulla. Questa \u00e8 la garanzia di integrit\u00e0: non esiste modo di ottenere testo in chiaro da un messaggio manomesso.<\/p>\n\n\n\n
      \/\/ cipher.js (continua)\nexport async function decrypt(ciphertext, nonce, key, associatedData = null) {\n  const sodium = await getSodium();\n  try {\n    const decrypted = sodium.crypto_aead_xchacha20poly1305_ietf_decrypt(\n      null,             \/\/ nsec, sempre null\n      ciphertext,\n      associatedData,\n      nonce,\n      key\n    );\n    return sodium.to_string(decrypted);\n  } catch (err) {\n    \/\/ Tag non valido: messaggio manomesso o chiave errata\n    throw new Error('Decifratura fallita: messaggio non autentico');\n  }\n}<\/code><\/pre>\n\n\n\n
      Non ignorare mai l’eccezione e non restituire un valore parziale. Un fallimento di decifratura significa una di queste cose: chiave sbagliata, nonce sbagliato, AAD diverso, oppure un tentativo di manomissione. In tutti i casi il comportamento corretto \u00e8 rifiutare il messaggio. Mostrare messaggi di errore diversi per “chiave errata” e “tag non valido” pu\u00f2 aprire la porta a un oracle attack: meglio un errore generico.<\/p>\n\n\n\n
      Step 6: Gestione corretta dei nonce<\/h2>\n\n\n\n
      Il nonce (number used once) \u00e8 il dato pi\u00f9 sottovalutato e pi\u00f9 pericoloso di tutto il sistema. La regola assoluta degli schemi AEAD \u00e8: mai riusare la stessa coppia (chiave, nonce) per due messaggi diversi. Il riuso del nonce con la stessa chiave rompe sia la riservatezza sia, in molti casi, l’integrit\u00e0, perch\u00e9 permette di recuperare il keystream e di forgiare tag validi.<\/p>\n\n\n\n
      Esistono due strategie corrette. La prima, che abbiamo gi\u00e0 adottato, \u00e8 generare un nonce casuale a 192 bit per ogni messaggio: con XChaCha20 lo spazio \u00e8 cos\u00ec grande che le collisioni sono trascurabili. La seconda \u00e8 usare un contatore monotono crescente, utile quando vuoi anche rilevare e rifiutare i replay. Ecco un esempio del secondo approccio, che incorpora il numero di sequenza nel nonce.<\/p>\n\n\n\n
      \/\/ counter-nonce.js\nimport { getSodium } from '.\/sodium.js';\n\nexport function makeCounterNonce(sodium, counter) {\n  const nonce = new Uint8Array(\n    sodium.crypto_aead_xchacha20poly1305_ietf_NPUBBYTES\n  );\n  \/\/ Scrive il contatore (big-endian) negli ultimi 8 byte del nonce\n  const view = new DataView(nonce.buffer);\n  view.setBigUint64(\n    nonce.length - 8,\n    BigInt(counter),\n    false \/\/ big-endian\n  );\n  return nonce;\n}<\/code><\/pre>\n\n\n\n
      Se scegli il contatore, devi persistere il valore in modo durevole: un riavvio che azzera il contatore reintroduce il riuso del nonce. Per questo, per la maggior parte delle applicazioni, il nonce casuale a 192 bit \u00e8 la scelta pi\u00f9 semplice e robusta. La tabella riassume il confronto tra le due strategie e i due cifrari principali.<\/p>\n\n\n\n
      \n
      Caratteristica<\/th>XChaCha20-Poly1305<\/th>ChaCha20-Poly1305 (IETF)<\/th>AES-256-GCM<\/th><\/tr><\/thead>
      Dimensione nonce<\/td>192 bit (24 byte)<\/td>96 bit (12 byte)<\/td>96 bit (12 byte)<\/td><\/tr>\n
      Nonce casuale sicuro<\/td>S\u00ec, sempre<\/td>Solo fino a circa 2^32 msg<\/td>Solo fino a circa 2^32 msg<\/td><\/tr>\n
      Accelerazione hardware<\/td>No (CPU generica)<\/td>No<\/td>S\u00ec (AES-NI)<\/td><\/tr>\n
      Robustezza nonce casuale<\/td>Molto alta<\/td>Media<\/td>Media<\/td><\/tr>\n
      Tag di autenticazione<\/td>128 bit<\/td>128 bit<\/td>128 bit<\/td><\/tr>\n
      Disponibile in libsodium<\/td>S\u00ec (alto livello)<\/td>S\u00ec<\/td>Non come primitiva<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
      Step 7: Forward secrecy con la rotazione delle chiavi (ratchet)<\/h2>\n\n\n\n
      Finora abbiamo una sessione cifrata, ma se un attaccante registra tutto il traffico e in futuro ruba la chiave privata di lungo termine, pu\u00f2 decifrare l’intero storico. La forward secrecy<\/strong> elimina questo rischio: ogni messaggio (o gruppo di messaggi) usa una chiave effimera che viene distrutta subito dopo l’uso. La compromissione della chiave di oggi non rivela i messaggi di ieri.<\/p>\n\n\n\n
      Il riferimento di settore \u00e8 il Double Ratchet del Signal Protocol, che combina uno scambio Diffie-Hellman effimero a ogni passo con un ratchet simmetrico via funzione di derivazione delle chiavi. Implementare un Double Ratchet completo va oltre questo tutorial, ma possiamo costruire una versione semplificata di ratchet simmetrico che fa avanzare la chiave a ogni messaggio usando una KDF (key derivation function). Usiamo crypto_kdf_derive_from_key<\/code>.<\/p>\n\n\n\n
      \/\/ ratchet.js\nimport { getSodium } from '.\/sodium.js';\n\nconst CONTEXT = 'e2ee-ctx'; \/\/ 8 byte di contesto\n\n\/\/ Deriva la chiave del messaggio N e la prossima chiave di catena\nexport async function ratchetStep(chainKey, counter) {\n  const sodium = await getSodium();\n  const messageKey = sodium.crypto_kdf_derive_from_key(\n    32, counter, CONTEXT, chainKey\n  );\n  const nextChainKey = sodium.crypto_kdf_derive_from_key(\n    32, counter + 1, CONTEXT, chainKey\n  );\n  \/\/ La vecchia chainKey va azzerata dal chiamante dopo questo step\n  return { messageKey, nextChainKey };\n}<\/code><\/pre>\n\n\n\n
      Il principio \u00e8 semplice: ogni messaggio ottiene una messageKey<\/code> univoca derivata dalla catena, e la catena avanza in modo irreversibile. Dato che la KDF \u00e8 a senso unico, conoscere una chiave futura non permette di tornare indietro alle chiavi passate. Ricorda di sovrascrivere in memoria le chiavi usate con sodium.memzero<\/code> non appena hai finito, per ridurre la finestra di esposizione in caso di dump della RAM.<\/p>\n\n\n\n
      Step 8: Firmare l’identit\u00e0 con Ed25519<\/h2>\n\n\n\n
      Lo scambio X25519 protegge dalla lettura, ma da solo non protegge dall’attacco man-in-the-middle: se un attaccante sostituisce le chiavi pubbliche durante lo scambio, pu\u00f2 inserirsi al centro della conversazione. La difesa \u00e8 autenticare le chiavi pubbliche con una firma digitale Ed25519 legata a un’identit\u00e0 verificabile. Ed25519 \u00e8 veloce, produce firme da 64 byte e chiavi pubbliche da 32 byte.<\/p>\n\n\n\n
      \/\/ identity.js\nimport { getSodium } from '.\/sodium.js';\n\nexport async function createIdentity() {\n  const sodium = await getSodium();\n  const { publicKey, privateKey } = sodium.crypto_sign_keypair();\n  return { signPub: publicKey, signPriv: privateKey };\n}\n\n\/\/ Firma la chiave pubblica X25519 con la chiave di identit\u00e0 Ed25519\nexport async function signKey(x25519PublicKey, signPriv) {\n  const sodium = await getSodium();\n  return sodium.crypto_sign_detached(x25519PublicKey, signPriv);\n}\n\nexport async function verifyKey(signature, x25519PublicKey, signPub) {\n  const sodium = await getSodium();\n  return sodium.crypto_sign_verify_detached(\n    signature, x25519PublicKey, signPub\n  );\n}<\/code><\/pre>\n\n\n\n
      Nel mondo reale la chiave di identit\u00e0 Ed25519 viene verificata fuori banda: tramite un QR code scansionato di persona (il “safety number” di Signal), un certificato emesso da una PKI aziendale, o la trust on first use con notifica all’utente in caso di cambio chiave. Senza questo anello, la crittografia end-to-end<\/strong> protegge dal server curioso ma non da un man-in-the-middle attivo capace di sostituire le chiavi.<\/p>\n\n\n\n
      Step 9: Serializzare e trasportare il messaggio cifrato<\/h2>\n\n\n\n
      Il ciphertext e il nonce sono array di byte (Uint8Array<\/code>). Per inviarli su una API JSON o salvarli in un database, vanno serializzati. Lo standard pratico \u00e8 codificarli in base64 e impacchettarli in un oggetto con un campo di versione, utile per future migrazioni di algoritmo.<\/p>\n\n\n\n
      \/\/ envelope.js\nimport { toBase64, fromBase64 } from '.\/keys.js';\n\nexport async function pack(ciphertext, nonce, senderId) {\n  return JSON.stringify({\n    v: 1,\n    alg: 'xchacha20poly1305',\n    sender: senderId,\n    nonce: await toBase64(nonce),\n    ct: await toBase64(ciphertext)\n  });\n}\n\nexport async function unpack(json) {\n  const obj = JSON.parse(json);\n  if (obj.v !== 1) throw new Error('Versione envelope non supportata');\n  return {\n    senderId: obj.sender,\n    nonce: await fromBase64(obj.nonce),\n    ciphertext: await fromBase64(obj.ct)\n  };\n}<\/code><\/pre>\n\n\n\n
      Il campo v<\/code> di versione non \u00e8 un dettaglio cosmetico: quando migrerai a una primitiva post-quantum (Step 12) potrai distinguere i vecchi messaggi dai nuovi e decifrare entrambi durante il periodo di transizione. Lega il campo sender<\/code> all’AAD durante la cifratura, cos\u00ec l’identit\u00e0 del mittente resta autenticata e non sostituibile.<\/p>\n\n\n\n
      Step 10: Il progetto completo che mette tutto insieme<\/h2>\n\n\n\n
      \u00c8 il momento di assemblare i moduli in un flusso end-to-end completo, da Alice a Bob, con scambio di chiavi, cifratura e decifratura. Crea demo.js<\/code>.<\/p>\n\n\n\n
      \/\/ demo.js\nimport { generateKeyPair } from '.\/keys.js';\nimport { clientSession, serverSession } from '.\/session.js';\nimport { encrypt, decrypt } from '.\/cipher.js';\nimport { pack, unpack } from '.\/envelope.js';\n\nasync function main() {\n  \/\/ 1. Alice e Bob generano le proprie coppie di chiavi\n  const alice = await generateKeyPair();\n  const bob = await generateKeyPair();\n\n  \/\/ 2. Scambio: ognuno conosce la chiave pubblica dell'altro\n  const aliceSession = await clientSession(alice, bob.publicKey);\n  const bobSession = await serverSession(bob, alice.publicKey);\n\n  \/\/ 3. Alice cifra un messaggio per Bob (usa la sua chiave tx)\n  const aad = new TextEncoder().encode('alice@example.com');\n  const { ciphertext, nonce } = await encrypt(\n    'Ciao Bob, questo messaggio \u00e8 end-to-end.',\n    aliceSession.tx,\n    aad\n  );\n\n  \/\/ 4. Serializzazione e \"invio\" tramite il server\n  const envelope = await pack(ciphertext, nonce, 'alice@example.com');\n  console.log('Sul filo viaggia solo:', envelope.slice(0, 80), '...');\n\n  \/\/ 5. Bob riceve, deserializza e decifra (usa la sua chiave rx)\n  const received = await unpack(envelope);\n  const aadBob = new TextEncoder().encode(received.senderId);\n  const plaintext = await decrypt(\n    received.ciphertext,\n    received.nonce,\n    bobSession.rx,\n    aadBob\n  );\n\n  console.log('Bob legge:', plaintext);\n}\n\nmain().catch(console.error);<\/code><\/pre>\n\n\n\n
      Nota la simmetria delle chiavi di sessione: Alice cifra con aliceSession.tx<\/code> e Bob decifra con bobSession.rx<\/code>. Grazie al design di crypto_kx<\/code> queste due chiavi sono identiche. Per il traffico nella direzione opposta (Bob verso Alice) useresti bobSession.tx<\/code> e aliceSession.rx<\/code>.<\/p>\n\n\n\n
      Step 11: Eseguire i test e leggere l’output di esempio<\/h2>\n\n\n\n
      Avvia la demo e osserva il risultato. Il server vede solo ciphertext base64 illeggibile, mentre Bob ricostruisce il testo originale.<\/p>\n\n\n\n
      $ node demo.js\nSul filo viaggia solo: {\"v\":1,\"alg\":\"xchacha20poly1305\",\"sender\":\"alice@example.com\",\"nonce\":\"k9Xq2...\"} ...\nBob legge: Ciao Bob, questo messaggio \u00e8 end-to-end.<\/code><\/pre>\n\n\n\n
      Aggiungiamo un test che dimostra la propriet\u00e0 di integrit\u00e0: se modifichiamo un solo byte del ciphertext, la decifratura deve fallire. Questo \u00e8 il cuore della verifica di autenticit\u00e0.<\/p>\n\n\n\n
      \/\/ tamper-test.js\nimport { generateKeyPair } from '.\/keys.js';\nimport { clientSession, serverSession } from '.\/session.js';\nimport { encrypt, decrypt } from '.\/cipher.js';\n\nconst alice = await generateKeyPair();\nconst bob = await generateKeyPair();\nconst aSess = await clientSession(alice, bob.publicKey);\nconst bSess = await serverSession(bob, alice.publicKey);\n\nconst { ciphertext, nonce } = await encrypt('dati riservati', aSess.tx);\n\n\/\/ Manomissione: capovolgiamo un bit\nciphertext[0] ^= 0x01;\n\ntry {\n  await decrypt(ciphertext, nonce, bSess.rx);\n  console.log('ERRORE: la manomissione non \u00e8 stata rilevata!');\n} catch (e) {\n  console.log('OK: manomissione rilevata ->', e.message);\n}<\/code><\/pre>\n\n\n\n
      $ node tamper-test.js\nOK: manomissione rilevata -> Decifratura fallita: messaggio non autentico<\/code><\/pre>\n\n\n\n
      Un benchmark rapido aiuta a capire le prestazioni. Su hardware desktop moderno senza accelerazione AES-NI, XChaCha20-Poly1305 cifra centinaia di megabyte al secondo, pi\u00f9 che sufficiente per messaggistica e file di dimensione media. Su CPU con AES-NI, AES-256-GCM pu\u00f2 risultare pi\u00f9 veloce su file molto grandi, ma per messaggi corti la differenza \u00e8 irrilevante e la robustezza del nonce a 192 bit pesa di pi\u00f9 nella scelta.<\/p>\n\n\n\n
      Step 12: Migrazione post-quantum con KEM ibrido ML-KEM<\/h2>\n\n\n\n
      Nel 2026 la minaccia quantistica non \u00e8 pi\u00f9 teorica nella pianificazione di sicurezza. Il rischio concreto \u00e8 il “harvest now, decrypt later”: un attaccante registra oggi il traffico cifrato con X25519 e lo decifra in futuro, quando un computer quantistico abbastanza grande romper\u00e0 la crittografia a curve ellittiche. Per i dati che devono restare riservati per un decennio, questo rischio \u00e8 reale adesso.<\/p>\n\n\n\n
      La risposta \u00e8 il KEM (key encapsulation mechanism) ibrido. ML-KEM, lo standard NIST pubblicato come FIPS 203 e basato sull’algoritmo Kyber, \u00e8 il KEM post-quantum di riferimento. La strategia consigliata per la transizione non \u00e8 sostituire X25519, ma affiancarlo: il segreto condiviso finale deriva dalla combinazione del segreto X25519 e del segreto ML-KEM. Cos\u00ec la sessione resta sicura finch\u00e9 almeno uno dei due rimane intatto.<\/p>\n\n\n\n
      \/\/ hybrid-kdf.js (concetto)\n\/\/ ss_classico  = X25519(privA, pubB)          \/\/ 32 byte\n\/\/ ss_pq        = ML-KEM-768 encapsulate(...)   \/\/ segreto post-quantum\n\/\/ chiave finale = BLAKE2b( ss_classico || ss_pq )\nimport { getSodium } from '.\/sodium.js';\n\nexport async function combineSecrets(ssClassic, ssPq) {\n  const sodium = await getSodium();\n  const concat = new Uint8Array(ssClassic.length + ssPq.length);\n  concat.set(ssClassic, 0);\n  concat.set(ssPq, ssClassic.length);\n  \/\/ BLAKE2b come KDF per derivare 32 byte di chiave di sessione\n  return sodium.crypto_generichash(32, concat);\n}<\/code><\/pre>\n\n\n\n
      Al momento libsodium-wrappers<\/code> non espone ML-KEM come primitiva di prima classe, quindi nel 2026 servono librerie dedicate (ad esempio i binding di liboqs o le API sperimentali del modulo crypto in alcune build di Node.js) per la parte post-quantum, mentre libsodium continua a fornire il ramo classico X25519 e la KDF di combinazione. Il campo v<\/code> di versione che abbiamo previsto nell’envelope serve proprio a gestire la coesistenza tra messaggi classici e ibridi durante la migrazione. Per approfondire lo stato dell’arte, consulta la nostra guida dedicata alla crittografia post-quantum.<\/p>\n\n\n\n
      5 errori comuni da evitare nella crittografia end-to-end<\/h2>\n\n\n\n
      La maggior parte delle vulnerabilit\u00e0 nei sistemi E2EE non nasce da algoritmi deboli, ma da errori di implementazione. Ecco i cinque pi\u00f9 frequenti, con la relativa correzione.<\/p>\n\n\n\n