Cryptography on My personal blog

Crittografia applicata: la serie

Tue, 04 Aug 2026 09:00:00 +0200

Perché questa serie

Usi la crittografia centinaia di volte al giorno senza pensarci: ogni sito in HTTPS, ogni messaggio cifrato, ogni password salvata, ogni aggiornamento firmato. Quando funziona è invisibile. Quando la si implementa male — ed è facile — i dati trapelano in silenzio, e nessun test funzionale se ne accorge. Questa serie in 10 capitoli spiega la crittografia applicata: non le dimostrazioni matematiche, ma quale primitiva usare, perché, e quali errori evitare.

La regola d’oro

Prima di tutto il resto, una regola che vale più di ogni capitolo:

Non inventare la tua crittografia, e non implementare primitive a mano. Usa librerie affermate, revisionate, e le loro impostazioni predefinite sicure.

La crittografia fallisce in modi silenziosi: un nonce riusato, un confronto non a tempo costante, un padding mal gestito. Capire come funziona serve a usarla bene e a riconoscere gli errori — non a riscriverla. Tutta la serie è pensata con questo spirito.

La mappa

  flowchart TD
    SYM[Simmetrica<br/>AES, AEAD] --> HASH[Hashing<br/>integrità]
    HASH --> MAC[HMAC<br/>autenticità]
    MAC --> PW[Password<br/>hashing]
    PW --> ASYM[Asimmetrica<br/>RSA, ECC]
    ASYM --> KEX[Scambio chiavi<br/>forward secrecy]
    KEX --> SIG[Firme<br/>digitali]
    SIG --> PKI[PKI<br/>catena di fiducia]
    PKI --> PQC[Post-quantum]
    style SYM fill:#fde2e4,stroke:#e63946
    style PKI fill:#e8f0fe,stroke:#4361ee

Si parte dai mattoni più semplici (cifrare e verificare l’integrità) e si sale fino a come TLS, le firme del software e la PKI li combinano. L’ultimo capitolo guarda avanti: cosa cambia quando arriveranno i computer quantistici.

I tre obiettivi della crittografia

Tutto ruota attorno a tre proprietà, e confonderle è l’errore concettuale più comune:

Riservatezza: nessuno legge il messaggio tranne il destinatario. → cifratura.
Integrità: il messaggio non è stato alterato. → hash, MAC.
Autenticità: il messaggio viene davvero da chi dice. → MAC, firme.

Cifrare non garantisce integrità; un hash non garantisce autenticità. Gran parte della serie è imparare quale strumento dà quale garanzia, e come combinarli senza lasciare buchi.

A chi si rivolge

A chi scrive software e deve scegliere come cifrare dati, salvare password, verificare firme — senza essere un crittografo. Diamo per note le basi (byte, encoding, un po’ di aritmetica); tutto il resto lo costruiamo. Questa serie è il complemento naturale di temi già trattati come il TLS e la Certificate Transparency.

Partiamo dal mattone più usato di tutti: la cifratura simmetrica, prossimo capitolo.

Crittografia post-quantum: prepararsi ora

Tue, 06 Oct 2026 09:00:00 +0200

Perché conta

Tutta la crittografia asimmetrica della serie — RSA, ECC, Diffie-Hellman, le firme — poggia su problemi che i computer classici non sanno risolvere: fattorizzazione e logaritmo discreto. Un computer quantistico abbastanza grande, invece, li risolverebbe con l’algoritmo di Shor, mandando in frantumi RSA ed ECC. La macchina non esiste ancora a quella scala. Eppure il problema è già oggi, e questo capitolo chiude la serie spiegando perché e cosa fare.

Cosa si rompe e cosa no

Una distinzione cruciale e spesso fraintesa:

Crittografia ASIMMETRICA (RSA, ECC, DH, firme)
  → algoritmo di Shor: ROTTA da un computer quantistico grande
Crittografia SIMMETRICA (AES) e HASH (SHA-2/3)
  → algoritmo di Grover: solo DIMEZZA la sicurezza → AES-256 resta solido (= 128 bit post-quantum)

Il quantistico non “rompe tutto”. Contro la simmetrica, l’algoritmo di Grover offre solo un dimezzamento della forza: raddoppiando la dimensione della chiave (usare AES-256) si resta al sicuro. A cadere è l’asimmetrica — proprio i meccanismi che stabiliscono chiavi e provano identità. Lì serve una matematica nuova.

“Harvest now, decrypt later”

Perché preoccuparsene se la macchina non c’è? Per un motivo che rende la minaccia presente:

  flowchart LR
    T1[Oggi] -->|avversario registra<br/>traffico cifrato| STORE[(Archivio<br/>traffico 2026)]
    STORE --> T2[Fra N anni:<br/>computer quantistico]
    T2 -->|decifra retroattivamente<br/>ciò che fu scambiato con ECC/RSA| LEAK[Dati del 2026<br/>esposti]
    style LEAK fill:#fde2e4,stroke:#e63946

Un avversario con risorse può registrare oggi il traffico cifrato e conservarlo, in attesa della macchina che un domani lo decifrerà. Tutto ciò che deve restare segreto per molti anni — segreti di stato, dati sanitari, proprietà intellettuale — è già a rischio oggi, anche se il quantistico arriverà tra dieci anni. È il motivo per cui la migrazione non può aspettare che la minaccia sia operativa.

I nuovi algoritmi

Il NIST ha standardizzato i primi algoritmi post-quantum (PQC), basati su problemi matematici (soprattutto reticoli) che si ritengono difficili anche per i computer quantistici:

ML-KEM (ex Kyber, FIPS 203): per lo scambio/incapsulamento di chiavi — il sostituto di (EC)DH.
ML-DSA (ex Dilithium, FIPS 204) e SLH-DSA (SPHINCS+, basato su hash): per le firme — i sostituti di ECDSA/RSA.

Hanno chiavi e messaggi più grandi dei loro predecessori ellittici, il che pesa su banda e handshake. Per questo la migrazione è un lavoro ingegneristico, non un semplice cambio di libreria.

La migrazione ibrida, già iniziata

La transizione non aspetta: è già in corso, in forma ibrida. L’approccio prudente combina il vecchio e il nuovo in un unico scambio:

1
2
3

Scambio di chiavi ibrido:  ECDHE (classico)  +  ML-KEM (post-quantum)
  → il segreto deriva da ENTRAMBI: sei sicuro se almeno uno regge
  → protegge dal quantistico futuro E da eventuali debolezze dei nuovi algoritmi (ancora giovani)

I browser e le librerie TLS stanno già dispiegando scambi ibridi: così la forward secrecy del capitolo sullo scambio di chiavi diventa anche post-quantum, e il traffico registrato oggi resta protetto anche domani. Cosa puoi fare: usare AES-256 dove serve longevità, preferire librerie che supportano gli ibridi, e sapere dove usi crittografia asimmetrica (crypto-agility) per poterla aggiornare quando sarà il momento.

Domanda: se i computer quantistici capaci di rompere RSA non esistono ancora e forse mancano molti anni, investire ora nella migrazione post-quantum non è allarmismo prematuro?

Sembra prematuro solo se guardi la data in cui la macchina diventerà operativa; diventa evidentemente urgente appena consideri i tre orizzonti temporali che vanno sommati, un ragionamento noto come "teorema di Mosca". La domanda giusta non è "quando arriverà il computer quantistico?" ma "per quanti anni i miei dati devono restare segreti, e quanto tempo mi serve per migrare?". Chiamiamo X gli anni di segretezza richiesti dai dati che cifro oggi, Y gli anni che la mia organizzazione impiega a migrare davvero tutta la crittografia (storicamente lunghissimi: pensa a quanto ci è voluto per abbandonare SHA-1), e Z gli anni che mancano a un computer quantistico utile. Se X + Y > Z, sei già in ritardo: i dati che proteggi adesso saranno ancora sensibili quando la macchina esisterà, ma li avrai migrati troppo tardi. Ed è qui che entra la minaccia "harvest now, decrypt later", che smonta l'idea di allarmismo: l'attacco non richiede che il quantistico esista ora, richiede solo che un avversario registri ora il traffico cifrato e lo conservi. La cattura avviene oggi, la decifratura domani — quindi per qualunque dato che debba restare riservato oltre l'arrivo stimato della macchina, la finestra di rischio è già aperta, non si aprirà in futuro. Per un messaggio effimero che non conta più fra un'ora, ignorare il post-quantum è ragionevole; per segreti di stato, cartelle cliniche, chiavi di lungo periodo, proprietà intellettuale, l'esposizione è concreta adesso. C'è poi un argomento di prudenza ingegneristica che rende la migrazione sensata a prescindere dalle date: adottare oggi gli scambi ibridi (classico + post-quantum insieme) non comporta quasi nessun rischio — se gli algoritmi nuovi si rivelassero deboli, ti protegge ancora quello classico; se il classico cade al quantistico, ti protegge quello nuovo — e nel frattempo costruisci la crypto-agility, cioè la capacità di sapere dove usi la crittografia e di cambiarla rapidamente, che è un bene a sé indipendentemente dai quanti. In breve: non è allarmismo, è pianificazione calibrata sulla longevità dei dati. Chi tratta solo dati a vita breve può attendere; chi tratta segreti di lungo periodo e sa quanto è lenta una migrazione reale dovrebbe aver già cominciato, perché il nemico può aver già iniziato a raccogliere.

Conclusione

Il computer quantistico romperebbe l’asimmetrica (RSA, ECC, DH, firme) ma non la simmetrica robusta (AES-256): la minaccia “harvest now, decrypt later” rende il problema attuale, e la risposta sono gli algoritmi NIST post-quantum (ML-KEM, ML-DSA) dispiegati in forma ibrida, già oggi. Qui si chiude la serie Crittografia applicata: dai mattoni — cifrare, verificare, autenticare — fino alla fiducia e al futuro. Il filo rosso resta quello del primo capitolo: non inventare la tua crittografia, scegli le primitive giuste, e capiscile abbastanza da riconoscere quando qualcosa non torna.

PKI e la catena di fiducia

Tue, 29 Sep 2026 09:00:00 +0200

Perché conta

Due capitoli hanno lasciato aperta la stessa domanda: la crittografia asimmetrica e le firme funzionano solo se sai che una chiave pubblica appartiene davvero a chi dice. Una chiave senza identità verificata è inutile: un man-in-the-middle ti dà la sua e tu cifri felicemente per lui. La PKI (Public Key Infrastructure) risolve questo: lega chiavi a identità tramite certificati firmati da autorità fidate.

Il certificato: un’identità firmata

Un certificato X.509 è, in sostanza, una dichiarazione firmata: “questa chiave pubblica appartiene a questo soggetto”, con una firma di chi lo attesta.

Certificato (semplificato):
  soggetto:       www.esempio.it         ← a chi appartiene
  chiave pubblica: 30 82 01 0a...         ← la chiave legata all'identità
  validità:       dal ... al ...
  emittente:      CA Intermedia X
  FIRMA dell'emittente                    ← la CA garantisce il legame

Il certificato non è segreto: è pubblico. La sua forza sta nella firma dell’emittente, che puoi verificare — a patto di fidarti dell’emittente. E qui comincia la catena.

La catena di fiducia

Nessuna singola autorità firma direttamente ogni certificato del mondo. La fiducia è gerarchica:

  flowchart TD
    ROOT[Root CA<br/>autofirmata, nel trust store<br/>del tuo SO/browser] -->|firma| INT[CA Intermedia]
    INT -->|firma| LEAF[Certificato del sito<br/>www.esempio.it]
    LEAF -.verifico risalendo.-> INT
    INT -.fino a una radice<br/>che già mi fido.-> ROOT
    style ROOT fill:#fde2e4,stroke:#e63946

Il tuo sistema operativo e il browser contengono un trust store: un insieme di poche centinaia di root CA di cui ti fidi a priori. Quando visiti un sito, il browser riceve il certificato foglia e la catena di intermedie, e verifica ogni firma risalendo fino a una radice fidata. Se la catena regge e tutto è valido (nome corretto, non scaduto, non revocato), la connessione è autenticata. È ciò che avviene a ogni handshake TLS.

Il punto debole: la revoca

Cosa succede se una chiave privata viene compromessa prima della scadenza del certificato? Va revocata. Ma la revoca è storicamente il tallone d’Achille della PKI:

CRL (liste di revoca)  → grandi, scaricate di rado: lente ad aggiornarsi
OCSP (query online)    → una richiesta per certificato: lenta, e un problema di privacy
OCSP stapling          → il server allega la prova di non-revoca: meglio
tendenza moderna       → certificati a VITA BREVE (es. 90 giorni, Let's Encrypt) + automazione

La direzione vincente è ridurre il problema alla fonte: certificati a vita breve, rinnovati automaticamente. Se un certificato dura 90 giorni, una compromissione ha una finestra corta anche senza revoca tempestiva — lo stesso principio delle credenziali effimere visto per i segreti e la forward secrecy.

Il rischio sistemico: una CA compromessa

Tutta la PKI poggia sulla fiducia nelle CA. Una CA compromessa o disonesta può emettere un certificato valido per qualsiasi dominio, abilitando un man-in-the-middle che il browser accetterebbe. È un rischio reale, già successo. La difesa è la Certificate Transparency: ogni certificato emesso finisce in log pubblici append-only, così un’emissione fraudolenta per il tuo dominio è visibile e rilevabile, anche se tecnicamente valida. La trasparenza non impedisce l’abuso, ma lo rende impossibile da nascondere — e questo cambia gli incentivi.

Domanda: l'intero sistema poggia sul fidarsi di qualche centinaio di CA che non conosco, inserite nel mio browser da qualcun altro. Non è un modello di fiducia fragile e centralizzato?

Sì, è fragile e in parte centralizzato, e la comunità della sicurezza lo riconosce apertamente — ma è anche il miglior compromesso pratico trovato finora per un problema che, su scala planetaria, non ha soluzioni perfette, e nel tempo è stato rinforzato proprio nei punti che citi. Partiamo dal problema di fondo: miliardi di persone devono poter verificare l'identità di milioni di siti che non hanno mai contattato, senza un incontro preliminare. Qualunque soluzione richiede un punto di partenza di fiducia comune, perché la fiducia non si crea dal nulla. Le alternative teoriche hanno tutte difetti peggiori alla scala: la verifica manuale delle impronte (come SSH al primo accesso) non scala a un web che visiti a centinaia di domini nuovi; la ragnatela di fiducia di PGP, dove ti fidi di chi è fidato dai tuoi contatti, è elegante ma troppo complessa per l'utente medio e con una copertura disomogenea. La PKI gerarchica ha vinto perché delega il lavoro di verifica a entità specializzate e lo ammortizza su tutti. Ora, i difetti che sollevi sono reali e sono stati attaccati su più fronti. Primo, "non conosco quelle CA": vero, ma non sei tu a doverle fidare alla cieca — i gestori dei trust store (i produttori di sistemi operativi e browser) applicano programmi di root rigorosi, con audit, requisiti tecnici e il potere di espellere una CA che si comporta male, cosa successa a CA importanti che hanno emesso certificati impropri. La fiducia non è eterna, è condizionata e revocabile. Secondo, "una CA può emettere per qualsiasi dominio": questo era il buco più grave, ed è proprio ciò che la Certificate Transparency ha chiuso rendendo pubblica e verificabile ogni emissione — un certificato fraudolento per la tua banca non può più essere emesso di nascosto, comparirebbe nei log monitorati. In aggiunta, meccanismi come i record CAA permettono a un dominio di dichiarare quali CA possono emettere per lui, restringendo la superficie. Terzo, la centralizzazione: è mitigata dal fatto che le root sono molte e indipendenti, e che errori di una non compromettono le altre. Resta vero che un attaccante con risorse statali, capace di piegare o compromettere una CA fidata, è una minaccia seria contro cui la PKI da sola non basta — ed è per questo che per i casi ad altissima sensibilità si aggiungono strati come il certificate pinning. Il quadro onesto: la PKI è un modello di fiducia imperfetto e centralizzato, ma sorvegliato, revocabile e reso trasparente, che funziona a una scala dove i modelli più "puri" falliscono. Non è fidarsi ciecamente: è fidarsi di un sistema con controllori, conseguenze e, ora, testimoni pubblici.

Conclusione

La PKI lega chiavi a identità tramite certificati firmati in una catena che risale a poche root fidate; la revoca è il punto debole, mitigato dai certificati a vita breve, e il rischio di una CA compromessa è reso visibile dalla Certificate Transparency. Con questo i mattoni della crittografia applicata sono completi — cifratura, integrità, autenticità, scambio di chiavi, firme e fiducia. Ma tutto questo poggia su problemi matematici che un computer quantistico potrebbe un giorno risolvere. Cosa cambia, e cosa fare già oggi, è l’ultimo capitolo.

Firme digitali: autenticità e non ripudio

Tue, 22 Sep 2026 09:00:00 +0200

Perché conta

Lo scambio di chiavi concorda un segreto ma non autentica. L’HMAC autentica, ma è simmetrico: chi verifica può anche forgiare. La firma digitale è l’autenticazione asimmetrica: si firma con la chiave privata, chiunque verifica con quella pubblica, e chi verifica non può creare firme. È il meccanismo dietro i certificati TLS, la firma del software, i commit firmati, gli aggiornamenti verificati.

Tre garanzie in una

  flowchart LR
    M[Messaggio] --> H["H(messaggio)"]
    H --> S[Firma con<br/>chiave PRIVATA]
    S --> SIG[Firma]
    SIG --> V[Verifica con<br/>chiave PUBBLICA]
    M --> V
    V --> OK{Valida?}
    style S fill:#fde2e4,stroke:#e63946

Una firma valida garantisce contemporaneamente:

Autenticità: viene da chi possiede la chiave privata corrispondente a quella pubblica.
Integrità: il messaggio non è stato alterato (la firma non combacerebbe più).
Non ripudio: il firmatario non può negare di aver firmato — proprietà che l’HMAC non ha, perché lì anche il verificatore conosce la chiave e avrebbe potuto produrre il tag.

Il non ripudio è ciò che distingue la firma dal MAC: con una firma, solo una persona al mondo poteva produrla.

Perché si firma l’hash

Non si firma mai il messaggio intero, ma il suo hash:

1
2
3

firma = Sign(chiave_privata, H(messaggio))
# 1. efficienza: l'asimmetrica è lenta → firmi 32 byte di hash, non 2 GB di file
# 2. la sicurezza della firma eredita dalla resistenza alle collisioni dell'hash

È anche il motivo per cui un hash rotto rovina la firma: se un attaccante trova due messaggi con lo stesso hash (collisione), una firma valida per uno vale anche per l’altro. Per questo le firme usano SHA-256 o più, mai SHA-1.

ECDSA, EdDSA e il pericolo del nonce

Gli algoritmi di firma su curve ellittiche:

ECDSA: lo standard diffuso. Ha un punto delicato: richiede un valore casuale ($k$, un nonce) per ogni firma, e quel valore deve essere unico e imprevedibile.
EdDSA (Ed25519): progettato per eliminare proprio quel rischio. È deterministico (il nonce deriva da chiave e messaggio), veloce, con chiavi corte. È la scelta preferibile oggi.

Il pericolo del nonce in ECDSA non è teorico:

1
2
3

Nonce k riusato o prevedibile in ECDSA → la chiave PRIVATA si ricava dalle firme
  (è successo davvero: console di gioco, wallet — chiavi estratte da firme con k debole)
→ un motivo in più per preferire Ed25519, che rende il nonce deterministico e sicuro by design.

Riusare — o anche solo generare male — il nonce $k$ permette di calcolare la chiave privata partendo dalle firme pubbliche. È accaduto a sistemi reali. EdDSA toglie l’arma dalle mani di chi implementa.

Firma non è cifratura

Un equivoco comune (“firmare = cifrare con la privata”). Concettualmente sono operazioni distinte, con scopi opposti: la cifratura protegge la riservatezza (nasconde), la firma protegge autenticità e integrità (non nasconde nulla, un messaggio firmato è in chiaro). Gli standard moderni le trattano come primitive separate. Usa una libreria che offre “firma” e “verifica” esplicite, non costruzioni fatte a mano.

Domanda: il "non ripudio" vale davvero in pratica? Se qualcuno mi ruba la chiave privata, può firmare a mio nome — quindi come fa una firma a provare che sono stato io?

Hai colto la tensione esatta tra la proprietà crittografica e la proprietà legale/pratica del non ripudio, e vale la pena separarle perché è lì che nascono i fraintendimenti. Dal punto di vista crittografico, il non ripudio afferma una cosa precisa e vera: una firma valida poteva essere prodotta solo da chi possedeva la chiave privata, perché nessun altro — nemmeno chi verifica, a differenza dell'HMAC — è matematicamente in grado di generarla. Questo è forte e reale: la firma lega in modo infalsificabile un messaggio a una specifica chiave privata. Ma, e qui sta il tuo punto, lega il messaggio alla chiave, non direttamente alla persona; il ponte tra "questa chiave" e "questa persona" non è crittografico, è organizzativo e dipende interamente dalla premessa che la chiave privata sia rimasta sotto il controllo esclusivo del suo titolare. Se quella premessa cade — chiave rubata, copiata, usata da un malware, custodita male — allora la firma prova ancora che "la chiave ha firmato", ma non più che "la persona ha voluto firmare". Ecco perché il non ripudio nella pratica non è una proprietà che la matematica ti regala da sola, è il risultato di un sistema attorno alla chiave: custodia in hardware non esportabile (smartcard, HSM, Secure Enclave) così la chiave non lascia mai il dispositivo; protezione d'uso (PIN, biometria) così il possesso del dispositivo non basta; e soprattutto meccanismi di revoca e timestamp. La revoca è decisiva: quando sospetti una compromissione, dichiari la chiave revocata a una certa data, e da quel momento le firme non sono più accettate; i timestamp fidati permettono di stabilire se una firma è stata prodotta prima della revoca (valida) o dopo (da rigettare). È la stessa logica della PKI che vedremo nel prossimo capitolo. Quindi la risposta onesta: la firma fornisce un non ripudio crittografico robusto condizionato alla sicurezza della chiave privata, e trasformarlo in non ripudio affidabile nel mondo reale richiede di proteggere la chiave in modo che "possedere la chiave" coincida davvero con "essere la persona", più l'infrastruttura di revoca per gestire i casi in cui quella coincidenza si rompe. Non è un difetto della firma: è il confine tra ciò che la crittografia può garantire (chi ha la chiave) e ciò che deve garantire il sistema (chi è la persona).

Conclusione

Le firme digitali danno autenticità, integrità e non ripudio: si firma l’hash con la chiave privata, si verifica con la pubblica, e Ed25519 è preferibile a ECDSA perché elimina il rischio del nonce che ha già svuotato chiavi reali. Ma resta il nodo sollevato dal capitolo sull’asimmetrica e qui sul non ripudio: di quale chiave pubblica mi fido, e perché? Legare una chiave a un’identità è il compito della PKI, prossimo capitolo.

Scambio di chiavi e forward secrecy

Tue, 15 Sep 2026 09:00:00 +0200

Perché conta

La crittografia asimmetrica può consegnare una chiave di sessione cifrandola con la chiave pubblica del destinatario. Funziona, ma ha un difetto grave: se un giorno la chiave privata trapela, un attaccante che aveva registrato tutto il traffico passato può ora decifrarlo tutto, retroattivamente. Lo scambio di chiavi Diffie-Hellman offre un modo migliore di concordare un segreto — e, nella sua forma effimera, elimina proprio questo rischio.

Diffie-Hellman: un segreto che non viaggia mai

L’idea è contro-intuitiva: due parti concordano un segreto condiviso parlando su un canale pubblico, senza mai trasmettere il segreto. La metafora dei colori:

  flowchart TD
    A[Alice: colore<br/>segreto a] -->|mescola con base<br/>pubblica| AM[Invia A = mix]
    B[Bob: colore<br/>segreto b] -->|mescola con base<br/>pubblica| BM[Invia B = mix]
    AM --> S[Alice calcola:<br/>B mescolato con a]
    BM --> S2[Bob calcola:<br/>A mescolato con b]
    S --> SEG[Stesso segreto condiviso]
    S2 --> SEG
    style SEG fill:#fde2e4,stroke:#e63946

Ciascuno combina il proprio segreto con il valore pubblico ricevuto dall’altro e arriva allo stesso risultato. Un osservatore vede i valori pubblici scambiati ma non riesce a ricostruire il segreto: è il problema del logaritmo discreto a proteggerlo. In forma matematica, con base $g$ e modulo primo $p$:

$$ (g^a \bmod p)^b \equiv (g^b \bmod p)^a \equiv g^{ab} \bmod p $$

Alice e Bob calcolano lo stesso $g^{ab}$; l’osservatore ha solo $g^a$ e $g^b$ e non può derivarlo. La versione su curve ellittiche, ECDH (con Curve25519), fa lo stesso con chiavi corte e veloci ed è quella usata oggi.

Il vero premio: forward secrecy

Qui sta il salto. Se le chiavi $a$ e $b$ sono effimere — generate nuove per ogni sessione e buttate subito dopo — si ottiene la forward secrecy (o perfect forward secrecy):

1
2
3

Chiave di consegna statica (RSA): registro il traffico oggi, rubo la chiave fra 2 anni → decifro TUTTO
Diffie-Hellman EFFIMERO (ECDHE):  ogni sessione ha un segreto nuovo, già distrutto
  → rubare la chiave di oggi NON decifra le sessioni passate: i loro segreti non esistono più

La forward secrecy spezza il legame tra la compromissione futura e le conversazioni passate. È il motivo per cui il TLS moderno (1.3) usa solo scambi effimeri (ECDHE): registrare traffico cifrato oggi nella speranza di decifrarlo domani — l’attacco “harvest now, decrypt later” — diventa inutile contro le chiavi già distrutte.

DH autentica? No — e serve saperlo

Diffie-Hellman concorda un segreto, ma non autentica chi c’è dall’altra parte. Da solo è vulnerabile al man-in-the-middle: un attaccante nel mezzo fa uno scambio DH con ciascuna parte e le collega. Per questo DH va combinato con l’autenticazione — le firme digitali del prossimo capitolo, che in TLS provano l’identità del server mentre ECDHE stabilisce il segreto. Scambio di chiavi e autenticazione sono due compiti distinti, e servono entrambi.

Domanda: se la forward secrecy è così importante, perché è esistito a lungo (e in parte esiste ancora) il modello con chiave statica senza di essa? Dov'è il compromesso?

Il modello a chiave statica non è sopravvissuto per stupidità, ma per una serie di compromessi concreti che all'epoca pesavano e in parte pesano ancora — ed è utile capirli per vedere perché il vento è definitivamente cambiato. Primo, il costo computazionale: generare una nuova coppia di chiavi effimere a ogni handshake costa CPU, e quando i server erano meno potenti e il traffico HTTPS cresceva, la tentazione di riusare una chiave statica (nessuna generazione per sessione, possibilità di cifrare la chiave di sessione con RSA una volta) era un risparmio reale. Con l'accelerazione hardware e con ECDHE su Curve25519 — velocissimo — questo costo oggi è trascurabile, e l'argomento è caduto. Secondo, e meno ovvio, la visibilità: in molte reti aziendali e data center si erano costruiti strumenti di sicurezza e debugging che decifravano passivamente il traffico TLS possedendo la chiave privata del server — ispezione, IDS, troubleshooting. La forward secrecy rompe deliberatamente questa capacità: proprio perché nessuna chiave statica decifra le sessioni, quegli strumenti passivi smettono di funzionare, e questo ha generato resistenza da parte di chi ci faceva affidamento. La risposta corretta è stata spostare quelle funzioni a un modello diverso (terminazione TLS esplicita su un proxy che partecipa all'handshake, non intercettazione passiva), ma la transizione ha avuto attrito. Terzo, la complessità dello stato: le chiavi effimere vanno generate con buona entropia e gestite correttamente per sessione, e un'implementazione sciatta può introdurre bug. Detto tutto questo, il compromesso oggi è nettamente a favore della forward secrecy, e non per moda: la minaccia "harvest now, decrypt later" è diventata concreta — avversari con risorse registrano oggi traffico cifrato scommettendo di poterlo decifrare domani, per furto di chiave o per i computer quantistici futuri. Contro questa minaccia la chiave statica è un disastro (un furto futuro apre tutto il passato), mentre l'effimero la neutralizza alla radice. Per questo TLS 1.3 ha eliminato gli scambi senza forward secrecy, non li ha solo sconsigliati: il piccolo costo residuo non giustifica più l'enorme rischio retroattivo. Il compromesso esisteva, ma gli sviluppi — hardware veloce, curve efficienti, minacce di lungo periodo — l'hanno risolto in un'unica direzione.

Conclusione

Diffie-Hellman fa concordare un segreto su un canale pubblico senza mai trasmetterlo, ed ECDHE (effimero, su Curve25519) aggiunge la forward secrecy: compromettere una chiave futura non apre le sessioni passate. Ma DH non autentica: va combinato con un meccanismo che provi chi c’è dall’altra parte — firmando con la chiave privata ciò che chiunque può verificare con quella pubblica. Sono le firme digitali, prossimo capitolo.

Crittografia asimmetrica: RSA ed ECC

Tue, 08 Sep 2026 09:00:00 +0200

Perché conta

Tutta la serie finora ha usato chiavi condivise: per cifrare, verificare o autenticare, le due parti dovevano già possedere lo stesso segreto. Ma come fai a condividere quel segreto con un server che non hai mai contattato, su una rete ostile, prima di avere un canale sicuro? È il problema della distribuzione delle chiavi, e per decenni non ha avuto soluzione pratica. La crittografia asimmetrica (a chiave pubblica) lo risolve con un’idea rivoluzionaria: due chiavi diverse ma legate.

Due chiavi, una coppia

  flowchart LR
    GEN[Generazione] --> PUB[Chiave pubblica<br/>la distribuisci a tutti]
    GEN --> PRIV[Chiave privata<br/>la custodisci, segreta]
    PUB -->|cifra / verifica firma| OP[Operazioni]
    PRIV -->|decifra / firma| OP
    style PRIV fill:#fde2e4,stroke:#e63946

Le due chiavi sono matematicamente legate ma non si deducono l’una dall’altra in pratica. Due usi speculari:

Cifratura: chiunque cifra con la tua chiave pubblica; solo tu, con la privata, decifri.
Firma: tu firmi con la privata; chiunque verifica con la pubblica. (Il capitolo sulle firme lo approfondisce.)

La chiave pubblica può stare su un cartellone: la sicurezza sta tutta nel tenere segreta la privata.

La funzione trapdoor

Il cuore matematico è una funzione trapdoor: facile da calcolare in un verso, infattibile all’inverso a meno che tu non abbia un’informazione segreta (la chiave privata). RSA la costruisce sulla fattorizzazione:

$$ n = p \times q $$

Moltiplicare due primi grandi $p$ e $q$ è banale; fattorizzare $n$ per ritrovarli è infattibile se $n$ è abbastanza grande. La chiave pubblica usa $n$; la privata sfrutta la conoscenza di $p$ e $q$. ECC usa invece la difficoltà del logaritmo discreto su curve ellittiche — problema diverso, stessa idea: facile avanti, infattibile indietro.

RSA contro ECC

Sicurezza equivalente a ~128 bit simmetrici:
  RSA  → chiave di ~3072 bit
  ECC  → chiave di ~256 bit   (curva P-256, o Curve25519)
→ ECC ottiene la stessa sicurezza con chiavi molto più piccole: meno banda, meno CPU.

A parità di sicurezza, ECC usa chiavi molto più corte: operazioni più veloci, meno dati da trasmettere, ideale per mobile e per il traffico di rete. Per questo i sistemi moderni preferiscono le curve ellittiche (Curve25519, P-256), riservando RSA ai contesti dove è già radicato. In entrambi i casi: usa dimensioni adeguate (RSA ≥ 3072 bit, curve note e sicure) e librerie affermate.

L’asimmetrica NON sostituisce la simmetrica

Un equivoco diffuso. La crittografia asimmetrica è lenta e adatta solo a piccoli dati, e nessuno cifra un file o un flusso TLS con RSA. Nella pratica si usa un modello ibrido:

Modello ibrido (quello reale, es. TLS):
  1. asimmetrica → concorda/consegna una CHIAVE di sessione simmetrica (piccolo dato)
  2. simmetrica  → cifra tutti i dati veri con AES-GCM (veloce)
→ l'asimmetrica risolve la distribuzione della chiave, la simmetrica fa il lavoro pesante.

L’asimmetrica serve a stabilire il segreto condiviso; poi lavora la simmetrica. I due mondi sono complementari, non in competizione — ed è esattamente così che funziona il TLS.

Domanda: se la chiave pubblica basta per cifrare, come fa chi la riceve a essere sicuro che sia davvero la mia e non quella di un impostore nel mezzo?

Hai messo il dito sul vero limite della crittografia a chiave pubblica: risolve brillantemente la distribuzione del segreto, ma da sola non risolve l'autenticità della chiave pubblica stessa, e senza quella l'intera costruzione è vulnerabile a un attacco man-in-the-middle. Lo scenario è esattamente quello che descrivi: vuoi cifrare per me, ma su una rete ostile un attaccante intercetta la comunicazione e ti consegna la sua chiave pubblica spacciandola per la mia. Tu cifri felicemente con quella, lui decifra con la propria privata, legge (o altera) il messaggio, lo ri-cifra con la mia vera chiave pubblica e me lo inoltra: nessuno dei due si accorge di nulla. La matematica asimmetrica ha funzionato perfettamente — ha solo protetto un dialogo con la persona sbagliata. Il problema, nota, non è crittografico ma di fiducia: come lego una chiave pubblica a un'identità reale di cui mi fido? Esistono due famiglie di risposte, ed entrambe sono argomenti di capitoli successivi di questa serie. La prima è la PKI (public key infrastructure): una terza parte fidata, la Certificate Authority, firma un certificato che attesta "questa chiave pubblica appartiene a questo dominio/identità"; tu ti fidi della chiave perché ti fidi della CA che l'ha firmata, e la catena di fiducia risale fino a radici che il tuo sistema conosce già. È il modello del web e del TLS. La seconda è la verifica fuori banda o su base di fiducia distribuita: confrontare manualmente l'impronta (fingerprint) della chiave attraverso un canale indipendente — come fai, anche senza saperlo, accettando la fingerprint di un host SSH al primo accesso — oppure modelli a ragnatela di fiducia come quello storico di PGP. In ogni caso il punto da portare a casa è che la crittografia asimmetrica sposta il problema dalla "condivisione di un segreto" alla "autenticazione di una chiave pubblica", che è un problema più gestibile ma non banale, e va risolto esplicitamente con la PKI o con la verifica dell'impronta. Una chiave pubblica di cui non puoi verificare l'origine non è ancora sicurezza: è sicurezza in attesa di un'identità fidata a cui agganciarsi.

Conclusione

La crittografia asimmetrica usa due chiavi legate da una funzione trapdoor (RSA sulla fattorizzazione, ECC sul logaritmo discreto): risolve la distribuzione del segreto, con ECC preferibile per le chiavi più corte, e si usa in modello ibrido perché è lenta. Ma cifrare con la chiave pubblica non è il modo migliore di concordare un segreto condiviso: esiste un meccanismo più elegante, che dà anche una proprietà preziosa chiamata forward secrecy. È lo scambio di chiavi, prossimo capitolo.

Password hashing: lentezza come virtù

Tue, 01 Sep 2026 09:00:00 +0200

Perché conta

Abbiamo visto che un hash crittografico è progettato per essere veloce. Per le password questa è la proprietà sbagliata: la velocità lavora per l’attaccante. Salvare le password è il caso d’uso che quasi tutti sbagliano, e lo sbaglio non si vede finché un database non trapela — allora si scopre in un pomeriggio se erano protette davvero o solo in apparenza. Le password richiedono un approccio opposto a tutto il resto della crittografia: la lentezza come virtù.

Cosa NON fare

Password in chiaro          → ovvio disastro
Cifrate (reversibili)       → la chiave è lì vicino; un furto le espone tutte
SHA-256(password)           → miliardi di tentativi/secondo: dizionario esaurito in minuti
SHA-256(password) senza salt → due utenti con la stessa password hanno lo stesso hash

Il punto chiave: quando un database di hash trapela, l’attaccante non “decifra” — indovina. Prova miliardi di candidati (password comuni, dizionari, brute force) e confronta gli hash. Il suo limite è la velocità. Un hash veloce come SHA-256 gli regala miliardi di tentativi al secondo.

Salt: contro il precalcolo

Un salt è un valore casuale, unico per ogni password, memorizzato accanto all’hash (non è segreto). Si hasha salt + password. Due effetti:

  flowchart TD
    A[Senza salt] --> A1[Stessa password<br/>→ stesso hash] --> A2[Rainbow table:<br/>hash precalcolati<br/>riutilizzabili su tutti]
    B[Con salt unico] --> B1[Stessa password<br/>→ hash DIVERSI] --> B2[Precalcolo inutile:<br/>ogni hash va attaccato<br/>singolarmente]
    style A2 fill:#fde2e4,stroke:#e63946
    style B2 fill:#e8f0fe,stroke:#4361ee

Il salt rende inutili le rainbow table (tabelle di hash precalcolati) e impedisce di vedere quali utenti condividono la stessa password. Ma non rallenta i tentativi: per quello serve altro.

Il costo regolabile

Gli algoritmi di password hashing sono deliberatamente lenti e costosi, con un parametro di costo che puoi alzare man mano che l’hardware migliora:

bcrypt: lento, con un fattore di costo (work factor). Collaudato da decenni.
scrypt: lento e avido di memoria (memory-hard), per neutralizzare le GPU.
Argon2: vincitore della Password Hashing Competition, regolabile su tempo, memoria e parallelismo. La variante Argon2id è la raccomandazione di oggi.

L’idea della memory-hardness è cruciale: le GPU e gli ASIC hanno tantissimi core ma poca memoria per core. Un algoritmo che richiede, diciamo, 64 MB per ogni tentativo annulla il vantaggio dell’hardware parallelo, che è l’arma principale dell’attaccante.

Tararlo bene

Obiettivo: un singolo hash impiega ~0,1–0,5s e usa decine di MB di RAM
  → per te (un login) è impercettibile
  → per l'attaccante (miliardi di tentativi) è proibitivo in tempo E in costo hardware
Rivaluta i parametri periodicamente: l'hardware migliora, il costo va alzato.

Il parametro va scelto in base alla tua infrastruttura: abbastanza alto da far male all’attaccante, abbastanza basso da non rendere lento il login legittimo né esporti a un DoS. E va rivisto nel tempo.

Il quadro completo

Password hashing robusto = Argon2id (o bcrypt se Argon2 non è disponibile) + salt unico per utente (gestito automaticamente dalla libreria) + costo tarato e rivisto. E, a monte, ridurre il valore del bersaglio: MFA, segreti gestiti bene, e dove possibile passare a meccanismi senza password. Un database con password Argon2id ben tarate, se trapela, costa all’attaccante molto più di quanto valgano la maggior parte degli account.

Domanda: se il salt è memorizzato in chiaro accanto all'hash, a cosa serve? L'attaccante che ruba il database ha anche i salt.

È vero che l'attaccante ottiene i salt insieme agli hash, e questo confonde molti — ma il salt non è mai stato pensato per essere segreto, e capire a cosa serve davvero chiarisce perché funziona anche se è pubblico. Il salt difende da un attacco specifico: il precalcolo e la condivisione del lavoro tra più password. Senza salt, un attaccante può fare il lavoro una volta sola e riusarlo contro tutti: costruisce in anticipo una gigantesca tabella (rainbow table) che mappa password comuni ai loro hash, e poi, quando ruba un database, confronta semplicemente gli hash rubati con la tabella già pronta — nessun calcolo nuovo, risposta immediata per milioni di account. Peggio, se due utenti hanno la stessa password hanno lo stesso hash, quindi crackarne uno li crackа tutti insieme, e vedi subito chi condivide la password. Il salt unico per utente distrugge entrambe le scorciatoie. Poiché ogni password è hashata con un salt diverso, la tabella precalcolata diventa inutile: dovrebbe esistere una rainbow table separata per ogni salt possibile, cioè miliardi di tabelle, il che è infattibile — il precalcolo collassa. E due utenti con la stessa password ora hanno hash diversi, quindi l'attaccante deve attaccare ogni account singolarmente, da zero, senza riusare nulla. Nota bene cosa il salt fa e cosa non fa: non rallenta il tentativo del singolo hash — quello è compito del costo regolabile di Argon2/bcrypt — ma impedisce all'attaccante di ammortizzare lo sforzo su molte password o di pre-pagarlo prima del furto. Il fatto che sia pubblico non lo indebolisce, perché la sua forza non sta nella segretezza ma nell'essere unico e diverso per ciascuno: costringe l'avversario a fare lavoro fresco e separato per ogni password, invece di un lavoro solo riutilizzabile per tutte. Salt e costo lavorano su assi ortogonali — il salt elimina le scorciatoie orizzontali (tra password), il costo rende caro ogni singolo tentativo verticale — ed è la combinazione dei due a rendere un database rubato poco redditizio da attaccare.

Conclusione

Le password si proteggono con algoritmi lenti e memory-hard — Argon2id oggi — con salt unico per utente e costo tarato e rivisto nel tempo: mai in chiaro, mai cifrate, mai con un hash veloce. Finora tutta la serie ha usato chiavi condivise: la stessa chiave per cifrare e decifrare, per generare e verificare. Ma come fanno due parti che non si sono mai incontrate a condividere una chiave? È il problema che la crittografia asimmetrica risolve, prossimo capitolo.

HMAC e autenticazione dei messaggi

Tue, 25 Aug 2026 09:00:00 +0200

Perché conta

L’hash dimostra che i dati non sono cambiati, ma non chi li ha prodotti: un attaccante che controlla il canale cambia dati e hash insieme. Il MAC (Message Authentication Code) chiude il buco legando l’integrità a una chiave segreta: solo chi la possiede può generare un tag valido, e solo chi la possiede può verificarlo. È la stessa garanzia di autenticità del tag AEAD, ma come primitiva a sé — usata ovunque ci siano token, webhook, API firmate, cookie di sessione.

Hash con chiave: l’idea giusta, l’implementazione sbagliata

L’intuizione è naturale: per autenticare, mescola la chiave segreta con il messaggio e fai l’hash.

1
2
3

Intuizione:  tag = H(chiave || messaggio)
# sembra ragionevole: solo chi ha la chiave produce il tag giusto...
# ...ma con gli hash della famiglia SHA-2 è VULNERABILE: length extension attack

Il problema è un dettaglio della costruzione di molti hash (Merkle–Damgård, come SHA-256): lo stato interno è il digest stesso. Un attaccante che vede H(chiave || messaggio) può estendere il messaggio — aggiungere dati in coda e calcolare un tag valido per chiave || messaggio || extra senza conoscere la chiave. L’intuizione era giusta, la costruzione ingenua no.

HMAC: la costruzione corretta

HMAC risolve il length extension con una doppia applicazione dell’hash e due derivazioni della chiave:

  flowchart LR
    K[Chiave] --> I["ipad ⊕ K"]
    K --> O["opad ⊕ K"]
    M[Messaggio] --> H1["H(ipad⊕K ‖ M)"]
    I --> H1
    H1 --> H2["H(opad⊕K ‖ hash interno)"]
    O --> H2
    H2 --> TAG[Tag HMAC]
    style H2 fill:#fde2e4,stroke:#e63946

L’hash esterno “sigilla” quello interno, rendendo inefficace l’estensione. Il bello è che HMAC usa una qualsiasi funzione di hash come componente: HMAC-SHA256 è lo standard di fatto. Non si implementa a mano — ogni libreria crittografica lo offre pronto.

Il confronto deve essere a tempo costante

Un errore sottile e frequente: verificare il tag con un confronto normale di stringhe.

# SBAGLIATO: '==' si ferma al primo byte diverso → il tempo rivela quanti byte combaciano
if tag_ricevuto == tag_atteso: ...

# GIUSTO: confronto a tempo costante, indipendente da dove differiscono
if hmac.compare_digest(tag_ricevuto, tag_atteso): ...

Un confronto che termina prima quando trova un byte diverso perde pochi microsecondi in meno: misurando quei tempi, un attaccante ricostruisce il tag byte per byte (timing attack). Le librerie offrono un confronto a tempo costante apposta: va usato sempre per dati segreti.

MAC o firma?

Il MAC è simmetrico: la stessa chiave genera e verifica. Chi verifica può anche forgiare. Va benissimo quando le due parti si fidano e condividono il segreto (la tua app che firma i propri token). Quando invece chi verifica non deve poter generare — software distribuito al pubblico, messaggi tra parti che non si fidano — serve l’asimmetria delle firme digitali, più avanti nella serie.

Domanda: se uso già AES-GCM, che è AEAD e autentica, perché dovrei conoscere l'HMAC? Non è ridondante?

Non è ridondante perché risolvono lo stesso bisogno — autenticità e integrità — in contesti diversi, e spesso te ne serve uno dove l'altro non si applica. AES-GCM autentica ciò che cifra: è la scelta giusta quando devi insieme nascondere e proteggere dei dati. Ma moltissimi casi reali richiedono di autenticare qualcosa che non vuoi affatto cifrare, ed è lì che vive l'HMAC. Pensa a un token di sessione o a un JWT firmato: il payload spesso è leggibile di proposito (il client deve sapere chi è, quando scade), ti serve solo garantire che nessuno lo abbia alterato — HMAC sul contenuto, nessuna cifratura. Pensa ai webhook: un servizio esterno ti invia un evento in chiaro e allega un tag HMAC-SHA256 calcolato con un segreto condiviso, così tu verifichi che l'evento venga davvero da lui e non sia stato manomesso in transito; cifrarlo non avrebbe senso, deve poterlo leggere chi lo riceve. Pensa alla firma delle richieste API (lo stile AWS SigV4): firmi gli header e il corpo con HMAC per provare l'autenticità della chiamata, ma il contenuto resta quello che è. In tutti questi casi vuoi autenticità senza riservatezza, e tirare dentro una cifratura AEAD solo per ottenere il tag sarebbe goffo e spesso controproducente. C'è poi la questione del livello di astrazione: AES-GCM è un AEAD che ti dà il tag come sottoprodotto del cifrare, mentre HMAC è la primitiva di autenticazione pura, quella che usi anche come mattone dentro costruzioni più grandi — la derivazione di chiavi (HKDF è costruito su HMAC), i meccanismi di challenge-response, la verifica di integrità di dati già cifrati con altro. In breve: se devi cifrare, usa un AEAD e hai l'autenticazione inclusa; se devi autenticare dati che restano in chiaro — token, webhook, richieste, messaggi tra parti che condividono un segreto — HMAC è lo strumento diretto e corretto. Conoscerli entrambi ti fa scegliere quello giusto invece di piegare l'uno al compito dell'altro.

Conclusione

Il MAC lega integrità e autenticità a una chiave segreta; HMAC è la costruzione corretta che evita il length extension, con HMAC-SHA256 come standard, e va verificato con un confronto a tempo costante. Ma il MAC è simmetrico: chi verifica può forgiare. Un caso particolare di “hash con chiave” merita un capitolo a sé, perché quasi tutti lo sbagliano — proteggere le password, prossimo capitolo.

Hashing e integrità

Tue, 18 Aug 2026 09:00:00 +0200

Perché conta

Il tag AEAD del capitolo precedente ci ha dato un primo assaggio di integrità. Ora il mattone fondamentale: la funzione di hash crittografica. Prende dati di qualsiasi dimensione e produce un’impronta di lunghezza fissa — il digest. È ovunque: verifica dei download, SBOM e firma del software, strutture come i Merkle tree della Certificate Transparency, deduplicazione, blockchain. Sembra banale; le proprietà che la rendono crittografica non lo sono.

Le tre proprietà

Una funzione di hash è crittografica se soddisfa tre proprietà, in difficoltà crescente:

Dato un hash h = H(m):
  1. Resistenza alla preimmagine   → dato h, infattibile trovare m
  2. Resistenza alla 2a preimmagine → dato m, infattibile trovare m' ≠ m con H(m')=H(m)
  3. Resistenza alle collisioni     → infattibile trovare QUALSIASI coppia m≠m' con H(m)=H(m')

La resistenza alle collisioni è la più forte e la più difficile da garantire: non devi trovare un secondo messaggio per uno dato, ma una coppia qualsiasi che collida — e qui il paradosso del compleanno gioca contro di te.

Il paradosso del compleanno

Se l’output ha $n$ bit, ci sono $2^n$ valori possibili. Ingenuamente penseresti che servano $2^n$ tentativi per una collisione. In realtà, per il paradosso del compleanno, ne bastano circa:

$$ 2^{n/2} $$

Un hash da 256 bit offre quindi circa $2^{128}$ di sicurezza contro le collisioni, non $2^{256}$. È il motivo per cui gli hash moderni usano output ampi (256+ bit): la resistenza alle collisioni è metà della lunghezza in bit. Un hash da 128 bit avrebbe solo $2^{64}$ di margine — oggi aggredibile.

L’effetto valanga

Una buona funzione di hash ha l’effetto valanga: cambiare un solo bit dell’input cambia circa metà dei bit dell’output, in modo imprevedibile.

1
2

H("crittografia")  = 1a2b3c... (256 bit)
H("Crittografia")  = f9e8d7... (completamente diverso, pur cambiando 1 bit)

Questo rende impossibile “avvicinarsi” a un digest per tentativi incrementali: non c’è correlazione tra la distanza degli input e quella degli output. È ciò che rende l’hash utile come impronta infalsificabile.

Quale hash usare

Scopo generale (integrità, firme, SBOM):
  SHA-256 / SHA-512   → solido, standard, ovunque
  SHA-3 (Keccak)      → costruzione diversa (sponge), utile come alternativa indipendente
EVITARE per uso crittografico:
  MD5, SHA-1          → collisioni PRATICHE dimostrate. Rotti. Solo per checksum non ostili.

MD5 e SHA-1 non sono “deboli”: sono rotti. Esistono collisioni costruite in pratica (due file diversi con lo stesso hash), quindi non offrono più alcuna garanzia contro un avversario. Vanno eliminati da ogni contesto di sicurezza.

L’errore da evitare: l’hash non autentica

Un hash dimostra che i dati non sono cambiati per caso o che corrispondono a un valore noto. Non dimostra chi li ha prodotti, né li protegge da un attaccante che può cambiare sia i dati sia l’hash. Se pubblichi file + H(file) e un attaccante controlla il canale, sostituisce entrambi. Per legare l’integrità a un segreto (autenticità) serve altro: l’HMAC, prossimo capitolo. E attenzione a un uso sbagliatissimo che tratteremo dopo — l’hash semplice non va usato per le password.

Domanda: se SHA-256 è così solido, perché non usarlo anche per le password invece di algoritmi dedicati come Argon2?

Perché per le password la proprietà che vuoi è l'opposto di quella per cui SHA-256 è progettato, ed è esattamente questa inversione di obiettivo a rendere l'hash generico pericoloso lì. SHA-256 è costruito per essere veloce: deve calcolare l'impronta di gigabyte di dati in un istante, verificare firme e integrità senza rallentare nulla. La velocità è una virtù quando l'hash serve a fare integrità. Ma quando l'hash protegge una password, la velocità diventa il regalo più grande che puoi fare all'attaccante. Pensa a cosa succede quando un database di password trapela: l'attaccante ha gli hash e vuole risalire alle password provando candidati (dizionari, password comuni, brute force su quelle corte). Il suo collo di bottiglia è quanti tentativi al secondo riesce a fare. Con SHA-256, su hardware moderno — e peggio su GPU o ASIC costruiti apposta — parliamo di miliardi di hash al secondo: un dizionario di tutte le password umane plausibili si esaurisce in minuti o ore. Hai usato un hash eccellente e hai protetto quasi nulla, perché la sua velocità lavora per chi attacca. Gli algoritmi di password hashing come Argon2, bcrypt e scrypt fanno la scelta deliberatamente opposta: sono lenti e, nel caso di Argon2 e scrypt, deliberatamente costosi in memoria. Puoi tararli perché un singolo hash impieghi, diciamo, un decimo di secondo e richieda decine di megabyte di RAM: per te che verifichi un login è impercettibile, ma per l'attaccante che deve provare miliardi di candidati diventa proibitivo in tempo e in costo hardware, e il requisito di memoria neutralizza proprio il vantaggio delle GPU, che hanno molti core ma poca memoria per core. In più questi algoritmi integrano il salt per impedire gli attacchi precalcolati (le rainbow table) e il costo regolabile per restare al passo con l'hardware che migliora. In breve: SHA-256 risponde alla domanda "questi dati sono integri?" nel modo più efficiente possibile; le password pongono la domanda opposta, "quanto posso rendere costoso indovinare?", e lì la risposta giusta è un algoritmo progettato per essere lento e avido di memoria. Usare SHA-256 per le password non è un'ottimizzazione, è usare lo strumento costruito per l'obiettivo sbagliato. Lo vedremo in dettaglio nel capitolo sul password hashing.

Conclusione

Una funzione di hash crittografica dà un’impronta fissa con resistenza a preimmagine e collisioni (ridotta a $2^{n/2}$ dal paradosso del compleanno) ed effetto valanga: usa SHA-256/SHA-3, mai MD5 o SHA-1. Ma l’hash garantisce integrità, non autenticità: non dice chi ha prodotto i dati. Per legarli a un segreto condiviso serve aggiungere una chiave all’hash — è l’HMAC, prossimo capitolo.

Cifratura simmetrica e AEAD

Tue, 11 Aug 2026 09:00:00 +0200

Perché conta

La serie parte dal mattone più usato: la cifratura simmetrica, dove la stessa chiave cifra e decifra. È veloce e protegge quasi tutti i dati a riposo e in transito. Ma “uso AES” è una frase incompleta e spesso pericolosa: AES è un cifrario a blocchi, e come lo si applica — la modalità operativa — decide se il sistema è sicuro o completamente rotto.

Il problema delle modalità: ECB

AES cifra blocchi da 16 byte. Un messaggio è più lungo: come si incatenano i blocchi? La modalità più ingenua, ECB, cifra ogni blocco in modo indipendente. Risultato disastroso: blocchi di testo in chiaro identici producono blocchi cifrati identici.

Testo in chiaro con pattern ripetuti (es. un'immagine, dati strutturati)
  ECB  → gli stessi blocchi → gli stessi cifrati → il pattern TRASPARE
  (il famoso "pinguino ECB": cifri l'immagine e la vedi ancora)
→ ECB non nasconde la struttura. NON usare MAI ECB.

La lezione generale: la riservatezza non dipende solo dal cifrario, ma da come lo usi. Serve che testi identici producano cifrati diversi — ottenuto introducendo un valore variabile per ogni cifratura.

Nonce e IV: il valore che cambia tutto

Le modalità sicure usano un nonce (o IV, initialization vector): un valore che rende ogni cifratura unica anche con la stessa chiave e lo stesso testo. La regola ferrea:

Un nonce non si riusa mai con la stessa chiave.

Riusare un nonce rompe la sicurezza in modi gravi e specifici per modalità — in GCM, come vedremo, è catastrofico. Il nonce non è segreto (viaggia in chiaro col messaggio), ma deve essere unico.

AEAD: cifrare e autenticare insieme

Ecco l’errore storico più comune: cifrare senza autenticare. Un cifrato non autenticato può essere modificato da un attaccante senza che te ne accorga — ribaltare bit, troncare, riordinare. La riservatezza non implica l’integrità. La soluzione moderna è AEAD (Authenticated Encryption with Associated Data): cifra e autentica in un’unica operazione.

  flowchart LR
    PT[Testo in chiaro] --> E[AEAD<br/>es. AES-GCM]
    K[Chiave] --> E
    N[Nonce unico] --> E
    AD["Associated data<br/>(header, in chiaro<br/>ma autenticato)"] --> E
    E --> CT[Cifrato]
    E --> TAG[Tag di autenticazione]
    style E fill:#fde2e4,stroke:#e63946

Il tag garantisce che il cifrato (e gli associated data, dati che viaggiano in chiaro ma vanno protetti da manomissione, come un header) non siano stati alterati. In decifratura, se il tag non combacia, l’operazione fallisce invece di restituire dati manomessi. Cifratura e integrità in un colpo solo, senza doverle combinare a mano (dove si sbaglia).

La risposta giusta oggi

Devo cifrare dei dati simmetricamente. Cosa uso?
  AES-GCM                → se hai accelerazione hardware AES (quasi tutti i server/CPU moderni)
  ChaCha20-Poly1305      → se non ce l'hai (mobile, embedded): veloce in software, nessun timing leak
  entrambi sono AEAD: cifratura + autenticazione. Nonce unico per ogni messaggio.
→ NON: ECB (rotto), CBC senza MAC (manipolabile), roll-your-own.

GCM e ChaCha20-Poly1305 sono le due scelte di default. Entrambe AEAD, entrambe standard, entrambe con lo stesso vincolo non negoziabile: nonce unico.

Domanda: perché riusare un nonce in AES-GCM è "catastrofico" e non solo una debolezza minore come in altre modalità?

Perché in GCM il riuso del nonce non degrada la sicurezza gradualmente, la demolisce su due fronti in una volta sola. Primo, la riservatezza, ed è il meccanismo comune a tutte le cifrature a flusso: GCM genera un keystream a partire da chiave e nonce, e cifra facendo lo XOR del testo con quel keystream. Se usi lo stesso nonce con la stessa chiave per due messaggi, generi lo stesso keystream per entrambi; facendo lo XOR dei due cifrati il keystream si cancella e ottieni lo XOR dei due testi in chiaro, da cui, con un po' di analisi, si recuperano i messaggi. Fin qui è il classico disastro del "two-time pad", condiviso con CTR e con ogni cifrario a flusso. Ma GCM aggiunge un secondo crollo, suo specifico e più grave: l'autenticazione. Il tag di GCM è calcolato con una funzione (GHASH) che usa una chiave di autenticazione derivata, e due tag prodotti sotto lo stesso nonce danno all'attaccante abbastanza informazioni per recuperare quella chiave di autenticazione segreta. Una volta che ce l'ha, non può più solo leggere: può forgiare tag validi per messaggi arbitrari di sua scelta, cioè l'intera garanzia di integrità di GCM svanisce, non per i due messaggi incriminati ma in generale per quella chiave. È la differenza che rende il riuso del nonce in GCM una categoria a sé: in CBC un IV prevedibile o riusato indebolisce la riservatezza in modi fastidiosi ma circoscritti; in GCM perdi riservatezza e la capacità di autenticare, e quest'ultima in modo che compromette la chiave di autenticazione per sempre. Ecco perché il vincolo "nonce unico" in GCM non è una buona pratica tra le tante, è la condizione senza la quale la modalità non ha alcuna proprietà di sicurezza. Nei sistemi dove garantire l'unicità è difficile (molte istanze che cifrano in parallelo senza coordinarsi, rischio di riavvii che azzerano un contatore) la pratica è generare il nonce in modo casuale con un margine ampio, o usare varianti pensate apposta per resistere al riuso come AES-GCM-SIV, che degrada in modo molto più clemente se l'unicità viene a mancare.

Conclusione

La cifratura simmetrica protegge la riservatezza, ma la modalità operativa decide tutto: ECB è rotto, cifrare senza autenticare è manipolabile, e la risposta moderna è AEAD (AES-GCM o ChaCha20-Poly1305), con nonce unico come vincolo sacro. AEAD ci ha già dato un assaggio di integrità tramite il tag. Ma l’integrità ha un mattone proprio, più fondamentale e usato ovunque, anche fuori dalla cifratura: le funzioni di hash, prossimo capitolo.