RSA titkosítás / visszafejtés

Két prím és egy csapóajtó. Egy RSA-kulcs két nagy véletlen prímmel p-vel és q-val indul; szorzatuk n (a modulus, innen a „2048 bites kulcs”) a nyilvános kulccsal együtt, egy e kitevővel közzétéve (szinte mindig 65537). A privát kulcs a d pár, e moduláris inverze − a p-ből és q-ból számítva —, plusz a prímekből származtatott gyorsítások, amelyek a privát kulcsú műveleteket 4×-es gyorsítják.

A titkosítás és az aláírás ugyanaz a hatványozás. Egy üzenetblokk m titkosítása a m^e mod n kiszámítását jelenti; visszafejtés a c^d mod n. Előre formázott blokk aláírása a privát kitevővel, és ellenőrzése a nyilvánossal ugyanaz a művelet az ellenkező irányban. Minden más ezen az oldalon — OAEP, PSS, PKCS#1 — arról szól, hogy ezt a blokkot biztonságosan formázzák, hogy a nyers hatványozás soha ne legyen kitéve.

Miért lassú. Egy RSA-művelet 2048 bites kulccsal nagyságrendileg egymillió-szer több processzoridőt igényel, mint egy blokk AES-sel történő titkosítása. Ezért használ a TLS RSA-t (vagy ECC-t) csak egy véletlen AES-kulcs egyeztetésére, és utána vált. Ugyanez a szabály vonatkozik mindenre, amit készítenek: RSA a kulcsra, AES az adatra.

Kulcsméret. A modulus hossza a biztonsági tárcsa: az 1024 bit irányelvileg feltörtnek számít (a faktorizáció államok elérhetőségén belül van), a 2048 bit ≈ 112 bites szimmetrikus erősség, a 3072 bit ≈ 128 bit, a 15360 bit pedig egy 256 bites szimmetrikus kulcsnak felelne meg. Kvantumos megjegyzés: a Shor-algoritmus nagy kvantumszámítógépen egyszerűen feltöri az RSA-t — még egy ok a kulcsok élettartamának korlátozására.

A nyers RSA problémája. A tankönyvi RSA (m^e mod n a nyers üzeneten) determinisztikus és módosítható: az azonos üzenetek azonosan titkosítódnak, egy támadó a titkosszöveget a 2 titkosításával megszorozhatja, hogy a nyílt szöveg megduplázódjon, a rövid üzenetek pedig a közbülső találkozás támadásával megtörnek. Soha nem szabad közvetlenül használni.

Mit csinál az OAEP. Az OAEP (PKCS#1 v2, RFC 8017) az üzenetet egy véletlen maggal keveri egy hash-alapú Feistel-hálózaton keresztül a hatványozás előtt. Az eredmény: a titkosítás randomizált (ugyanaz a nyílt szöveg minden alkalommal más titkosszöveget ad — az OAEP-minta kétszeri futtatása és összehasonlítása ezt megmutatja), a visszafejtéskor a manipuláció észlelhető, és az üzenetnek a modulus belsejébe kell férnie a hash számára fenntartott hellyel — a fent táblázatba foglalt k−2·hashLen−2 korláttal.

A címke. Egy opcionális nyilvános sztring, amely a kitöltésbe kötődik. Mindkét félnek azonos címkét kell megadnia, különben a visszafejtés meghiúsul — mint az AES-GCM AAD-ja, lehetővé teszi, hogy a titkosszöveget kontextushoz kössük (fájlnév, algoritmusazonosító). Az üres érték a szokásos.

A PKCS#1 v1.5 titkosítás szándékosan hiányzik. Az 1993-as korszak kitöltésének nincs integritása, és a visszafejtési hibaviselkedésen át információt szivárogtat (a Bleichenbacher-féle 1998-as támadás kitöltési orákulumot néhány millió szerkesztett titkosszöveggel teljes visszafejtéssé alakít; még 2017-ben is törte valós rendszereket ROBOT néven). A WebCrypto nem valósítja meg; ez az oldal sem.

Aláírás = hash, majd kitöltés, majd hatványozás. Mindkét séma hasheli az üzenetet (itt SHA-256/384/512), a digestet blokkba formázza, és alkalmazza a privát kitevőt. Az ellenőrzés a nyilvános kulccsal újraformázza a blokkot, és összehasonlítja. A különbség a formázásban van:

Melyik választandó. Új tervezéseknél: PSS. A meglévő tanúsítványokkal, JWT-kkel (RS256) vagy régi partnerekkel való együttműködéshez: v1.5. Mindkettő biztonságos aláírási sémaként — a v1.5-katasztrófa-történet a *titkosítási* kitöltésről szól, ami a hasonló név ellenére más konstrukció.

A PEM csak base64-gel becsomagolt DER. Egy PEM-fájl címkéből és egy DER (bináris ASN.1) struktúra base64-jéből áll. A címke megmondja, melyik struktúra — és ez az egész különbség az oldal által generált négy formátum között:

Ugyanaz a kulcs, más csomagolás. A fenti négy doboz a generálás után ugyanazt a kulcspárt tartalmazza — az SPKI és a PKCS#1 nyilvános kulcs azonos n-t és e-t, a PKCS#8 és PKCS#1 privát kulcs azonos privát értékeket. Az oldal veszteségmentesen konvertál közöttük a böngészőben (önellenőrzése oda-vissza futtatja az átalakításokat). A formátumok összekeverése a legelterjedtebb oka az „érvénytelen kulcs” hibának, amikor kulcsok illesztődnek be eszközök között.

Titkosított PEM-ek (-----BEGIN ENCRYPTED PRIVATE KEY-----) jelszó-alapú titkosító rétegű PKCS#8-ak. Az oldal ezeket nem fogadja el — előbb offline kell visszafejteni (openssl pkcs8 -in enc.pem -out plain.pem).

• Nagy adatmennyiség titkosítása RSA-val. Az OAEP szigorú méretkorlátján túl abszurdan lassú. A minta: generálni egy véletlen AES-kulcsot, az AES-kulcsot RSA-OAEP-pal titkosítani, az adatot AES-GCM-mel titkosítani, és mindkét részt elküldeni.
• A privát kulcs közzététele, mert „ez csak teszt”. Az oldal vektoraiba ágyazott mintakulcsok szándékosan vannak közzétéve — csak tesztadatokat írhatnak alá. A valódi kulcsok nem ilyenek.
• Ellenőrzés a privát kulccsal. Matematikailag általában „működik”, és egyes eszközök engedik, de a privát kulcs ellenőrzőknek való terjesztése megtöri az egész modellt. Az ellenőrzés a nyilvános kulccsal történjen (ezt az oldal kikényszeríti).
• Aláírások bájtról bájtra való összehasonlítása kód ellenőrzésére. A PSS (és az OAEP) randomizált: két helyes futás különböző kimenetet ad. Összehasonlítás ellenőrzéssel történjen, ne egyenlőséggel — csak a v1.5 aláírások determinisztikusak.
• 1024 bites kulcsok, „mert gyorsabbak”. Jól finanszírozott faktorizálás hatókörébe esnek. A sebesség érve a hibrid titkosítással megszűnt: az RSA munkamenetenként fut egyszer, nem bájtonként.
• A PSS-hez a hash-hossztól eltérő sóhossz beégetése. Az ellenőrzőnek egyeznie kell; a hash-hossz (az oldal választása és az OpenSSL -sigopt rsa_pss_saltlen:32) az együttműködő alapértelmezett.

Miért hiúsult meg a visszafejtés a „rossz kulcs, rossz hash vagy sérült titkosszöveg” üzenettel? Az OAEP-visszafejtés meghiúsul, ha: nem a megfelelő privát kulcs, a hash eltér a titkosítási oldaltól, a címke eltér, vagy a titkosszöveg egy bájtja megváltozott. A hiba szándékosan azonos minden esetben — annak megmutatása, melyik ellenőrzés hiúsult meg, kitöltési orákulum-szivárgás lenne.

Lehet a nyilvános kulcsot a privátból megkapni? Igen — a privát formátumok is tartalmazzák az n-t és az e-t. Az oldal a generálás után mindkettőt megmutatja; az OpenSSL ezt így végzi: openssl pkey -in priv.pem -pubout.

Miért a 65537 a kitevő? Prím, csak két 1-es bitje van (gyors hatványozás), és elég nagy ahhoz, hogy elkerülje az alacsony kitevős támadásokat, amelyek az e=3-at érintik. Az 1990-es évek óta szabványos választás; egy „furcsa” kitevő általában gyenge vagy nem szabványos kulcsot jelez.

Halott az RSA a kvantumszámítógépek miatt? Még nem — nincs olyan gép, amely a Shor-algoritmust egy 2048 bites modulusra futtatni tudná. De az olyan adatokat, amelyeknek a 2030-as évektől is titokban kell maradniuk, már most migrálják; a PQC-hibrid sémák a mérnöki válasz.

Mi a helyzet az openssl rsautl-lal? Ez a pkeyutl elavult őse. Alapértelmezetten v1.5 titkosítási kitöltést használ — még egy ok, amiért kivonták a forgalomból.