IETF popsal v RFC 10042 tři hybridní postkvantové výměny klíčů pro SSH

Dokument RFC 10042 nese datum srpen 2026 a v datatrackeru IETF je zapsaný 31. srpna. Podepsali ho Panos Kampanakis a Torben Hansen z AWS a Douglas Stebila z University of Waterloo. Kategorie je Informational, ne Standards Track: text tedy popisuje postup, který je venku, spíš než aby ho někomu nařizoval.

Tři jména v rejstříku IANA

Nové metody se v pozdravu SSH ohlašují těmito názvy:

• mlkem768nistp256-sha256 – ML-KEM-768 s křivkou NIST P-256 a hashem SHA-256,
• mlkem1024nistp384-sha384 – ML-KEM-1024 s křivkou NIST P-384 a SHA-384,
• mlkem768x25519-sha256 – ML-KEM-768 s Curve25519 a SHA-256.

Všechny tři už rejstřík IANA vede s odkazem na RFC 10042 a se známkou SHOULD ve sloupci „OK to Implement“. Ve stejné tabulce leží i tři čistě mřížkové metody bez eliptické části, tedy mlkem512-sha256, mlkem768-sha256 a mlkem1024-sha384. Ty se ale odvolávají jen na koncept jednotlivce a mají jen MAY.

Proč se stará matematika nevyhazuje

Útok, kterému má hybrid předejít, jmenuje dokument anglicky „harvest now, decrypt later“. Odposlouchávající strana si dnes uloží zašifrovaný provoz a rozšifruje ho později, až bude mít dost velký kvantový počítač. Klasická výměna klíčů v SSH stojí na diskrétním logaritmu, a ten by takový stroj vyřešil.

Řešení není výměna jedné matematiky za druhou, ale jejich složení. Bezpečnost obou částí je podle textu nezávislá, takže hybridní metoda je vždy aspoň tak silná jako ta silnější z dvojice. Kdyby se trhlina našla v ML-KEM, drží spojení eliptická křivka. Kdyby padla křivka, drží ML-KEM.

Sdílené tajemství se hashuje, ne skládá jako číslo

Každá půlka výměny vyrobí vlastní tajemství a RFC je spojuje předpisem K = HASH(K_PQ || K_CL), kde K_PQ pochází z ML-KEM a K_CL z eliptické křivky.

Zajímavější než ten vzorec je způsob zápisu obou vstupů. Starší výměny v SSH kódovaly sdílené tajemství jako celé číslo (mpint), jehož délka kolísá podle hodnoty. RFC 10042 obě dílčí tajemství zapisuje jako pole bajtů pevné délky, tedy 32 bajtů pro Curve25519 i pro secp256r1 a 48 bajtů pro secp384r1. Důvod dokument jmenuje: proměnlivá délka vstupu do hashovací funkce může prozradit nejvyšší bit tajemství nebo to, že nejvyšší bajty jsou nulové. Odkazuje u toho na časovací útoky Lucky Thirteen a Raccoon.

Od TLS 1.3 se SSH v tomhle bodě liší. Tam se obě tajemství pouze zřetězí a rovnou vstupují do rozvrhu klíčů, kdežto tady se zřetězená dvojice ještě prožene hashem. Text uvádí, že rozdíl je kvůli efektivitě. V TLS 1.2 přitom míří práce IETF opačným směrem: RFC 10015 z července 2026 tam výměnu klíčů přes RSA i přes Diffieho–Hellmana nad konečným tělesem zakázalo.

Dvě věci žádá bezpečnostní oddíl závazně. Klíčový pár pro ECDH i pro ML-KEM se musí vygenerovat pro každé spojení znovu a implementace nesmí při tvorbě šifrových textů ML-KEM sáhnout po téže náhodnosti dvakrát.

OpenSSH i PuTTY tu metodu nabízely dřív, než vzniklo RFC

Podle poznámek k vydání OpenSSH přibyla metoda mlkem768x25519-sha256 už ve verzi 9.9 z 19. září 2024, a to s odkazem na tehdejší koncept draft-kampanakis-curdle-ssh-pq-ke-03. Výchozí metodou pro dohodu klíče se stala v OpenSSH 10.0 z 9. dubna 2025. PuTTY přidal podporu ML-KEM ve verzi 0.83 z 8. února 2025.

Cesta k číslu RFC byla dlouhá. První verze individuálního konceptu má v datatrackeru datum 20. listopadu 2022, pracovní skupina sshm si dokument převzala jako svůj 29. ledna 2025 a poslední, desátou revizi odevzdala 26. února 2026. Mezi prvním konceptem a vydaným RFC tak uplynuly bezmála čtyři roky.

Není to ani první postkvantová výměna klíčů pro SSH s vlastním číslem. V dubnu 2026 vyšlo RFC 9941 o metodě sntrup761x25519-sha512, tedy o kombinaci Streamlined NTRU Prime a X25519, kterou OpenSSH zapnul jako výchozí ještě dřív. I ono je Informational a jeho spoluautorem je Markus Friedl z OpenSSH.

Co dokument nechává otevřené

Velikost paketů. RFC 4253 žádá po implementacích SSH, aby zvládly nekomprimovaný obsah do 32 768 bajtů a celý paket do 35 000 bajtů. Postkvantové výměny umějí posílat velké zprávy, jenže RFC 10042 výslovně píše, že jeho tři metody tyhle meze nepřekračují, a pro případ, že by je nějaká výměna překročila, žádné nové chování nezavádí.

Opatrně je psaná i příloha o FIPS. Prosté zřetězení tajemství ze schváleného algoritmu (secp256r1, secp384r1, ML-KEM) s tajemstvím z neschváleného (X25519) je podle NIST SP 800-227 přípustné a odvození klíčů v SSH schvaluje SP 800-135. Autoři z toho vyvozují, že kombinátor v dokumentu podle FIPS schválený nejspíš je, byť ho SP 800-227 jmenovitě neuvádí. Jistotu tedy nedávají a čtenář, který potřebuje razítko, si ji z textu neodnese.

Pro správce serverů z toho plyne málo práce. Kdo má OpenSSH 10.0 nebo novější na obou koncích, hybridní výměnu už používá, aniž o tom ví. Zbytek je papírování, které tomu stavu dodalo číslo.

Zdroje

• RFC 10042: Post-Quantum/Traditional Hybrid Key Exchange with the Module-Lattice-Based Key-Encapsulation Mechanism for Use in SSH, RFC Editor
• draft-ietf-sshm-mlkem-hybrid-kex, datatracker IETF
• Secure Shell (SSH) Protocol Parameters, IANA
• OpenSSH Release Notes, projekt OpenSSH
• PuTTY change log, Simon Tatham
• RFC 9941: SSH Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512, RFC Editor