Genereer RSA-sleutelparen in de browser, codeer en decodeer met RSA-OAEP, onderteken met RSA-PSS of PKCS#1 v1.5, en converteer sleutels tussen SPKI-, PKCS#8- en PKCS#1-PEM-formaten. Alles draait lokaal met de WebCrypto-engine — geen enkele sleutel of bericht verlaat deze pagina.
Waarvoor RSA dient: kleine berichten en handtekeningen, niet voor grote hoeveelheden gegevens. RSA codeert hooguit k−2·hashLen−2 bytes per aanroep (190 bytes voor een 2048-bits sleutel met SHA-256) en is ~1000× trager dan AES. Echte systemen gebruiken hybride codering: RSA verpakt een willekeurige AES-sleutel, AES codeert de gegevens (zie de AES-tool). Deze pagina bestaat voor leren, testen en interoperabiliteitscontroles.
1. Een sleutelpaar genereren(WebCrypto, lokaal; de vier PEM-formaten worden samen gemaakt)
Modulusgrootte:
Publieke sleutel — SPKI(-----BEGIN PUBLIC KEY-----, het gebruikelijke formaat voor "RSA-publieke sleutel")
Publieke sleutel — PKCS#1(-----BEGIN RSA PUBLIC KEY-----, kale modulus + exponent)
Privésleutel — PKCS#8(-----BEGIN PRIVATE KEY-----, niet versleuteld; behandel hem als een wachtwoord)
Privésleutel — PKCS#1(-----BEGIN RSA PRIVATE KEY-----, het klassieke OpenSSL-formaat)
Een sleutel genereren in de browser versleutelt hem niet. Verplaats hem voor opslag naar een echte sleutelkluis of versleutel hem offline.
2. Of een bestaande sleutel importeren(plak een van de vier PEM-formaten)
3. Coderen / decoderen (RSA-OAEP)- de richting volgt de huidige sleutel: publiek = coderen, privé = decoderen
Hash:Label:
PKCS#1 v1.5-codering is bewust niet geïmplementeerd: het heeft geen integriteit van de cijfertekst en valt aan via padding-oracle-aanvallen (Bleichenbacher). OAEP is de enige coderingsmodus die een nieuw ontwerp zou moeten gebruiken.
4. Ondertekenen (vereist de privésleutel)- PSS (gerandomiseerd, modern) of PKCS#1 v1.5 (deterministisch, compatibel met oud)
Schema:Hash:
5. Verifiëren (vereist de publieke sleutel)- plak het bericht en de handtekening
Schema:Hash:
Hoeveel kan één RSA-aanroep dragen?OAEP-berichtlimiet = sleutelbytes − 2×hashbytes − 2:
Modulus
SHA-256
SHA-384
SHA-512
1024-bits
62 bytes
30 bytes
0 bytes
2048-bits
190 bytes
126 bytes
62 bytes
3072-bits
318 bytes
254 bytes
190 bytes
4096-bits
446 bytes
382 bytes
318 bytes
Handtekeningen hebben geen berichtlimiet — het bericht wordt eerst gehasht; de handtekening zelf is altijd precies de sleutelgrootte (256 bytes voor 2048 bits).
Sterkte en levensduur van de sleutel(NIST SP 800-57 deel 1 rev. 5): 1024-bits is sinds 2013 niet meer toegestaan voor nieuw gebruik; 2048-bits is vandaag het minimum en blijft aanvaardbaar tot 2030; 3072-bits en hoger is de comfortabele keuze voor 2031 en later. 8192-bits werkt hier, maar het genereren kan in de browser een minuut of langer duren en levert beveiliging op die niemand nu nodig heeft — geef de voorkeur aan 3072/4096.
OpenSSL-interoperabiliteit — de PEM's die deze pagina maakt, werken rond op de opdrachtregel: openssl pkeyutl -encrypt -pubin -inkey pub.pem -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256 -pkeyopt rsa_mgf1_md:sha256 openssl pkeyutl -decrypt -inkey priv.pem -pkeyopt rsa_padding_mode:oaep ... openssl dgst -sha256 -sign priv.pem -out msg.sig msg.txt (PKCS#1 v1.5) / openssl dgst -sha256 -verify pub.pem -signature msg.sig msg.txt PSS: voeg -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:32 toe aan beide dgst-aanroepen. Sleutelformaatconversie: openssl rsa -in key.pem -RSAPublicKey -out pubkey.pem doet SPKI ↔ PKCS#1 op schijf; deze pagina doet het in de browser.
Zelftest Draait de pagina-engine tegen onafhankelijke ankerpunten: sleutelgeneratie bij drie modulusgroottes, OAEP-codeer-/decodeerrondes, PSS- en PKCS#1 v1.5-ondertekening/verificatie over hashes, een deterministische v1.5-handtekeningvector byte voor byte (gegenereerd door een onafhankelijke native implementatie), een vaste OAEP-cijfertekst en PSS-handtekening geproduceerd door OpenSSL die deze pagina moet decoderen/verifiëren (interoperabiliteit tussen implementaties), PEM-formaatconversierondes, en negatieve tests (gemanipuleerde handtekening, verkeerde sleutel moet falen). Niets wordt ergens naartoe gestuurd.
RSA-codering en handtekeningen van nul uitgelegd
In één zin: RSA is publieke-sleutelcryptografie — iedereen kan naar u coderen met de publieke sleutel of uw handtekeningen verifiëren, maar alleen de private sleutel kan decoderen of ondertekenen — en de veiligheid berust op het feit dat het ontbinden van een getal van 2048 bits in twee priemgetallen buiten het bereik van elke bestaande computer valt.
Wat RSA eigenlijk berekent
Twee priemgetallen en een achterdeurtje. Een RSA-sleutel begint met twee grote willekeurige priemgetallen p en q; hun product n (de modulus, vandaar "2048-bits sleutel") wordt in de publieke sleutel gepubliceerd, samen met een exponent e (bijna altijd 65537). De private sleutel is het paar d, de modulaire inverse van e −, berekend uit p en q — plus snelkoppelingen die uit de priemgetallen zijn afgeleid en private-sleutelbewerkingen 4× versnellen.
Coderen en ondertekenen zijn dezelfde exponentiatie. Een berichtblok m coderen betekent me mod n berekenen; decoderen is cd mod n. Een vooraf geformatteerd blok ondertekenen met de private exponent en verifiëren met de publieke is dezelfde bewerking in de andere richting. Al het overige op deze pagina — OAEP, PSS, PKCS#1 — gaat over het veilig formatteren van dat blok, zodat ruwe exponentiatie nooit bloot komt te liggen.
Waarom het traag is. Eén RSA-bewerking op een 2048-bits sleutel kost ongeveer een miljoen keer zoveel rekenkracht als het coderen van één blok met AES. Daarom gebruikt TLS RSA (of ECC) alleen om een willekeurige AES-sleutel af te spreken, en schakelt daarna over. Dezelfde regel geldt voor alles wat u bouwt: RSA voor de sleutel, AES voor de gegevens.
Sleutelgrootte. De lengte van de modulus is de veiligheidsknop: 1024-bits is volgens beleid gebroken (factorisatie valt binnen het bereik van staten), 2048-bits ≈ 112-bits symmetrische sterkte, 3072-bits ≈ 128-bits, 15360-bits zou overeenkomen met een symmetrische sleutel van 256 bits. Post-kwantumopmerking: het algoritme van Shor breekt RSA volledig op een grote kwantumcomputer — nog een reden om sleutels een eindige levensduur te geven.
OAEP: de enige coderingsopvulling die u zou moeten gebruiken
Het probleem met ruwe RSA. Leerboek-RSA (me mod n op het ruwe bericht) is deterministisch en vervormbaar: identieke berichten worden identiek gecodeerd, een aanvaller kan een cijfertekst vermenigvuldigen met de codering van 2 om de klaartekst te verdubbelen, en korte berichten vallen aan door meet-in-the-middle. Het mag nooit direct worden gebruikt.
Wat OAEP doet. OAEP (PKCS#1 v2, RFC 8017) mengt het bericht met een willekeurig zaad via een op hash gebaseerd Feistel-netwerk vóór de exponentiatie. Het resultaat: codering is gerandomiseerd (dezelfde klaartekst geeft elke keer een andere cijfertekst — voer het OAEP-voorbeeld twee keer uit en vergelijk), manipulatie wordt bij decodering gedetecteerd, en het bericht moet in de modulus passen met ruimte voor de hash — de limiet k−2·hashLen−2 uit de tabel hierboven.
Het label. Een optionele publieke tekenreeks die in de opvulling wordt opgenomen. Beide kanten moeten exact hetzelfde label opgeven, anders mislukt de decodering — net als de AAD bij AES-GCM laat het u de cijfertekst aan een context binden (een bestandsnaam, een algoritme-id). Leeg is normaal.
PKCS#1 v1.5-codering is bewust afwezig. De opvulling uit 1993 heeft geen integriteit en lekt informatie via het gedrag bij decoderingsfouten (de aanval van Bleichenbacher uit 1998 maakt van een padding-oracle volledige decodering met enkele miljoenen gemaakte cijferteksten; hij breekt nog steeds echte systemen als ROBOT, 2017). WebCrypto weigert het te implementeren; deze pagina ook.
PSS- versus PKCS#1 v1.5-handtekeningen
Ondertekenen = hashen, dan opvullen, dan exponentiëren. Beide schema's hashen het bericht (hier SHA-256/384/512), formatteren de digest tot een blok en passen de private exponent toe. Verifiëren formatteert het blok opnieuw met de publieke sleutel en vergelijkt. Het verschil zit in de formattering:
Schema
Blokinhoud
Eigenschappen
RSASSA-PKCS1-v1_5
digest + digest-info-header, deterministisch
Elke handtekening van hetzelfde bericht is byte-voor-byte identiek (controleer de zelftest: de v1.5-vector is vast). Brede ondersteuning voor oudere systemen: X.509-certificaten, JWT RS*, TLS vóór 1.3. Er is geen bekende vervalsing wanneer de verificatie correct is geïmplementeerd.
RSA-PSS
digest + willekeurig zout van hashlengte, MGF1-maskering
Gerandomiseerd — elke handtekening verschilt. Bewezen veilig in het random-oracle-model; vereist in TLS 1.3-certificaten van de toekomst en nieuwere protocollen. De verifier moet de zoutlengte kennen (deze pagina gebruikt de hashlengte, de gebruikelijke standaard).
Welke kiezen. Nieuwe ontwerpen: PSS. Interoperabiliteit met bestaande certificaten, JWT's (RS256) of oude partners: v1.5. Beide zijn veilig als handtekeningschema's — het v1.5-drama gaat over *codering*-opvulling, een andere constructie ondanks de vergelijkbare naam.
PKCS#1 vs PKCS#8 vs SPKI: waarom dezelfde sleutel vier PEM's heeft
PEM is gewoon base64-verpakte DER. Een PEM-bestand is een label plus base64 van een DER-structuur (binaire ASN.1). Het label vertelt welke structuur het is — en dat is het hele verschil tussen de vier formaten die deze pagina genereert:
Kaal (n, e). Oud OpenSSL en sommige embedded stacks.
-----BEGIN PRIVATE KEY-----
PKCS#8 PrivateKeyInfo
Algoritme-OID + privésleutel. Algoritmeonafhankelijke container, de moderne standaard.
-----BEGIN RSA PRIVATE KEY-----
PKCS#1 RSAPrivateKey
n, e, d, p, q, …. De klassieke OpenSSL-uitvoer van genrsa.
Dezelfde sleutel, andere verpakkingen. Alle vier de vakken hierboven na Genereren bevatten hetzelfde sleutelpaar — SPKI en de publieke PKCS#1 bevatten identieke n, e; PKCS#8 en de private PKCS#1 bevatten identieke private waarden. Deze pagina converteert er verliesvrij tussen in de browser (de zelftest rondt de conversies af). Het verwarren van formaten is de meest voorkomende oorzaak van "ongeldige sleutel"-fouten bij het plakken van sleutels tussen tools.
Versleutelde PEM's (-----BEGIN ENCRYPTED PRIVATE KEY-----) zijn PKCS#8 met een op wachtwoord gebaseerde versleutelingslaag. Deze pagina accepteert ze niet — ontsleutel ze eerst offline (openssl pkcs8 -in enc.pem -out plain.pem).
Veelgemaakte fouten
Grote hoeveelheden gegevens met RSA coderen. Voorbij de harde OAEP-groottelimiet is het absurd traag. Het patroon is: genereer een willekeurige AES-sleutel, codeer de AES-sleutel met RSA-OAEP, codeer de gegevens met AES-GCM en verstuur beide delen.
De private sleutel verzenden omdat "het een test is". De voorbeeldsleutels die in de vectoren van deze pagina zijn ingebed, zijn bewust gepubliceerd — ze kunnen alleen testgegevens ondertekenen. Uw sleutels zijn niet zo.
Verifiëren met de private sleutel. Het "werkt" wiskundig meestal en sommige tools staan het toe, maar het verspreiden van een private sleutel naar verifiers ondermijnt het hele model. Verifieer met de publieke sleutel (deze pagina dwingt dat af).
Handtekeningen byte voor byte vergelijken om code te controleren. PSS (en OAEP) zijn gerandomiseerd: twee correcte uitvoeringen geven verschillende uitvoer. Vergelijk door te verifiëren, niet door gelijkheid — alleen v1.5-handtekeningen zijn deterministisch.
1024-bits sleutels "omdat ze sneller zijn". Ze liggen ook binnen bereik van goed gefinancierde factorisatie. Het snelheidsargument verdween met hybride codering: RSA draait één keer per sessie, niet per byte.
Een andere saltlengte dan de hashlengte vastleggen voor PSS. De verifier moet het ermee eens zijn; de hashlengte (de keuze van deze pagina en van OpenSSL's -sigopt rsa_pss_saltlen:32) is de interoperabele standaard.
Veelgestelde vragen
Waarom mislukte mijn decodering met "verkeerde sleutel, verkeerde hash of beschadigde cijfertekst"? OAEP-decodering mislukt wanneer een van de volgende dingen geldt: het is niet de bijpassende private sleutel, de hash verschilt van de coderingskant, het label verschilt, of een cijfertekstbyte is gewijzigd. De foutmelding is bewust gelijk voor alle gevallen — laten zien welke controle is mislukt, is zelf een padding-oracle-lek.
Kan ik de publieke sleutel uit de private sleutel halen? Ja — de private formaten bevatten ook n en e. Deze pagina toont beide na Genereren; OpenSSL doet dat met openssl pkey -in priv.pem -pubout.
Waarom 65537 als exponent? Het is priem, heeft slechts twee 1-bits (snelle exponentiatie), en is groot genoeg om de exponentaanvallen met lage exponent te vermijden die e=3 treffen. Het is sinds de jaren negentig de standaardkeuze; een "vreemde" exponent betekent meestal een zwakke of niet-standaard sleutel.
Is RSA dood door kwantumcomputers? Nog niet — er bestaat geen machine die het algoritme van Shor op een modulus van 2048 bits kan uitvoeren. Maar gegevens die tot in de jaren 2030 geheim moeten blijven, worden al gemigreerd; PQC-hybride schema's zijn het technische antwoord.
En openssl rsautl? Het is de verouderde voorloper van pkeyutl. Het gebruikt standaard v1.5-coderingsopvulling — nog een reden waarom het is uitgefaseerd.
