Tim Hudson, Presidente di OpenSSL Corporation – Serie di Interviste

Tim Hudson è coautore di SSLeay e uno degli organizzatori della OpenSSL Conference, Praga 13-15 ottobre 2026. Ha oltre 30 anni di esperienza in sicurezza di sistemi e reti ed è Presidente di OpenSSL Corporation e Chief Technology Officer presso Cryptsoft Pty Ltd. Dal 1995, il suo lavoro ha incluso la cofondazione di SSLeay con Eric Young, la libreria crittografica che è divenuta la OpenSSL Library, la cofondazione del centro di sviluppo RSA Security Australia, il contributo a modifiche alle normative statunitensi sull’esportazione della crittografia, la conduzione di più di 30 convalide FIPS 140, la co‑presidenza dei comitati tecnici OASIS KMIP e SAM, e interventi alle principali conferenze di sicurezza, tra cui RSA Conference, AusCERT, ICMC, LinuxConf e la OpenSSL Conference.

OpenSSL è un progetto globale collaborativo open source che sviluppa e mantiene la OpenSSL Library, una delle librerie crittografiche più diffuse al mondo. Utilizzata su sistemi operativi, piattaforme cloud, software aziendali e dispositivi connessi, la OpenSSL Library aiuta a proteggere quotidianamente miliardi di interazioni online sicure. Attraverso la OpenSSL Foundation e OpenSSL Corporation, il progetto si impegna a promuovere una crittografia affidabile, a sostenere lo sviluppo sostenibile dell’open source e a rafforzare la sicurezza di Internet.

Hai cofondato SSLeay con Eric Young nel 1995 dopo aver riconosciuto la necessità di un’implementazione non statunitense di SSL, e quel lavoro è diventato alla fine la base di OpenSSL. Quale problema stavi cercando di risolvere originariamente, e avevi qualche intuizione all’epoca che la tecnologia potesse diventare così fondamentale per la sicurezza di Internet.

Il problema era del tutto concreto, ed era prima di tutto commerciale. Lavoravo per Mincom a Brisbane, e avevamo clienti che dovevano proteggere le loro comunicazioni. Non c’era modo di acquistare tale capacità. I controlli statunitensi sull’esportazione della crittografia significavano che i prodotti americani o non potevano essere forniti a noi, o venivano forniti con dimensioni di chiave così limitate che il loro impiego sarebbe stato disonesto. Non si trattava di un’obiezione filosofica alla politica di esportazione. Era un problema di ingegneria in cui il componente di cui avevo bisogno non esisteva in alcuna forma acquistabile, e avevo clienti in attesa.

Quello che avevo era la conoscenza di qualcosa che la maggior parte delle persone aveva dimenticato. Eric Young aveva scritto qualche anno prima un’implementazione DES: codice buono, pulito, liberamente disponibile, scritto per il gusto di farlo e completamente estraneo a tutto ciò. Eric non stava lavorando su SSL. Non era a conoscenza di SSL. Quando Netscape pubblicò la specifica, la lessi, andai da Eric con il problema e lo presentai come un passo relativamente modesto rispetto a quello a cui era già arrivato.

Questo non era l’intero quadro. Ogni parte era lineare, ma c’era un numero significativo di parti. Un’implementazione DES fornisce un cifrario simmetrico. SSL richiede crittografia a chiave pubblica, aritmetica a precisione arbitraria, ASN.1, gestione dei certificati X.509 e una macchina a stati del protocollo, il tutto corretto, perché in crittografia quasi corretto e rotto sono la stessa cosa. Avevo presentato la scala del progetto in modo ottimista. Eric capì presto quanto fosse esteso, e lo apprezzò, perché la dimensione si rivelò l’attrattiva piuttosto che l’ostacolo. Non sono sicuro che sarebbe iniziato in altro modo.

Lui si occupò del nucleo crittografico, motivo per cui la libreria porta le sue iniziali. Io mi occupai delle parti che trasformano una libreria in qualcosa che altri possono effettivamente distribuire: l’integrazione applicativa, i test, la documentazione e l’aspetto comunitario. Cercai attivamente ogni luogo in cui fosse in uso una libreria di crittografia concorrente e la convertii o sostituii. SSLtelnet, SSLftp, NCSA httpd e molti altri pacchetti furono il mio lavoro, applicazioni costruite sopra gli algoritmi e i protocolli crittografici implementati da Eric. Questa combinazione ci permise a ciascuno di concentrarci su ciò che realmente ci interessava, il che credo sia la ragione principale per cui il progetto continuò.

Essere in Australia è stato ciò che ha reso possibile la soluzione, e poi si è scoperto che moltissime altre persone avevano esattamente lo stesso problema per lo stesso motivo. Qualcosa costruito per soddisfare un requisito specifico di un cliente a Brisbane è diventato utile a tutti al di fuori degli Stati Uniti, e alla fine anche a molte persone all’interno di essi.

Sapevamo cosa sarebbe diventato? No. Nessuno si propone di costruire un’infrastruttura critica. L’infrastruttura critica è ciò che scopri di aver costruito, qualche anno dopo, quando scopri chi ne dipende. Quello che pensavamo di fare era risolvere un problema davanti a noi e poi rispondere alle domande di altre persone che avevano incontrato lo stesso ostacolo. La parte di risposta alle domande si rivelò importante quanto il codice.

Hai lavorato nella crittografia e nella sicurezza di Internet per più di tre decenni. Qual è stato il cambiamento più drammatico nel panorama delle minacce durante quel periodo, e quali problemi di sicurezza sono rimasti sorprendentemente simili nonostante enormi progressi tecnologici?

Il cambiamento più grande è che l’attacco ai sistemi è diventato una professione con un modello economico alla base. A metà degli anni ’90, le persone che violavano i sistemi lo facevano principalmente perché era interessante. Oggi c’è un’industria, con specializzazione, strumenti, catene di fornitura, supporto clienti e, in alcuni casi, finanziamenti statali. Questo cambia tutto il modo di pensare, perché non si difende più dalla curiosità, ma da qualcuno con un budget, una scadenza e un caso d’uso commerciale.

Il secondo cambiamento è la scala e la dipendenza. L’applicazione media nel 1995 era qualcosa che scrivevi. L’applicazione media oggi è qualcosa che assembli, e la maggior parte del codice è stata scritta da persone che non hai mai incontrato e non puoi nominare. La superficie di attacco è passata dal tuo codice alle tue dipendenze, e la maggior parte delle organizzazioni non ha adeguato il proprio pensiero di conseguenza.

Ciò che è rimasto sorprendentemente costante sono i modi di fallimento. Continuiamo a scrivere bug in codice che analizza input non attendibili. Continuiamo a distribuire sistemi con impostazioni predefinite che nessuno ha rivisto. I certificati scadono ancora di sabato. Le credenziali finiscono ancora in luoghi dove non dovrebbero essere. E la crittografia è ancora quasi mai violata a livello matematico. Viene aggirata, configurata in modo errato, o semplicemente non attivata. Se mi avessi dato una lista delle dieci cause principali di violazioni del 1996 e una lista di quello del mese scorso, avresti difficoltà a distinguerle. La tecnologia si è trasformata completamente. Gli errori no.

OpenSSL 4.0 è stato rilasciato ad aprile 2026, segnando il primo importante rilascio del progetto in diversi anni. Cosa ci dice questo rilascio su dove si sta dirigendo l’infrastruttura crittografica, e quali cambiamenti pensi saranno alla fine i più importanti per le organizzazioni che dipendono da OpenSSL?

La cosa più utile da capire su 4.0 è che è principalmente un rilascio di sottrazione, ed è proprio questo il suo scopo.

Abbiamo rimosso completamente l’interfaccia ENGINE. Abbiamo rimosso SSLv3 e il ClientHello di SSLv2. Abbiamo disabilitato le curve ellittiche deprecate e le curve EC esplicite al momento della compilazione. Abbiamo reso ASN1_STRING opaco e rafforzato numerose firme API. Questi sono i cambiamenti che generano lavoro per le persone, e sono i cambiamenti che contano, perché una libreria crittografica che si limita ad accumulare non può rimanere sicura. Ogni percorso di codice deprecato che mantieni attivo è una superficie di attacco che qualcuno mantiene per tuo conto e nessuno testa.

Ci sono aggiunte: Encrypted Client Hello, supporto RFC 8998 includendo il gruppo ibrido SM2/ML‑KEM, cSHAKE, KDF per SNMP e SRTP, FFDHE negoziato per TLS 1.2. L’ECH in particolare colma una reale lacuna di privacy, perché Server Name Indication ha trapelato l’identità di ogni sito visitato sin dal rilascio di TLS 1.3. Ma le rimozioni sono la storia.

Il messaggio che vorrei che le organizzazioni colgessero è questo: 4.0 non è la versione LTS. È supportata fino a maggio 2027. L’attuale versione stabile a lungo termine è la 3.5, supportata fino ad aprile 2030, e la 3.5 include già gli algoritmi post‑quantistici. Se vuoi il codice più recente, usa la 4.0. Se vuoi un obiettivo stabile su cui costruire un piano di migrazione quinquennale, usa la 3.5. Scegliere il numero più alto solo perché è più alto è un errore che vediamo ripetuto ogni ciclo.

La crittografia post‑quantistica è passata da un problema di ricerca a una sfida di migrazione, con OpenSSL che supporta già ML‑KEM, ML‑DSA e SLH‑DSA e lo scambio di chiavi ibrido post‑quantistico. Per i leader aziendali che presumono che il calcolo quantistico sia ancora troppo lontano per preoccuparsene, quali rischi stanno trascurando oggi?

L’errore più comune è trattare la questione come se riguardasse il momento in cui arriverà un computer quantistico rilevante per la crittografia. Questa è la variabile sbagliata. La domanda giusta è per quanto tempo i tuoi dati devono rimanere riservati, e quanto tempo impiegherà la tua migrazione. Sottraendo il secondo dal primo ottieni la tua scadenza reale, e per molte organizzazioni quella scadenza è già nel passato.

Il traffico cifrato può essere catturato oggi e conservato indefinitamente. Se le informazioni in esso contenute hanno un orizzonte di sensibilità di vent’anni (cartelle cliniche, file del personale, proprietà intellettuale, materiale diplomatico, posizioni finanziarie), allora un avversario non ha bisogno di un computer quantistico ora. Ne avrà bisogno eventualmente, e nel frattempo dispone di archiviazione a basso costo. Non si tratta di un attacco speculativo; è una decisione di archiviazione.

La seconda cosa trascurata è che la migrazione non è un unico progetto. Lo scambio di chiavi è la parte più semplice, e gran parte di esso è già in corso: OpenSSL 3.5 ha reso lo scambio di chiavi ibrido post‑quantistico il valore predefinito di TLS, così molte organizzazioni stanno già usando accordi di chiavi post‑quantistici senza averne ancora deciso l’adozione. Le firme e la gerarchia dei certificati sono la parte difficile, perché coinvolgono autorità di certificazione, radici hardware di fiducia, chiavi di firma del firmware, moduli di sicurezza hardware e dispositivi con una vita operativa di quindici anni, costruiti sull’assunzione che RSA sarebbe stato valido per sempre.

La terza cosa è la limitazione per cui nessuno prevede un budget: le firme post‑quantistiche sono grandi. Una firma ML‑DSA‑65 è circa cinquanta volte più grande di una firma ECDSA P‑256, e SLH‑DSA è ancora più grande. Questo rompe le cose: dimensioni dell’handshake, dispositivi con risorse limitate, protocolli con limiti di campo codificati, collegamenti satellitari e IoT. Si scoprono questi problemi testando, non leggendo uno standard.

Una delle sfide della migrazione post‑quantistica è che le organizzazioni potrebbero non sapere nemmeno dove la crittografia è utilizzata nelle loro applicazioni, infrastrutture, dispositivi e dipendenze di terze parti. Come dovrebbero le aziende affrontare l’inventario crittografico e la crypto‑agilità affinché la prossima grande transizione algoritmica non diventi un’emergenza?

Iniziate con una verità scomoda: non potete creare un inventario crittografico inviando ai vostri fornitori un questionario. Riceverete una mescolanza di testi di marketing, incertezze sincere e risposte valide tre versioni fa. Lo dico avendo trascorso molto tempo recentemente a leggere la documentazione dei fornitori hardware in un settore correlato, e il divario tra ciò che la documentazione afferma e ciò che un prodotto effettivamente fa è più ampio di quanto la maggior parte degli acquirenti immagini.

Bisogna guardare. Ci sono tre livelli, e richiedono tecniche diverse. Codice che avete scritto: analisi statica, scansione delle dipendenze e ricerca delle stringhe degli identificatori di algoritmo che avete codificato anni fa. Codice che avete collegato: bill of materials software, esteso ai bill of materials crittografici, dove il lavoro CBOM è realmente utile. Cose che avete acquistato o connesso: osservazione di rete, perché ciò che i vostri sistemi negoziano realmente sul filo è la verità di base e spesso non è ciò che qualcuno credeva.

Sull’agilità, il principio è semplice ma la pratica no: l’algoritmo dovrebbe essere una decisione di configurazione, non una modifica al codice. Se cambiare un cifrario richiede un sviluppatore, una compilazione, un ciclo di test e un rilascio, non avete agilità. Avete un progetto. Centralizzate le operazioni crittografiche dietro un’interfaccia che controllate, così da avere un unico punto da modificare anziché quattrocento.

E poi la parte che quasi tutti saltano: mettetela alla prova. Un’agilità mai usata è una affermazione, non una capacità. Scegliete un fine settimana tranquillo, disattivate un algoritmo in un ambiente non di produzione e scoprite cosa si rompe. Qualcosa si romperà. È meglio scoprirlo secondo il vostro programma che durante una transizione d’emergenza imposta.

Una funzione costruttiva utile è la durata dei certificati. L’industria sta passando a certificati dalla vita molto più breve, il che rende la gestione manuale dei certificati insostenibile e costringe all’automazione di cui avreste comunque avuto bisogno. Se automatizzate correttamente l’emissione e la rotazione dei certificati, avrete costruito la maggior parte dell’infrastruttura necessaria per una futura transizione algoritmica.

L’IA sta cambiando sia la difesa della cybersicurezza sia le capacità a disposizione degli aggressori. Dove credi che l’IA cambi realmente l’equazione della sicurezza, e dove pensi che le organizzazioni si concentrino troppo sulla tecnologia trascurando debolezze più fondamentali?

L’IA cambia realmente una cosa, e posso parlarne direttamente perché è accaduta a noi.

Un numero considerevole di vulnerabilità divulgate in OpenSSL quest’anno è stato scoperto tramite analisi guidata dall’IA. A gennaio abbiamo rilasciato una versione che correggeva dodici problemi, praticamente tutti provenienti da un unico gruppo di ricerca che usava analisi automatizzata, e hanno fornito patch insieme ai report. A giugno abbiamo risolto un uso dopo liberazione (use‑after‑free) di gravità elevata nella verifica PKCS#7 trovato da un ricercatore che lavorava con un sistema IA. Questo rappresenta un reale cambiamento di capacità nel trovare bug di sicurezza della memoria e di parsing in codice C maturo, rivisto da esperti per anni. Ho osservato lo stesso schema in altre librerie crittografiche. Analizzando un lotto di CVE di Bouncy Castle di quest’anno, l’impronta dell’analisi automatizzata del codice è evidente.

L’implicazione ovvia è che questo taglia in entrambe le direzioni. Le stesse tecniche sono disponibili a chiunque voglia usarle, sugli stessi codici, e i difensori non hanno accesso esclusivo.

L’implicazione meno ovvia, e quella che sottolineerei, è l’onere che impone ai manutentori. Generare un report di vulnerabilità plausibile è ormai quasi gratuito. Valutarne uno non lo è. Richiede ancora il tempo reale di un esperto umano. I team di sicurezza open source, di solito piccoli e spesso volontari, stanno assorbendo un volume crescente di segnalazioni di qualità molto variabile. Le buone, come la ricerca citata, arrivano con riproduttori e patch. Le cattive sono un attacco denial‑of‑service alle persone da cui dipendete. Se la vostra organizzazione utilizza l’IA contro il codice open source, finanziate la capacità di triage all’altro capo.

Dove penso che l’attenzione sia mal riposta: l’IA non corregge i vostri sistemi. Non fa l’inventario dei vostri asset, non ruota le vostre credenziali, non ritira l’hardware non supportato, né rende responsabile qualcuno per il certificato che scade il prossimo mese. Le organizzazioni che acquistano strumenti di sicurezza IA mentre eseguono software con vulnerabilità note non corrette hanno l’ordine sbagliato. Il lavoro poco appariscente è ancora dove si trova il rischio.

Molte organizzazioni investono molto in strumenti ma rimangono vulnerabili a causa di errori di configurazione, sistemi obsoleti, processi deboli o scarsa preparazione agli incidenti. Quali sono gli errori di sicurezza più consequenziali che continui a osservare, e cosa dovrebbero avere in atto i team di leadership prima che si verifichi un attacco?

L’errore più consequenziale è trattare la sicurezza come un’attività di approvvigionamento. Gli strumenti vengono acquistati, i budget sono rispettati, i cruscotti sono verdi, e nessuno si è chiesto se l’organizzazione possa effettivamente fare le cose fondamentali.

Il secondo è non sapere cosa si sta eseguendo. Non si può patchare software di cui non si è a conoscenza, e la maggior parte delle organizzazioni scopre il vero contenuto del proprio patrimonio durante un incidente. Ecco perché il lavoro sul bill of materials è importante, non come artefatto di conformità ma come ciò a cui si ricorre alle due del mattino quando arriva un avviso critico e qualcuno chiede se si è interessati.

Il terzo sono le impostazioni predefinite. I sistemi vengono installati, funzionano, e la configurazione non viene mai rivista. Cinque anni dopo quella configurazione è una responsabilità, e nessuno coinvolto nella decisione originale lavora più lì.

Il quarto è la gestione di chiavi e certificati lasciata a singoli individui. Una notevole percentuale di interruzioni auto‑inflitte sono certificati scaduti che una persona teneva silenziosamente sotto controllo in un foglio di calcolo fino a cambiare lavoro.

Prima di un incidente, la leadership ha bisogno di quattro cose in atto. Un decisore nominato con l’autorità di mettere offline l’attività, deciso in anticipo e per iscritto, perché la discussione su chi abbia quell’autorità non è qualcosa che si vuole affrontare in tempo reale. Accordi già firmati con esperti forensi esterni e consulenti specialisti, perché quell’approvvigionamento richiede settimane e voi avrete solo ore. Un canale di comunicazione che non dipenda dai sistemi che potrebbero essere compromessi. E una capacità di ripristino che sia stata effettivamente testata end‑to‑end, non un regime di backup verificato solo nel senso che i lavori sono stati completati con successo.

Poi provatelo. Un esercizio tabletop a livello esecutivo, una volta all’anno, evidenzierà più lacune reali rispetto a un altro strumento.

Quando si verifica un grave attacco informatico, i dirigenti possono improvvisamente trovarsi a prendere decisioni tecniche, legali, operative e di comunicazione sotto enorme pressione. Cosa separa le organizzazioni che rispondono efficacemente da quelle che permettono a un incidente di peggiorare notevolmente?

Le organizzazioni che gestiscono bene la situazione hanno preso le decisioni importanti prima dell’incidente, così durante l’incidente eseguono piuttosto che deliberare. Questo è il punto principale.

Oltre alla preparazione, alcune cose separano costantemente le buone risposte da quelle cattive.

Separano l’indagine tecnica dal percorso esecutivo e di comunicazione, con un’interfaccia definita tra i due. Quando le stesse persone cercano di contenere un’intrusione e redigere una notifica al cliente, entrambi i compiti vengono svolti male.

Preservano le prove prima di intervenire. L’istinto di ricostruire immediatamente la macchina compromessa è forte e distrugge le informazioni necessarie per definire l’ambito. Se non potete rispondere a “cos’altro hanno toccato”, non potete dire credibilmente a nessuno che l’incidente è finito.

Accettano che le informazioni iniziali siano provvisorie e comunicano di conseguenza. La maggior parte del danno reputazionale che ho osservato non è derivato dalla violazione, ma da dichiarazioni iniziali sicure che hanno dovuto essere ritirate. Dire “ecco cosa sappiamo, ecco cosa non sappiamo ancora, ecco quando vi aggiorneremo” non è una debolezza. È l’unica posizione che non dovrete invertire.

E, cosa fondamentale: creano condizioni in cui gli ingegneri possono dire ai dirigenti cattive notizie. Il modello di fallimento che ho più spesso osservato è un’organizzazione in cui l’esposizione legale era così evidente che nessuno voleva essere la persona che scriveva ciò che era realmente accaduto. L’incidente peggiora così in silenzio. Se i vostri ingegneri gestiscono la propria responsabilità invece dell’incidente, avete un problema di governance che nessuna quantità di strumenti potrà risolvere.

OpenSSL occupa una posizione insolita come infrastruttura open source critica usata in tutto l’ecosistema tecnologico, mentre OpenSSL Corporation si concentra sul servire le comunità commerciali insieme alla OpenSSL Foundation operata in modo indipendente. Come bilanci le esigenze di imprese, sviluppatori, regolatori e della più ampia comunità open source quando le decisioni su sicurezza e compatibilità possono influenzare una così ampia parte di Internet?

La risposta onesta è che non li bilanciate cercando di rendere felici tutti in ogni decisione. Li bilanciate avendo una politica pubblicata e applicandola in modo prevedibile, così le persone possono pianificare intorno a voi anche quando non gradiscono un risultato specifico.

La prevedibilità è ciò che dobbiamo ai nostri utenti. Rilasciamo versioni con nuove funzionalità ad aprile e ottobre. Annunciamo in anticipo quale versione è a lungo termine stabile e fino a quando. Annunciamo rimozioni significative molto prima che avvengano. La rimozione dell’ENGINE in 4.0 è stata descritta pubblicamente mesi prima del rilascio, ed è stata concordata sia dalla Corporation che dalla Foundation. Chi è rimasto sorpreso ad aprile non aveva prestato attenzione, e noi l’abbiamo resa il più semplice possibile da seguire.

La risposta strutturale è la separazione stessa. La Foundation esiste per servire la libreria open source e la comunità che la circonda. La Corporation esiste per servire le organizzazioni con requisiti commerciali (impegni di supporto, convalida FIPS, scadenze specifiche) e per rendere l’intero progetto finanziariamente sostenibile. Mantenere queste entità distinte significa che nessuno dei due insiemi di esigenze viene risolto silenziosamente a favore dell’altro. Quando i requisiti aziendali e quelli della comunità confliggono realmente, il conflitto avviene tra due organizzazioni con mandate chiare, non nella mente di una sola persona.

L’altra parte è ascoltare correttamente, il che richiede meccanismi concreti piuttosto che supposizioni. Questo è un grande motivo per cui organizziamo the conference, che si svolge a Praga questo ottobre, e perché esiste l’infrastruttura della comunità. È molto facile per i manutentori sviluppare teorie sicure su ciò di cui gli utenti hanno bisogno. È molto più utile essere in una stanza con loro.

10. Guardando al prossimo decennio, quale transizione di sicurezza o crittografica credi che le organizzazioni stiano ancora sottovalutando oggi, e quali lezioni dall’evoluzione di SSL, OpenSSL e dagli ultimi 30 anni di sicurezza di Internet dovrebbero i leader applicare mentre si preparano a essa?

La transizione che penso sia più sottovalutata non è la crittografia post‑quantistica come problema di algoritmo. È l’identità delle macchine e la gerarchia dei certificati che sta sotto tutto.

Lo scambio di chiavi post‑quantistico sarà in gran parte risolto dalle impostazioni predefinite, e gran parte di esso è già avvenuto. Ciò che non sarà risolto dalle impostazioni predefinite è l’infrastruttura di fiducia: certificati radice in hardware, chiavi di firma del firmware incise nei dispositivi, HSM con un decennio di vita residua, sistemi industriali e medici che saranno ancora operativi nel 2040 con assunzioni crittografiche incorporate in fabbrica. Questi non possono essere aggiornati semplicemente distribuendo una nuova versione della libreria, e in alcuni casi non possono essere aggiornati affatto. La scala di questo problema di sostituzione non è attualmente riflessa nella pianificazione di capitale di nessuno.

In parallelo c’è una transizione normativa. Il Cyber Resilience Act in Europa, e quadri comparabili altrove, cambierà gli obblighi legati alla distribuzione di software con componenti che non avete scritto. La maggior parte delle organizzazioni non ha ancora valutato cosa significhi per la loro dipendenza dall’open source, o per le persone che lo mantengono.

Tre lezioni da trent’anni:

1. Le transizioni richiedono un decennio più del previsto. SSLv3 è stato deprecato nel 2015, disabilitato per impostazione predefinita nel 2016, e noi abbiamo finalmente rimosso il codice nell’aprile 2026. Sono undici anni, per un protocollo che tutti concordavano fosse rotto. Pianificate la migrazione post‑quantistica tenendo conto di questa realtà, non del comunicato stampa.
2. Le impostazioni predefinite sono l’unico controllo di sicurezza che funziona su larga scala. Qualsiasi cosa che richieda a ogni amministratore di prendere una decisione corretta non avverrà. Il motivo per cui lo scambio di chiavi ibrido post‑quantistico è stato distribuito così rapidamente è che è attivo per impostazione predefinita e non richiede alcuna decisione. Progettate per le persone che non leggeranno mai la vostra documentazione, perché sono quasi tutti.
3. Dipendete da meno persone di quanto pensiate. Quasi ogni organizzazione sulla Terra si affida a codice crittografico mantenuto da un numero molto piccolo di individui. Questo era vero quando eravamo in due a Brisbane, e la struttura non è cambiata fondamentalmente anche se le poste in gioco sono aumentate di ordini di grandezza. Qualunque cosa stiate pianificando per il prossimo decennio, una sua parte dipende da un manutentore che non avete mai contattato e che non finanziate. È utile saperlo prima di averne bisogno.