Skip to main content

RSA Key Generator

Generate RSA key pairs (2048 or 4096 bit) in PEM format using the Web Crypto API.

Geprüft von · Zuletzt geprüft

Ein RSA-Schlüsselpaar im Browser erzeugen

  1. Schlüsselgröße auswählen: 2048 für allgemeine moderne TLS-Zertifikate und JWT-Signierung, 4096 für langlebige Schlüssel oder Compliance-Anforderungen, die den zusätzlichen Sicherheitsspielraum verlangen. 3072 wird in NIST SP 800-57 als Äquivalent der 128-Bit-Sicherheitsstufe angegeben, aber seltener angeboten.
  2. "RSA-Schlüsselpaar generieren" klicken. Der Browser ruft crypto.subtle.generateKey({name: 'RSA-OAEP', modulusLength: 2048, publicExponent: new Uint8Array([1,0,1]), hash: 'SHA-256'}, true, ['encrypt', 'decrypt']) auf. Dabei wird eine probabilistische Primzahlsuche durchgeführt, was bei 2048 Bit 200 ms bis wenige Sekunden und bei 4096 Bit bis zu 30 Sekunden dauert.
  3. Die zwei PEM-Blöcke lesen. Der öffentliche Schlüssel erscheint als -----BEGIN PUBLIC KEY----- (SubjectPublicKeyInfo / SPKI-Format, gemäß RFC 5280); der private Schlüssel erscheint als -----BEGIN PRIVATE KEY----- (PKCS#8-Format, gemäß RFC 5958).
  4. Öffentlichen Schlüssel kopieren in alles, was deine Signaturen verifizieren oder Nachrichten an dich verschlüsseln muss. Er ist sicher zu veröffentlichen; auf GitHub posten, in Zertifikat-Signing-Requests einbetten oder in eine JWT-Verifizierungskonfiguration einfügen.
  5. Privaten Schlüssel sofort in einem Secret-Manager speichern. Jeder mit dem PEM kann an dich gerichtete Nachrichten entschlüsseln oder deine Signaturen fälschen. Nicht per E-Mail senden, nicht in Git eincommiten und nicht in ein Ticket einfügen.

Wie der Browser Primzahlen generiert und den Schlüssel zusammensetzt

RSA-Schlüsselgenerierung wird in RFC 8017 (PKCS#1 v2.2) Abschnitt 3 spezifiziert. Der Browser wählt zwei zufällige Primzahlen p und q von jeweils ungefähr modulusLength / 2 Bits mit crypto.getRandomValues-gesätem Miller-Rabin-Test, berechnet den Modulus n = p * q, den Totient phi(n) = (p-1)(q-1), den öffentlichen Exponenten e = 65537 und den privaten Exponenten d = e^-1 mod phi(n) via erweitertem Euklid. Der private Schlüssel speichert CRT-Parameter dp, dq, qinv für 4-mal schnellere Entschlüsselung. Ausgabe-CryptoKey-Objekte werden via exportKey('spki', publicKey) und exportKey('pkcs8', privateKey) serialisiert, Base64-kodiert und in PEM-Header eingebettet. BoringSSL oder NSS läuft wo möglich in konstanter Zeit, um zeitbasierte Schlüsselwiederherstellung zu verhindern.

Legitime Anwendungsfälle und warum diese Schlüssel generiert werden

  • Beantragung eines TLS-Zertifikats: Schlüsselpaar generieren, CSR (Certificate Signing Request) mit dem öffentlichen Schlüssel erstellen, bei Let's Encrypt oder einer internen CA einreichen, ein signiertes Zertifikat erhalten, das den öffentlichen Schlüssel an die Domain bindet.
  • JWT-Signierung mit RS256: der Aussteller hält den privaten Schlüssel und signiert jedes JWT; der Prüfende hat nur den öffentlichen Schlüssel, sodass ein Server-Einbruch auf der Verifier-Seite keine neuen Tokens prägen kann.
  • PGP/GPG-Schlüsselpaar für verschlüsselte E-Mails und Commit-Signierung. GitHub verifiziert Commits, die mit in das Kontoprofil hochgeladenen Schlüsseln signiert sind.
  • SSH-Host- oder Benutzerauthentifizierung, obwohl Ed25519 hier der moderne Standard ist, da RSA-Schlüssel und Signaturen größer und langsamer sind.
  • Code-Signierung: macOS Developer ID, Microsoft Authenticode und npm-Paket-Provenienz verwenden alle RSA oder ECDSA; 2048-Bit-RSA bleibt akzeptiert.
  • Asymmetrische Envelope-Verschlüsselung zum Senden eines symmetrischen Sitzungsschlüssels an einen Empfänger: einen zufälligen AES-Schlüssel mit dem öffentlichen RSA-Schlüssel des Empfängers verschlüsseln, der ihn mit seinem privaten Schlüssel entschlüsselt, und der Großteil der Nutzlast wird AES-GCM mit dem Sitzungsschlüssel verarbeitet.

Schlüsselgröße, Padding-Modus und Post-Quanten-Bedenken

NIST SP 800-57 Teil 1 Rev 5 bildet RSA-Größen auf symmetrische Äquivalenzgrade ab: 2048 entspricht 112 Bit (akzeptabel bis 2030), 3072 entspricht 128 Bit (empfohlen für Neuimplementierungen), 7680 entspricht 192 Bit, 15360 entspricht 256 Bit. 4096 liegt zwischen 3072 und 7680 bei ungefähr 140 Bit. Die gefährlichste Falle ist das Padding: PKCS#1 v1.5 (noch von älterem TLS und JWT RS256 verwendet) ist angreifbar durch Bleichenbacher-Padding-Oracle-Angriffe, die echte Systeme gebrochen haben (ROBOT 2017 betraf F5, Citrix, Cisco). RSA-OAEP ist das moderne Verschlüsselungs-Padding; RSA-PSS ist das moderne Signatur-Padding. Niemals texbook-RSA ohne Padding verwenden. Die drohende Gefahr ist Shors Algorithmus auf einem Quantencomputer: jeder RSA-Schlüssel würde trivial faktorisierbar. NIST finalisierte Post-Quanten-KEM-Standards 2024 (ML-KEM FIPS 203). Für Langzeit-Schlüssel hybrides RSA+ML-KEM erwägen.

PEM, PKCS#1, PKCS#8, SPKI und OpenSSH

RSA-Schlüssel kommen in verschiedenen Kodierungen, und die falsche Wahl bricht die Interoperabilität. PEM ist die äußere textuelle Hülle: Base64-kodiertes DER-kodiertes ASN.1 zwischen BEGIN/END-Zeilen. Innen ist PKCS#1 (RFC 8017 Anhang A.1) RSA-spezifisch (BEGIN RSA PRIVATE KEY, die alte openssl genrsa-Ausgabe). PKCS#8 (RFC 5958) ist algorithmusagnostisch (BEGIN PRIVATE KEY) - Web Crypto gibt PKCS#8 aus und es ist das moderne bevorzugte Format. Für öffentliche Schlüssel umhüllt SPKI (RFC 5280) jeden öffentlichen Schlüsseltyp mit einem Algorithmus-Bezeichner - Web Crypto exportiert SPKI als BEGIN PUBLIC KEY. OpenSSH verwendet ein eigenes Nicht-PEM-Format (ssh-rsa AAAA...), das anders DER-kodiert ist; mit ssh-keygen -i -f input.pem -m PKCS8 aus PEM PKCS#8 konvertieren. Falsches Format ist von einem defekten Schlüssel nicht zu unterscheiden.

RSA im Jahr 2026 vs. Ed25519 und ECDSA

RSA ist das Arbeitspferd, wird aber verdrängt. Ed25519 (RFC 8032) erzeugt 64-Byte-Signaturen gegenüber RSA-2048s 256 Bytes, signiert in Mikrosekunden und ist der Standard für neue SSH-Schlüssel (ssh-keygen -t ed25519), GitHub-Commit-Signierung und viele TLS-Bibliotheken. ECDSA P-256 (FIPS 186-5) ist der Standard für WebAuthn und die meisten modernen TLS-Zertifikate. RSA gewinnt noch wenn Verschlüsselung benötigt wird (Ed25519 ist nur zum Signieren), Interoperabilität mit Legacy-Systemen erforderlich ist oder FIPS 140-3 Module eingesetzt werden, bei denen Ed25519 erst kürzlich hinzugefügt wurde. Praktische Regel: RSA generieren wenn eine spezifische Anforderung vorliegt, andernfalls elliptische-Kurven-Alternativen verwenden, die schneller und kompakter sind.

Häufig gestellte Fragen

Warum dauert die Generierung von 4096-Bit-Schlüsseln so lange?

RSA-Schlüsselgenerierung ist eine probabilistische Primzahlsuche: Zufallszahlen der erforderlichen Bitlänge auswählen, Miller-Rabin-Primzahltests anwenden, zusammengesetzte Zahlen verwerfen, wiederholen bis zwei geeignete Primzahlen gefunden sind. Die Wahrscheinlichkeit, dass eine zufällige 2048-Bit-Zahl eine Primzahl ist, beträgt nach dem Primzahlsatz ungefähr 1 zu 1400; bei 4096 Bit ist es 1 zu 2800, daher sind doppelt so viele Miller-Rabin-Runden bei individuell langsamerer Ganzzahl-Arithmetik erforderlich. Auf einem modernen Laptop kostet das bei 4096 Bit 10-30 Sekunden gegenüber 200-800 Millisekunden bei 2048 Bit. Der Tab bleibt reaktionsschnell, da crypto.subtle.generateKey asynchron ist und auf einem nativen Krypto-Thread läuft.

Wird der private Schlüssel je an den Server übertragen?

Nein. crypto.subtle.generateKey läuft vollständig im nativen Krypto-Modul des Browsers, und die resultierenden CryptoKey-Objekte werden via crypto.subtle.exportKey im gleichen Thread in PEM exportiert. Kein Fetch- oder XHR-Aufruf berührt das Schlüsselmaterial. DevTools-Netzwerk-Tab öffnen, einen 4096-Bit-Schlüssel generieren und null ausgehende Anfragen mit Schlüsseldaten beobachten. Der einzige Weg, wie der private Schlüssel dein Gerät verlässt, ist wenn du ihn explizit irgendwo einfügst; behandle die Zwischenablage und den Bildschirm als Vertrauensgrenze.

Ist 2048-Bit-RSA im Jahr 2026 noch sicher?

Ja, bis 2030 gemäß NIST SP 800-57 Teil 1 Rev 5, das 2048-Bit-RSA als sicherheitsäquivalent zu 112-Bit-Symmetrie einstuft. Die besten bekannten Angriffe auf Faktorisierung (General Number Field Sieve) haben die 2048-Bit-Schwelle nicht überschritten. Für Schlüssel, die nach 2030 sicher bleiben oder Ernte-jetzt-entschlüssel-später-Bedrohungen durch künftige Quantencomputer standhalten sollen, 3072 Bit oder Hybride mit ML-KEM verwenden. Für kurzlebige Schlüssel (TLS-Zertifikate, die alle 90 Tage per ACME rotieren) ist 2048 Bit mehr als ausreichend.

Warum ist der öffentliche Exponent immer 65537?

Leistung und Kompatibilität. 65537 = 2^16 + 1 hat im Binärformat nur zwei gesetzte Bits, was RSA-Verschlüsselung und Signaturverifizierung schnell macht. Es ist eine Primzahl, was die Berechnung von d vereinfacht. Und es ist seit den späten 1990ern der De-facto-Standard, sodass jede Bibliothek, Smartcard und HSM es korrekt verarbeitet. Kleinere Exponenten wie 3 sind kryptanalytisch in Ordnung mit korrektem Padding, haben aber echte Sicherheitslücken verursacht (Bleichenbachers e=3-Signaturfälschung von 2006). 65537 ist der sichere Standard.

Was ist RSA-OAEP und warum ist es wichtig?

RSA-OAEP (RFC 8017 Abschnitt 7.1) ist das moderne RSA-Verschlüsselungs-Padding. Es fügt strukturierte Zufälligkeit hinzu, sodass die zweimalige Verschlüsselung derselben Nachricht unterschiedliche Geheimtexte erzeugt, und widersteht Bleichenbacher-Padding-Oracle-Angriffen (ROBOT 2017 brach PKCS#1 v1.5). Dieses Tool generiert Schlüssel mit RSA-OAEP und SHA-256 Masken-Hash. Niemals rohes RSA oder PKCS#1 v1.5 für neue Verschlüsselung verwenden.

Muss ich mir wegen Quantencomputern Sorgen machen?

Bei häufig rotierenden Schlüsseln nein - ein kryptografisch relevanter Quantencomputer wird vor 2030 nicht erwartet. Für Langzeit-Geheimnisse (verschlüsselte Archive, Compliance-E-Mails) ja: ein Angreifer kann heute RSA-Verkehr abfangen und später entschlüsseln, sobald Quantum-Hardware verfügbar ist. NIST finalisierte ML-KEM (FIPS 203) 2024 als Standard für post-Quanten-KEM. Für langlebige Daten ist hybrides RSA+ML-KEM aktuell beste Praxis.

Kann ich eine große Datei direkt mit dem öffentlichen Schlüssel verschlüsseln?

Nein. RSA kann nur Nachrichten verschlüsseln, die kürzer als der Modulus minus Padding-Overhead sind - ungefähr 214 Bytes für 2048-Bit-RSA mit OAEP-SHA-256. Für größere Daten hybride Verschlüsselung verwenden: einen zufälligen AES-GCM-Schlüssel generieren, die Datei mit AES-GCM verschlüsseln, dann den AES-Schlüssel mit dem öffentlichen RSA-Schlüssel des Empfängers verschlüsseln. Das ist das Muster in PGP, S/MIME und dem TLS-Handshake. Das begleitende AES-GCM-Tool dieser Seite behandelt den symmetrischen Teil.

Wie verhält sich das im Vergleich zu openssl genpkey?

Funktional äquivalente Ausgabe. openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 erzeugt einen PKCS#8 PEM-Privatschlüssel in identischem Format; openssl rsa -in key.pem -pubout extrahiert den passenden SPKI-öffentlichen Schlüssel. Das CLI gewinnt bei Skriptierbarkeit und FIPS-validierten Builds; dieses Tool gewinnt bei browserlokal Generierung. Für automatisierte Pipelines sind openssl oder Sprachbindungen (Python cryptography, Node crypto.generateKeyPairSync) die richtige Wahl.

Mehr Security & Privacy

AES-256 Encrypt / Decrypt Online - Free, In-Browser

Encrypt and decrypt text with AES-128, AES-192, or AES-256 in GCM, CBC, or CTR mode. PBKDF2 key derivation, entirely in your browser.

Open tool

Basic Auth Header Generator

Create HTTP Basic Authentication headers from a username and password or API token.

Open tool

CSP Header Generator

Build Content-Security-Policy headers with a visual form, presets and per-directive configuration.

Open tool

Password Entropy Calculator

Estimate password entropy, character pool size and crack-time ranges for online and offline attacks.

Open tool

Password Generator

Generate cryptographically secure random passwords with configurable length, character types and entropy display.

Open tool

Password Strength Checker

Check password strength with entropy calculation, pattern detection and common password matching.

Open tool