Tim Hudson, præsident for OpenSSL Corporation – Interviewserie

Tim Hudson er medforfatter af SSLeay og en af arrangørerne af OpenSSL Conference, Prag 13.-15. oktober 2026. Han har over 30 års erfaring inden for system‑ og netværkssikkerhed og er præsident for OpenSSL Corporation og chef for teknologi (Chief Technology Officer) hos Cryptsoft Pty Ltd. Siden 1995 har hans arbejde omfattet medstiftelse af SSLeay sammen med Eric Young, det kryptografiske bibliotek der blev til OpenSSL Library, medstiftelse af RSA Security Australia‑udviklingscenteret, bidrag til ændringer i amerikanske eksportregler for kryptering, ledelse af mere end 30 FIPS‑140‑valideringer, medformandskab for OASIS KMIP‑ og SAM‑teknisk udvalg samt taler på førende sikkerhedskonferencer, herunder RSA Conference, AusCERT, ICMC, LinuxConf og OpenSSL Conference.

OpenSSL er et globalt samarbejdsprojekt med åben kildekode, som udvikler og vedligeholder OpenSSL Library, et af verdens mest udbredte kryptografiske biblioteker. Bruges på tværs af operativsystemer, cloud‑platforme, virksomhedssoftware og tilsluttede enheder, hjælper OpenSSL Library med at beskytte milliarder af sikre online‑interaktioner hver dag. Gennem OpenSSL Foundation og OpenSSL Corporation er projektet forpligtet til at fremme pålidelig kryptografi, støtte bæredygtig open‑source‑udvikling og styrke internettets sikkerhed.

Du medstiftede SSLeay sammen med Eric Young i 1995 efter at have indset behovet for en ikke‑amerikansk implementering af SSL, og dette arbejde blev i sidste ende grundlaget for OpenSSL. Hvilket problem forsøgte du oprindeligt at løse, og havde du på det tidspunkt en fornemmelse af, at teknologien kunne blive så grundlæggende for at sikre internettet?

Problemet var fuldstændig konkret, og det var et kommercielt problem, før det var noget andet. Jeg arbejdede hos Mincom i Brisbane, og vi havde kunder, der havde brug for at sikre deres kommunikation. Der var ingen mulighed for at købe den funktion. Amerikanske eksportkontroller på kryptografi betød, at amerikanske produkter enten ikke kunne leveres til os overhovedet eller kom med nøglestørrelser så begrænsede, at implementering ville have været uærlig. Det var ikke en filosofisk indvending mod eksportpolitikken. Det var et ingeniørproblem, hvor den komponent, jeg havde brug for, ikke eksisterede i nogen form, jeg kunne købe, og jeg havde kunder, der ventede.

Det, jeg havde, var viden om noget, de fleste mennesker var glemt. Eric Young havde skrevet en DES‑implementation for nogle år siden: god, ren, frit tilgængelig kode, skrevet for sin egen skyld og fuldstændig uafhængig af dette. Eric arbejdede ikke med SSL. Han var ikke klar over SSL. Da Netscape offentliggjorde specifikationen, læste jeg den, gik til Eric med problemet og præsenterede det som et relativt beskedent skridt fra, hvor han allerede var.

Dette var ikke hele billedet. Hver del var ligetil, men der var et betydeligt antal dele. En DES‑implementation giver dig én symmetrisk cipher. SSL kræver offentlig‑nøglekryptografi, vilkårlig præcisionsaritmetik, ASN.1, X.509‑certifikatbehandling og en protokol‑tilstandsmaskine, alt sammen korrekt, fordi i kryptografi er næsten korrekt og brudt det samme. Jeg præsenterede omfanget optimistisk. Eric fandt hurtigt ud af, hvor meget der var, og nød det, fordi omfanget viste sig at være tiltrækningen snarere end hindringen. Jeg er ikke sikker på, at det ville være startet på en anden måde.

Han lavede den kryptografiske kerne, hvilket er grunden til, at biblioteket bærer hans initialer. Jeg tog mig af de dele, der gør et bibliotek til noget, andre faktisk kan implementere: applikationsintegration, test, dokumentation og fællesskabsdelen. Jeg søgte også aktivt efter steder, hvor et konkurrerende krypteringsbibliotek blev brugt, og konverterede eller erstattede det. SSLtelnet, SSLftp, NCSA httpd og mange andre pakker var mit arbejde, applikationer bygget oven på de kryptografiske algoritmer og protokoller, Eric implementerede. Den blanding lod os hver især koncentrere os om, hvad der faktisk var interessant for os, hvilket jeg tror er hovedårsagen til, at det holdt ved.

At være i Australien var det, der gjorde det muligt at løse problemet overhovedet, og så viste det sig, at mange andre havde præcis det samme problem af præcis samme grund. Noget bygget for at opfylde et specifikt kundekrav i Brisbane blev nyttigt for alle uden for USA, og efterhånden for mange også inden for USA.

Vidste vi, hvad det ville blive? Nej. Ingen sætter sig for at bygge kritisk infrastruktur. Kritisk infrastruktur er det, du opdager, at du har bygget, nogle år senere, når du finder ud af, hvem der er afhængig af det. Det, vi troede, vi gjorde, var at løse et problem foran os og så besvare spørgsmål fra andre, der havde ramt den samme mur. Besvarelsesdelen viste sig at være lige så vigtig som koden.

Du har arbejdet med kryptografi og internetsikkerhed i mere end tre årtier. Hvad har ændret sig mest dramatisk i trusselsbilledet i den periode, og hvilke sikkerhedsproblemer er overraskende ens trods enorme teknologiske fremskridt?

Den største ændring er, at angreb på systemer er blevet en profession med en økonomisk model bag sig. I midten af 1990’erne var de fleste, der brød ind i systemer, primært motiveret af nysgerrighed. I dag er der en industri med specialisering, værktøjer, forsyningskæder, kundesupport og i nogle tilfælde statslig finansiering. Det ændrer alt ved, hvordan du skal tænke, fordi du ikke længere forsvarer dig mod nysgerrighed, men mod en aktør med budget, deadline og forretningscase.

Den anden ændring er skala og afhængighed. Gennemsnitsapplikationen i 1995 var noget, du skrev selv. Gennemsnitsapplikationen i dag er noget, du samler, og størstedelen af koden er skrevet af personer, du aldrig har mødt og ikke kan navngive. Angrebsfladen er flyttet fra din egen kode til dine afhængigheder, og de fleste organisationer har ikke justeret deres tankegang tilsvarende.

Det, der har forblevet bemærkelsesværdigt konstant, er fejltilstandene. Vi skriver stadig fejl i kode, der parser upålidelig input. Vi udgiver stadig systemer med standardindstillinger, som ingen har gennemgået. Certifikater udløber stadig på en lørdag. Legitimationer ender stadig på steder, de ikke bør være. Og kryptografi bliver næsten aldrig brudt på det matematiske niveau. Den omgås, fejlkonfigureres eller slås simpelthen fra. Hvis du gav mig en liste over de ti mest fremtrædende årsager til brud i 1996 og en liste fra sidste måned, ville du have svært ved at skelne dem. Teknologien har transformeret sig fuldstændigt. Fejlene har den ikke.

OpenSSL 4.0 blev udgivet i april 2026 og markerer projektets første store udgivelse i flere år. Hvad fortæller denne udgivelse os om, hvor kryptografisk infrastruktur er på vej hen, og hvilke ændringer tror du i sidste ende vil betyde mest for organisationer, der er afhængige af OpenSSL?

Det mest nyttige ved 4.0 er, at det primært er en “subtraktions‑udgivelse”, og det var pointen.

Vi fjernede ENGINE‑grænsefladen helt. Vi fjernede SSLv3 og SSLv2‑ClientHello. Vi deaktiverede forældede elliptiske kurver og eksplicitte EC‑kurver ved kompilering. Vi gjorde ASN1_STRING opaque og strammede en lang række API‑signaturer. Det er de ændringer, der skaber arbejde for folk, og det er de ændringer, der betyder noget, fordi et kryptografisk bibliotek, der kun akkumulerer, ikke kan forblive sikkert. Hver forældet kodevej, du holder i live, er en angrebsflade, som nogen vedligeholder på dine vegne, og som ingen tester.

Der er tilføjelser: Encrypted Client Hello, RFC 8998‑understøttelse inklusiv den hybride SM2/ML‑KEM‑gruppe, cSHAKE, SNMP‑ og SRTP‑KDF‑er, forhandlet FFDHE for TLS 1.2. ECH lukker i særdeleshed et reelt privatlivshul, fordi Server Name Indication har lækket identiteten på hver side, du besøger, siden TLS 1.3 blev lanceret. Men fjernelserne er historien.

Det vigtigste, jeg vil have organisationer til at tage med sig, er dette: 4.0 er ikke LTS‑udgivelsen. Den understøttes indtil maj 2027. Den nuværende langtidssikre version er 3.5, som understøttes indtil april 2030, og 3.5 indeholder allerede post‑kvante‑algoritmerne. Hvis du vil have den nyeste kode, kør 4.0. Hvis du vil have et stabilt mål, du kan bygge en fem‑års migrationsplan omkring, kør 3.5. At vælge det højere tal, blot fordi det er højere, er en fejl, vi ser folk begå hver cyklus.

Post‑kvante‑kryptografi er gået fra et forskningsproblem til en migrationsudfordring, og OpenSSL understøtter allerede ML‑KEM, ML‑DSA og SLH‑DSA samt hybrid post‑kvante‑nøgleudveksling. For forretningsledere, der antager, at kvantecomputere stadig er for fjerne til at bekymre sig om, hvilke risici overser de i dag?

Den mest almindelige fejl er at behandle dette som et spørgsmål om, hvornår en kryptografisk relevant kvantecomputer ankommer. Det er den forkerte variabel. Det rigtige spørgsmål er, hvor længe dine data skal forblive fortrolige, og hvor lang tid din migration vil tage. Træk den anden fra den første, så har du din faktiske deadline, og for mange organisationer er den deadline allerede passeret.

Krypteret trafik kan indsamles i dag og gemmes på ubestemt tid. Hvis informationen har en følsomhedshorisont på tyve år (patientjournaler, personalemapper, intellektuel ejendom, diplomatiske dokumenter, finansielle positioner), behøver en modstander ikke en kvantecomputer nu. De har brug for en på et tidspunkt, og billig lagerplads i mellemtiden. Det er ikke et spekulativt angreb; det er en arkiveringsbeslutning.

Den anden oversete faktor er, at migration ikke er ét projekt. Nøgleudveksling er den lette del, og meget af den sker allerede: OpenSSL 3.5 gjorde hybrid post‑kvante‑nøgleudveksling til TLS‑standard, så mange organisationer kører post‑kvante‑nøgleaftale nu uden at have truffet en beslutning om det. Signaturer og certifikat‑hierarkiet er den svære del, fordi de involverer certifikat‑autoriter, hardware‑rods‑af tillid, firmware‑signatur‑nøgler, hardware‑sikkerhedsmoduler og enheder med femten‑års levetid, som blev bygget under antagelsen om, at RSA ville holde for evigt.

Den tredje faktor er den begrænsning, ingen budgetterer for: post‑kvante‑signaturer er store. En ML‑DSA‑65‑signatur er cirka halvtreds gange så stor som en ECDSA P‑256‑signatur, og SLH‑DSA er endnu større. Det bryder ting: håndtryk‑størrelser, begrænsede enheder, protokoller med hårdkodede felt‑grænser, satellit‑ og IoT‑forbindelser. Du opdager disse problemer ved at teste, ikke ved at læse en standard.

En af udfordringerne ved post‑kvante‑migration er, at organisationer måske ikke engang ved, hvor kryptografi anvendes i deres applikationer, infrastruktur, enheder og tredjeparts‑afhængigheder. Hvordan bør virksomheder gribe kryptografisk inventar og crypto‑agility an, så den næste store algoritme‑overgang ikke bliver en nødsituation?

Start med en ubehagelig sandhed: du kan ikke bygge et kryptografisk inventar ved at sende dine leverandører et spørgeskema. Du får en blanding af markedsførings‑copy, ærlig usikkerhed og svar, der var korrekte for tre udgivelinger siden. Jeg siger dette efter at have brugt en betydelig tid på at læse hardware‑leverandørers dokumentation inden for et beslægtet område, og afstanden mellem, hvad dokumentationen påstår, og hvad et produkt faktisk gør, er større end de fleste købere antager.

Du er nødt til at kigge. Der er tre lag, som kræver forskellige teknikker. Kode du har skrevet: statisk analyse, afhængighedsscanning og søgning efter de algoritme‑identifikatorer, du indkodede for år tilbage. Kode du har linket: software‑bill of materials, udvidet til kryptografisk bill of materials, hvor CBOM‑arbejdet virkelig er nyttigt. Ting du har købt eller tilsluttet: netværksobservation, fordi hvad dine systemer faktisk forhandler på ledningen er den faktiske sandhed, og den er ofte ikke, hvad nogen troede.

Om agilitet er princippet enkelt, men praksis er det ikke: algoritmen bør være en konfigurations‑beslutning, ikke en kodeændring. Hvis ændring af en cipher kræver en udvikler, et build, en test‑cyklus og en udgivelse, har du ingen agilitet. Du har et projekt. Centraliser kryptografiske operationer bag en grænseflade, du kontrollerer, så der kun er ét sted at ændre i stedet for fire hundrede.

Og så er der den del, næsten alle springer over: afprøv den. Agilitet, du aldrig har brugt, er en påstand, ikke en evne. Tag en stille weekend, slå en algoritme fra i et ikke‑produktionsmiljø, og find ud af, hvad der går i stykker. Noget vil. Det er bedre at opdage det på din egen tidsplan end under en påkrævet nødovergang.

En nyttig tvangs‑funktion er certifikat‑levetiden. Branchen går mod dramatisk kortere‑levende certifikater, hvilket gør manuel certifikat‑administration uholdbar og tvinger den automatisering, du alligevel havde brug for. Hvis du automatiserer udstedelse og rotation af certifikater korrekt, har du bygget det meste af maskineriet, som en fremtidig algoritme‑overgang vil kræve.

AI ændrer både cybersikkerheds‑forsvar og de evner, som angribere har til rådighed. Hvor mener du, AI ægte ændrer sikkerhedsligningen, og hvor tror du, organisationer fokuserer for meget på teknologien, mens de overser mere grundlæggende svagheder?

AI ændrer ærligt talt én ting, og jeg kan tale om det direkte, fordi det har ramt os.

Et betydeligt antal af de sårbarheder, der blev offentliggjort i OpenSSL i år, blev fundet ved AI‑drevet analyse. I januar udgav vi en version, der rettede tolv problemer, stort set alle fra én forskningsgruppe, der brugte automatiseret analyse, og de bidrog med patches sammen med rapporterne. I juni rettede vi en høj‑severitets use‑after‑free i PKCS#7‑verifikation fundet af en forsker, der arbejdede med et AI‑system. Det er en reel ændring i evnen til at finde hukommelsessikkerheds‑ og parse‑fejl i moden C‑kode, som er blevet gennemgået af eksperter i årevis. Jeg har set det samme mønster i andre kryptografiske biblioteker. Når man analyserer en bunke Bouncy Castle‑CVE’er fra i år, er fingeraftrykket af automatiseret kodeanalyse tydeligt.

Den åbenlyse implikation er, at dette går begge veje. De samme teknikker er tilgængelige for dem, der vil bruge dem, på de samme kodebaser, og forsvarere har ikke eksklusiv adgang.

Den mindre åbenlyse implikation, som jeg vil understrege, er den byrde, den pålægger vedligeholdere. At generere en plausibel sårbarhedsrapport er nu næsten gratis. At triagere en er det ikke. Det koster stadig en menneskelig ekspert reelle timer. Open‑source‑sikkerhedsteams, som typisk er små og ofte frivillige, absorberer en stigende mængde rapporter af meget varierende kvalitet. De gode, som den forskning jeg nævnte, kommer med reproducerbare eksempler og patches. De dårlige er et denial‑of‑service‑angreb på de personer, du er afhængig af. Hvis din organisation bruger AI mod open‑source‑kode, skal du finansiere triage‑kapaciteten i den anden ende.

Hvor jeg mener, opmærksomheden er fejlagtig: AI patchede ikke dine systemer. Det laver ikke inventar over dine aktiver, roterer ikke dine legitimationsoplysninger, pensionerer din forældede hardware eller gør nogen ansvarlig for certifikatet, der udløber næste måned. Organisationer, der køber AI‑sikkerhedsværktøjer, mens de kører software med kendte uopdaterede sårbarheder, har deres rækkefølge forkert. Det mindre glamourøse arbejde er stadig, hvor risikoen ligger.

Mange organisationer investerer kraftigt i værktøjer, men forbliver sårbare på grund af konfigurationsfejl, forældede systemer, svage processer eller dårlig hændelses‑forberedelse. Hvad er de mest konsekvente sikkerhedsfejl, du fortsat ser, og hvad bør ledelsesteam have på plads, før et angreb faktisk indtræffer?

Den mest konsekvente fejl er at behandle sikkerhed som en indkøbsaktivitet. Værktøjer købes, budgetter overholdes, dashboards er grønne, og ingen har spurgt, om organisationen faktisk kan udføre de grundlæggende ting.

Den anden er ikke at vide, hvad du kører. Du kan ikke opdatere software, du ikke ved, du har, og de fleste organisationer opdager den egentlige sammensætning af deres ejendom under en hændelse. Det er derfor, arbejdet med bill‑of‑materials er vigtigt, ikke som et compliance‑artefakt, men som det du griber efter klokken to om morgenen, når et kritisk advisory falder, og nogen spørger, om du er berørt.

Den tredje er standardindstillinger. Systemer installeres, de fungerer, og konfigurationen gennemgås aldrig igen. Fem år senere er den konfiguration en forpligtelse, og ingen fra den oprindelige beslutning er stadig ansat.

Den fjerde er nøgle‑ og certifikat‑administration overladt til enkeltpersoner. En bemærkelsesværdig andel af selvforskyldte nedbrud er udløbne certifikater, som én person stille holdt styr på i et regneark, indtil de skiftede job.

Før en hændelse har ledelsen brug for fire ting på plads. En navngivet beslutningstager med myndighed til at tage forretningen offline, besluttet på forhånd og skriftligt, fordi argumentet om, hvem der har den myndighed, ikke er et, du vil have live. Aftaler, der allerede er underskrevet med eksterne retsmedicinske eksperter og specialiseret rådgivning, fordi den indkøb tager uger, og du kun har timer. En kommunikationskanal, der ikke afhænger af de systemer, der kan blive kompromitteret. Og en gendannelses‑kapacitet, der faktisk er testet end‑to‑end, ikke et backup‑regime, der kun er bekræftet ved, at job‑erne fuldførte succesfuldt.

Derefter øv det. En tabletop‑øvelse på ledelsesniveau, en gang om året, vil afsløre flere reelle huller end et nyt værktøj.

Når et alvorligt cyberangreb sker, kan ledere pludselig stå over for tekniske, juridiske, operationelle og kommunikations‑beslutninger under enormt pres. Hvad adskiller organisationer, der reagerer effektivt, fra dem, der lader en hændelse blive væsentligt værre?

De organisationer, der håndterer det godt, har truffet de vigtige beslutninger før hændelsen, så de under hændelsen udfører snarere end drøfter. Det er det meste af det.

Udover forberedelse er der nogle få ting, der konsekvent adskiller gode svar fra dårlige.

De adskiller den tekniske efterforskning fra den ledelsesmæssige og kommunikationsmæssige spor, med en defineret grænseflade mellem dem. Når de samme personer prøver at indeholde en indtrængning og udforme en kundemeddelelse, udføres begge opgaver dårligt.

De bevarer beviser, før de afhjælper. Instinktet til straks at genopbygge den kompromitterede maskine er stærkt og ødelægger den information, du har brug for til at fastslå omfanget. Hvis du ikke kan svare på “hvad andet rørte de?”, kan du ikke troværdigt fortælle nogen, at hændelsen er overstået.

De accepterer, at tidlige informationer er foreløbige og kommunikerer derefter. Det meste af den omdømmeskade, jeg har observeret, kom ikke fra bruddet, men fra selvsikre tidlige udtalelser, der måtte trækkes tilbage. At sige “her er, hvad vi ved, her er, hvad vi endnu ikke ved, her er, hvornår vi vil opdatere jer” er ikke en svaghed. Det er den eneste position, du ikke behøver at vende.

Og kritisk: de skaber betingelser, hvor ingeniører kan fortælle ledelsen dårlige nyheder. Den fejlpatern, jeg oftest ser, er en organisation, hvor den juridiske eksponering var så tydelig, at ingen ville være den, der skrev, hvad der faktisk skete. Hændelsen forværres så i stilhed. Hvis dine ingeniører håndterer deres egen ansvarlighed i stedet for hændelsen, har du et governance‑problem, som ingen mængde værktøjer kan løse.

OpenSSL befinder sig i en usædvanlig position som kritisk open‑source‑infrastruktur, der anvendes i hele teknologiekosystemet, mens OpenSSL Corporation fokuserer på at betjene kommercielle fællesskaber sammen med den uafhængigt drevne OpenSSL Foundation. Hvordan balancerer du behovene hos virksomheder, udviklere, regulatorer og det bredere open‑source‑fællesskab, når beslutninger om sikkerhed og kompatibilitet kan påvirke så stor en del af internettet?

Det ærlige svar er, at du ikke balancerer dem ved at forsøge at gøre alle glade i hver beslutning. Du balancerer dem ved at have en offentlig politik og anvende den forudsigeligt, så folk kan planlægge omkring dig, selv når de misbilliger et bestemt udfald.

Forudsigelighed er, hvad vi skylder vores brugere. Vi udgiver funktions‑udgivelser i april og oktober. Vi siger på forhånd, hvilken udgivelse der er langtidssikret, og indtil hvornår. Vi annoncerer væsentlige fjernelser langt før de sker. ENGINE‑fjernelsen i 4.0 blev offentligt beskrevet måneder før udgivelsen og blev aftalt af både Corporation og Foundation. Den, der blev overrasket i april, havde ikke holdt øje, og vi havde gjort det så let som rimeligt muligt at holde øje.

Den strukturelle løsning er selve adskillelsen. Foundation eksisterer for at tjene det open‑source‑bibliotek og fællesskabet omkring det. Corporation eksisterer for at tjene organisationer med kommercielle krav (support‑forpligtelser, FIPS‑validering, specifikke tidsplaner) og for at gøre hele projektet økonomisk bæredygtigt. At holde dem adskilt betyder, at ingen af behovene løses stille og roligt til fordel for den anden. Når virksomheds‑krav og fællesskabs‑krav reelt konflikter, sker konflikten mellem to organisationer med klare mandat, snarere end i én persons hoved.

Den anden del er at lytte ordentligt, hvilket kræver faktiske mekanismer frem for antagelser. Det er en stor del af, hvorfor vi afholder konferencen, som er i Prag i oktober, og hvorfor fællesskabs‑infrastrukturen findes. Det er meget let for vedligeholdere at udvikle selvsikre teorier om, hvad brugerne har brug for. Det er betydeligt mere nyttigt at være i et rum med dem.

10. Når vi ser på det næste årti, hvilken sikkerheds‑ eller kryptografisk overgang tror du, organisationer stadig undervurderer i dag, og hvilke lektioner fra SSL‑, OpenSSL‑ og de sidste 30 års internetsikkerhed bør ledere anvende, når de forbereder sig på den?

Den overgang, jeg mener er mest undervurderet, er ikke post‑kvante‑kryptografi som et algoritmeproblem. Det er maskin‑identitet og certifikat‑hierarkiet under alt.

Post‑kvante‑nøgleudveksling vil i vid udstrækning blive løst af standardindstillinger, og meget af det er allerede gjort. Det, der ikke vil blive løst af standardindstillinger, er tillids‑infrastrukturen: rod‑certifikater i hardware, firmware‑signatur‑nøgler brændt ind i enheder, HSM‑er med et årti tilbage af service‑levetid, industrielle og medicinske systemer, der stadig vil køre i 2040 med kryptografiske antagelser indlejret ved fremstillingen. Disse kan ikke opdateres ved blot at levere en ny biblioteks‑version, og i nogle tilfælde kan de slet ikke opdateres. Omfanget af dette udskiftningsproblem afspejles i øjeblikket ikke i nogen organisations kapitalplanlægning.

Samtidig er der en regulatorisk overgang. Cyber Resilience Act i Europa og tilsvarende rammer andre steder vil ændre forpligtelserne ved at levere software med komponenter, du ikke har skrevet. De fleste organisationer har ikke gennemgået, hvad det betyder for deres afhængighed af open‑source, eller for de personer, der vedligeholder den.

1. Overgange tager et årti længere end annonceret. SSLv3 blev udfaset i 2015, deaktiveret som standard i 2016, og vi fjernede koden først i april 2026. Det er elleve år for en protokol, som alle var enige om var brudt. Planlæg post‑kvante‑migration mod denne virkelighed, ikke mod pressemeddelelsen.
2. Standardindstillinger er den eneste sikkerhedskontrol, der virker i skala. Alt, der kræver, at hver administrator træffer en korrekt beslutning, vil ikke ske. Årsagen til, at hybrid post‑kvante‑nøgleudveksling er blevet implementeret så hurtigt, er, at den er slået til som standard og kræver ingen beslutning overhovedet. Design for de mennesker, der aldrig vil læse din dokumentation, for det er næsten alle.
3. Du er afhængig af færre personer, end du tror. Næsten alle organisationer på jorden er afhængige af kryptografisk kode, som vedligeholdes af et meget lille antal individer. Det var sandt, da det var to af os i Brisbane, og strukturen har ikke fundamentalt ændret sig, selvom stakes er steget eksponentielt. Uanset hvad du planlægger for det næste årti, hviler en del af det på en vedligeholder, du aldrig har kontaktet og ikke finansierer. Det er værd at vide, før du har brug for dem.

Tak for det fantastiske interview. Læsere, der ønsker at lære mere, bør besøge OpenSSL.