ML-KEM ni čarobna zamenjava za RSA.

Izdaja 14 serije »Postkvantna varnost v slovensko-nemški dobavni verigi«. Za omrežne strokovnjake in razvijalce, ki nastavljajo ali programirajo povezave do nemških naročnikov.

»RSA ni kvantno odporen, zato ga bomo zamenjali z ML-KEM.« Stavek se sliši logično, a drži le deloma. RSA v vaših sistemih namreč ne opravlja ene naloge, ampak tri: prenaša ključe, podpisuje in včasih, čeprav ne bi smel, šifrira podatke. ML-KEM zna samo prvo.

V tem članku: Tri naloge, ki jih opravlja RSA · Kaj zamenja kaj · Simetrična kriptografija · Zakaj hibridno · Izvedba ni podrobnost · Primer · Ko naslovnik še ni pripravljen · Kako preveriti svoje profile · Vprašanje za naročnika · Priloga: matrika in profili

Pojdite skozi svoj popis (izdaja 04 ali 09) in pri vsaki uporabi RSA zapišite, kaj dejansko počne:

• Prenos ključa. RSA zašifrira naključni sejni ključ, s katerim se nato podatki šifrirajo simetrično. Tako je delovala izmenjava ključev v starejših različicah TLS in tako so še danes zaščitena marsikatera šifrirana e-poštna sporočila in datoteke.
• Podpis. RSA podpiše dokument, potrdilo, žeton ali programsko opremo. Prejemnik z javnim ključem preveri, da je podpis pristen.
• Neposredno šifriranje podatkov. Kratek podatek, na primer geslo ali številka, se zašifrira neposredno z RSA. Redko, a se najde, predvsem v starejših lastnih rešitvah.

Podobno velja za eliptične krivulje: ECDH služi dogovoru o ključu, ECDSA in EdDSA podpisom. Ime postopka vam ne pove naloge. Naloga je tisto, kar šteje.

ML-KEM je mehanizem za enkapsulacijo ključa (KEM). Ne šifrira podatkov in ne podpisuje. Ustvari skupni ključ, s katerim nato AES šifrira podatke. Če ste z RSA neposredno šifrirali podatke, z ML-KEM tega ne morete narediti enako; spremeniti morate postopek, ne le algoritma: najprej enkapsulirate ključ, nato z njim šifrirate.

Kjer RSA podpisuje, ga ML-KEM sploh ne more nadomestiti. Tam je zamenjava ML-DSA ali SLH-DSA, z drugačnimi velikostmi, drugačnimi knjižnicami in pogosto drugačnim upravljanjem ključev.

Pogosto vprašanje: če kvantni računalnik ogroža RSA, ali ogroža tudi AES? Odgovor je bistveno blažji. Za simetrične postopke je znan kvantni algoritem (Grover), ki iskanje ključa pospeši, a ne zlomi postopka. Zato se za dolgoročno zaupnost priporočajo ključi dolžine 256 bitov, ne nov postopek. Podobno velja za zgoščevalne funkcije, kot sta SHA-256 in SHA-3.

Za prakso to pomeni dvoje. Prvič: šifriranja podatkov z AES-256 vam ni treba zamenjati; pozornost potrebuje mehanizem, ki ključ AES prenese ali dogovori. Drugič: kjer si strani že danes delita vnaprej dogovorjen simetrični ključ, na primer pri nekaterih povezavah VPN ali v industrijskih protokolih, je kvantno tveganje manjše, je pa toliko pomembnejše, kako je bil ta ključ razdeljen in kako se menja.

Hibridni postopek združi klasični in postkvantni postopek tako, da ostane rezultat varen, dokler je vsaj eden od njiju nezlomljen. V TLS 1.3 je razširjena kombinacija X25519MLKEM768: klasični dogovor o ključu z eliptičnimi krivuljami in ML-KEM-768.

Zakaj ne takoj samo nov postopek? Ker so postkvantni postopki mladi. Njihova matematika je dobro raziskana, njihove izvedbe v izdelkih pa še niso prestale toliko let uporabe kot klasične. Hibrid varuje pred obema tveganjema: pred prihodnjim kvantnim računalnikom in pred danes neodkrito slabostjo novega postopka ali njegove izvedbe. Evropski načrt za prehod iz junija 2025 zato priporoča standardizirane in preizkušene hibridne rešitve, kjer je to izvedljivo.

Postopek na papirju in postopek v vaši aplikaciji nista isto:

• Kyber ni ML-KEM. Zgodnje izvedbe so uporabljale predhodne različice postopka (Kyber), ki niso združljive s končnim standardom ML-KEM. Dva sistema, ki imata oba v opisu »Kyber« ali »hibridno«, se morda ne razumeta.
• Lastne izvedbe so tvegane. Postkvantni postopki so občutljivi na napade prek stranskih kanalov, na primer na merjenje časa. Uporabljajte preverjene knjižnice v aktualnih različicah, ne kode s spleta.
• Velikost šteje. Prvo sporočilo TLS s ključem ML-KEM je za približno kilobajt daljše. Ob uvedbi v brskalnikih leta 2024 se je pokazalo, da nekateri strežniki in omrežne naprave tega niso prenesli, kadar prvo sporočilo ni več šlo v en paket. Posledica so prekinjene povezave brez razumljivega sporočila.

Mislimo si podjetje za inženirske storitve v Novem mestu, ki nemškemu naročniku pošilja tehnične risbe. Zaradi zaupnosti jih aplikacija pred pošiljanjem šifrira: ustvari ključ AES, z njim zašifrira datoteko in ključ AES zašifrira z naročnikovim javnim ključem RSA. Poleg tega datoteko podpiše s svojim ključem RSA.

Ko vodja razvoja prebere, da »RSA zamenja ML-KEM«, naroči zamenjavo. Naročilo ima dve besedi, odgovor nanj precej več. Razvijalec ugotovi:

• Šifriranje ključa AES z RSA je prenos ključa. Tu ML-KEM ustreza, a potrebuje naročnikov javni ključ ML-KEM, ki ga naročnik še nima.
• Podpis z RSA je podpis. Tu ML-KEM ne ustreza; potreben je ML-DSA, ki ga mora naročnikova stran znati preveriti.
• Šifriranje z AES-256 ostane.

Iz enega naročila »zamenjajte RSA« nastaneta dve različni spremembi z dvema različnima odvisnostma od naročnika.

Dogovor o ključu je dogovor: odjemalec ponudi, kar zna, strežnik izbere, kar znata oba. Če vaš sistem zna hibridni postopek, naročnikov pa ne, se povezava vzpostavi klasično, brez napake in brez opozorila.

Zato so v prehodnem obdobju pomembne tri navade:

• Ponujajte hibridno, ne zahtevajte ga. Zahtevanje brez preverjene pripravljenosti druge strani povzroči izpade.
• Beležite dogovorjeni postopek pri vsaki povezavi in ga redno preglejte.
• Preizkusite pred spremembo. Z naročnikom se dogovorite za skupni preizkus, preden vklopite novo nastavitev v produkciji.

Za vsako povezavo do naročnika zapišite, kaj vaš sistem ponudi, kaj ponudi naročnik in kaj se dejansko dogovori. Orodja so znana: openssl s_client od različice 3.5 izpiše dogovorjeno skupino, ssh -v dogovorjeno izmenjavo ključev, dnevnik naprave VPN dogovorjene skupine. Rezultat vpišite v matriko v prilogi.

Pri podpisih preverite, ali naročnikova stran zna preveriti ML-DSA. To je vprašanje njegove programske opreme, ne vaše.

Meritev ponovite po vsaki posodobitvi knjižnice, strežnika ali naprave na eni ali drugi strani. Dogovorjeni postopek se lahko spremeni, ne da bi kdo karkoli nastavil, samo zato, ker je nova različica prinesla drugačne privzete vrednosti. Matrika, ki je bila pravilna spomladi, jeseni morda ni več.

„Für unsere Verbindungen unterscheiden wir Schlüsselaustausch und Signaturen. Für den Schlüsselaustausch bieten wir hybride Verfahren an. Für Signaturen: Ab wann können Ihre Systeme ML-DSA prüfen, und benötigen Sie von uns einen öffentlichen Schlüssel für ML-KEM, um Dateien für uns zu verschlüsseln?“

Prevod: Pri naših povezavah ločujemo dogovor o ključu in podpise. Za dogovor o ključu ponujamo hibridne postopke. Za podpise: od kdaj vaši sistemi lahko preverjajo ML-DSA in ali za šifriranje datotek za nas potrebujete naš javni ključ ML-KEM?

Zakaj tako? Ker pokaže, da razumete razliko med nalogami, in ker obe odvisnosti, ki ju ne morete rešiti sami, postavi na mizo naenkrat.

Nemška izdaja te teme se obrača na arhitekte povezav med podjetji pri naročnikih: „Hybride Kryptografie: Was passiert, wenn Ihr Lieferant den neuen Standard noch nicht unterstützt?“ (v nemščini). Prejšnja izdaja: Če je vaš kriptografski algoritem del poslovne logike, imate problem.

Po izidu te izdaje je hibridna izmenjava ključev za TLS 1.3 izšla kot RFC 10024 (avgust 2026). Sprotno posodobljeno stanje rokov in standardov je na strani BSI TR-02102 in postkvantni roki.

Matrika interoperabilnosti (ena vrstica za vsako povezavo in smer). V nemški izdaji je vsebinsko enaka.

Preverjanje profilov: kaj preveriti pri katerem protokolu? Stanje avgust 2026; oznake se lahko s standardizacijo spremenijo.

Vse objavljene izdaje serije: pregled »Postkvantna varnost v dobavni verigi«

Naslednja izdaja (7. 9. 2026): »Deset let stara aplikacija in postkvantna prihodnost: kaj sploh lahko spremenimo?«

Viri (stanje 3. 8. 2026): NIST FIPS 203, 204 in 205 (avgust 2024); osnutek IETF draft-ietf-tls-ecdhe-mlkem; RFC 9370 (maj 2023); RFC 9881 (oktober 2025); OpenSSH 10.0 Release Notes (april 2025); NIS Cooperation Group, »A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography«, različica 1.1 (junij 2025).

Če ne veste, katero nalogo opravlja RSA v vaših sistemih, nam pišite.