Postkvantova kryptografie

Postkvantová kryptografie

Kolem kvantových počítačů je hodně hluku a málo praktických informací. Pravda je nudnější a užitečnější než obojí, co se obvykle píše: část kryptografie kvantový počítač zboří úplně, část se ho skoro netýká, a přechod už tiše probíhá v tvém prohlížeči i v SSH, aniž bys cokoliv nastavoval.

Tahle stránka říká, co se rozbije, co ne, co s tím dělat a hlavně čemu nevěřit.

Navazuje na stavební kameny, asymetrickou kryptografii a Diffie-Hellmana.

Co se skutečně rozbije

Existují dva relevantní kvantové algoritmy a je zásadní je nezaměňovat.

Shor: konec asymetrické kryptografie

Peter Shor v roce 1994 ukázal, že dostatečně velký kvantový počítač umí efektivně rozkládat čísla na součin a řešit diskrétní logaritmus. To jsou přesně ty dvě úlohy, na kterých stojí veškerá dnešní asymetrická kryptografie.

Není to zrychlení, je to zásadní změna složitosti. RSA, klasický Diffie-Hellman, ECDH, ECDSA i Ed25519 padnou úplně. Delší klíč nepomůže — RSA-16384 padne o něco později než RSA-2048, ale padne.

Eliptické křivky jsou na tom dokonce hůř: potřebují méně kvantových bitů než RSA stejné klasické síly. Ironie výhody, kterou mají proti klasickým útokům.

Grover: symetrickou kryptografii jen poškrábe

Groverův algoritmus zrychlí hledání hrubou silou z 2ⁿ na zhruba 2^(n/2). Pro AES-128 to znamená efektivně 64 bitů, což zní znepokojivě.

V praxi to znepokojivé není. Grover se špatně paralelizuje — dvojnásobek strojů nepřinese dvojnásobné zrychlení, jen odmocninový posun — a musí běžet jako jeden dlouhý souvislý výpočet, což je u kvantového hardwaru to nejtěžší. Odborný konsenzus je, že AES-128 zůstane v praxi použitelný, ale AES-256 je levná jistota.

	Klasicky	Po Shorovi / Groverovi
RSA-2048, RSA-4096	bezpečné	rozbité
Diffie-Hellman, ECDH, X25519	bezpečné	rozbité
ECDSA, Ed25519, RSA podpisy	bezpečné	rozbité
AES-128	128 bitů	~64 bitů, prakticky stále v pořádku
AES-256, ChaCha20	256 bitů	~128 bitů, bez problému
SHA-256, SHA-3, BLAKE3	128 bitů proti kolizím	~85 bitů proti kolizím, v pořádku
HMAC, Argon2, hesla		bez problému

Zapamatuj si tenhle závěr: veškerý objem dat jede symetricky a ten je v pořádku. Problém je jen v tom, jak se strany na klíč domluví — a čím se podepisují.

Kdy to bude

Nikdo neví a kdo tvrdí opak, něco prodává.

Dnešní stroje mají stovky až tisíce fyzických qubitů s vysokou chybovostí. Na rozložení 2048bitového RSA je potřeba řádově miliony fyzických qubitů kvůli korekci chyb, které dají několik tisíc stabilních logických. To je rozdíl několika řádů, ne poslední kilometr.

Odhady odborníků se rozprostírají zhruba mezi lety 2035 a „možná nikdy". Rekordy typu „rozložili jsme číslo 21" jsou demonstrace principu, ne pokrok směrem k reálným klíčům.

Nemá tedy smysl panikařit. Má smysl vědět proč se přesto migruje.

Harvest now, decrypt later

Tohle je jediný důvod, proč se něco děje už dnes.

Kdo si dnes uloží zašifrovaný provoz, může ho dešifrovat, až bude mít čím.

Odposlouchávat linku a ukládat data je levné a děje se to. Když se za deset nebo dvacet let objeví použitelný kvantový počítač, veškerý archivovaný provoz se otevře najednou — i ten, který dnes vypadá dokonale chráněný.

Z toho plyne rozdělení naléhavosti, které dává smysl:

Výměna klíčů je naléhavá. Data, která dnes projdou linkou, mohou být zajímavá i za dvacet let. Tady se migruje teď a tady už migrace běží.

Podpisy nejsou naléhavé. Padělat dnešní podpis v budoucnosti nemá smysl — certifikát bude dávno vypršelý a software dávno nahrazený. Podpisy se musí přepnout dřív, než kvantový počítač vznikne, ale ne dřív než dnes.

Dlouhodobě uložená data jsou naléhavá. Šifrovaná záloha, která má vydržet dvacet let, potřebuje AES-256 už dnes.

Kdyby ti někdo chtěl prodat postkvantové řešení: zeptej se, jestli řeší výměnu klíčů. Jinak řeší nesprávný problém.

Nové algoritmy

NIST vyhlásil soutěž v roce 2016 a v srpnu 2024 vydal první tři standardy.

Standard	Algoritmus	Původní název	Na co
FIPS 203	ML-KEM	Kyber	výměna klíčů
FIPS 204	ML-DSA	Dilithium	podpisy
FIPS 205	SLH-DSA	SPHINCS+	podpisy, záložní varianta

Většina z nich stojí na mřížkách — na úloze najít nejkratší vektor v mřížce o mnoha dimenzích, kterou kvantový počítač neumí nijak zrychlit. SLH-DSA je jiná káva: stojí jen na hashích, tedy na tom nejjistějším, co v kryptografii máme. Zaplatí za to obrovskými podpisy a je tam záměrně jako pojistka pro případ, že se v mřížkách najde díra.

Zvláštní pojem, na který narazíš: KEM (key encapsulation mechanism). Není to výměna klíčů jako u Diffie-Hellmana, kde obě strany přispějí. Funguje to jinak — jedna strana pošle veřejný klíč, druhá si vygeneruje náhodné tajemství, zapouzdří ho tím klíčem a pošle zpátky. Výsledek je stejný (obě strany mají společné tajemství), ale postup je jednosměrný. Proto se v hybridech kombinuje s klasickým DH.

Za co se platí velikostí

Tohle je jediný praktický dopad, který v síti opravdu uvidíš:

	Veřejný klíč	Podpis / zapouzdření
X25519	32 B	32 B
Ed25519	32 B	64 B
RSA-2048	256 B	256 B
ML-KEM-768	1 184 B	1 088 B
ML-DSA-65	1 952 B	3 309 B
SLH-DSA (rychlá varianta)	32 B	17–50 kB

Z 32 bajtů na 1 184 je faktor 37. Důsledky jsou reálné:

ClientHello se přestal vejít do jednoho paketu. Když se v roce 2024 zapnul hybridní režim v Chrome, některé krabice ve stylu firewallů a „bezpečnostních" prostředníků na dvoupaketový pozdrav nebyly připravené a rozbily HTTPS. Nešlo o chybu v kryptografii, ale o krabice, které předpokládaly, že větší ClientHello neexistuje.

U DNS a QUIC to bolí víc, protože tam se s velikostí paketů opravdu počítá.

Podpisy zatím nikam nespěchají. Certifikát s ML-DSA znamená řetěz o desítky kilobajtů, což se u každého jednotlivého spojení projeví. Proto se podpisy migrují až po výměně klíčů — a proto je to dobře.

Hybridní režim

Nikdo dnes nesází všechno na algoritmy staré deset let. Řešením je udělat obojí a spojit výsledky:

sdílené tajemství = KDF( X25519_výsledek ‖ ML-KEM_výsledek )

Aby útočník získal klíč, musí zlomit obě části. Klasická polovina chrání pro případ, že se v mřížkách najde slabina — a to není teoretická obava, jeden ze soutěžících algoritmů (SIKE) padl v roce 2022 na běžném notebooku za hodinu, když byl už ve finále.

Tenhle přístup má jednu velkou výhodu: nasazení nemůže nic zhoršit. Nejhorší možný scénář je, že jsi zaplatil kilobajtem navíc.

Co už běží

Nejlepší část celé stránky: většinu z toho už máš a nemusel jsi nic dělat.

TLS

Prohlížeče zapnuly X25519MLKEM768 jako výchozí volbu během let 2024 a 2025. Cloudflare, Google i další velcí poskytovatelé ji na straně serverů podporují.

Ověř si to sám:

openssl s_client -connect cloudflare.com:443 </dev/null 2>&1 | grep -i "group"
# Negotiated TLS1.3 group: X25519MLKEM768

V prohlížeči: Firefox má about:networking#http, Chrome ukáže vyjednanou skupinu v Developer Tools → Security.

Na svém serveru to potřebuje OpenSSL 3.5 nebo novější (případně nginx s BoringSSL). Nic se nekonfiguruje — je to jen další jméno ve supported_groups a klient si ho vybere sám.

SSH

Tady byl OpenSSH napřed před všemi ostatními:

Verze	Výchozí výměna klíčů
9.0 (2022)	sntrup761x25519-sha512 — hybrid s NTRU Prime
9.9 (2024)	přidána podpora mlkem768x25519-sha256
10.0 (2025)	mlkem768x25519-sha256 jako výchozí

ssh -Q kex | grep -E "mlkem|sntrup"
ssh -v server 2>&1 | grep "kex: algorithm"

Pokud máš OpenSSH 9.0 nebo novější, tvoje SSH spojení jsou postkvantově chráněná už teď a nemusel jsi o tom vědět.

WireGuard

Zatím ne. WireGuard používá X25519 a jeho návrh záměrně nemá vyjednávání algoritmů, takže se to nedá zapnout — muselo by se změnit v protokolu.

Existuje obcházka: předsdílený symetrický klíč.

[Peer]
PublicKey = ...
PresharedKey = <výstup z `wg genpsk`>

Ten se přimíchá k výsledku výměny klíčů. Kdo ho nezná, spojení nedešifruje ani s kvantovým počítačem, protože 256bitový symetrický klíč je proti Groverovi v pořádku. Musíš ho ale dostat na obě strany bezpečnou cestou.

Pro homelab je to nadbytečné. Pro tunel, jehož obsah má být tajný i za dvacet let, je to řádek konfigurace navíc.

Co dělat prakticky

Seřazeno podle poměru užitku k námaze.

1. Aktualizuj. Tím je hotová většina práce. Nový OpenSSH, nový prohlížeč, nové OpenSSL. Postkvantová výměna klíčů se zapne sama.

2. Používej AES-256 tam, kde data přežijí dekádu. Šifrované zálohy, archivy, LUKS na discích, které někam poputují. restic i borg používají AES-256 ve výchozím stavu, takže ani tady většinou není co dělat.

3. Nespěchej s podpisy. Certifikáty a podpisy softwaru migrují dodavatelé, ne ty. Vlastní SSH CA s Ed25519 je dnes naprosto v pořádku.

4. U opravdu dlouhodobých tajemství přidej předsdílený klíč. WireGuard PresharedKey, případně další vrstva symetrického šifrování.

5. Nekupuj nic s nálepkou „quantum". Viz níže.

Pro naprostou většinu domácích sítí je bod 1 celá odpověď.

Čemu nevěřit

„Kvantově bezpečný VPN/router/NAS." Skoro vždycky marketing okolo něčeho, co používá stejný AES-256 jako všichni ostatní.

„Quantum random number generator." Fyzikálně zajímavé, prakticky zbytečné. Systémový generátor je dostatečný a rizikem je jeho selhání, ne nedostatek kvantovosti.

„Kvantová kryptografie" (QKD). Skutečná technologie, ale úplně jiná věc — přenos klíče po optickém vlákně s využitím kvantových stavů. Potřebuje vyhrazené vlákno, nefunguje přes internet, neřeší ověření protistrany a agentury NSA i NCSC ji pro běžné použití nedoporučují. Do domácí sítě si ji nekup.

„RSA prolomeno!" Zhruba jednou ročně proběhne titulek o rozkladu velkého čísla kvantovým počítačem. Vždycky jde o speciálně zvolené číslo se strukturou, kterou skutečné RSA klíče nemají.

„Musíš migrovat okamžitě, jinak…" Migrace probíhá a nevyžaduje od tebe nic než aktualizace. Kdo ti prodává naléhavost, prodává naléhavost.

Co si odnést

Symetrická kryptografie je v pohodě. AES, ChaCha20, hashe, hesla — beze změny.

Asymetrická kryptografie padne celá. RSA, DH, ECC. Ne oslabí, padne.

Naléhavá je výměna klíčů, ne podpisy. Kvůli ukládání provozu na později.

Hybridní režim je správná odpověď a už běží ve tvém prohlížeči i v SSH.

Kvantový počítač schopný lámat klíče neexistuje a nikdo neví, kdy bude.

Tvůj úkol je aktualizovat. Nic víc se od tebe nečeká.

Kam dál

• Diffie-Hellman — co přesně se nahrazuje
• TLS handshake krok za krokem — kde v handshaku to sedí
• SSH do hloubky — kde už to běží nejdéle
• Šifrování disků a souborů — dlouhodobě uložená data
• Stavební kameny — proč je symetrická část bez problému