La svolta di Whitfield Diffie sulle chiavi pubbliche per il web e l'identità

Perché la crittografia a chiave pubblica ha cambiato la sicurezza di tutti i giorni

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.

Cosa imparerai in questa guida

Legheremo i concetti principali alle cose che usi davvero:

• Il web (HTTPS/TLS): come il tuo browser può comunicare in modo sicuro con un sito che non ha mai visto prima.
• Messaggistica sicura: perché la crittografia end-to-end si basa su uno scambio di chiavi come primo passo.
• Identità digitale: come il “provare chi sei” può andare oltre le password usando chiavi e firme.

Quanto sarà tecnico?

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 di Diffie: il problema della condivisione delle chiavi in parole semplici

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.

Crittografia simmetrica, con un'analogia semplice

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 della distribuzione delle chiavi

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":

• Per comunicare in modo sicuro, abbiamo bisogno di una chiave segreta condivisa.
• Per condividere quella chiave in modo sicuro, abbiamo già bisogno di un canale sicuro.

Perché peggiora a scala internet

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.

Dove la crittografia simmetrica è ancora eccellente

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.

Whitfield Diffie e l'idea centrale di chiave pubblica vs privata

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.

Le persone e il momento

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.

L'intuizione centrale: dividere la chiave in due ruoli

La svolta di Diffie e Hellman fu l'idea che la crittografia potesse usare due chiavi correlate invece di un segreto condiviso:

• Una chiave pubblica che può essere condivisa apertamente.
• Una chiave privata che deve essere mantenuta segreta dal proprietario.

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à.

Dallo scambio di segreti ai sistemi a chiave aperta

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.

Scambio di chiavi Diffie–Hellman: concordare un segreto in pubblico

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.

L'idea centrale (senza matematica pesante)

Pensate al DH come mescolare ingredienti in modo facile da fare in avanti, ma estremamente difficile da “smontare”. La ricetta usa:

• un insieme pubblico di parametri che tutti possono conoscere (come uno “stile di ricetta” condiviso)
• una scelta privata casuale da ciascuna parte (il loro ingrediente segreto)

Passo dopo passo

1. Impostazione pubblica: Alice e Bob concordano parametri pubblici. Non sono segreti e possono essere riutilizzati da molti.
2. Scelte private: Alice crea un nuovo valore privato casuale. Bob fa lo stesso.
3. Condivisioni pubbliche: Alice calcola un valore pubblico derivato dal suo privato e dai parametri pubblici e lo invia a Bob. Bob fa lo stesso.
4. Stesso segreto su entrambi i lati: Usando il valore pubblico di Bob + il valore privato di Alice, Alice calcola un segreto condiviso. Usando il valore pubblico di Alice + il valore privato di Bob, Bob calcola lo stesso segreto.

Cosa può vedere un attaccante (e perché funziona lo stesso)

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.

Considerazioni pratiche importanti

• Parametri: I sistemi reali usano gruppi DH standardizzati e analizzati (o la versione moderna su curve ellittiche, ECDH) per evitare configurazioni deboli.
• Freshness: Usare nuovi valori privati usa e getta per sessione dà forward secrecy—il traffico passato resta sicuro anche se una chiave permanente viene compromessa in seguito.
• Casualità: I valori privati devono essere veramente imprevedibili; una casualità debole può compromettere l'intero scambio.

DH non cripta i messaggi da solo—crea la chiave condivisa che rende possibile la crittografia quotidiana veloce.

L'intuizione matematica: facile da fare, difficile da invertire

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.

Funzioni unidirezionali e “problemi difficili"

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.

Cosa significa davvero “difficile"

“Difficile” non significa impossibile per sempre. Significa:

• Fattibile: puoi farlo con i computer e budget di oggi (secondi, minuti, magari ore).
• Inattuabile: il costo è così alto che non vale la pena tentare (anni fino a milioni di anni di tempo di calcolo, enorme consumo energetico, hardware massiccio).

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).

Sidebar opzionale: aritmetica modulare in parole semplici

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.

Come questo abilita HTTPS: cosa usa TLS della chiave pubblica

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.

TLS in passi semplici (cosa succede in un handshake)

Un handshake TLS moderno è una negoziazione rapida che imposta privacy e fiducia:

1. Hello e opzioni: Il browser si connette e comunica quali versioni e algoritmi supporta.
2. Il server prova l'identità (di solito): il server invia un certificato contenente la sua chiave pubblica. Il browser verifica se quel certificato si ricongiunge a un emittente di fiducia.
3. Accordo di chiave in pubblico: usando un accordo autenticato come (EC)DHE, entrambe le parti creano un segreto condiviso. Un intercettatore può osservare lo scambio ma non calcolare lo stesso segreto.
4. Derivazione delle chiavi di sessione: il segreto viene trasformato in chiavi a breve durata per cifratura e integrità.
5. Inizio del traffico cifrato: da questo momento la connessione è protetta.

Perché la chiave pubblica la avvia e poi prende il sopravvento la crittografia simmetrica

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.

Firme digitali: provare chi l'ha inviata (e che non è stata modificata)

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:

• Autenticità: è stata creata dal possessore della chiave privata (il mittente atteso).
• Integrità: il contenuto non è stato alterato dopo la firma.

Crittografia vs firma: privacy vs prova

Queste due idee vengono spesso confuse:

• Crittografia riguarda la privacy. Nasconde il contenuto così che solo il destinatario previsto possa leggerlo.
• Firma riguarda la prova. Non necessariamente nasconde nulla; applica un sigillo che evidenzia alterazioni e che può essere verificato in seguito.

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).

Dove vedi le firme nella vita reale

Le firme digitali compaiono in contesti che potresti usare quotidianamente:

• Aggiornamenti software: il dispositivo verifica che un aggiornamento sia firmato dal fornitore e non sia stato modificato.
• Contratti e PDF: la firma può provare chi ha approvato un documento e che la versione firmata è quella concordata.
• Firma delle email (S/MIME o PGP): i destinatari possono verificare che l'email provenga davvero da te e non sia stata modificata in transito.

Fiducia senza condividere un segreto

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.

Certificati e PKI: trasformare le chiavi in identità fidate

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”.

Cos'è un certificato (e perché esiste)

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.

Certificate Authority e catene di fiducia

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.

Un esempio familiare: il “lucchetto” sul sito della banca

Quando digiti l'URL della banca e vedi l'icona del lucchetto, il browser ha verificato che:

• il certificato corrisponde al nome del sito che stai visitando
• il certificato è valido e non scaduto
• la catena porta a una CA fidata
• il server può dimostrare di controllare la chiave privata corrispondente alla chiave pubblica del certificato

Se questi controlli passano, TLS può usare in sicurezza quella chiave pubblica per l'autenticazione e per aiutare a stabilire la cifratura.

Limiti e fallimenti da ricordare

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.

Messaggistica sicura: lo scambio di chiavi al centro della E2EE

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.

Cosa cerca di ottenere la messaggistica sicura

La maggior parte delle chat moderne bilancia tre obiettivi:

• Riservatezza: i messaggi sono illeggibili agli estranei.
• Autenticità & integrità: puoi sapere che il messaggio proviene davvero dal tuo contatto e non è stato alterato.
• Forward secrecy: se una chiave viene rubata in seguito, i messaggi passati restano protetti.

Perché lo scambio di chiavi è il primo passo

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.

Forward secrecy in parole semplici

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.

Gli ostacoli nell'esperienza utente che la gente percepisce

Anche con crittografia forte, la vita reale aggiunge attriti:

• Verifica delle chiavi: numeri di sicurezza/QR code sono efficaci, ma molti utenti li saltano.
• Backup: i backup cifrati sono complessi—backup facili possono minare la E2EE se le chiavi non sono gestite correttamente.
• Nuovi dispositivi e ripristini: cambiare telefono, ripristinare account o aggiungere un laptop può innescare ri-keying e avvisi confusi su “codici di sicurezza cambiati”.

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”.

Identità digitale: dalle password al login basato su chiavi

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.

Login senza password in parole semplici

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”:

• Passkey (FIDO2/WebAuthn): il tuo telefono o laptop conserva la chiave privata, spesso protetta da biometria o PIN. Autentichi approvando una richiesta e il dispositivo firma la sfida.
• Chiavi basate su dispositivi: hardware sicuro (come TPM o Secure Enclave) può generare e proteggere chiavi private in modo che non possano essere copiate via come una password testuale.

Oltre i login umani: identità API

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.

Cosa può andare storto: implementazione, chiavi e fattori umani

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.

Rischi comuni (le parti “noiose” che rompono la sicurezza)

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.

Gestione delle chiavi: la chiave privata è il gioiello della corona

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.

Usabilità vs sicurezza (senza incolpare gli utenti)

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.

Linee guida pratiche per i team di prodotto

• Usa librerie e impostazioni consolidate; evita di scrivere crittografia personalizzata.
• Applica impostazioni TLS moderne e valida i certificati correttamente.
• Genera chiavi con un CSPRNG provato; aggiungi controlli di stato e monitoraggio.
• Conserva le chiavi private nei keystore OS o in HSM; limita l'export.
• Progetta il recupero con cura: deve essere sicuro, limitato in intensità e verificabile.
• Pianifica rotazione e risposta agli incidenti (cosa succede se una chiave perde segretezza?).
• Tratta il phishing come requisito centrale: aggiungi binding al dispositivo, controlli step-up e prompt utente chiari.

Dove questo incontra i workflow moderni di sviluppo (incluso Koder.ai)

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:

• Quando distribuisci un'app sotto un dominio personalizzato, assicurati che TLS sia configurato correttamente end-to-end e che i certificati si rinnovino automaticamente.
• Considera chiavi private e chiavi di firma come segreti di produzione: tienile fuori dal controllo del codice sorgente, limita gli accessi e preferisci store gestiti.
• Usa snapshot e rollback intenzionalmente: sono ottimi per il recupero rapido, ma assicurati che la rotazione dei segreti e lo stato dei certificati non si disallineino tra i rollback.
• Se esporti il codice sorgente, mantieni gli stessi standard: default TLS moderni, validazione rigorosa dei certificati e nessuna disattivazione temporanea per il debug.

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.

L'impatto duraturo e cosa aspetta la crittografia a chiave pubblica

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.

Successori moderni: stessa idea, migliore efficienza

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.

Post-quantistico: prepararsi, non andare nel panico

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.

Cosa resta costante

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