Come la svolta di Whitfield Diffie sulla crittografia a chiave pubblica ha reso possibili HTTPS, la messaggistica sicura e l'identità digitale—spiegato con idee chiave e casi d'uso reali.
Ogni volta che effettui il login in una banca, compri qualcosa online o invii un messaggio privato, stai sfruttando un'idea semplice: puoi condividere informazioni su una rete che altri possono osservare e comunque mantenere segreto ciò che conta.
Ora sembra ovvio, ma prima era un problema pratico. Se due persone volevano usare la crittografia dovevano prima concordare una chiave segreta condivisa. Farlo in modo sicuro richiedeva spesso un corriere fidato, un incontro preordinato o una rete aziendale sicura—opzioni che non scalano per milioni di sconosciuti su internet aperto.
La crittografia a chiave pubblica ha cambiato le regole. Ha introdotto un modo per pubblicare una chiave (chiave pubblica) mantenendo segreta un'altra (chiave privata). Con questa separazione si può iniziare una relazione sicura senza condividere già un segreto. Whitfield Diffie fu una figura centrale nello spingere questa svolta alla luce e nel mostrare perché fosse importante.
Legheremo i concetti principali alle cose che usi davvero:
Avrai spiegazioni in linguaggio semplice, con la giusta intuizione matematica per capire perché i trucchi funzionano—senza trasformare il testo in un manuale. L'obiettivo è far sembrare la crittografia a chiave pubblica meno come magia e più come uno strumento pratico che protegge la vita quotidiana.
Prima della crittografia a chiave pubblica, la comunicazione sicura significava per lo più crittografia simmetrica: entrambi i lati usano la stessa chiave segreta per bloccare e sbloccare i messaggi.
Pensalo come un lucchetto con una sola chiave condivisa. Se tu ed io abbiamo copie della stessa chiave, posso chiudere una scatola, spedirla a te e tu puoi aprirla. Bloccare e sbloccare è semplice—a condizione che entrambi abbiamo già quella chiave.
Il problema è ovvio: come condividiamo la chiave in modo sicuro? Se la mando via email, qualcuno potrebbe intercettarla. Se la testo, stesso problema. Se la metto in una busta sigillata e la spedisco, può funzionare una tantum, ma è lento, costoso e non sempre affidabile.
Questo crea un problema tipo "uovo o gallina":
La crittografia simmetrica funziona bene quando ci sono poche persone e un modo fidato per scambiarsi le chiavi in anticipo. Ma su internet aperto si rompe rapidamente.
Immagina un sito che necessita di connessioni private con milioni di visitatori. Con solo chiavi simmetriche, il sito avrebbe bisogno di una chiave segreta diversa per ogni visitatore, più un modo sicuro per consegnarla. Il numero di chiavi e la logistica per gestirle (crearle, conservarle, ruotarle, revocarle) diventano un onere operativo enorme.
Questo non significa che la crittografia simmetrica sia “cattiva”. È eccellente in ciò che fa: crittografia veloce ed efficiente per grandi quantità di dati (come la maggior parte di ciò che viene inviato via HTTPS). La sfida pre-Diffie non era la velocità—era il pezzo mancante: un modo pratico per sconosciuti di concordare un segreto senza averlo già condiviso.
All'inizio degli anni '70, la comunicazione sicura significava soprattutto segreti condivisi. Se due persone volevano usare la crittografia, avevano bisogno della stessa chiave segreta—e dovevano trovare un modo sicuro per scambiarsela prima. Questo approccio funzionava in ambienti piccoli e controllati, ma non scalava in un mondo dove sconosciuti potevano dover comunicare in modo sicuro.
Whitfield Diffie era un giovane ricercatore affascinato dalla privacy e dai limiti pratici della crittografia dell'epoca. Si collegò con Martin Hellman a Stanford, e il loro lavoro fu influenzato dall'interesse accademico crescente per la sicurezza informatica e le reti—campi che stavano passando da sistemi isolati a sistemi connessi.
Non fu tanto la storia di un genio solitario quanto l'incontro dell'idea giusta con l'ambiente giusto: ricercatori che confrontavano appunti, esploravano esperimenti mentali e mettevano in discussione vincoli “ovvi” accettati da decenni.
La svolta di Diffie e Hellman fu l'idea che la crittografia potesse usare due chiavi correlate invece di un segreto condiviso:
Ciò che rende potente questa separazione non è solo la presenza di due chiavi—è che hanno compiti diversi. La chiave pubblica è pensata per la distribuzione sicura, mentre la chiave privata è concepita per il controllo e l'esclusività.
Questo cambio di prospettiva risolse il problema della condivisione. Invece di organizzare un incontro segreto (o un corriere fidato) per scambiarsi una chiave segreta, si poteva pubblicare una chiave pubblica ampiamente e mantenere comunque la sicurezza.
Quel passaggio—da “dobbiamo condividere un segreto prima” a “possiamo iniziare in modo sicuro con informazioni pubbliche”—è il fondamento concettuale che poi ha reso possibili la navigazione web sicura, la messaggistica criptata e i sistemi di identità digitale moderni.
Diffie–Hellman (DH) è un metodo intelligente per due persone per creare lo stesso segreto condiviso anche quando tutti i loro messaggi sono visibili a chiunque. Quel segreto condiviso può poi essere usato come una normale chiave simmetrica per criptare una conversazione.
Pensate al DH come mescolare ingredienti in modo facile da fare in avanti, ma estremamente difficile da “smontare”. La ricetta usa:
Un eavesdropper può vedere i parametri pubblici e i due valori pubblici scambiati. Quello che non può fare in modo praticabile è recuperare i valori privati o calcolare il segreto condiviso a partire solo da quei pezzi pubblici. Con parametri ben scelti, invertire il processo richiederebbe quantità irrealistiche di potenza di calcolo.
DH non cripta i messaggi da solo—crea la chiave condivisa che rende possibile la crittografia quotidiana veloce.
La crittografia a chiave pubblica funziona perché alcune operazioni matematiche sono asimmetriche: sono facili da eseguire in una direzione, ma estremamente difficili da annullare senza un'informazione speciale.
Un modello utile è la “funzione unidirezionale”. Immagina una macchina che trasforma un input in un output rapidamente. Chiunque può usare la macchina, ma dato solo l'output, risalire all'input originale non è realisticamente possibile.
In crittografia non ci affidiamo al segreto della macchina. Ci basiamo sul fatto che invertirla richiederebbe risolvere un problema difficile—un problema che si crede richieda una quantità impraticabile di calcolo.
“Difficile” non significa impossibile per sempre. Significa:
La sicurezza si basa quindi su assunzioni (ciò che matematici e crittografi credono sui problemi) più pratica reale (dimensioni delle chiavi, implementazioni sicure e standard aggiornati).
Molta matematica a chiave pubblica avviene “modulo” un numero—pensalo come un orologio.
Su un orologio a 12 ore, se sono le 10 e aggiungi 5 ore, non ottieni 15; torni alle 3. Quel comportamento di avvolgimento è l'aritmetica modulare.
Con numeri grandi, operazioni ripetute con avvolgimento possono creare output che sembrano confusi. Andare avanti (fare l'aritmetica) è veloce. Tornare indietro (capire da dove si è partiti) può essere dolorosamente lento a meno di conoscere una scorciatoia segreta—come una chiave privata.
Questa lacuna facile-avanti, difficile-indietro è il motore dietro lo scambio di chiavi e le firme digitali.
Quando vedi il lucchetto nel browser stai generalmente usando HTTPS: una connessione cifrata tra il tuo dispositivo e un sito. Il web non avrebbe potuto scalare a miliardi di connessioni sicure se ogni browser dovesse condividere una chiave segreta con ogni server in anticipo.
La crittografia a chiave pubblica risolve il problema del “primo contatto”: permette al tuo browser di stabilire in modo sicuro un segreto condiviso con un server che non ha mai incontrato.
Un handshake TLS moderno è una negoziazione rapida che imposta privacy e fiducia:
Le operazioni a chiave pubblica sono più lente e pensate per accordo e autenticazione, non per il trasferimento massivo di dati. Una volta che TLS ha stabilito chiavi di sessione, passa a crittografia simmetrica veloce (come AES o ChaCha20) per proteggere tutto ciò che invii—richieste di pagine, password e cookie.
Se vuoi la differenza in parole semplici tra HTTP e HTTPS, vedi /blog/https-vs-http.
Una firma digitale è lo strumento a chiave pubblica per rendere un messaggio verificabile. Quando qualcuno firma un file o un messaggio con la sua chiave privata, chiunque può verificare la firma usando la corrispondente chiave pubblica.
Una firma valida dimostra due cose:
Queste due idee vengono spesso confuse:
Puoi fare l'una senza l'altra. Per esempio, un annuncio pubblico può essere firmato (così le persone possono fidarsi) senza essere cifrato (perché è destinato a essere leggibile da tutti).
Le firme digitali compaiono in contesti che potresti usare quotidianamente:
Il vantaggio principale è che la verifica non richiede la condivisione di un segreto. Il firmatario conserva la chiave privata, mentre la chiave pubblica può essere distribuita largamente. Questa separazione—privata per firmare, pubblica per verificare—permette agli sconosciuti di validare messaggi su scala senza dover prima stabilire una password o una chiave segreta condivisa.
La crittografia a chiave pubblica risolve “come condividiamo segreti”, ma lascia un'altra domanda: a chi appartiene davvero questa chiave? Una chiave pubblica da sola è solo un numero lungo. Serve un modo per collegare in modo affidabile quella chiave a un'identità reale come “la mia banca” o “il server email di questa azienda”.
Un certificato digitale è un documento firmato che dice, in pratica: “Questa chiave pubblica appartiene a questa identità.” Include il nome del sito o dell'organizzazione (e altri dettagli), la chiave pubblica e date di scadenza. La parte importante è la firma: una terza parte fidata firma il certificato così il tuo dispositivo può verificare che non sia stato alterato.
Quella terza parte è solitamente una Certificate Authority (CA). Il browser e il sistema operativo includono una lista di radici CA fidate. Quando visiti un sito, il sito presenta il suo certificato più eventuali certificati intermedi, formando una catena di fiducia fino a una root CA che il tuo dispositivo già si fida.
Quando digiti l'URL della banca e vedi l'icona del lucchetto, il browser ha verificato che:
Se questi controlli passano, TLS può usare in sicurezza quella chiave pubblica per l'autenticazione e per aiutare a stabilire la cifratura.
PKI non è perfetta. Le CA possono sbagliare o essere compromesse, portando a emissioni errate (un certificato per la parte sbagliata). I certificati scadono, il che è utile per la sicurezza ma può interrompere l'accesso se non rinnovati. La revoca (segnalare al mondo che un certificato non è più affidabile) è complicata su scala internet, e i browser non sempre la applicano in modo coerente.
La messaggistica end-to-end punta a una promessa semplice: solo le persone nella conversazione possono leggere i messaggi. Né il fornitore dell'app, né l'operatore, né chiunque osservi la rete dovrebbero poterli leggere.
La maggior parte delle chat moderne bilancia tre obiettivi:
La crittografia ha bisogno di chiavi. Ma due persone che non si sono mai incontrate non dovrebbero dover condividere un segreto in anticipo—altrimenti si ritorna al problema iniziale.
La crittografia a chiave pubblica risolve il passo di setup. In molti sistemi E2EE, i client usano uno scambio basato su chiave pubblica (nello spirito del Diffie–Hellman) per stabilire segreti condivisi su una rete non fidata. Quei segreti alimentano poi la crittografia simmetrica veloce per il traffico dei messaggi.
La forward secrecy significa che l'app non si affida a una chiave lunga per tutto. Invece, rinnova continuamente le chiavi nel tempo—spesso per sessione o persino per messaggio—così compromettare una chiave non sblocca tutta la cronologia.
Questo è il motivo per cui “rubare il telefono oggi, decriptare anni di chat domani” è molto più difficile quando la forward secrecy è fatta correttamente.
Anche con crittografia forte, la vita reale aggiunge attriti:
Sotto il cofano, la messaggistica sicura è in gran parte una storia di scambio e gestione delle chiavi—perché questo trasforma “crittografato” in “privato, anche sulla rete”.
L'identità digitale è la versione online di “chi sei” quando usi un servizio: il tuo account, il tuo login e i segnali che provano che sei davvero tu (non qualcuno che ha indovinato o rubato la password). Per anni i sistemi hanno trattato la password come quella prova—semplice, familiare e anche facile da phishing, riutilizzare, perdere o forzare.
La crittografia a chiave pubblica offre un approccio diverso: invece di dimostrare di conoscere un segreto condiviso (una password), dimostri di controllare una chiave privata. La tua chiave pubblica può essere memorizzata dal sito o dall'app, mentre la chiave privata rimane con te.
Con il login basato su chiavi, il servizio invia una sfida (un pezzo di dati casuale). Il tuo dispositivo la firma con la chiave privata. Il servizio verifica la firma con la tua chiave pubblica. Nessuna password attraversa la rete e non c'è nulla di riutilizzabile che un attaccante possa rubare da un modulo di login.
Questa idea alimenta le moderne esperienze “passwordless”:
L'identità a chiave pubblica funziona anche per le macchine. Per esempio, un client API può firmare le richieste con una chiave privata e il server le verifica con la chiave pubblica—utile per l'autenticazione service-to-service dove i segreti API condivisi sono difficili da ruotare e facili da perdere.
Se vuoi un approfondimento sul rollout reale e sull'UX, vedi /blog/passwordless-authentication.
La crittografia a chiave pubblica è potente, ma non è magia. Molti fallimenti reali non avvengono perché la matematica è rotta, ma perché i sistemi intorno a essa lo sono.
La casualità debole può distruggere tutto silenziosamente. Se un dispositivo genera nonce o chiavi prevedibili (soprattutto durante l'avvio, in macchine virtuali o hardware IoT limitato), gli attaccanti possono ricostruire i segreti.
La implementazione scorretta è un'altra causa frequente: usare algoritmi obsoleti, saltare la validazione dei certificati, accettare parametri deboli o gestire male gli errori. Anche piccole scorciatoie “temporanee”—come disattivare i controlli TLS per il debug—spesso arrivano in produzione.
Il phishing e l'ingegneria sociale bypassano la crittografia completamente. Se un utente viene ingannato ad approvare un login, rivelare un codice di recupero o installare malware, chiavi forti non bastano.
Le chiavi private devono essere archiviate in modo da non poter essere copiate facilmente (idealmente in hardware sicuro) e protette a riposo con cifratura. I team devono anche pianificare backup, rotazione e revoca—perché le chiavi si perdono, i dispositivi vengono rubati e le persone lasciano le aziende.
Se i flussi sicuri sono confusi, le persone troveranno soluzioni alternative: condividere account, riutilizzare dispositivi, ignorare avvisi o salvare codici di recupero in posti insicuri. Un buon design della sicurezza riduce i “punti decisionali” e rende l'azione sicura la più semplice.
Se stai costruendo e distribuendo software rapidamente, il rischio maggiore non è spesso la crittografia—è la configurazione incoerente tra ambienti. Piattaforme come Koder.ai (una piattaforma vibe-coding per creare app web, server e mobile da un'interfaccia chat) possono accelerare la delivery, ma le stesse basi a chiave pubblica rimangono valide:
In breve: costruire più velocemente non cambia le regole—le idee di Diffie continuano a sostenere come la tua app guadagni fiducia al primo contatto.
La svolta di Diffie non ha solo aggiunto un nuovo strumento—ha cambiato l'assunzione predefinita della sicurezza da “dobbiamo incontrarci prima” a “possiamo iniziare a parlare in modo sicuro su una rete aperta.” Quel singolo cambiamento ha reso pratico per miliardi di dispositivi e sconosciuti creare segreti, provare identità e costruire fiducia su scala globale.
Lo scambio Diffie–Hellman originale è ancora una base, ma la maggior parte dei sistemi moderni usa versioni aggiornate.
L'Elliptic-curve Diffie–Hellman (ECDH) mantiene lo stesso obiettivo—accordarsi su un segreto in pubblico—usando chiavi più piccole e operazioni più veloci. RSA, sviluppata poco dopo il lavoro di Diffie, divenne famosa per cifratura e firme nell'era iniziale della sicurezza web; oggi la si usa con più cautela, mentre firme su curve ellittiche ed ECDH sono comuni.
Quasi tutte le implementazioni reali sono uno schema ibrido: i metodi a chiave pubblica gestiscono l'handshake (autenticazione e accordo di chiave), poi la crittografia simmetrica veloce protegge i dati. Quel pattern è il motivo per cui HTTPS può essere sia sicuro che veloce.
I futuri computer quantistici potrebbero indebolire le tecniche a chiave pubblica odierne (soprattutto quelle basate sulla fattorizzazione e sui log discreti). La direzione pratica è “aggiungere nuove opzioni e migrare in modo sicuro”, non sostituire tutto subito. Molti sistemi stanno testando scambi di chiavi e firme post-quantistiche mantenendo design ibridi in modo da ottenere nuove protezioni senza puntare tutto su un solo algoritmo.
Anche se gli algoritmi cambiano, il problema fondamentale resta: scambiare segreti e fiducia tra parti che potrebbero non essersi mai incontrate—velocemente, globalmente e con il minor attrito possibile per l'utente.
Punti chiave: la crittografia a chiave pubblica abilita il primo contatto sicuro; gli ibridi la rendono pratica su scala; la prossima era sarà un'evoluzione attenta.
Letture successive: /blog/diffie-hellman-explained, /blog/tls-https-basics, /blog/pki-certificates, /blog/post-quantum-crypto-primer
La crittografia simmetrica usa una chiave segreta condivisa per criptare e decriptare. È veloce ed eccellente per grandi quantità di dati, ma ha un problema di configurazione: bisogna avere un modo sicuro per condividere quella chiave in anticipo.
La crittografia a chiave pubblica divide i ruoli in una chiave pubblica (condivisibile) e una chiave privata (da mantenere segreta), il che rende possibile il “primo contatto sicuro” senza un segreto pre-condiviso.
Ha risolto il problema della distribuzione delle chiavi: due sconosciuti possono iniziare una comunicazione sicura su una rete osservabile senza incontrarsi per scambiarsi una chiave segreta.
Questo cambio di paradigma rende praticabile la sicurezza su scala internet per:
Diffie–Hellman (DH) è un metodo per creare un segreto condiviso su un canale pubblico.
In pratica:
DH di per sé non cripta i messaggi; aiuta ad accordarsi sulla chiave che lo farà.
Non da solo. DH fornisce accordo di chiave, ma non dimostra con chi stai comunicando.
Per prevenire attacchi man-in-the-middle, DH viene di solito abbinato ad autenticazione, come:
TLS usa la crittografia a chiave pubblica principalmente per autenticazione e accordo di chiave durante l'handshake, poi passa a chiavi simmetriche per i dati.
Una vista semplificata:
Una firma digitale permette a qualcuno di provare di aver creato qualcosa e che non è stato modificato.
Usi tipici includono:
Si verifica con una chiave pubblica; solo il possessore della può creare una firma valida.
Un certificato lega una chiave pubblica a un'identità (come il nome di un sito) tramite la firma di un emittente fidato.
I browser si fidano dei certificati perché possono costruire una catena dal certificato del sito, attraverso intermedi, fino a una root CA fidata installata nel sistema operativo/browser.
Operativamente, per questo motivo il rinnovo del certificato, la corretta configurazione dell'hostname e la validazione sono critici per il funzionamento affidabile di HTTPS.
Le app E2EE devono comunque trovare un modo per stabilire chiavi condivise tra dispositivi che non si sono scambiati segreti prima.
Spesso usano scambi in stile DH (spesso con curve ellittiche) per:
Le passkey (FIDO2/WebAuthn) sostituiscono il login con password usando una firma challenge–response.
In pratica:
Questo riduce phishing e riuso delle credenziali perché non esiste un segreto riutilizzabile da digitare in un modulo web.
La maggior parte dei fallimenti riguarda implementazione e operazioni, non la matematica di base.
Errori comuni:
Regola pratica: usa librerie e impostazioni consolidate e tratta la gestione delle chiavi come un requisito di sistema di prima classe.
