Tim Hudson, Președinte al OpenSSL Corporation – Seria de Interviuri

Tim Hudson este coautor al SSLeay și unul dintre organizatorii OpenSSL Conference, Praga, 13‑15 octombrie 2026. Are peste 30 de ani de experiență în securitatea sistemelor și a rețelelor și este Președinte al OpenSSL Corporation și Director Tehnic la Cryptsoft Pty Ltd. Din 1995, activitatea lui a inclus co‑fondarea SSLeay împreună cu Eric Young, biblioteca criptografică care a devenit OpenSSL Library, co‑fondarea centrului de dezvoltare RSA Security Australia, contribuții la modificările reglementărilor de export ale criptografiei din SUA, conducerea a peste 30 de validări FIPS 140, co‑președintă a comitetelor tehnice OASIS KMIP și SAM și prezentări la conferințe de securitate de top, inclusiv RSA Conference, AusCERT, ICMC, LinuxConf și OpenSSL Conference.

OpenSSL este un proiect global colaborativ open source care dezvoltă și întreține OpenSSL Library, una dintre cele mai utilizate biblioteci criptografice din lume. Folosită pe scară largă în sistemele de operare, platformele cloud, software‑ul enterprise și dispozitivele conectate, biblioteca OpenSSL ajută la protejarea zilnică a miliardelor de interacțiuni online securizate. Prin intermediul OpenSSL Foundation și OpenSSL Corporation, proiectul se angajează să promoveze criptografia de încredere, să susțină dezvoltarea sustenabilă a open source și să consolideze securitatea internetului.

Tu ai co‑fondat SSLeay cu Eric Young în 1995 după ce ai recunoscut nevoia pentru o implementare non‑US a SSL, iar acea lucrare a devenit în cele din urmă fundația pentru OpenSSL. Ce problemă încercai inițial să rezolvi și aveai la acea vreme vreo idee că tehnologia ar putea deveni o parte atât de fundamentală a securizării internetului?

Problema era complet concretă și era una comercială înainte de a fi altceva. Eram la Mincom în Brisbane și aveam clienți care aveau nevoie să securizeze comunicațiile lor. Nu exista nicio modalitate de a achiziționa acea capacitate. Controalele de export ale SUA asupra criptografiei însemnau că produsele americane fie nu puteau fi furnizate deloc, fie veneau cu dimensiuni de cheie atât de restricționate încât utilizarea lor ar fi fost necinstită. Nu era o obiecție filozofică la politica de export. Era o problemă de inginerie în care componenta de care aveam nevoie nu exista în nicio formă pe care să o pot cumpăra, iar clienții așteptau.

Ceea ce dețineam era cunoașterea unui lucru pe care majoritatea oamenilor îl uitaseră. Eric Young scrisese câțiva ani mai devreme o implementare DES: cod bun, curat, disponibil gratuit, scris de dragul său și complet nelegat de această situație. Eric nu lucra la SSL. Nu era conștient de SSL. Când Netscape a publicat specificația, am citit‑o, m‑am adresat lui Eric cu problema și i‑am prezentat‑o ca un pas relativ modest față de ceea ce deja făcea.

Aceasta nu era întreaga imagine. Fiecare parte era simplă, dar existau un număr semnificativ de părți. O implementare DES îți oferă un cifru simetric. SSL necesită criptografie cu cheie publică, aritmetică cu precizie arbitrară, ASN.1, gestionarea certificatelor X.509 și o mașină de stare a protocolului, toate corecte, deoarece în criptografie aproape că corect și defect sunt același lucru. Am prezentat scala optimist. Eric a înțeles repede cât de mare era, și a îmbrățișat‑o, pentru că dimensiunea s‑a dovedit a fi atracția, nu obstacolul. Nu sunt sigur că ar fi început altfel.

El a realizat nucleul criptografic, motiv pentru care biblioteca poartă inițialele sale. Eu am preluat părțile care transformă o bibliotecă într‑un lucru pe care alții îl pot implementa: integrarea aplicațiilor, testarea, documentația și partea de comunitate. Am căutat activ oriunde era folosită o bibliotecă de criptare concurentă și am convertit sau înlocuit‑o. SSLtelnet, SSLftp, NCSA httpd și multe alte pachete au fost munca mea, aplicații construite pe baza algoritmilor și protocoalelor criptografice implementate de Eric. Această combinație ne‑a permis fiecăruia să ne concentrăm pe ceea ce ne interesa cu adevărat, ceea ce cred că este motivul principal pentru care a continuat.

Faptul că eram în Australia a făcut posibilă rezolvarea problemei, iar apoi s‑a dovedit că mulți alți oameni aveau exact aceeași problemă din același motiv. Ceva construit pentru a satisface o cerință specifică a unui client din Brisbane a devenit util pentru toată lumea din afara Statelor Unite și, în cele din urmă, pentru mulți oameni și în interiorul acestora.

Știam ce va deveni? Nu. Nimeni nu își propune să construiască infrastructură critică. Infrastructura critică este ceea ce descoperi că ai construit, câțiva ani mai târziu, când afli cine se bazează pe ea. Ceea ce credeam că facem era să rezolvăm o problemă în fața noastră și apoi să răspundem la întrebările altor persoane care întâmpinau același obstacol. Partea de răspuns la întrebări s‑a dovedit la fel de importantă ca și codul.

Ai lucrat în criptografie și securitatea internetului de peste trei decenii. Ce s‑a schimbat cel mai dramatic în peisajul amenințărilor în această perioadă și care probleme de securitate au rămas surprinzător de similare în ciuda avansurilor enorme în tehnologie?

Singura schimbare majoră este că atacarea sistemelor a devenit o profesie cu un model economic în spate. La mijlocul anilor ’90, oamenii care pătrundeau în sisteme o făceau în mare parte pentru că era interesant. Astăzi există o industrie, cu specializări, unelte, lanțuri de aprovizionare, suport pentru clienți și, în unele cazuri, finanțare de stat. Acest lucru schimbă totul în modul în care trebuie să gândești, pentru că nu te mai aperi împotriva curiozității. Te aperi împotriva cuiva care are un buget, un termen limită și un caz de afaceri.

A doua schimbare este scala și dependența. Aplicația medie din 1995 era ceva ce scriai tu. Aplicația medie de astăzi este ceva ce asamblezi, iar majoritatea codului din ea a fost scris de oameni pe care nu i‑ai întâlnit niciodată și nu îi poți numi. Suprafața de atac s‑a mutat de la codul tău la dependențele tale, iar majoritatea organizațiilor nu și‑a ajustat gândirea în consecință.

Ceea ce a rămas remarcabil de constant sunt modurile de eșec. Încă scriem erori în codul care analizează intrări neîncredere. Încă livrăm sisteme cu setări implicite pe care nimeni nu le‑a revizuit. Certificatele încă expiră într‑o sâmbătă. Creditele încă ajung în locuri în care nu ar trebui să fie. Și criptografia încă nu este ruptă la nivel matematic. Este ocolită, configurată greșit sau pur și simplu nu este activată. Dacă mi‑ai da o listă cu primele zece cauze principale ale încălcărilor din 1996 și una din luna trecută, ai avea dificultăți să le deosebești. Tehnologia s‑a transformat complet. Greșelile nu.

OpenSSL 4.0 a fost lansat în aprilie 2026, marcând prima versiune majoră a proiectului în câțiva ani. Ce ne spune această versiune despre direcția infrastructurii criptografice și ce schimbări crezi că vor conta cu adevărat pentru organizațiile care depind de OpenSSL?

Cel mai util lucru de înțeles despre 4.0 este că este în primul rând o versiune de reducere, și acesta a fost scopul ei.

Am eliminat complet interfața ENGINE. Am eliminat SSLv3 și SSLv2 ClientHello. Am dezactivat curbele eliptice depreciate și curbele EC explicite la compilare. Am făcut ASN1_STRING opac și am restrâns un număr mare de semnături API. Acestea sunt schimbările care generează muncă pentru oameni și sunt schimbările care contează, deoarece o bibliotecă criptografică care doar acumulează nu poate rămâne sigură. Orice cale de cod depreciată pe care o păstrezi activă reprezintă o suprafață de atac pe care cineva o menține în numele tău și nimeni nu o testează.

Există adăugiri: Encrypted Client Hello, suport pentru RFC 8998 inclusiv grupul hibrid SM2/ML‑KEM, cSHAKE, KDF‑uri SNMP și SRTP, negociere FFDHE pentru TLS 1.2. ECH în special închide o lacună reală de confidențialitate, deoarece Server Name Indication a scurgerat identitatea fiecărui site pe care îl vizitezi de la livrarea TLS 1.3. Dar eliminările sunt povestea.

Punctul pe care aș dori ca organizațiile să îl rețină este următorul: 4.0 nu este versiunea LTS. Este susținută până în mai 2027. Versiunea curentă cu suport pe termen lung este 3.5, susținută până în aprilie 2030, și 3.5 include deja algoritmii post‑cuantic. Dacă vrei cel mai nou cod, rulează 4.0. Dacă vrei o țintă stabilă în jurul căreia să construiești un plan de migrare de cinci ani, rulează 3.5. A alege numărul mai mare doar pentru că este mai mare este o greșeală pe care o vedem la fiecare ciclu.

Criptografia post‑cuantică a trecut de la o problemă de cercetare la o provocare de migrare, OpenSSL susținând deja ML‑KEM, ML‑DSA și SLH‑DSA și schimbul de chei hibrid post‑cuantic. Pentru liderii de afaceri care consideră că calculul cuantic este încă prea îndepărtat pentru a fi o preocupare, ce riscuri neglijează astăzi?

Cea mai comună greșeală este să tratezi aceasta ca pe o întrebare despre când va apărea un calculator cuantic relevant criptografic. Aceasta este variabila greșită. Întrebarea corectă este cât timp trebuie să rămână confidențială informația ta și cât va dura migrarea. Scade a doua din prima și obții termenul real, iar pentru multe organizații acel termen a trecut deja.

Traficul criptat poate fi capturat astăzi și stocat pe termen nelimitat. Dacă informația are un orizont de sensibilitate de douăzeci de ani (dosare medicale, fișiere de personal, proprietate intelectuală, materiale diplomatice, poziții financiare), atunci un adversar nu are nevoie de un calculator cuantic acum. Are nevoie de unul în cele din urmă și de stocare ieftină în timp. Nu este un atac speculativ; este o decizie de arhivare.

Al doilea aspect neglijat este că migrarea nu este un singur proiect. Schimbul de chei este partea ușoară, iar o mare parte din el se întâmplă deja: OpenSSL 3.5 a făcut schimbul de chei hibrid post‑cuantic implicit în TLS, așa că multe organizații utilizează deja acordul de chei post‑cuantic fără să fi luat o decizie în acest sens. Semnăturile și ierarhia certificatelor sunt partea dificilă, deoarece implică autorități de certificare, rădăcini hardware de încredere, chei de semnare a firmware‑ului, module de securitate hardware și dispozitive cu o durată de viață de cincisprezece ani, construite pe presupunerea că RSA va fi valabil pentru totdeauna.

Al treilea aspect este constrângerea pentru care nimeni nu alocă buget: semnăturile post‑cuantice sunt mari. O semnătură ML‑DSA‑65 are aproximativ cincizeci de ori dimensiunea unei semnături ECDSA P‑256, iar SLH‑DSA este și mai mare. Acest lucru perturbă: dimensiunile handshake‑urilor, dispozitivele cu resurse limitate, protocoalele cu limite de câmp fixe, legăturile satelit și IoT. Descoperi aceste probleme prin testare, nu prin citirea unui standard.

Una dintre provocările migrației post‑cuantice este că organizațiile s‑ar putea să nu știe nicăieri unde este utilizată criptografia în aplicațiile, infrastructura, dispozitivele și dependențele terților. Cum ar trebui companiile să abordeze inventarierea criptografică și agilitatea criptografică pentru ca următoarea tranziție majoră a algoritmilor să nu devină o urgență?

Începe cu un adevăr inconfortabil: nu poți construi un inventar criptografic trimițând furnizorilor tăi un chestionar. Vei primi un amestec de texte de marketing, incertitudine onestă și răspunsuri care erau adevărate cu trei versiuni în urmă. Spun asta după ce am petrecut recent mult timp citind documentația furnizorilor de hardware într‑un domeniu conex, iar diferența dintre ceea ce susține documentația și ceea ce face efectiv un produs este mai mare decât cred majoritatea cumpărătorilor.

Trebuie să cauți. Există trei niveluri, fiecare necesitând tehnici diferite. Codul pe care l‑ai scris: analiză statică, scanare de dependențe și căutare a identificatorilor de algoritmi pe care i‑ai codificat cu ani în urmă. Codul la care ai legat: facturi de materiale software, extinse la facturi de materiale criptografice, unde munca CBOM este cu adevărat utilă. Lucruri pe care le‑ai cumpărat sau conectat: observare de rețea, deoarece ceea ce sistemele tale negociază pe fir este adevărul de bază și adesea nu este ceea ce credea oricine.

În ceea ce privește agilitatea, principiul este simplu, iar practica nu este: algoritmul ar trebui să fie o decizie de configurare, nu o modificare de cod. Dacă schimbarea unui cifru necesită un dezvoltator, o compilare, un ciclu de testare și o lansare, nu ai agilitate. Ai un proiect. Centralizează operațiunile criptografice în spatele unei interfețe pe care o controlezi, astfel încât să existe un singur loc de schimbat în loc de patru sute.

Și apoi partea pe care aproape toată lumea o omite: testeaz‑o. Agilitatea pe care nu ai folosit‑o niciodată este o afirmație, nu o capacitate. Alege un weekend liniștit, dezactivează un algoritm într‑un mediu non‑productiv și vezi ce se rupe. Ceva se va rupe. Mai bine să descoperi asta în programul tău decât în timpul unei tranziții de urgență impuse.

Un factor de forțare util este durata de viață a certificatelor. Industria se îndreaptă spre certificate cu durată de viață mult mai scurtă, ceea ce face imposibilă gestionarea manuală a certificatelor și impune automatizarea de care vei avea nevoie oricum. Dacă automatizezi corect emiterea și rotația certificatelor, ai construit cea mai mare parte a mecanismului de care va avea nevoie o viitoare tranziție a algoritmilor.

AI schimbă atât apărarea cibernetică, cât și capabilitățile disponibile atacatorilor. Unde crezi că AI schimbă cu adevărat ecuația securității și unde crezi că organizațiile se concentrează prea mult pe tehnologie, neglijând slăbiciuni mai fundamentale?

AI schimbă cu adevărat un singur lucru, și pot vorbi direct despre asta pentru că ne‑a afectat pe noi.

Un număr substanțial de vulnerabilități dezvăluite în OpenSSL anul acesta au fost găsite prin analiză bazată pe AI. În ianuarie am lansat o versiune care a corectat doisprezece probleme, practic toate provenind de la un grup de cercetare care a folosit analiză automată, și au contribuit cu patch‑uri alături de rapoarte. În iunie am remediat un bug de tip use‑after‑free în verificarea PKCS#7 găsit de un cercetător care lucra cu un sistem AI. Aceasta este o schimbare reală de capabilitate în găsirea erorilor de siguranță a memoriei și de parsare în cod C matur, revizuit de experți de ani de zile. Am observat același model în alte biblioteci criptografice. Analizând un lot de CVE‑uri Bouncy Castle din acest an, amprenta analizei automate de cod este evidentă.

Implicarea evidentă este că acest lucru are două fețe. Aceleași tehnici sunt disponibile pentru oricine dorește să le folosească, pe aceleași baze de cod, iar apărătorii nu au acces exclusiv.

Implicarea mai puțin evidentă, și cea pe care aș sublinia‑o, este povara pe care o pune asupra mentenanților. Generarea unui raport de vulnerabilitate plausibil este acum aproape gratuită. Evaluarea unuia nu este. Încă costă timp real unui expert uman. Echipele de securitate open source, de obicei mici și adesea voluntare, absorb un volum crescând de rapoarte de calitate variabilă. Cele bune, cum ar fi cercetarea menționată, vin cu reproducători și patch‑uri. Cele rele sunt un atac de tip denial‑of‑service asupra oamenilor de care depinzi. Dacă organizația ta implementează AI asupra codului open source, finanțează capacitatea de triere la capătul celălalt.

Unde cred că atenția este greșit direcționată: AI nu repară sistemele tale. Nu face inventarierea activelor, nu rotește acreditările, nu retrage hardware‑ul neacceptat, nici nu face pe cineva responsabil pentru certificatul care expiră luna viitoare. Organizațiile care achiziționează instrumente de securitate AI în timp ce rulează software cu vulnerabilități cunoscute nepatchate își greșesc secvențierea. Munca neglamă este încă acolo unde este riscul.

Multe organizații investesc masiv în instrumente, dar rămân vulnerabile din cauza greșelilor de configurare, sistemelor învechite, proceselor slabe sau pregătirii deficitare pentru incidente. Care sunt cele mai consecvente greșeli de securitate pe care le vezi în continuare și ce ar trebui să aibă echipele de conducere în loc înainte ca un atac să aibă loc?

Greșeala cu cele mai mari consecințe este să tratezi securitatea ca pe o activitate de achiziție. Instrumentele sunt cumpărate, bugetele sunt respectate, dashboard‑urile sunt verzi și nimeni nu s‑a întrebat dacă organizația poate face cu adevărat lucrurile fundamentale.

A doua greșeală este să nu știi ce rulezi. Nu poți patchui software‑ul pe care nu știi că îl ai, iar majoritatea organizațiilor descoperă conținutul real al portofoliului lor în timpul unui incident. De aceea munca de factură‑de‑materiale contează, nu ca un artefact de conformitate, ci ca instrumentul la care apelezi la ora două dimineața când apare un advisory critic și cineva întreabă dacă ești afectat.

A treia greșeală sunt setările implicite. Sistemele sunt instalate, funcționează și configurarea nu este revizuită niciodată. Cinci ani mai târziu acea configurare devine o povară, iar nimeni implicat în decizia inițială nu mai lucrează acolo.

A patra greșeală este gestionarea cheilor și certificatelor lăsată pe seama indivizilor. O proporție remarcabilă de întreruperi auto‑infligate sunt certificate expirate pe care o singură persoană le urmărea într‑un tabel până când a schimbat jobul.

Înainte de un incident, conducerea are nevoie de patru lucruri: un decident numit cu autoritatea de a opri afacerea, stabilit în prealabil și în scris, deoarece discuția despre cine are această autoritate nu este una pe care vrei să o ai în timpul incidentului. Contracte deja semnate cu experți externi în forensic și consilieri specialiști, pentru că achiziționarea lor durează săptămâni și vei avea nevoie de ore. Un canal de comunicare care să nu depindă de sistemele care pot fi compromise. Și o capacitate de restaurare care a fost testată efectiv end‑to‑end, nu un regim de backup verificat doar în sensul că job‑urile s‑au încheiat cu succes.

Apoi exersează. Un exercițiu de tip tabletop la nivel executiv, o dată pe an, va scoate la suprafață mai multe lacune reale decât un alt instrument.

Când are loc un atac cibernetic grav, executivii pot să se găsească brusc luând decizii tehnice, juridice, operaționale și de comunicare sub o presiune enormă. Ce separă organizațiile care răspund eficient de cele care lasă incidentul să se agraveze semnificativ?

Organizațiile care gestionează bine situația au luat deciziile importante înainte de incident, astfel încât în timpul incidentului să execute, nu să delibeere. Asta este cea mai mare parte.

Dincolo de pregătire, câteva lucruri separă în mod constant răspunsurile bune de cele rele.

Ele separă investigația tehnică de pista executivă și de comunicare, cu o interfață definită între ele. Când aceleași persoane încearcă să conțină o intruziune și să redacteze o notificare pentru clienți, ambele sarcini sunt realizate prost.

Ele păstrează dovezile înainte de a remedia. Instinctul de a reconstrui imediat mașina compromisă este puternic și distruge informațiile necesare pentru a stabili amploarea. Dacă nu poți răspunde la „ce altceva au atins?”, nu poți spune credibil că incidentul s‑a încheiat.

Ele acceptă că informațiile timpurii sunt provizorii și comunică în consecință. Majoritatea daunelor de reputație pe care le‑am observat au venit nu din încălcare, ci din declarațiile timpurii încrezătoare care au trebuit să fie retrase. A spune „iată ce știm, iată ce nu știm încă, iată când vă vom actualiza” nu este o slăbiciune. Este singura poziție pe care nu va trebui să o revii.

Și, critic, ele creează condiții în care inginerii pot spune executivilor vești proaste. Modelul de eșec pe care l‑am văzut cel mai des este o organizație în care expunerea juridică era atât de evidentă încât nimeni nu voia să fie persoana care notează ce s‑a întâmplat cu adevărat. Incidentul se agravează în tăcere. Dacă inginerii își gestionează propria răspundere în loc de incident, ai o problemă de guvernanță pe care nicio cantitate de instrumente nu o va rezolva.

OpenSSL se află într‑o poziție neobișnuită ca infrastructură open‑source critică utilizată în întregul ecosistem tehnologic, în timp ce OpenSSL Corporation se concentrează pe servirea comunităților comerciale alături de OpenSSL Foundation, operată independent. Cum echilibrezi nevoile întreprinderilor, dezvoltatorilor, regulatorilor și comunității open‑source mai largă când deciziile privind securitatea și compatibilitatea pot afecta o parte atât de mare a internetului?

Răspunsul sincer este că nu le echilibrezi încercând să mulțumești pe toată lumea la fiecare decizie. Le echilibrezi având o politică publicată și aplicând‑o predictibil, astfel încât oamenii să poată planifica în jurul tău chiar și când nu le place un anumit rezultat.

Predictibilitatea este ceea ce datorăm utilizatorilor noștri. Lansăm versiuni de funcționalități în aprilie și octombrie. Anunțăm în avans care versiune este stabilă pe termen lung și până când. Anunțăm în avans eliminările semnificative. Eliminarea ENGINE în 4.0 a fost descrisă public cu luni înainte de lansare și agreată atât de Corporație, cât și de Fundație. Oricine a fost surprins în aprilie nu acorda atenție, iar noi am făcut tot ce am putut să fie ușor de urmărit.

Răspunsul structural este separarea în sine. Fundația există pentru a servi biblioteca open source și comunitatea din jurul ei. Corporația există pentru a servi organizațiile cu cerințe comerciale (angajamente de suport, validări FIPS, termene specifice) și pentru a face întregul proiect sustenabil din punct de vedere financiar. Menținerea acestor două entități distincte înseamnă că niciun set de nevoi nu este rezolvat silențios în favoarea celuilalt. Când cerințele enterprise și cele ale comunității intră în conflict, conflictul are loc între două organizații cu mandate clare, nu în mintea unei singure persoane.

Cealaltă parte este să asculți corect, ceea ce necesită mecanisme reale, nu presupuneri. Asta explică de ce organizăm conferința, care are loc în Praga în octombrie, și de ce există infrastructura comunității. Este foarte ușor ca mentenanții să dezvolte teorii încrezătoare despre ce au nevoie utilizatorii. Este mult mai util să fii într‑o sală cu ei.

10. Privind următorul deceniu, ce tranziție de securitate sau criptografică crezi că organizațiile subestimează astăzi, și ce lecții din evoluția SSL, OpenSSL și din ultimele 30 de ani de securitate a internetului ar trebui să aplice liderii în pregătirea pentru aceasta?

Tranziția pe care o consider cel mai subestimată nu este criptografia post‑cuantică ca problemă de algoritm. Este identitatea mașinii și ierarhia certificatelor de sub tot.

Schimbul de chei post‑cuantic va fi în mare parte rezolvat prin setări implicite, și o mare parte din el a fost deja rezolvată. Ceea ce nu va fi rezolvat prin setări implicite este infrastructura de încredere: certificatele rădăcină în hardware, cheile de semnare a firmware‑ului arse în dispozitive, HSM‑uri cu un deceniu de viață rămasă, sisteme industriale și medicale care vor funcționa și în 2040 cu presupuneri criptografice încorporate la fabricație. Acestea nu pot fi actualizate printr‑o nouă versiune a bibliotecii și, în unele cazuri, nu pot fi actualizate deloc. Scara acelei probleme de înlocuire nu este reflectată în planificarea de capital a nimănui.

Alături de aceasta există o tranziție de reglementare. Legea privind reziliența cibernetică din Europa și cadre similare în alte părți vor schimba obligațiile legate de livrarea de software cu componente pe care nu le‑ai scris. Majoritatea organizațiilor nu au analizat ce înseamnă acest lucru pentru dependența lor de open source sau pentru oamenii care îl mențin.

Trei lecții din treizeci de ani:

1. Tranzițiile durează cu un deceniu mai mult decât se anunță. SSLv3 a fost depreciat în 2015, dezactivat implicit în 2016 și am eliminat în final codul în aprilie 2026. Aceasta înseamnă unsprezece ani, pentru un protocol pe care toată lumea a convenit că este defect. Planificați migrarea post‑cuantică în funcție de această realitate, nu în funcție de comunicatul de presă.
2. Setările implicite sunt singurul control de securitate care funcționează la scară. Orice necesită ca fiecare administrator să ia o decizie corectă nu se va întâmpla. Motivul pentru care schimbul de chei hibrid post‑cuantic a fost implementat atât de repede este că este activat implicit și nu necesită nicio decizie. Proiectați pentru oamenii care nu vor citi niciodată documentația, pentru că aproape toți sunt așa.
3. Depindeți de mai puțini oameni decât credeți. Aproape fiecare organizație de pe glob se bazează pe cod criptografic întreținut de un număr foarte mic de persoane. Așa era când eram doar noi doi în Brisbane, iar structura nu s‑a schimbat fundamental, chiar dacă miza a crescut cu ordine de mărime. Orice planificați pentru următorul deceniu, o parte din el se sprijină pe un mentenanțist cu care nu ați intrat niciodată în contact și pe care nu îl finanțați. E bine să știți asta înainte să aveți nevoie de el.

Vă mulțumim pentru interviul excelent. Cititorii care doresc să afle mai multe ar trebui să viziteze OpenSSL.