A kvantumszámítógépek még nem mindennaposak, de a titkosított adatokat már ma is le lehet „begyűjteni” későbbi visszafejtésre. Az Amazon most azt mutatja meg, hogyan próbálják ezt a kockázatot úgy kezelni, hogy közben ne fizess túl nagy teljesítményárat.

Mi történt

Az Amazon Science blogposztja szerint a mai biztonságos online kommunikáció gerincét a nyilvános kulcsú kriptográfia adja, főleg az RSA és az elliptikus görbéken alapuló kriptográfia (ECC). Ezek biztonsága azon a feltételezésen nyugszik, hogy bizonyos matematikai feladatok klasszikus számítógépeken „gyakorlatilag megoldhatatlanok”. A cég viszont kiemeli: elég nagy kvantumszámítógépekkel ezek a problémák elvileg kezelhetővé válhatnak, ami hosszú távon alááshatja az RSA/ECC alapú kulcscserét.

A poszt külön hangsúlyozza a „store now, decrypt later” modellt: a támadó ma lehallgat és eltárol titkosított adatokat, majd később – amikor a technológia elég erős – megpróbálja visszafejteni. Emiatt a védekezést nem akkor kell elkezdeni, amikor a kvantumszámítógépek már készen állnak, hanem jóval korábban.

Erre a problémára fókuszál a posztkvantum kriptográfia (PQC): olyan algoritmusok, amelyek klasszikus gépeken futnak, de kvantumos támadóval szemben is ellenállónak tervezik őket. A bejegyzés szerint 2024-ben, egy nyolcéves standardizáció után a NIST kiadta a FIPS-203 szabványt, amely az ML-KEM-et (Module-Lattice-Based Key Encapsulation Mechanism) jelöli ki kulcsmegállapodási (key agreement) célra. Az ML-KEM korábbi neve Kyber volt.

Az Amazon leírása alapján az Automated Reasoning Group, az AWS Cryptography és a nyílt forráskódú közösség együttműködésével egy nyílt forrású, formálisan ellenőrzött és optimalizált ML-KEM implementációt készítettek. A projekt a Linux Foundation Post-Quantum Cryptography Alliance (PQCA) ernyője alatt futó Post-Quantum Cryptography Package (PQCP) kezdeményezéshez kapcsolódik, és a konkrét implementáció neve: mlkem-native.

A posztban az Amazon azt is megfogalmazza, mit tart „jó kriptográfiai mérnöki munkának”: (1) a felhasználói adatok biztonságát, (2) a jó felhasználói élményt – mert a kriptográfia „számítási adó”, amit minimalizálni kell –, és (3) a hosszú távú karbantarthatóságot. A csavar az, hogy ezek gyakran feszültségben vannak: az egyszerű kód általában könnyebben auditálható és karbantartható, de lassabb; a gyors kód viszont gyakran bonyolultabb, nehezebben ellenőrizhető, és könnyebben csúsznak bele hibák.

A megközelítésük kulcsa az „automated reasoning”, azaz automatizált formális módszerek használata. Gondolj rá úgy, mint egy nagyon szigorú, gépi „bizonyításra”: nem csak tesztekkel próbálják elkapni a hibákat, hanem bizonyos tulajdonságokat (például a specifikációnak való megfelelést) matematikai értelemben is igazolni akarnak.

A mlkem-native felépítése moduláris: van egy „frontend”, ami az ML-KEM magas szintű logikáját kezeli, és egy „backend”, ami a teljesítménykritikus részeket adja. Ilyenek például:

A poszt szerint ezekhez több, hardverre optimalizált implementációt is adnak: az alap C kód mellett assembly/intrinsics backendet AArch64, x86_64 és RISC‑V64 architektúrákra. A karbantarthatóságot egy fix frontend–backend interfész segíti: ha valaki új platformra optimalizál, a backend specifikációját kell implementálnia, miközben a frontend változatlan maradhat. A bejegyzés azt is jelzi, hogy ennek a backend specifikációnak a megtervezése nem triviális.

Miért fontos

A „store now, decrypt later” fenyegetés azért különösen kellemetlen, mert nem a jövőben kezdődik: a kockázat már ma keletkezik, amikor hosszú élettartamú, érzékeny adatokat (például üzleti dokumentumokat, egészségügyi adatokat, állami kommunikációt) titkosítva továbbítanak vagy archiválnak. Ha ezeknek az adatoknak évekkel később is titokban kell maradniuk, akkor a kulcscsere kvantumbiztossá tétele előbb-utóbb gyakorlati kérdéssé válik.

A másik lényeg: a kriptográfiában nem elég „jó algoritmust” választani. A megvalósítás legalább ennyire kritikus. Egy gyors, de hibás kód vagy egy nehezen auditálható optimalizáció ugyanúgy kockázat lehet, mint egy elavult algoritmus. Az Amazon narratívája itt arról szól, hogy a formális ellenőrzés és az optimalizált, célhardverre hangolt backendek kombinációja segíthet egyszerre magas biztonsági garanciát és vállalható költséget elérni.

Mire figyelj

  1. Standardok és bevezetés üteme: a NIST FIPS-203 már megjelent, de a valódi átállás jellemzően évekig tart. Érdemes figyelni, mikor és hol jelenik meg az ML‑KEM a mindennapi protokollokban és szolgáltatásokban.
  2. Implementációs minőség: a PQC-nál különösen fontos, hogy a kód ne csak gyors legyen, hanem jól ellenőrizhető is. A „formális verifikáció” ígérete itt nem marketingdísz: azt jelenti, hogy bizonyos hibakategóriák ellen erősebb garanciát próbálnak adni, mint amit teszteléssel reálisan elérsz.
  3. Platformoptimalizáció és karbantarthatóság: az olyan megoldások, amelyek több architektúrát céloznak (x86_64, AArch64, RISC‑V), könnyen fragmentálódhatnak. A fix frontend–backend interfész jó jel, de az igazi kérdés az, mennyire lesz hosszú távon fenntartható a specifikáció és a hozzá tartozó ellenőrzési folyamat.
  4. Memóriabiztonság és C-kód kockázatai: a poszt külön is utal a C nyelv tipikus veszélyeire (például puffer-túlcsordulás). Figyeld, milyen módszerekkel és eszközökkel kezelik ezeket a kockázatokat a nagy teljesítményű, alacsony szintű implementációkban.

A bejegyzés alapján az irány egyértelmű: a PQC nem csak algoritmusválasztás, hanem mérnöki fegyelem kérdése is – és a következő években az fog számítani, ki tudja ezt nagy rendszerekben, költséghatékonyan és ellenőrizhetően megcsinálni.