Postkvantová kryptografie v protokolu TLS: jak nasadit vše potřebné už dnes

U symetrických kryptografických algoritmů (jako AES nebo ChaCha20) se předpokládá, že jsou kvantově odolné, pouze bude nutné zvětšit velikost použitého klíče ze 128 bitů na 256 bitů – takto velký klíč je ale běžně používán již nyní a zvětšení velikosti symetrického klíče tedy obvykle představuje jen konfigurační změnu. Ovšem existují názory, že ani AES využívající klíč o velikosti 128 bitů nebude nikdy prolomeno ani s využitím kvantového počítače.

Problém nastává u asymetrických kryptografických algoritmů (např. RSA nebo algoritmy založené na bázi eliptických křivek jako jsou SecP256 či X25519), které jsou používány pro podepisování nebo k ustavení symetrického šifrovacího klíče. Tyto algoritmy jsou kvantově zranitelné a budou muset být nahrazeny novými algoritmy, které budou kvantově odolné – takové algoritmy se označují také jako postkvantové – ty by měly být odolné jak proti útoku běžným, tak kvantovým počítačem.

Kvantově odolnou kryptografii potřebujeme již nyní

Ač se to může zdát jako problém budoucnosti, potřebujeme kvantově odolnou kryptografii již dnes. Kryptograficky relevantní kvantový počítač ještě neexistuje a není ani jasné, kdy a zda vůbec dostupný bude. Zavádět již nyní postkvantovou kryptografii má ale smysl ze dvou důvodů.

Zaprvé, ač se to může zdát ve světě IT s podivem, mnoho specializovaných IT nebo řídicích systémů má velmi dlouhou dobu životnosti. Některé systémy se pořizují s předpokládanou životností 10 i více let – třeba elektronické občanské průkazy nebo cestovní pasy mají platnost 10 let. Pokud se naplní optimistické (či pesimistické, záleží na úhlu pohledu) představy a kryptograficky relevantní kvantový počítač bude dostupný na počátku 30. let 21. století, na přechod na kvantově odolnou kryptografii je u těchto systémů již teď pozdě a buď bude muset dojít k výměně těchto systémů, aktualizaci firmware (pokud to bude technicky možné) nebo zapouzdření komunikace do zabezpečeného protokolu.

Druhým důvodem je technika zvaná „harvest now, decrypt later” při které potenciální útočník může již nyní zaznamenat šifrovanou komunikaci a až bude dostupný dostatečně výkonný kvantový počítač, bude ji moci rozšifrovat a narušit tak zpětně její důvěrnost. Některé citlivé informace mohou být pro útočníka zajímavé třeba i po pěti letech. Typicky se bude jednat o státní tajemství, kdy útočníkem bude státní aktér (např. lokace tajných vojenských základen nebo seznam „špionů” může být cenný i po desítkách let).

Podle NÚKIB existuje reálná možnost (s pravděpodobností 40–50 %), že takové útoky již probíhají. V praxi je možné takový útok provést například napadením síťového zařízení mezi komunikujícími stranami (Man-in-the-Middle), odposloucháváním komunikace nebo přesměrováním provozu přes BGP hijacking. Obecně je velmi obtížné tyto útoky detekovat.

Na příchod kryptograficky relevantních kvantových počítačů reagují i státní regulátoři v oblasti kybernetické bezpečnosti. V Evropské unii by měl být podle zveřejněné roadmapy určené pro členské státy dokončen přechod na kvantově odolnou kryptografii u systémů zpracovávající vysoce citlivé informace do konce roku 2030, u středně citlivých pak do konce roku 2035. USA stanovili podobný deadline přechodu na postkvantovou kryptografii pro vládní agentury do roku 2035.

Přechod na postkvantovou kryptografii

Proto jsou zkoumány a vyvíjeny kvantově odolné algoritmy, které by měly zůstat neprolomitelné i poté, co bude dostupný dostatečně výkonný kvantový počítač. Tyto algoritmy jsou postupně implementovány do kryptografických protokolů např. do kryptografického protokolu TLS verze 1.3, což je v současné době nejčastěji používaným protokolem pro zabezpečenou komunikaci.

V tomto protokolu se kryptografické algoritmy využívají ve třech komponentách:

• Asymetrický algoritmus pro ověření protistrany (typicky podpis serverového certifikátu)
• Asymetrický algoritmus pro dohodnutí šifrovacího klíče pro symetrické šifrování
• Symetrický algoritmus pro samotné šifrování komunikace

TLSv1.3 v současné době podporuje pro symetrické šifrování blokový algoritmus AES s velikostí klíče 128 a 256 bitů a proudovým algoritmus ChaCha20. Podle doporučení NÚKIB jsou AES i ChaCha20 využívající klíč o délce 256 bitů kvantově odolné a typicky tedy stačí změnit konfiguraci klienta či serveru, aby se pro symetrické šifrování používaly jen tyto odolnější algoritmy.

U komponent využívajících asymetrické algoritmy ale bude potřeba změna algoritmu na kvantově odolný. I když již existují standardy algoritmů pro kvantově odolné podepisování (ML-DSA – FIPS 204 a SLH-DSA – FIPS 205), stále není vyřešeno, jakým způsobem zajistit podepisování certifikátů novým algoritmem se zachováním zpětné kompatibility s aplikacemi, které ještě nové algoritmy nepodporují.

V současné době je nejnaléhavější potřeba změny algoritmu u druhé komponenty a to u dohody nad šifrovacím klíčem. Pro narušení důvěrnosti komunikace prolomením algoritmu podpisu certifikátu bude možné tehdy, až bude reálně k dispozici dostatečně výkonný kvantový počítač – narušení komunikace musí nastat v době navazování spojení. U algoritmu dohody nad šifrovacím klíčem stačí zaznamenat komunikaci při navazování spojení, následně kvantovým počítačem vypočítat šifrovací klíč – tedy použít techniku „harvest now, decrypt later”.

U asymetrického algoritmu pro dohodu nad šifrovacím klíčem byla postkvantová kryptografie implementována nejdříve. Americká společnost NIST, která pro americké potřeby kryptografické algoritmy standardizuje a jejíž výstupy přebírá většina světa, už od roku 2016 pořádala soutěž o nejvhodnější postkvantový algoritmus pro dohodu nad šifrovacím klíčem.

Ještě před dokončením standardizačního procesu v rámci NIST došlo k prvním implementacím hybridního postkvantového algoritmu kombinujícího postkvantový Kyber768 a klasický X25519 využívající Curve25519, tato kombinace v protokolu TLSv1.3 dostala označení X25519Kyber768Draft00. Během dokončování standardizace algoritmu Kyber u NIST došlo k drobným úpravám algoritmu a finální verze byla publikována jako FIPS 203 s označením ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). Po finalizaci algoritmu došlo i ke změně v TLS, finalizovaná verze hybridního algorimu kombinujícího ML-KEM-768 a X25519 se nyní jmenuje X25519MLKEM768. Nepředpokládá se, že by podpora pro tento algoritmus byla přidána do již překonaného, ale stále používaného protokolu TLSv1.2.

FIPS 203 definuje tři typy algoritmu ML-KEM: 512, 768 a 1024. Číslo definuje parametry algoritmu, čímž ovlivňuje délku klíčů a tím i výpočetní náročnost a určuje bezpečnostní kategorii algoritmu.

Dále v článku se budeme věnovat primárně postkvantovým algoritmům pro dohodu nad šifrovacím klíčem.

Hybridní algoritmus pro dohodu nad šifrovacím klíčem

Někteří kryptologové ještě nemají důvěru v nové, časem neodzkoušené algoritmy a jejich implementace. RSA pochází z roku 1977, kryptografie nad eliptickými křivkami je z roku 1985 a v současné době nejčastěji používaná eliptická křivka využívaná pro dohodu nad klíči Curve25519 je z roku 2005.

Že je tato nedůvěra v nové algoritmy relevantní ukazuje případ algoritmu SIKE, který se dostal do čtvrtého, posledního kola šest let trvající soutěže NIST pro nový, kvantově odolný algoritmus na dohodu nad klíči. Tento algoritmus byl představen v roce 2011, ale až v roce 2022 se ukázalo, že jednu z implementací SIKE (SIKEp434) je možné prolomit pomocí běžného počítače s jedním procesorovým jádrem během několika hodin. Po tomto prolomení byl tento algoritmus ze soutěže vyřazen.

I kvůli této nedůvěře v březnu 2025 NIST vybral záložní algoritmus HQC, který je založen na jiném matematickém problému než ML-KEM a slouží jako záložní pro případ, pokud by byl ML-KEM prolomen. Standardizován by ale měl být až v roce 2027.

Proto se zatím nové postkvantové algoritmy pro dohodu nad klíči používají primárně v hybridním módu, kdy se pro dohodu nad klíčem používá kombinace jak klasického tak i kvantově odolného algoritmu. I kdyby došlo k prolomení jednoho z těchto algoritmů (typicky klasického kvantovým počítačem, kvantově odolného novým typem útoku pomocí běžného počítače), důvěrnost komunikace zůstane zachována. Podle NÚKIB je ale schváleno i samostatné použití algoritmu ML-KEM-1024.

V případě protokolu TLS se nejčastěji volí varianta kombinující klasický X25519 a postkvantový algoritmus ML-KEM-768. Návrh RFC definuje i kombinace SecP256r1 s ML-KEM-768 a SecP384r1 s ML-KEM-1024 (hlavním důvodem pro zavedení kombinace s SecP256r1 nebo SecP384r1 je ten, že algoritmus X25519 není schválen v rámci FIPS 140–3 a není možné jej využít v systémech, u kterých je vyžadována FIPS certifikace), další návrh RFC definuje samostatné použití ML-KEM. Zatím ale žádná z kombinací (kromě X25519MLKEM768) nebo samostatné použití ML-KEM není široce podporováno.

Dále v článku se tedy budeme věnovat primárně nejčastěji používanemu hybridnímu algoritmu pro dohodu nad šifrovacím klíčem X25519MLKEM768.

Jak funguje X25519MLKEM768 v TLSv1.3

V prostředí internetu, kde často není snadné nebo vůbec možné ovlivnit aplikaci, kterou využívá komunikující protistrana, je nutné zachovávat zpětnou kompatibilitu. Protokol TLS je proto navržen jako univerzální, aby umožňoval rozšiřitelnost kryptografických algoritmů, které jsou jednoznačně identifikovány pomocí tzv. named groups.

Dohoda na klíči probíhá při TLS handshake v rámci zpráv ClientHello a ServerHello, kde si strany dohodnou sdílené tajemství. Při navazování TLS komunikace klient zašle serveru ve zprávě ClientHello seznam algoritmů, které podporuje pro dohodu nad šifrovacím klíčem. Dle RFC 8446 definujícího protokol TLSv1.3 musí server i klient podporovat algoritmus SecP256r1 a měl by podporovat i X25519. Pokud klient podporuje i hybridní algoritmus X25519MLKEM768, jednoduše zašle serveru v seznamu podporovaných algoritmů i identifikátor tohoto algoritmu.

Při analýze provozu pomocí nástroje Wireshark naleznete seznam podporovaných algoritmů ze strany klienta ve zprávě ClientHello v poli Transport Layer Security → TLSv1.3 → Handshake Protocol → Extension: supported_groups → Supported Groups.

Pokud server tento algoritmus taktéž podporuje, může být použit pro dohodu nad klíči. Klientovi zašle zpět ve zprávě ServerHello název vybraného algoritmu a následně dojde i k ustanovení šifrovacího klíče pomocí hybridního postkvantového algoritmu. Takto vygenerovaný šifrovací klíč je následně použit pro symetrické šifrovaní. I v případě, že by útočník zaznamenal tuto komunikaci a měl k dispozici kryptograficky relevantní kvantový počítač, komunikace by měla zůstat neprolomitelná.

Při analýze provozu pomocí nástroje Wireshark naleznete dohodnutý algoritmus ve zprávě ServerHello v poli Transport Layer Security → TLSv1.3 → Handshake Protocol → Extension: key_share → Key Share extension.

Slabina jménem tldr.fail

Prohlížeče začaly experimentálně podporovat X25519Kyber768Draft00 již v roce 2023. Tehdy se ukázal problém, který se netýkal samotného protokolu, ale některých síťových prvků, které provádějí inspekci TLS provozu. Při navazování spojení se totiž jako součást zprávy ClientHello posílá veřejná část klíče pro ustanovení finálního šifrovacího klíče.

ML-KEM ale používá mnohem delší veřejné klíče, než jsme zvyklí z eliptických křivek – klasický algoritmus X25519 používá veřejný klíč o velikosti 32 bajtů, X25519Kyber768Draft00 resp. X25519MLKEM768 o velikosti 1216 bajtů (1184 bajtů pro ML-KEM-768 a 32 bajtů pro X25519). Tak velký klíč spolu s dalšími informacemi předávanými ve zprávě ClientHello se tak nemusí vejít do jednoho TCP paketu.

Některá zařízení ale mylně předpokládala, že ClientHello se vždy do jednoho paketu vejde a proto odmítla toto „pokažené” spojení povolit. Chyba dostala označení tldr.fail a týkala se například zařízení a systémů od společností Vercel, Cisco nebo Palo Alto – většinou už byla upravena novou verzí firmwaru nebo softwaru.

Vliv algoritmu X25519MLKEM768 na výkon

Algoritmus X25519MLKEM768 využívá větší klíče a tedy i mírně zvyšuje latence při navazování zabezpečeného spojení – ze strany serveru i klienta je potřeba přenést přibližně o 2000 bajtů navíc, což je vzhledem k rychlosti dnešních linek a velikosti současných webových stránek zanedbatelné, ale v některých prostředích s vyšší latencí (např. mobilní sítě) může mít mírný dopad.

Na latence má také vliv rychlost samotného výpočtu klíče. Dobrá zpráva je, že algoritmus ML-KEM-768 je násobně rychlejší než výpočet klíče u algoritmu X25519. Špatnou zprávou je, že v případě využití hybridního X25519MLKEM768 se musí zkombinovat a tedy vypočítat oba algoritmy. Podle společnosti Cloudflare je takový výpočet o desítky procent pomalejší než při použití samotného X25519.

Je potřeba ale upozornit na to, že jak větší velikost klíče, tak vyšší výpočetní náročnost se projeví jen při navazování nového spojení. Na samotnou rychlost přenosu a výpočetní náročnost šifrování obsahu má vliv použitý symetrický algoritmus, který se s použitím X25519MLKEM768 nemění. Podle Amazonu se výpočetní náročnost zvýší přibližně o 80–150 mikrosekund oproti použití P256 a sníží se počet požadavků za sekundu o 2 %.

Podpora X25519MLKEM768 v prohlížečích a operačních systémech

Podpora algoritmu X25519MLKEM768 v prohlížečích je již v současné době na dobré úrovni. Google Chrome a jeho deriváty jako Microsoft Edge podporují tento algoritmus od verze 131, která byla vydána v listopadu 2024. Již předtím Chrome podporoval dočasný algoritmus X25519Kyber768Draft00.

Mozilla Firefox podporuje X25519MLKEM768 od verze 132, která vyšla říjnu 2024. Podporu pro X25519Kyber768Draft00 bylo v předchozích verzích možné manuálně zapnout přes  about:config.

Google Chrome i Mozilla Firefox používají vlastní kryptografické knihovny nezávislé na typu a verzi operačního systému. Jiná situace je ale u aplikací, které využívají výchozí kryptografické knihovny poskytované operačním systémem. Např. Safari na macOS nebo na iPhone či iPad podporuje X25519MLKEM768 až od verze 26 těchto operačních systémů, které byly vydány 15. září 2025. U Microsoft Windows 11 je podpora v současné době dostupná pouze v rámci programu Windows Insider a verze podporující postkvantové algoritmy by měla být distribuována uživatelům na podzim 2025.

Do linuxových operačních systémů podpora přišla s novou verzí knihovny OpenSSL 3.5. Ta je integrována například v linuxových distribucích Alpine Linux od verze 3.22, CentOS 10 Stream, Debian Trixie nebo Fedora Rawhide. V případě, že aplikace využívá systémovou knihovnu na podporovaném systému, měla by automaticky podporovat i X25519MLKEM768 – výjimku mohou tvořit aplikace, u kterých jsou použité algoritmy konfigurovatelné nebo autor aplikace tyto algoritmy uvedl přímo v kódu aplikace.

V RHEL 10 a odvozených distribucích (AlmaLinux 10, RockyLinux 10) je možné podporu zapnout pomocí následující kombinace příkazů (interně bude použit doplněk Open Quantum Safe provider pro OpenSSL).

# dnf install crypto-policies-pq-preview crypto-policies-scripts
# update-crypto-policies --set DEFAULT:TEST-PQ

Podpora X25519MLKEM768 v kryptografických knihovnách

Jak již bylo zmíněno výše, podporu pro postkvantové algoritmy přineslo OpenSSL ve verzi 3.5, která byla vydána v dubnu 2025.

Pro implementaci některých algoritmů v nové verzi OpenSSL bylo využito kódu z knihovny BoringSSL, což je fork OpenSSL od Google, který používá např. Google Chrome. Obecně ale není vhodné používat tuto knihovnu v produkční prostředí, jelikož Google neprovádí u této knihovny žádné verzování a poskytuje jen minimální komunitní podporu.

Další možností, jak podporu pro postkvantové algoritmy přidat do starších verzí OpenSSL 3, je využít rozšíření Open Quantum Safe provider, které jako zásuvný modul přidává do OpenSSL mnoho různých postkvantových algoritmů. Obecně se ale použití tohoto doplňku pro produkční účely nedoporučuje a slouží spíše na experimentování s novými algoritmy.

Aplikace napsaná v jazyce Go využívající výchozí knihovnu crypto/tls podporují ve výchozím nastavení X25519MLKEM768 od verze 1.24.

Postkvantové algoritmy podporuje taktéž knihovna AWS-LC, což je fork OpenSSL a BoringSSL od Amazonu.

Podpora X25519MLKEM768 na straně webových služeb

Pokud máte webový prohlížeč, který podporuje X25519MLKEM768, komunikace s Google nebo CDN Cloudflare (která je často používána jako DDoS ochrana webových aplikací) již bude tento algoritmus využívat. Jednou z prvních aplikací (možná vůbec první) tohoto algoritmu v Česku je Portál NÚKIB, který slouží pro komunikaci mezi organizacemi spadajícím pod zákon o kybernetické bezpečnost a NÚKIB. Na tomto Portálu si můžete i jednoduše ověřit, zda váš prohlížeč podporuje postkvantovou dohodu nad klíči – v takovém případě je v patičce webu uveden odkaz Zabezpečeno postkvantovým šifrováním.

Globálně X25519MLKEM768 podporuje 28 % domén ze seznamu 100 tisíc nejnavštěvovanějších domén světa – ale téměř 27 % připadá na domény zabezpečené CDN Cloudflare. Podle jiného výzkumu společnosti F5 má ale podporu pro postkvantový algoritmus jen 9 % domén ze seznamu 100 tisíc nejnavštěvovanějších domén světa. Mezi doménami nejvyšší úrovně vede Austrálie a Nový Zéland se 17 % podporou.

V případě, že X25519MLKEM768 podporuje CDN, tak je sice postkvantově zabezpečena komunikace mezi prohlížečem s podporou tohoto algorimu a CDN, ale zda je i postkvantově zabezpečena komunikace z CDN do místa původu dat už není možné z veřejného skenování internetu zjistit.

Společnost Cloudflare taktéž zveřejňuje na své webové stránce Cloudflare Radar statistiky, jak velký podíl provozu na webové služby Cloudflare je již zabezpečeno pomocí kvantově odolné kryptografie. Celosvětově je v současné době již 37 % provozu zabezpečeno proti útoku kvantovým počítačem – před rokem to bylo pouze 17 %.

V případě přístupů na Portál NÚKIB využívá již 58 % HTTP požadavků algoritmus X25519MLKEM768.

Protokol TLS se ale používá i například pro zabezpečení e-mailové komunikace. Služba Gmail od Google pro příjem e-mailů pomocí protokolu SMTPS již podporuje algoritmus X25519MLKEM768.

Ověření použitého algoritmu pro dohodu nad klíčem v prohlížeči

Pokud chcete zjistit, jaký algoritmus pro dohodu nad klíčem byl použit pro sestavení zabezpečeného spojení ve webovém prohlížeči, lze k tomuto účelu využít Nástroje pro vývojáře.

V Google Chrome zvolte položku v menu Další nástroje → Nástroje pro vývojáře a přepněte se do záložky Privacy and Security. Následně v levém menu zvolte pod Security položku Overview. V sekci Connection se dozvíte verzi použitého protokolu TLS, typ algoritmu použitého pro dohodu nad klíči a taktéž typ algoritmu pro samotné symetrické šifrování přenášeného obsahu. V případě na obrázku níže byl použit protokol TLSv1.3, symetrický klíč byl vygenerován hybridním postkvantovým algoritmem X25519MLKEM768 a symetrické šifrování probíhalo AES s 128 bitovým klíčem v módu GCM.

V prohlížeči Mozilla Firefox je možné použitý algoritmus v menu Další nástroje → Nástroje pro webové vývojáře, následně přepnout na záložku Síť, obnovit stránku, kliknout na první položku v tabulce a zvolit vpravo záložku Zabezpečení. V položce „Grupa pro výměnu klíčů” naleznete použitý algoritmus, ve Firefoxu mlkem768×25519 odpovídá X25519MLKEM768.

Ověření podporovaných algoritmů z příkazové řádky

Pokud chcete ověřit, zda server podporuje postkvantovou kryptografii, je možné využít aplikaci openssl, která je součástí knihovny OpenSSL.

Nejprve si pomocí příkazu openssl list -kem-algorithms zjistíme, zda námi využitá verze OpenSSL podporuje algoritmus X25519MLKEM768.

# openssl list -kem-algorithms
  { 1.2.840.113549.1.1.1, 2.5.8.1.1, RSA, rsaEncryption } @ default
  { 1.2.840.10045.2.1, EC, id-ecPublicKey } @ default
  { 1.3.101.110, X25519 } @ default
  { 1.3.101.111, X448 } @ default
  { 2.16.840.1.101.3.4.4.1, id-alg-ml-kem-512, ML-KEM-512, MLKEM512 } @ default
  { 2.16.840.1.101.3.4.4.2, id-alg-ml-kem-768, ML-KEM-768, MLKEM768 } @ default
  { 2.16.840.1.101.3.4.4.3, id-alg-ml-kem-1024, ML-KEM-1024, MLKEM1024 } @ default
  X25519MLKEM768 @ default
  X448MLKEM1024 @ default
  SecP256r1MLKEM768 @ default
  SecP384r1MLKEM1024 @ default

Pokud používáte operační systém, který ještě nemá integrovanou OpenSSL ve verzi 3.5 nebo vyšší, nejjednodušší je si stáhnout Docker image s poslední distribucí Alpine a potřebnou verzi OpenSSL si doinstalovat:

docker run -it --rm alpine:3.22
apk add openssl curl

Následně zjistit, zda i při navázání spojení se serverem je tento algoritmus využit pomocí příkazu openssl s_client -connect portal.nukib.gov.cz:443, kde portal.nukib.gov.cz je doména serveru, na který se chceme připojit a za dvojtečkou následuje číslo portu (443 je typicky využit pro HTTPS). V položce Negotiated TLS1.3 group naleznete název algoritmu použitého pro dohodu nad klíči.

# openssl s_client -connect portal.nukib.gov.cz:443
Connecting to 185.48.23.26
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E6
verify return:1
depth=0 CN=portal.nukib.gov.cz
verify return:1
---
No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ecdsa_secp384r1_sha384
Negotiated TLS1.3 group: X25519MLKEM768
---
SSL handshake has read 3523 bytes and written 1632 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 384 bit
This TLS version forbids renegotiation.
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Jinou možností je přímo vynutit použitý algoritmus pomocí parametru -curves a specifikování algoritmu X25519MLKEM768. Pokud server tento algoritmus nebude podporovat, spojení nebude navázáno.

# openssl s_client -connect root.cz:443 -curves X25519MLKEM768 -tls1_3
Connecting to 91.213.160.188
CONNECTED(00000003)
20AD05BCFFFF0000:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:916:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>

Ke stejnému účelu lze použít i oblíbený nástroj curl a to za použití příkazu curl -s -v -o /dev/null https://portal.nukib.gov.cz, který na řádku začínajícím na SSL connection vypíše použité algoritmy pro spojení. Tento postup lze využít pouze na systémech, kde curl využívá kryptografickou knihovnu s podporou příslušných algoritmů.

# curl -s -v -o /dev/null https://portal.nukib.gov.cz
* Host portal.nukib.gov.cz:443 was resolved.
* IPv6: 2a01:95a0:c010:45:1:5ee:bad:c0de
* IPv4: 185.48.23.26
* ALPN: curl offers h2,http/1.1
...
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey

Využití X25519MLKEM768 u webového serveru

Pokud provozujete webový server a chce, aby komunikace na něj byla odolná proti útoku „harvest now, decrypt later” nebo jen rádi experimentujete s novými technologii, můžete aktivovat podporu pro X25519MLKEM768 u vašeho webového serveru. Ukážeme si to na příkladu nejpopulárnějšího webového serveru Nginx, který využívá knihovny OpenSSL. V praxi se nabízí čtyři možnosti, jak podporu do tohoto serveru přidat:

1. Kompilace Nginx s BoringSSL,
2. kompilace Nginx s OpenSSL 3.5,
3. využití operačního systému s knihovnou OpenSSL 3.5,
4. využití operačního systému s knihovnou OpenSSL 3 a Open Quantum Safe provider.

U jiných webových serverů či aplikací používajících knihovnu OpenSSL bude princip obdobný.

Kompilace Nginx s BoringSSL

Pro kompilaci Nginx s BoringSSL je možné na Ubuntu 24.04 postupovat následovně:

# apt-get update
# apt-get install build-essential curl libpcre3-dev zlib1g-dev cmake ninja-build
# curl -LO https://github.com/google/boringssl/archive/refs/heads/main.tar.gz
# tar -zxvf main.tar.gz
# cd boringssl-main
# cmake -GNinja -B build
# ninja -C build
# cd ..
# curl -O https://nginx.org/download/nginx-1.28.0.tar.gz
# tar -zxvf nginx-1.28.0.tar.gz
# cd nginx-1.28.0
# ./configure --with-cc-opt="-I../boringssl-main/include -x c" --with-ld-opt="-L../boringssl-main/build -lstdc++" --with-cc=c++
# make

Po kompilaci můžeme ověřit, zda byl Nginx zkompilován opravdu s knihovnou BoringSSL:

# ./objs/nginx -V
nginx version: nginx/1.28.0
built by gcc 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04)
built with OpenSSL 1.1.1 (compatible; BoringSSL) (running with BoringSSL)
TLS SNI support enabled

Kompilace Nginx s BoringSSL je vhodná pro experimentování, ale osobně jej nedoporučuji pro produkční prostředí, jelikož knihovna BoringSSL nevydává stabilní verze a nezachovává tak zpětnou kompatibilitu – samotný popis knihovny uvádí: Nedoporučujeme, aby se na něj třetí strany spoléhaly. To bude pravděpodobně frustrující, protože neexistují žádné záruky stability API nebo ABI. V případě jakékoliv zranitelnosti je potřeba navíc ručně aktualizovat knihovnu BoringSSL a znovu zkompilovat Nginx.

Kompilace Nginx s OpenSSL 3.5

Tuto možnost využijete v případě, že použitý operační systém ještě neintegruje knihovnu OpenSSL 3.5 nebo novější a zároveň nechcete využívat nestabilní BoringSSL. Např. Ubuntu 24.04 obsahuje OpenSSL 3.0.13, která ještě postkvantové algoritmy nepodporuje.

# apt-get update
# apt-get install build-essential curl libpcre3-dev zlib1g-dev
# curl -LO https://github.com/openssl/openssl/releases/download/openssl-3.5.1/openssl-3.5.1.tar.gz
# tar -zxvf openssl-3.5.1.tar.gz
# curl -O https://nginx.org/download/nginx-1.28.0.tar.gz
# tar -zxvf nginx-1.28.0.tar.gz
# cd nginx-1.28.0
# ./configure --with-http_ssl_module --with-openssl=../openssl-3.5.1
# make

Po kompilaci můžeme ověřit, zda byl Nginx zkompilován opravdu s knihovnou OpenSSL 3.5:

./objs/nginx -V
nginx version: nginx/1.28.0
built by gcc 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04)
built with OpenSSL 3.5.1 1 Jul 2025
TLS SNI support enabled

Z výpisu příkazu ldd můžete ověřit, že knihovna OpenSSL byla s Nginx staticky linkována a Nginx nevyžívá systémovou knihovnu:

# ldd ./objs/nginx
linux-vdso.so.1 (0x0000ffff9fe3d000)
libcrypt.so.1 => /lib/aarch64-linux-gnu/libcrypt.so.1 (0x0000ffff9fdb0000)
libpcre.so.3 => /lib/aarch64-linux-gnu/libpcre.so.3 (0x0000ffff9f570000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffff9fd70000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff9f3b0000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff9fe00000)

Využítí operačního systému s knihovnou OpenSSL 3.5

Vhodnější je použít operační systém, který již integruje knihovnu OpenSSL verze 3.5. Například Nginx nainstalovaný na Alpine Linux 3.22 již bude podporovat postkvantové algoritmy bez potřeby ruční kompilace binárky:

# apk add nginx
# nginx -V
nginx version: nginx/1.28.0
built with OpenSSL 3.5.0 8 Apr 2025 (running with OpenSSL 3.5.1 1 Jul 2025)
TLS SNI support enabled

Využítí operačního systému s knihovnou OpenSSL 3 a Open Quantum Safe provider

Tento postup je nejvhodnější pro operační systémy RHEL 10, AlmaLinux 10 nebo CentOS Stream 10 jelikož je Open Quantum Safe provider součástí standardních repozitářů

# dnf install crypto-policies-pq-preview nginx

Po instalaci můžeme ověřit, zda OpenSSL podporuje algoritmus X25519MLKEM768 za pomocí knihovny Open Quantum Safe provider pomocí již výše zmíněného příkazu openssl list -kem-algorithms, jen výstup bude o něco odlišný:

# openssl list -kem-algorithms
  { 1.2.840.113549.1.1.1, 2.5.8.1.1, RSA, rsaEncryption } @ default
  { 1.2.840.10045.2.1, EC, id-ecPublicKey } @ default
  { 1.3.101.110, X25519 } @ default
  { 1.3.101.111, X448 } @ default
  mlkem512 @ oqsprovider
  p256_mlkem512 @ oqsprovider
  x25519_mlkem512 @ oqsprovider
  mlkem768 @ oqsprovider
  p384_mlkem768 @ oqsprovider
  x448_mlkem768 @ oqsprovider
  X25519MLKEM768 @ oqsprovider
  SecP256r1MLKEM768 @ oqsprovider
  mlkem1024 @ oqsprovider
  p521_mlkem1024 @ oqsprovider
  SecP384r1MLKEM1024 @ oqsprovider

Konfigurace Nginx

Algoritmy pro dohodu nad klíčem je možné v Nginx konfigurovat pomocí parametru ssl_ecdh_curve umístěné v bloku http nebo server. Typická konfigurace povolují X25519MLKEM768 se zachováním zpětné kompatiblity by vypadala následovně:

http {
    ...
    # zapnutí logování použité verze TLS protokolu a použitých kryptografických algoritmů
    log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" $ssl_protocol $ssl_cipher $ssl_curve';
    ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1:secp384p1; # na pořadí záleží, server vybere první algoritmus, který podporuje klient
    ...
}

Pro vynucení podpory pouze kvantově odolné kryptografie pro dohodu nad šifrovacím klíčem a i pro symetrické šifrovaní je možné v Nginx použít následující konfiguraci:

http {
    ...
    ssl_protocols TLSv1.3;
    ssl_ecdh_curve X25519MLKEM768;
    ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256; # na pořadí záleží, server vybere první algoritmus, který podporuje klient
    ...
}

Taková konfigurace má v současné době význam pouze u systémů, u kterých máme kontrolu nad zařízeními a aplikacemi, které k nim přistupují (např. k internímu systému, který je dostupný pouze ze spravovaných zařízení s aktuální verzí Microsoft Edge). Tato konfiguraci taktéž porušuje RFC 8446 definující TLSv1.3, které uvádí, že vždy musí být implementován algoritmus TLS_AES⁠_⁠128⁠_GCM_SHA256 pro symetrické šifrování a musí podporovat secp256r1 pro dohodu nad klíčem.

Připravit na zítřek se musíme už dnes

Kvantové počítače sice dnes ještě nejsou schopné prolomit běžně používané asymetrické algoritmy, ale doba, kdy to možné bude, se blíží. Už dnes existuje reálné riziko útoků typu „harvest now, decrypt later”, při kterých útočník sbírá šifrovaná data s úmyslem je později dešifrovat pomocí kvantového počítače.

To je obzvlášť nebezpečné pro data s dlouhou životností – typicky v oblasti zdravotnictví, financí nebo státní správy. Postkvantová kryptografie nabízí cestu, jak se těmto hrozbám bránit. Díky hybridním algoritmům pro dohodu nad klíči jako X25519MLKEM768 je možné zavádět kvantově odolné ustanovení klíče už nyní, a to bez ohrožení zpětné kompatibility.

Další informace od NÚKIB k postkvantové kryptografii

• Minimální požadavky na kryptografické algoritmy platné pro systémy spadající pod regulaci zákona o kybernetické bezpečnosti
• Kvantová hrozba a kvantově odolná kryptografie
• Strategická analýza útoku harvest now, decrypt later
• Strategická analýza: Útoky s využitím kvantového počítače mohou prolomit současné šifrování: řešením je včasná a efektivní implementace nových standardů

(Není-li uvedeno jinak, je autorem obrázků Jakub Onderka.)