ťařina
Obsah Soubory
markdown

Postkvantova-kryptografie.md

12 kB 214 řádků Změněno Zobrazit na GitHubu Stáhnout
markdown
# 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](Sifrovani-zaklady), [asymetrickou kryptografii](Verejny-a-soukromy-klic) a [Diffie-Hellmana](Diffie-Hellman). ## 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: ```bashopenssl 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í | ```bashssh -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](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](#grover-symetrickou-kryptografii-jen-poškrábe). 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](Sifrovani-disku-a-souboru), 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](SSH#ssh-certifikáty) 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](Nahodnost-a-entropie) 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](Diffie-Hellman)** — co přesně se nahrazuje- **[TLS handshake krok za krokem](TLS-handshake)** — kde v handshaku to sedí- **[SSH do hloubky](SSH)** — kde už to běží nejdéle- **[Šifrování disků a souborů](Sifrovani-disku-a-souboru)** — dlouhodobě uložená data- **[Stavební kameny](Sifrovani-zaklady)** — proč je symetrická část bez problému