Tim Hudson, prezident společnosti OpenSSL Corporation – série rozhovorů

Tim Hudson je spoluautorem SSLeay a jedním z organizátorů OpenSSL Conference, Praha 13.–15. října 2026. Má více než 30 let zkušeností v oblasti systémové a síťové bezpečnosti a je prezidentem OpenSSL Corporation a hlavním technologickým ředitelem ve Cryptsoft Pty Ltd. Od roku 1995 jeho práce zahrnovala spoluzaložení SSLeay s Ericem Youngem, kryptografické knihovny, která se stala OpenSSL Library, spoluzaložení vývojového centra RSA Security Australia, přispění ke změnám v amerických exportních předpisech pro šifrování, vedení více než 30 validací FIPS 140, spolupředsednictví v technických výborech OASIS KMIP a SAM a přednášky na předních bezpečnostních konferencích, včetně RSA Conference, AusCERT, ICMC, LinuxConf a OpenSSL Conference.

OpenSSL je globální spolupracující open source projekt, který vyvíjí a udržuje OpenSSL Library, jednu z nejrozšířenějších kryptografických knihoven na světě. Používána napříč operačními systémy, cloudovými platformami, podnikovým softwarem i připojenými zařízeními, OpenSSL Library pomáhá denně chránit miliardy zabezpečených online interakcí. Prostřednictvím OpenSSL Foundation a OpenSSL Corporation se projekt zavazuje podporovat důvěryhodnou kryptografii, udržitelný vývoj open source a posilovat bezpečnost internetu.

Spoluzaložil jste SSLeay s Ericem Youngem v roce 1995 poté, co jste si uvědomil potřebu neamerické implementace SSL, a tato práce se nakonec stala základem pro OpenSSL. Jaký problém jste se původně snažil vyřešit a měl jste v té době představu, že se tato technologie může stát tak zásadní součástí zabezpečení internetu?

Problém byl zcela konkrétní a byl komerční, ještě před tím, než se stal čímkoli jiným. Pracoval jsem ve společnosti Mincom v Brisbane a měli jsme zákazníky, kteří potřebovali zabezpečit své komunikace. Nebyla žádná možnost tuto schopnost zakoupit. Americké exportní kontroly šifrování znamenaly, že americké produkty buď nemohly být vůbec dodány, nebo přišly s tak omezenými velikostmi klíčů, že jejich nasazení by bylo nečestné. Nešlo o filozofický nesouhlas s exportní politikou. Šlo o inženýrský problém, kdy komponenta, kterou jsem potřeboval, neexistovala v žádné formě, kterou bych mohl zakoupit, a zákazníci čekali.

Měl jsem však znalost něčeho, na co většina lidí zapomněla. Eric Young před několika lety napsal implementaci DES: dobrý, čistý, volně dostupný kód, vytvořený pro samotný účel a zcela nesouvisející s tímto. Eric nepracoval na SSL. Nebyl si vědom SSL. Když Netscape zveřejnilo specifikaci, přečetl jsem ji, obrátil se na Erica s problémem a představil mu to jako relativně skromný krok od toho, kde už byl.

Toto nebyl celý obrázek. Každá část byla jednoduchá, ale bylo jich značně mnoho. Implementace DES vám poskytuje jeden symetrický šifrovací algoritmus. SSL vyžaduje kryptografii s veřejným klíčem, aritmetiku libovolné přesnosti, ASN.1, zpracování certifikátů X.509 a stavový stroj protokolu, a to vše správně, protože v kryptografii je rozdíl mezi téměř správným a porušeným prakticky neexistuje. Původně jsem rozsah projektu prezentoval optimisticky. Eric brzy pochopil, kolik toho je, a užíval si to, protože rozsah se ukázal být spíše atrakcí než překážkou. Nejsem si jistý, že by to mohlo začít jinak.

On on cryptografické jádro, což je důvod, proč knihovna nese jeho iniciály. Já jsem převzal části, které promění knihovnu v něco, co mohou ostatní skutečně nasadit: integraci do aplikací, testování, dokumentaci a komunitní stránku. Aktivně jsem také hledal místa, kde se používá konkurenční šifrovací knihovna, a převáděl nebo nahrazoval ji. SSLtelnet, SSLftp, NCSA httpd a řada dalších balíčků byly mou prací, aplikace postavené na kryptografických algoritmech a protokolech, které Eric implementoval. Toto rozdělení nám umožnilo soustředit se na to, co nás skutečně zajímá, což je podle mě hlavní důvod, proč projekt pokračoval.

Být v Austrálii umožnilo vůbec najít řešení a ukázalo se, že mnoho dalších lidí mělo přesně stejný problém ze stejného důvodu. Něco, co bylo vytvořeno pro konkrétní požadavek zákazníka v Brisbane, se stalo užitečným pro všechny mimo Spojené státy a nakonec i pro mnoho lidí uvnitř nich.

Věděli jsme, čím se to stane? Ne. Nikdo si neplánuje budovat kritickou infrastrukturu. Kritická infrastruktura je to, co zjistíte, že jste postavili, o několik let později, když zjistíte, kdo na ní závisí. Mysleli jsme si, že řešíme problém před námi, a pak odpovídáme na otázky ostatních, kteří narazili na stejnou překážku. Část s odpovídáním na otázky se ukázala být stejně důležitá jako kód.

Pracujete v kryptografii a internetové bezpečnosti více než tři desetiletí. Co se během této doby nejdramatičtěji změnilo v oblasti hrozeb a které bezpečnostní problémy zůstaly překvapivě podobné navzdory obrovskému technologickému pokroku?

Největší změna spočívá v tom, že útoky na systémy se staly profesí s ekonomickým modelem. V polovině devadesátých let lidé, kteří vnikali do systémů, to dělali hlavně proto, že je to zajímavé. Dnes existuje průmysl se specializací, nástroji, dodavatelskými řetězci, zákaznickou podporou a v některých případech i státním financováním. To mění vše, jak musíte přemýšlet, protože už nebráníte jen zvědavosti, ale bráníte někomu s rozpočtem, termínem a obchodním případem.

Druhá změna je rozsah a závislost. Průměrná aplikace v roce 1995 byla něco, co jste napsali. Průměrná aplikace dnes je něco, co jste sestavili, a většina kódu v ní byla napsána lidmi, které jste nikdy nepotkali a neznáte. Útočná plocha se přesunula z vašeho kódu na vaše závislosti a většina organizací si toto neuvědomila.

Co zůstalo pozoruhodně konstantní, jsou způsoby selhání. Stále píšeme chyby v kódu, který zpracovává nedůvěryhodný vstup. Stále vydáváme systémy s výchozími nastaveními, která nikdo nepřezkoumal. Certifikáty stále expirují v sobotu. Přihlašovací údaje stále končí na místech, kde by neměly být. A kryptografie se téměř nikdy neporuší na úrovni matematiky. Je obcházená, špatně nakonfigurovaná nebo prostě vypnutá. Kdybyste mi dali seznam deseti hlavních příčin narušení z roku 1996 a seznam z minulého měsíce, těžko byste je od sebe odlišili. Technologie se kompletně proměnila. Chyby zůstaly.

OpenSSL 4.0 byl vydán v dubnu 2026, což představuje první významné vydání projektu po několika letech. Co nám toto vydání říká o budoucnosti kryptografické infrastruktury a které změny budou podle vás pro organizace, které na OpenSSL spoléhají, nejvíce podstatné?

Nejvíce užitečné, co je třeba o 4.0 pochopit, je to, že jde především o verzi s odečtením funkcí, a to byl její hlavní smysl.

Úplně jsme odstranili rozhraní ENGINE. Odstranili jsme SSLv3 a SSLv2 ClientHello. Zakázali jsme zastaralé eliptické křivky a explicitní EC křivky při kompilaci. Udělali jsme ASN1_STRING neprůhledným a zpřesnili řadu API signatur. To jsou změny, které vytvářejí práci pro vývojáře, a jsou to změny, které mají význam, protože kryptografická knihovna, která jen hromadí funkce, nemůže zůstat bezpečná. Každá zastaralá cesta kódu, kterou udržíte, představuje útočnou plochu, kterou někdo spravuje vaším jménem a nikdo ji nezkouší.

Jsou zde také novinky: Encrypted Client Hello, podpora RFC 8998 včetně hybridní skupiny SM2/ML‑KEM, cSHAKE, SNMP a SRTP KDF, vyjednaný FFDHE pro TLS 1.2. ECH konkrétně uzavírá skutečnou mezeru v soukromí, protože Server Name Indication uniká identitu každého navštíveného webu od doby, kdy byl nasazen TLS 1.3. Ale odstranění jsou tím hlavním příběhem.

Co bych organizacím chtěl nejvíce zdůraznit, je toto: 4.0 není LTS verze. Je podporována do května 2027. Současná dlouhodobě stabilní verze je 3.5, podporována do dubna 2030, a 3.5 již obsahuje postkvantové algoritmy. Pokud chcete nejnovější kód, použijte 4.0. Pokud chcete stabilní cíl, kolem kterého můžete vybudovat pětiletý migrační plán, použijte 3.5. Volba vyššího čísla jen proto, že je vyšší, je chyba, kterou vidíme u lidí každým cyklem.

Postkvantová kryptografie se posunula z výzkumného problému k migrační výzvě, přičemž OpenSSL již podporuje ML‑KEM, ML‑DSA a SLH‑DSA a hybridní postkvantovou výměnu klíčů. Pro obchodní lídry, kteří předpokládají, že kvantové počítače jsou ještě příliš vzdálené, jaká rizika dnes přehlížejí?

Nejčastější chybou je považovat to za otázku, kdy přijde kryptograficky relevantní kvantový počítač. To je špatná proměnná. Správná otázka je, jak dlouho musí vaše data zůstat důvěrná a jak dlouho bude trvat vaše migrace. Odečtěte druhé od prvního a získáte skutečný termín, a pro mnoho organizací je tento termín už v minulosti.

Šifrovaný provoz může být dnes zachycen a uložen na neurčito. Pokud má informace v něm dvacetiletý horizont citlivosti (zdravotní záznamy, osobní soubory, duševní vlastnictví, diplomatické materiály, finanční pozice), útočník nyní nepotřebuje kvantový počítač. Potřebuje ho nakonec a mezitím levné úložiště. To není spekulativní útok; je to rozhodnutí o archivaci.

Druhou přehlíženou věcí je, že migrace není jedním projektem. Výměna klíčů je snadná část a mnoho z ní se již děje: OpenSSL 3.5 učinil hybridní postkvantovou výměnu klíčů výchozím nastavením TLS, takže mnoho organizací již nyní používá postkvantové dohodnutí klíčů, aniž by o tom rozhodly. Podpisy a hierarchie certifikátů jsou obtížná část, protože zahrnují certifikační autority, hardwarové kořeny důvěry, klíče pro podepisování firmware, hardwarové bezpečnostní moduly a zařízení s patnáctiletou životností, která byla postavena na předpokladu, že RSA bude navždy fungovat.

Třetí věc je omezení, na které nikdo neplánuje rozpočet: postkvantové podpisy jsou velké. Podpis ML‑DSA‑65 je přibližně padesátkrát větší než podpis ECDSA P‑256 a SLH‑DSA je ještě větší. To rozbíjí věci: velikosti handshake, omezená zařízení, protokoly s pevně zakódovanými limity polí, satelitní a IoT spojení. Tyto problémy objevíte testováním, ne čtením standardu.

Jednou z výzev postkvantové migrace je, že organizace možná ani neví, kde všude je kryptografie používána v jejich aplikacích, infrastruktuře, zařízeních a závislostech třetích stran. Jak by měly společnosti přistupovat k inventarizaci kryptografie a kryptografické agilnosti, aby další velký přechod algoritmu se nestal nouzovou situací?

Začněte nepříjemnou pravdou: kryptografickou inventuru nelze vytvořit zasláním dotazníku vašim dodavatelům. Dostanete směs marketingových textů, upřímné nejistoty a odpovědí, které byly pravdivé před třemi verzemi. Říkám to po tom, co jsem nedávno strávil značné množství času čtením dokumentace hardwarových dodavatelů v souvisejícím oboru, a rozdíl mezi tím, co dokumentace tvrdí, a tím, co produkt skutečně dělá, je větší, než si většina kupujících představuje.

Musíte se podívat. Existují tři vrstvy a každá vyžaduje jiné techniky. Kód, který jste napsali: statická analýza, skenování závislostí a vyhledávání identifikátorů algoritmů, které jste před lety tvrdě zakódovali. Kód, který jste propojili: softwarové bill of materials, rozšířené na kryptografické bill of materials, kde je práce s CBOM skutečně užitečná. Věci, které jste zakoupili nebo připojili: pozorování sítě, protože to, co vaše systémy skutečně vyjednávají na drátě, je pravda a často to není to, co kdokoli věřil.

Co se týče agility, princip je jednoduchý a praxe nikoli: algoritmus by měl být rozhodnutím v konfiguraci, ne změnou kódu. Pokud změna šifry vyžaduje vývojáře, sestavení, testovací cyklus a vydání, nemáte agilitu. Máte projekt. Centralizujte kryptografické operace za rozhraní, které kontrolujete, aby existovalo jedno místo ke změně místo čtyř stovek.

A pak část, kterou téměř všichni přeskočí: vyzkoušejte ji. Agilita, kterou jste nikdy nepoužili, je tvrzení, ne schopnost. Vyberte si klidný víkend, vypněte algoritmus v neprodukčním prostředí a zjistěte, co selže. Něco selže. Je lepší to objevit ve vašem plánu než během povinné nouzové migrace.

Užitečnou vynucovací funkcí je životnost certifikátů. Průmysl přechází na výrazně kratší životnost certifikátů, což dělá ruční správu certifikátů neudržitelnou a nutí automatizaci, kterou jste stejně potřebovali. Pokud správně automatizujete vydávání a rotaci certifikátů, vytvořili jste většinu mechanismů, které bude budoucí přechod algoritmu vyžadovat.

AI mění jak obranu v kybernetické bezpečnosti, tak schopnosti útočníků. Kde podle vás AI skutečně mění bezpečnostní rovnici a kde si myslíte, že organizace příliš soustředí na technologii a přitom přehlíží základnější slabiny?

AI skutečně mění jednu věc a mohu o tom mluvit přímo, protože se to nám stalo.

Významná část zranitelností zveřejněných v OpenSSL letos byla nalezena analýzou řízenou AI. V lednu jsme vydali verzi, která opravila dvanáct problémů, prakticky všechny od jedné výzkumné skupiny používající automatizovanou analýzu, a přispěli patchemi spolu s hlášením. V červnu jsme opravili vysoce závažný use-after-free v ověřování PKCS#7, který našel výzkumník pracující s AI systémem. To je skutečná změna schopnosti nacházet chyby v paměťové bezpečnosti a parsování v zralém C kódu, který byl po léta kontrolován experty. Viděl jsem stejný vzor i v jiných kryptografických knihovnách. Analýzou šarže CVE Bouncy Castle z tohoto roku je otisk automatizované analýzy kódu jasný.

Zřejmý důsledek je, že to funguje obousměrně. Stejné techniky jsou k dispozici komukoli, kdo je chce použít, na stejných kódech, a obránci nemají výlučný přístup.

Méně zřejmý důsledek, který zdůrazňuji, je zátěž, kterou to klade na správce. Vytvoření věrohodné zprávy o zranitelnosti je nyní téměř zdarma. Její třídění už není. Stále to stojí lidského experta v reálném čase. Týmy pro bezpečnost open source, které jsou obvykle malé a často dobrovolnické, absorbují rostoucí objem zpráv s velmi proměnlivou kvalitou. Dobré, jako výzkum, který jsem zmínil, přicházejí s reproduktory a patchemi. Špatné jsou útok typu denial-of-service na lidi, na které spoléháte. Pokud vaše organizace nasazuje AI proti open source kódu, financujte kapacitu třídění na druhé straně.

Kde podle mě směřuje pozornost špatně: AI neaktualizuje vaše systémy. Neinventarizuje vaše aktiva, neotáčí vaše přihlašovací údaje, neodstraňuje nepodporovaný hardware ani nevyžaduje odpovědnost za certifikát, který expiruje příští měsíc. Organizace, které kupují AI bezpečnostní nástroje a zároveň provozují software se známými neopravenými zranitelnostmi, mají špatné pořadí. Nezářící práce je stále tam, kde je riziko.

Mnoho organizací investuje značně do nástrojů, ale zůstává zranitelných kvůli konfiguračním chybám, zastaralým systémům, slabým procesům nebo špatné přípravě na incidenty. Jaké jsou nejzávažnější bezpečnostní chyby, které stále vidíte, a co by měly mít vedení organizací připravené ještě před tím, než k útoku dojde?

Nejzávažnější chybou je považovat bezpečnost za nákupní aktivitu. Nástroje jsou zakoupeny, rozpočty splněny, dashboardy jsou zelené a nikdo se nezeptal, zda organizace skutečně dokáže provádět základní úkony.

Druhou chybou je neznát, co provozujete. Nemůžete opravovat software, o kterém nevíte, že jej máte, a většina organizací odhalí skutečný obsah svého majetku během incidentu. Proto je práce s bill-of-materials důležitá, ne jako artefakt shody, ale jako něco, na co sáhnete ve dvou ráno, když spadne kritické upozornění a někdo se zeptá, zda jste zasaženi.

Třetí jsou výchozí nastavení. Systémy jsou nainstalovány, fungují a konfigurace se nikdy nezkoumá. O pět let později je tato konfigurace závazkem a nikdo, kdo se podílel na původním rozhodnutí, už tam nepracuje.

Čtvrtá je správa klíčů a certifikátů ponechaná jednotlivcům. Pozoruhodná část výpadků způsobených vlastními chybami jsou expirující certifikáty, které jeden člověk tiše sledoval v tabulce, dokud nezměnil práci.

Před incidentem potřebuje vedení čtyři věci. Jmenovaného rozhodovatele s pravomocí vypnout podnik, rozhodnutého předem a písemně, protože argument o tom, kdo má tuto pravomoc, není něco, co chcete řešit v reálném čase. Již podepsané smlouvy s externími forenzními a specialistickými poradci, protože tato zakázka trvá týdny a vy budete mít jen hodiny. Komunikační kanál, který nezávisí na systémech, jež mohou být kompromitovány. A schopnost obnovy, která byla skutečně testována od začátku do konce, ne jen záložní režim ověřený pouze tím, že úlohy úspěšně skončily.

Pak to procvičte. Cvičení na stole na úrovni vedení, jednou ročně, odhalí více skutečných mezer než další nástroj.

Když dojde k vážnému kybernetickému útoku, výkonný management může najednou čelit technickým, právním, provozním a komunikačním rozhodnutím pod obrovským tlakem. Co odlišuje organizace, které reagují efektivně, od těch, které umožní incidentu výrazně se zhoršit?

Organizace, které to zvládnou dobře, učinily důležitá rozhodnutí před incidentem, takže během incidentu provádějí akce místo úvah. To je podstatná část.

Kromě přípravy je několik věcí, které konzistentně oddělují dobré reakce od špatných.

Oddělují technické vyšetřování od výkonného a komunikačního proudu, s definovaným rozhraním mezi nimi. Když stejní lidé snaží se omezit průnik a připravit oznámení zákazníkům, oba úkoly jsou provedeny špatně.

Zachovávají důkazy před nápravou. Instinkt okamžitě přestavět kompromitovaný stroj je silný a ničí informace potřebné k určení rozsahu. Pokud nedokážete odpovědět „co dalšího se dotkli“, nemůžete věrohodně říci, že incident je ukončen.

Uznávají, že včasné informace jsou provizorní, a podle toho komunikují. Většina poškození reputace, které jsem pozoroval, nepocházela z porušení, ale ze sebevědomých prvních prohlášení, která musela být odvolána. Říci „tady je to, co víme, tady je to, co ještě nevíme, tady je, kdy vás budeme aktualizovat“, není slabost. Je to jediná poloha, kterou nebudete muset couvat.

A kriticky: vytvářejí podmínky, ve kterých mohou inženýři sdělit manažerům špatné zprávy. Vzorec selhání, který jsem viděl nejčastěji, je organizace, kde bylo právní odhalení tak evidentní, že nikdo nechtěl být tím, kdo zapsal, co se skutečně stalo. Incident se pak v tichosti zhorší. Pokud vaši technici spravují svou vlastní odpovědnost spíše než incident, máte problém s řízením, který nevyřeší žádné množství nástrojů.

OpenSSL stojí v neobvyklé pozici jako kritická open-source infrastruktura používaná v celém technologickém ekosystému, zatímco OpenSSL Corporation se zaměřuje na poskytování služeb komerčním komunitám vedle nezávisle provozované OpenSSL Foundation. Jak vyvažujete potřeby podniků, vývojářů, regulačních orgánů a širší open source komunity, když rozhodnutí o bezpečnosti a kompatibilitě mohou ovlivnit tak velkou část internetu?

Upřímnou odpovědí je, že je nevyvažujete snahou, aby byli všichni v každém rozhodnutí šťastní. Vyvážíte je tím, že máte zveřejněnou politiku a předvídatelně ji aplikujete, takže lidé kolem vás mohou plánovat, i když se jim konkrétní výsledek nelíbí.

Předvídatelnost je to, co dlužíme našim uživatelům. Vydání funkcí odesíláme v dubnu a říjnu. Předem říkáme, které vydání je dlouhodobě stabilní a do kdy. Významná odstranění oznamujeme s dostatečným předstihem před jejich uskutečněním. Odstranění ENGINE ve 4.0 bylo veřejně popsáno měsíce před vydáním a odsouhlaseno korporací i nadací. Každý, koho to v dubnu překvapilo, tomu nevěnoval pozornost a my jsme to usnadnili, jak jsme jen mohli, věnovat pozornost.

Strukturální odpovědí je samotné oddělení. Nadace existuje, aby sloužila knihovně s otevřeným zdrojovým kódem a komunitě kolem ní. Korporace existuje, aby sloužila organizacím s komerčními požadavky (závazky podpory, validace FIPS, konkrétní časové osy) a aby byla celá věc finančně udržitelná. Zachování těchto odlišných potřeb znamená, že ani jeden soubor potřeb není tiše vyřešen ve prospěch druhého. Když jsou podnikové požadavky a požadavky komunity skutečně v rozporu, ke konfliktu dochází spíše mezi dvěma organizacemi s jasnými pravomocemi než v hlavě jednoho člověka.

Další částí je správné naslouchání, které vyžaduje skutečné mechanismy spíše než předpoklady. To je velká část toho, proč pořádáme konferenci, která je letos v říjnu v Praze, a proč komunitní infrastruktura existuje. Pro správce je velmi snadné vytvořit sebevědomé teorie o tom, co uživatelé potřebují. Podstatně užitečnější je být s nimi v místnosti.

Když se podíváte na příští desetiletí, jaké zabezpečení nebo kryptografický přechod podle vás dnes organizace stále podceňují a jaké poučení z vývoje SSL, OpenSSL a posledních 30 let internetové bezpečnosti by měli lídři uplatnit, když se na to připravují?

Přechod, který je podle mě nejvíce podceňován, není postkvantová kryptografie jako problém algoritmu. Je to identita stroje a hierarchie certifikátů pod vším.

Postkvantová výměna klíčů bude z velké části vyřešena výchozími nastaveními a mnoho z toho již bylo. Co se výchozími nastaveními nevyřeší, je infrastruktura důvěry: kořenové certifikáty v hardwaru, podepisovací klíče firmwaru vypálené do zařízení, HSM s desetiletou zbývající životností, průmyslové a lékařské systémy, které budou v roce 2040 stále fungovat s kryptografickými předpoklady zapečenými ve výrobě. Ty nelze aktualizovat dodáním nové verze knihovny a v některých případech je nelze aktualizovat vůbec. Rozsah tohoto problému s náhradou se v současnosti neodráží v kapitálovém plánování nikoho.

Souběžně probíhá změna regulace. Zákon Cyber ​​Resilience Act v Evropě a srovnatelné rámce jinde změní povinnosti spojené s dodáváním softwaru s komponentami, které jste nenapsali. Většina organizací nepropracovala, co to znamená pro jejich závislost na open source nebo pro lidi, kteří jej udržují.

Tři lekce z třiceti let:

1. Přechody trvají o deset let déle, než se oznamuje. SSLv3 byl označen za zastaralý v roce 2015, ve výchozím nastavení vypnut v roce 2016 a jeho kód jsme konečně odstranili v dubnu 2026. To je jedenáct let u protokolu, o němž se všichni shodli, že je nefunkční. Plánujte postkvantovou migraci podle této reality, nikoli podle tiskové zprávy.
2. Výchozí nastavení jsou jediným bezpečnostním opatřením, které funguje ve velkém měřítku. Cokoli vyžaduje, aby se každý správce rozhodl správně, se neuskuteční. Hybridní postkvantová výměna klíčů se rozšířila tak rychle proto, že je ve výchozím nastavení zapnutá a nevyžaduje žádné rozhodnutí. Navrhujte pro lidi, kteří si nikdy nepřečtou vaši dokumentaci, protože to jsou téměř všichni.
3. Závisíte na menším počtu lidí, než si myslíte. Téměř každá organizace na světě spoléhá na kryptografický kód udržovaný velmi malým počtem jednotlivců. Platilo to, když jsme byli dva v Brisbane, a struktura se zásadně nezměnila, přestože význam a rizika vzrostly o několik řádů. Ať plánujete na příští desetiletí cokoli, část toho závisí na správci, kterého jste nikdy nekontaktovali a kterého nefinancujete. Je dobré to vědět dříve, než ho budete potřebovat.

Děkuji za skvělý rozhovor. Čtenáři, kteří se chtějí dozvědět více, by měli navštívit OpenSSL.