RSA-kryptering / -dekryptering

Två primtal och en fälla. En RSA-nyckel börjar med två stora slumpmässiga primtal p och q; deras produkt n (modulen, därav "2048-bitars nyckel") publiceras i den publika nyckeln tillsammans med exponenten e (nästan alltid 65537). Den privata nyckeln är paret d, den modulära inversen av e − beräknad från p och q — plus genvägar härledda från primtalen som snabbar upp operationer med den privata nyckeln 4×.

Kryptering och signering är samma exponentiering. Att kryptera ett meddelandeblock m innebär att beräkna m^e mod n; dekryptering är c^d mod n. Att signera ett förformaterat block med den privata exponenten och verifiera med den publika är samma operation i andra riktningen. Allt annat på denna sida — OAEP, PSS, PKCS#1 — handlar om att formatera blocket säkert så att rå exponentiering aldrig exponeras.

Varför det är långsamt. En RSA-operation med en 2048-bitars nyckel kostar i storleksordningen en miljon gånger mer processorkraft än att kryptera ett block med AES. Det är därför TLS använder RSA (eller ECC) endast för att komma överens om en slumpmässig AES-nyckel, och sedan byter. Samma regel gäller för allt som byggs: RSA för nyckeln, AES för datan.

Nyckelstorlek. Modullängden är säkerhetsreglaget: 1024-bitars är knäckt enligt policy (faktorisering ligger nära det som statliga aktörer kan), 2048-bitars ≈ 112-bitars symmetrisk styrka, 3072-bitars ≈ 128-bitars, 15360-bitars skulle motsvara en 256-bitars symmetrisk nyckel. Post-kvantnotering: Shors algoritm bryter RSA helt på en stor kvantdator — ännu ett skäl att hålla nyckellivslängder ändliga.

Problemet med rå RSA. Lärobokens RSA (m^e mod n på det råa meddelandet) är deterministisk och formbar: identiska meddelanden krypteras identiskt, en angripare kan multiplicera en chiffertext med krypteringen av 2 för att fördubbla klartexten, och korta meddelanden faller för mötet-i-mitten. Den får aldrig användas direkt.

Vad OAEP gör. OAEP (PKCS#1 v2, RFC 8017) blandar meddelandet med ett slumpmässigt frö genom ett hash-baserat Feistel-nätverk före exponentieringen. Resultatet: kryptering är randomiserad (samma klartext ger en annan chiffertext varje gång — kör OAEP-exemplet två gånger och jämför), manipulation upptäcks vid dekryptering, och meddelandet måste få plats inom modulen med utrymme för hashen — gränsen k−2·hashLen−2 som tabellerats ovan.

Etiketten. En valfri publik sträng bunden till paddingen. Båda sidor måste ange identisk etikett eller dekryptering misslyckas — likt AAD i AES-GCM låter den binda chiffertexten till ett sammanhang (ett filnamn, ett algoritm-id). Tom är normalt.

PKCS#1 v1.5-kryptering är avsiktligt utelämnad. Paddingen från 1993 har ingen integritet och läcker information genom beteendet vid dekrypteringsfel (Bleichenbachers attack från 1998 förvandlar ett padding-orakel till fullständig dekryptering med några miljoner konstruerade chiffertexter; den bryter fortfarande verkliga system som ROBOT, 2017). WebCrypto vägrar implementera den; det gör inte heller denna sida.

Signera = hasha, sedan padda, sedan exponentiera. Båda schemana hashar meddelandet (SHA-256/384/512 här), formaterar sammandraget till ett block och tillämpar den privata exponenten. Verifiering formaterar om blocket med den publika nyckeln och jämför. Skillnaden ligger i formateringen:

Vilket att välja. Nya konstruktioner: PSS. Interoperabilitet med befintliga certifikat, JWT (RS256) eller gamla motparter: v1.5. Båda är säkra som signaturscheman — katastrofhistorien om v1.5 handlar om *kryptering*-padding, en annan konstruktion trots det liknande namnet.

PEM är bara base64-inslagen DER. En PEM-fil är en etikett plus base64 av en DER-struktur (binär ASN.1). Etiketten talar om vilken struktur det är — och det är hela skillnaden mellan de fyra format som denna sida genererar:

Samma nyckel, olika omslag. Alla fyra rutorna ovan efter Generera innehåller samma nyckelpar — SPKI och PKCS#1 publik innehåller identiska n, e; PKCS#8 och PKCS#1 privat innehåller identiska privata värden. Sidan konverterar mellan dem förlustfritt i webbläsaren (dess självtest gör rundresor genom konverteringarna). Att blanda ihop formaten är den vanligaste orsaken till felet "ogiltig nyckel" när nycklar klistras in mellan verktyg.

Krypterade PEM-filer (-----BEGIN ENCRYPTED PRIVATE KEY-----) är PKCS#8 med ett lösenordsbaserat krypteringslager. Den här sidan accepterar dem inte — dekryptera dem offline först (openssl pkcs8 -in enc.pem -out plain.pem).

• Att kryptera massdata med RSA. Bortom den hårda OAEP-storleksgränsen är det absurt långsamt. Mönstret är: generera en slumpmässig AES-nyckel, RSA-OAEP-kryptera AES-nyckeln, AES-GCM-kryptera datan och skicka båda delarna.
• Att skicka ut den privata nyckeln för att "det är ett test". Exempelnycklarna inbäddade i denna sidas vektorer är publicerade med avsikt — de kan bara någonsin signera testdata. Egna nycklar är inte sådana.
• Att verifiera med den privata nyckeln. Det "fungerar" oftast matematiskt och vissa verktyg tillåter det, men att distribuera en privat nyckel till verifierare undergräver hela modellen. Verifiera med den publika nyckeln (den här sidan tvingar fram det).
• Att jämföra signaturer byte för byte för att kontrollera kod. PSS (och OAEP) är randomiserade: två korrekta körningar ger olika utdata. Jämför genom att verifiera, inte genom likhet — endast v1.5-signaturer är deterministiska.
• 1024-bitars nycklar "för att de är snabbare". De ligger också inom räckhåll för välfinansierad faktorisering. Hastighetsargumentet dog med hybridkryptering: RSA körs en gång per session, inte per byte.
• Att hårdkoda en saltlängd som inte är hashlängden för PSS. Verifieraren måste vara överens; hashlängd (denna sidas val och OpenSSL:s -sigopt rsa_pss_saltlen:32) är den interoperabla standarden.

Varför misslyckades dekrypteringen med "fel nyckel, fel hash eller skadad chiffertext"? OAEP-dekryptering misslyckas när något av följande gäller: det inte är matchande privat nyckel, hashen skiljer sig från krypteringssidan, etiketten skiljer sig, eller en byte i chiffertexten har ändrats. Felmeddelandet är avsiktligt identiskt för alla fall — att avslöja vilken kontroll som misslyckades är i sig ett padding-orakelläckage.

Kan man få den publika nyckeln från den privata? Ja — de privata formaten innehåller även n och e. Sidan visar båda efter Generera; OpenSSL gör det med openssl pkey -in priv.pem -pubout.

Varför 65537 som exponent? Det är ett primtal, har bara två 1-bitar (snabb exponentiering), och är tillräckligt stort för att undvika de lågexponentattacker som drabbar e=3. Det har varit standardvalet sedan 1990-talet; en "udda" exponent betyder oftast en svag eller icke-standard nyckel.

Är RSA dött på grund av kvantdatorer? Inte ännu — det finns ingen maskin som kan köra Shors algoritm på en 2048-bitars modul. Men data som måste förbli hemlig in på 2030-talet migreras redan; PQC-hybridscheman är det tekniska svaret.

Vad med openssl rsautl? Det är den föråldrade föregångaren till pkeyutl. Den använder som standard v1.5-krypteringspadding — ännu ett skäl till att den avvecklades.