Skip to content

Kostenloser RSA-Schlüsselpaar-Generator — ECDSA, Ed25519

RSA-Schlüsselpaar online erzeugen — der private Schlüssel bleibt im Browser. RSA 2048/4096, ECDSA, Ed25519 als PKCS#8- oder PKCS#1-PEM, mit JWK und Fingerprint.

Kein Tracking Läuft im Browser Kostenlos
Schlüsselpaare werden in deinem Browser mit der Web Crypto API erzeugt, und beim Erzeugen geht keine Netzwerkanfrage raus. Trenne die Verbindung und diese Seite funktioniert weiter.

PKCS#8 (BEGIN PRIVATE KEY) ist der moderne Standard und das, was das JDK erwartet. PKCS#1 (BEGIN RSA PRIVATE KEY) ist die traditionelle Form von OpenSSL, die manche Gateways weiterhin verlangen. Das Umschalten codiert denselben Schlüssel neu.

Halte ihn geheim. Wer ihn besitzt, kann sich als du ausgeben.

Fingerprint des öffentlichen Schlüssels — SHA-256 des SPKI-DER
JWK (JSON Web Key)
Privater JWK — niemals veröffentlichen 
 
 
 
 Öffentlicher JWK  
 
 
 
 
  
 
Dieselbe Art Schlüsselpaar mit OpenSSL erzeugen
 
 
    
 
  
  
  
  Geprüft auf Korrektheit gemäß RFC 5958/5208 (PKCS#8), RFC 8017 (PKCS#1), RFC 8410 (Ed25519) und RFC 7468 (PEM-Codierung) sowie auf das Verhalten der Web Crypto API über RSA, ECDSA und Ed25519 hinweg. — Go Tools Security Tooling Team · Aug 10, 2026  
 Unser Team prüft die Umrechnung von PKCS#8 nach PKCS#1 Byte für Byte gegen die Referenzausgabe des crypto-Moduls von Node, sodass ein hier exportierter Schlüssel identisch mit dem ist, den OpenSSL aus demselben Material erzeugen würde. 
 
 
      
 
Was ist ein RSA-Schlüsselgenerator?
 
 
Ein RSA-Schlüsselgenerator erzeugt ein mathematisch verbundenes Paar: einen privaten Schlüssel, den du behältst, und einen öffentlichen Schlüssel, den du weitergibst. Was mit der privaten Hälfte signiert wurde, lässt sich mit der öffentlichen prüfen, und nur die öffentliche Hälfte darf veröffentlicht werden. Genau diese Asymmetrie ist der Sinn der Sache — sie erlaubt einem Prüfer, deine Signaturen zu kontrollieren, ohne selbst welche fälschen zu können; ein gemeinsames Secret kann das nie leisten.
Dieser Generator läuft in deinem Browser über die Web Crypto API, der private Schlüssel entsteht also im Tab, und die Seite stellt beim Erzeugen keine Netzwerkanfrage. Neben RSA erzeugt sie auch ECDSA- und Ed25519-Paare, die denselben Zweck mit viel kürzeren Schlüsseln erfüllen: Ein privater Ed25519-Schlüssel ist in PKCS#8 48 Byte groß, während ein 2048-Bit-RSA-Schlüssel über 1,2 KB kommt.
Was in der Praxis stolpern lässt, ist nicht die Mathematik, sondern die Verpackung. Derselbe Schlüssel kann als PKCS#8, PKCS#1, SPKI oder JWK geschrieben werden, und eine Bibliothek, die das eine ablehnt, akzeptiert oft das andere — ohne deutlichere Meldung als einen Parse-Fehler. Die Tabelle weiter unten ordnet jedem Container die Ökosysteme zu, die ihn erwarten.
 
 
// Verify a downloaded key pair matches, using OpenSSL:
openssl pkey -in rsa-2048-private.pem -pubout | diff - rsa-2048-public.pem
// No output means the public key really belongs to that private key.
 
  
 
Hauptfunktionen
 
 
 
Im Browser erzeugt
 
Die Schlüssel kommen aus der Web Crypto API in deinem eigenen Tab, und die Seite stellt beim Erzeugen keine Netzwerkanfrage. Schalte die Verbindung ab und es funktioniert weiter — das zeigt, dass das Tool für seine Arbeit keinen Server braucht.
 
 
RSA, ECDSA und Ed25519
 
RSA mit 2048, 3072 und 4096 Bit; ECDSA auf P-256, P-384 und P-521; dazu Ed25519 — alles auf einer Seite mit denselben Exportoptionen.
 
 
Ausgabe als PKCS#8 und PKCS#1
 
Wechsle zwischen BEGIN PRIVATE KEY und der traditionellen Form BEGIN RSA PRIVATE KEY, ohne OpenSSL zu bemühen. Das Umschalten codiert den bereits angezeigten Schlüssel neu, es bleibt also derselbe Schlüssel.
 
 
JWK-Export
 
Beide Hälften stehen als JSON Web Key bereit. Der öffentliche JWK ist das, was in ein JWKS-Dokument oder zu einem JOSE-Prüfer gehört; der private JWK ist allein für deinen Signierer und darf nie veröffentlicht werden.
 
 
SHA-256-Fingerprint
 
Zu jedem Paar gehört ein Fingerprint des öffentlichen Schlüssels, damit beide Seiten außerhalb der Leitung prüfen können, dass sie denselben Schlüssel halten.
 
 
Passende OpenSSL-Befehle
 
Unter der Ausgabe stehen die Befehle, mit denen du lokal denselben Schlüsseltyp erzeugst — falls du lieber auf der Kommandozeile weiterarbeitest.
 
 
Downloads mit sprechenden Namen
 
Die Dateien werden als rsa-2048-private.pem und rsa-2048-public.pem gespeichert, nicht unter einem generischen Namen, den du erst umbenennen musst.
 
 
Kein Konto, kein Limit
 
Es ist kein Server beteiligt, also gibt es nichts zu registrieren und kein Kontingent, das ausgehen könnte.
 
 
 
      
 
Durchgearbeitete Beispiele
 
 
 
Ein Ed25519-Paar, vollständig gezeigt
 
 
Algorithmus: Ed25519
 
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIA2HJVU1qChbOJN8XksXVhyD0IjYVt0UU6Mwz814rOFf
-----END PRIVATE KEY-----

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAV5uB7UaPJrtncx3SXNtNzn1ZXjF1ApwvzBZ8nFzT5eU=
-----END PUBLIC KEY-----
 
 
Ein privater Ed25519-Schlüssel ist in PKCS#8 48 Byte groß, der öffentliche 44 Byte — deshalb passt jedes PEM in eine einzige base64-Zeile. Das hier ist ein Wegwerf-Beispielpaar: Erzeuge dein eigenes, statt dieses zu kopieren.
 
 
PKCS#8 und PKCS#1 unterscheiden sich im Header
 
 
Algorithmus: RSA 2048, Struktur umgeschaltet
 
PKCS#8:  -----BEGIN PRIVATE KEY-----
PKCS#1:  -----BEGIN RSA PRIVATE KEY-----
 
 
Derselbe Schlüssel, zwei Hüllen. PKCS#8 legt einen Algorithmus-Identifier um die RSA-Struktur — deshalb trägt es jeden Algorithmus, während PKCS#1 nur für RSA existiert. Das Umschalten codiert den bereits angezeigten Schlüssel neu, der Fingerprint ändert sich also nicht.
 
 
Öffentlicher RSA-2048-Schlüssel
 
 
Algorithmus: RSA 2048
 
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuvUHLjyK9zje2aaNIni
eSccN1uleXFRBb1g2TN6bk/fbpPCGDyh71m73oB9Bk8+fKVkSThXyWTtpgblB7pX
iQBtTvSWVZGHprkLgMGkU2Yw8Z43m1WpoRuYyXNFe92S5viIdVuKTj/VEUuEpzHd
ffWMIUw70LaUdTP04iQdkNVeS3M6VHkpTwsPSQfsFSwObtLVNy2Lf+ODwJRqCk2r
C749hgKqBdJqkcIj49R7UP4SMQ/9V3yy8DFMrIcgsjC4tHwlQSCGeXNxTNlapGSa
ke55LUR83FASryVJRbUs678SCZSFkyGcT0qLZ/olu/e7Jj2lB0Qy/SJawkrs9hPE
4QIDAQAB
-----END PUBLIC KEY-----
 
 
Das Präfix MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A ist der rsaEncryption-Algorithmus-Identifier — daran erkennst du einen RSA-SPKI-Schlüssel auf einen Blick.
 
 
Öffentlicher Schlüssel als JWK
 
 
Algorithmus: Ed25519, JWK-Panel
 
{
  "key_ops": [
    "verify"
  ],
  "ext": true,
  "alg": "Ed25519",
  "crv": "Ed25519",
  "x": "V5uB7UaPJrtncx3SXNtNzn1ZXjF1ApwvzBZ8nFzT5eU",
  "kty": "OKP"
}
 
 
Das ist der Export im Wortlaut, samt der Felder key_ops und ext, die Web Crypto immer hinzufügt. Ein JWKS-Eintrag will sie nicht — lösche beide und ergänze stattdessen kid und use, damit Prüfer bei einer Rotation den richtigen Schlüssel auswählen können. Ed25519 landet im Schlüsseltyp OKP; RSA-Schlüssel erscheinen als kty RSA mit den Feldern n und e.
 
 
SHA-256-Fingerprint
 
 
Algorithmus: Ed25519
 
SHA256(SPKI) = KAXVxapxpG4zLsTVMpPafovT+X1NLWc8fsOXqtrb59o=
 
 
Ein SHA-256-Digest der öffentlichen Schlüsselstruktur, kurz genug, um ihn am Telefon vorzulesen. Beachte: Das ist nicht der Wert, den ssh-keygen ausgibt — OpenSSH bildet den Hash über sein eigenes Übertragungsformat, deshalb stimmen die beiden für denselben Schlüssel nie überein.
 
 
 
      
 
So nutzt du den RSA-Schlüsselgenerator
 
     
  1.  1 
     
    Den Algorithmus wählen
     
    RSA deckt die größte Bandbreite an Altsystemen ab. ECDSA erreicht dieselbe Stärke mit deutlich kürzeren Schlüsseln. Ed25519 ist der moderne Standard für neue Signieraufgaben.
     
     
  2.  2 
     
    Die Schlüssellänge wählen
     
    RSA 2048 erfüllt die aktuellen Empfehlungen; 3072 und 4096 geben langlebigen Schlüsseln Reserve. ECDSA bietet P-256, P-384 und P-521. Ed25519 hat genau eine Größe.
     
     
  3.  3 
     
    Die PEM-Struktur festlegen
     
    PKCS#8 gibt BEGIN PRIVATE KEY aus und funktioniert fast überall, auch im JDK. Wechsle nur dann zu PKCS#1, wenn etwas ausdrücklich BEGIN RSA PRIVATE KEY verlangt.
     
     
  4.  4 
     
    Beide Hälften kopieren oder herunterladen
     
    Der private Schlüssel gehört in deinen Secrets-Speicher. Den öffentlichen Schlüssel bekommt, wer deine Signaturen prüft. Verschicke die private Hälfte niemals.
     
     
  5.  5 
     
    Den Fingerprint abgleichen
     
    Vergleiche den SHA-256-Fingerprint über einen zweiten Kanal, um zu bestätigen, dass die Gegenseite genau den öffentlichen Schlüssel eingespielt hat, den du erzeugt hast.
     
     
    6.  
 
  
 
Häufige Fehler bei Schlüsselformaten
 
 
 
Den öffentlichen Schlüssel dort eingefügt, wo der private hingehört
 
Zum Signieren braucht es die private Hälfte. Bekommt eine Bibliothek BEGIN PUBLIC KEY, wo sie einen privaten Schlüssel erwartet, meldet sie meist einen nichtssagenden Parse-Fehler statt des eigentlichen Problems.
 
 
 ✗ Falsch 
-----BEGIN PUBLIC KEY-----
 
 
 ✓ Richtig 
-----BEGIN PRIVATE KEY-----
 
 
 
 
Falsche PEM-Struktur für die Bibliothek
 
Nur wenige Ökosysteme lesen ausschließlich das traditionelle RSA-Layout — die -traditional-Ausgabe von OpenSSL selbst, manche Payment-Gateway-SDKs, ältere Ruby- und Perl-Werkzeuge. Die meisten modernen Bibliotheken und insbesondere das JDK erwarten PKCS#8. Schalte die PEM-Struktur um, statt nach einem Konvertierungsbefehl zu suchen.
 
 
 ✗ Falsch 
-----BEGIN RSA PRIVATE KEY-----
 
 
 ✓ Richtig 
-----BEGIN PRIVATE KEY-----
 
 
 
 
Den abschließenden Zeilenumbruch verloren
 
PEM-Dateien enden mit einem Zeilenumbruch nach dem letzten Trenner. Kopieren durch ein Formularfeld, das Leerraum abschneidet, erzeugt eine Datei, die manche Parser rundweg ablehnen — und weil das fehlende Zeichen unsichtbar ist, sieht die Datei im Editor korrekt aus.
 
 
 ✗ Falsch 
-----END PRIVATE KEY-----[EOF]
 
 
 ✓ Richtig 
-----END PRIVATE KEY-----↵[EOF]
 
 
 
 
Ein Zeichen auf dem Transportweg verloren
 
Ein PEM zerbricht an einem verlorenen, eingefügten oder ersetzten Zeichen, nicht an der Zeilenbreite — die meisten Parser akzeptieren jeden Umbruch. Eine Kopie durch einen Chat-Client oder ein Formularfeld kann einen Zeilenumbruch stillschweigend in ein Leerzeichen verwandeln, und base64 verrät nicht, welches Zeichen danebenging; der Schlüssel lädt einfach nicht. Nimm den Kopieren-Button, statt von Hand zu markieren.
 
 
 ✗ Falsch 
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuvUHLjyK9zje2aaNIni eSccN1uleXFRBb1g2TN6bk
 
 
 ✓ Richtig 
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuvUHLjyK9zje2aaNIni
eSccN1uleXFRBb1g2TN6bk
 
 
 
 
Ein HS256-Secret verwendet, wo RS256 konfiguriert ist
 
HS256 nimmt ein einzelnes gemeinsames Secret, RS256 ein Schlüsselpaar. Eine Zufallszeichenkette an einen RS256-Signierer zu geben scheitert schon beim Parsen. Erzeuge hier das Paar — oder nutze unseren JWT-Secret-Generator, falls du HS256 meintest.
 
 
 ✗ Falsch 
alg: RS256, key: 8f3a9c2e1b7d
 
 
 ✓ Richtig 
alg: RS256, key: -----BEGIN PRIVATE KEY-----
 
 
 
 
Ein PEM in authorized_keys eingefügt
 
Ein öffentlicher SSH-Schlüssel ist die einzeilige OpenSSH-Form ssh-ed25519 AAAA…, kein PEM-Block; den öffentlichen Schlüssel dieser Seite in authorized_keys zu kopieren funktioniert also nicht. Bei einem RSA-Schlüssel leitest du die richtige Zeile lokal mit ssh-keygen -y ab; für SSH-Zugriff allgemein ist es noch besser, direkt auf der Zielmaschine zu erzeugen.
 
 
 ✗ Falsch 
-----BEGIN PUBLIC KEY-----
 
 
 ✓ Richtig 
ssh-keygen -y -f rsa-2048-private.pem > id_rsa.pub
 
 
 
 
 
  
 
Wer dieses Tool nutzt
 
 
 
JWTs mit RS256 oder EdDSA signieren
 
Asymmetrische JWT-Algorithmen brauchen ein Schlüsselpaar statt eines gemeinsamen Secrets. Signiere mit dem privaten Schlüssel, veröffentliche den öffentlichen, und Prüfer halten nie etwas in der Hand, womit sie selbst Tokens ausstellen könnten. Unser JWT-Kodierer nimmt die Schlüssel dieser Seite direkt an.
 
 
Webhooks und Releases signieren
 
Veröffentliche den öffentlichen Schlüssel einmal, signiere jede Nutzlast mit dem privaten, und Konsumenten prüfen die Echtheit ohne gemeinsames Geheimnis, das leaken könnte.
 
 
Lokale Entwicklung und Tests
 
Testsuites, die Signaturprüfung durchspielen, brauchen ein Wegwerf-Schlüsselpaar. Hier eines zu erzeugen geht schneller, als sich den OpenSSL-Aufruf zu merken.
 
 
Verstehen, wie ein Schlüsselpaar aussieht
 
Algorithmen und PEM-Strukturen nebeneinander umzuschalten macht die Unterschiede so greifbar, wie es keine Spezifikation schafft.
 
 
Einen JWKS-Endpunkt vorbereiten
 
Der öffentliche JWK passt unverändert in das keys-Array eines OpenID-Connect-Discovery-Dokuments. Ergänze eine kid, damit Prüfer ihn bei einer Rotation auswählen können, und halte den privaten JWK aus dieser Datei heraus.
 
 
Weg von RSA migrieren
 
Erzeuge den Ed25519-Ersatz direkt neben dem RSA-Original und vergleiche die Größen, bevor du dich auf den Wechsel festlegst.
 
 
Ein Formatproblem beheben
 
Wenn eine Bibliothek einen Schlüssel mit Parse-Fehler ablehnt, ist ein erneutes Ausgeben in der jeweils anderen PEM-Struktur meist schon die ganze Lösung.
 
 
 
  
 
PEM-Formate und wie der Generator arbeitet
 
 
 
Welcher Container wohin gehört
 
Ein Schlüssel, fünf Verpackungen. Die falsche zu wählen ist der häufigste Grund, warum ein Schlüssel abgelehnt wird, und die Fehlermeldung ist selten konkreter als ein gescheitertes Parsen.


ContainerPEM-HeaderEnthältWo er dir begegnet
PKCS#8BEGIN PRIVATE KEYJeden AlgorithmusWeb Crypto, das JDK, Go, .NET — die meisten modernen Bibliotheken
PKCS#1BEGIN RSA PRIVATE KEYNur RSATraditionelle OpenSSL-Ausgabe, manche Payment-Gateways, ältere Ruby- und Perl-Werkzeuge
SPKI / X.509BEGIN PUBLIC KEYJeden Algorithmus, öffentliche HälfteDer öffentliche Schlüssel, den fast jede Bibliothek erwartet
PKCS#1 publicBEGIN RSA PUBLIC KEYNur RSA, öffentliche HälfteAlte RSA-Werkzeuge
JWKkeiner — es ist JSONJeden AlgorithmusJWKS-Endpunkte, OIDC-Discovery, JOSE-Bibliotheken


Um bereits vorhandene Dateien umzuwandeln, geht openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem in die eine Richtung und openssl rsa -traditional -in pkcs8.pem -out pkcs1.pem in die andere.
 
 
Die Zufälligkeit stammt vom Betriebssystem
 
Web Crypto speist die Schlüsselerzeugung aus der Entropiequelle der Plattform — getrandom unter Linux und dem System-CSPRNG unter Windows und macOS. Es ist dieselbe Art Quelle, aus der auch OpenSSL schöpft, kein JavaScript-Pseudozufallsgenerator.
 
 
Die Erzeugung friert die Seite nicht ein
 
crypto.subtle.generateKey arbeitet asynchron, und in den großen Browser-Engines läuft die Suche nach Primzahlen außerhalb des Haupt-Threads, sodass die Oberfläche bedienbar bleibt, während ein 4096-Bit-Modul gesucht wird. Ein Spinner erscheint trotzdem, denn wie lange diese Suche dauert, ist Glückssache.
 
 
PKCS#8 umschließt PKCS#1
 
Ein PKCS#8-PrivateKeyInfo besteht aus Versionsnummer, Algorithmus-Identifier und einem OCTET STRING. Bei einem unverschlüsselten rsaEncryption-Schlüssel enthält dieser OCTET STRING einen vollständigen PKCS#1-RSAPrivateKey — genau so rechnet diese Seite zwischen beiden um, ohne irgendetwas neu abzuleiten.
 
 
Öffentliche Schlüssel nutzen SubjectPublicKeyInfo
 
BEGIN PUBLIC KEY ist ein X.509-SubjectPublicKeyInfo: ein Algorithmus-Identifier plus ein BIT STRING. Was in diesen Bits steckt, hängt vom Algorithmus ab — bei RSA ist es ein PKCS#1-RSAPublicKey, weshalb BEGIN RSA PUBLIC KEY kürzer ausfällt; bei ECDSA ist es der unkomprimierte Kurvenpunkt und bei Ed25519 der rohe 32-Byte-Schlüssel.
 
 
Der öffentliche Exponent ist 65537
 
Jeder RSA-Schlüssel hier verwendet e = 65537, geschrieben 0x010001. Er ist groß genug, um Angriffe auf kleine Exponenten auszuschließen, und hat nur zwei gesetzte Bits, sodass die Prüfung 16 Quadrierungen und eine einzige Multiplikation kostet.
 
 
Fingerprints bilden den Digest über das DER, nicht über das PEM
 
Der SHA-256-Fingerprint wird über das binäre SubjectPublicKeyInfo gebildet. Über den base64-Text gebildet, würde er sich ändern, sobald sich der Zeilenumbruch ändert. Lokal entspricht dem openssl pkey -in private.pem -pubout -outform DER | openssl dgst -sha256 -binary | openssl base64.
 
 
 
  
 
Best Practices für die Schlüsselverwaltung
 
 
 
Schlüssel dort erzeugen, wo sie verwendet werden
 
Ein privater Schlüssel, der über ein Netz wandert, war jedem Zwischenknoten ausgesetzt. Die Erzeugung im Browser hält den Schlüssel selbst vom Netz fern, auch wenn der Code der Seite weiterhin über das Netz kommt; die Erzeugung direkt auf dem Zielhost spart sogar den Kopierschritt. Für einen Schlüssel, der Produktionssysteme schützt, nimm den Host.
 
 
Ed25519 bevorzugen, solange nichts RSA erzwingt
 
Ed25519 liefert starke Sicherheit in einem 32-Byte-Schlüssel, signiert schnell und hat keine Parameter, die man falsch wählen könnte. Greif zu RSA, wenn eine Gegenstelle oder eine alte Bibliothek dir keine Wahl lässt.
 
 
2048 Bit als Untergrenze behandeln
 
NIST SP 800-131A verbietet RSA unterhalb von 2048 Bit für die Signaturerzeugung seit 2013, und keine öffentliche Zertifizierungsstelle stellt gegen einen kleineren Schlüssel aus. Wähle 3072 oder 4096 für Schlüssel, die viele Jahre im Einsatz bleiben sollen.
 
 
Niemals einen privaten Schlüssel committen
 
Private Schlüssel gehören in einen Secrets-Manager oder in eine zur Laufzeit geladene Umgebungsvariable. Sobald ein Schlüssel in einem Repository gelandet ist, hilft nur noch, ihn auszutauschen.
 
 
Nach Plan rotieren, nicht erst nach einem Vorfall
 
Veröffentliche neue öffentliche Schlüssel mit einer Schlüsselkennung, bevor du die alten zurückziehst, damit Prüfer während der Überlappung beide akzeptieren. Routiniert geübte Rotation ist die Rotation, die unter Druck funktioniert.
 
 
 
  
 
Häufig gestellte Fragen
 
 
 Ist es sicher, einen privaten Schlüssel auf einer Website zu erzeugen? 
 Der Schlüssel wird von der Web Crypto API in deinem eigenen Browser erzeugt, und diese Seite stellt beim Erzeugen keine Netzwerkanfrage — du kannst das Netzwerk-Panel beobachten oder die Verbindung trennen und sehen, dass die Erzeugung weiterhin funktioniert. Sei dir klar darüber, was das zeigt und was nicht: Es belegt, dass die Seite keinen Server braucht, ist aber kein Beweis gegen ein kompromittiertes Skript, denn das JavaScript wird bei jedem Besuch neu von unserem Server geladen. Die verbleibenden Risiken liegen im Browser, nicht im Netz — eine bösartige Erweiterung kann die Seite und deine Zwischenablage lesen, und wer Zugriff auf die Maschine hat, kann die heruntergeladene Datei lesen. Für einen Schlüssel, der Produktionssysteme schützt, erzeuge ihn auf dem Host, der ihn verwenden wird; genau das tun die OpenSSL-Befehle weiter unten. Für Entwicklung, Tests, zum Lernen und überall dort, wo ein im Browser erzeugter Schlüssel akzeptabel ist, ist diese Seite das richtige Werkzeug. 
 
 Was ist der Unterschied zwischen PKCS#8 und PKCS#1? 
 Es sind zwei Behälter für denselben RSA-Schlüssel. PKCS#1, erkennbar an BEGIN RSA PRIVATE KEY, enthält die RSA-Zahlen direkt und existiert nur für RSA. PKCS#8, erkennbar an BEGIN PRIVATE KEY, legt einen Algorithmus-Identifier um dieselben Zahlen, sodass ein Format RSA, ECDSA und Ed25519 gleichermaßen trägt. Die meisten modernen Bibliotheken erwarten PKCS#8 — das JDK liest ohne Zusatzbibliothek sogar ausschließlich PKCS#8 —, während einige Payment-Gateways und ältere Werkzeuge aus der OpenSSL-Ära weiterhin PKCS#1 verlangen. Das Umschalten auf dieser Seite codiert den bereits angezeigten Schlüssel neu, es wird also keine Information hinzugefügt oder entfernt, und der Fingerprint bleibt derselbe. 
 
 Wie konvertiere ich einen PKCS#1-Schlüssel nach PKCS#8 und zurück? 
 Schalte auf dieser Seite die PEM-Struktur um, und derselbe Schlüssel wird im jeweils anderen Container ausgegeben. Für eine Datei, die du schon hast, konvertiert OpenSSL lokal: openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem macht aus einer BEGIN-RSA-PRIVATE-KEY-Datei eine mit BEGIN PRIVATE KEY, und openssl rsa -traditional -in pkcs8.pem -out pkcs1.pem geht den umgekehrten Weg. Keine der beiden Richtungen fügt Schlüsselmaterial hinzu oder entfernt welches; es ändert sich nur die Hülle, weshalb beide Dateien denselben Schlüssel beschreiben und denselben Fingerprint ergeben. 
 
 Wie komme ich vom privaten RSA-Schlüssel zum öffentlichen? 
 Der öffentliche Schlüssel lässt sich aus dem privaten ableiten, umgekehrt niemals. Diese Seite zeigt beide Hälften gleichzeitig an, es gibt hier also nichts abzuleiten. Für einen privaten Schlüssel, der schon auf der Festplatte liegt, schreibt openssl pkey -in private.pem -pubout -out public.pem die passende BEGIN-PUBLIC-KEY-Datei. Genau so prüfst du auch, ob ein Paar zusammengehört — erzeuge die öffentliche Hälfte neu und vergleiche sie mit der Datei, die du bekommen hast. 
 
 Soll ich RSA oder Ed25519 wählen? 
 Wähle Ed25519, wenn dich nichts festlegt. Es erreicht mit einem 32-Byte-Schlüssel eine Sicherheit vergleichbar mit RSA 3072, signiert schneller und hat keine Parameter, die man falsch konfigurieren kann. Wähle RSA, wenn eine Gegenstelle, eine Zertifizierungsstelle oder eine alte Bibliothek es verlangt — in Unternehmens- und Zahlungssystemen ist das nach wie vor häufig. ECDSA liegt dazwischen und ist in TLS breit unterstützt. 
 
 Ist RSA mit 2048 Bit noch stark genug? 
 Ja, für die meisten Zwecke heute. NIST bewertet RSA mit 2048 Bit als 112 Bit Sicherheitsniveau und führt es in SP 800-57 bis 2030; 3072 Bit erreichen 128 Bit und sind das, worauf NIST darüber hinaus verweist. Also: 2048 für alles, was du innerhalb weniger Jahre rotierst, 3072 oder 4096 für einen Schlüssel, den du in den 2030er-Jahren noch im Einsatz erwartest oder für den eine Zertifizierungsstelle es fordert. Der Preis des größeren Schlüssels sind langsameres Signieren und größere Signaturen, keine schwächere Sicherheit. 
 
 Kann ich diese Schlüssel zum Signieren von JWTs verwenden? 
 Ja. RSA-Schlüssel arbeiten mit RS256, RS384 und RS512 sowie den PSS-Varianten; ECDSA P-256 passt zu ES256; und Ed25519 ist der Algorithmus EdDSA. Signiere mit dem privaten Schlüssel und veröffentliche den öffentlichen, damit Prüfer Signaturen kontrollieren können, ohne selbst welche zu erzeugen. Ein Vorbehalt, wenn du das JWK-Panel statt des PEM nutzt: Web Crypto stempelt einem RSA-JWK alg RS256 auf, und strenge Bibliotheken weigern sich dann, ihn für PS256 oder RS512 zu laden — lösche das Feld alg oder nimm das PEM. Unser JWT-Kodierer nimmt diese Schlüssel an, und der Dekodierer zeigt, was im entstandenen Token steht. 
 
 Kann das einen SSH-Schlüssel erzeugen? 
 Nicht direkt. OpenSSH hat eine eigene Datei für private Schlüssel, und diese Seite schreibt sie nicht. Ein RSA-Schlüssel von hier ist trotzdem nutzbar: ssh-keygen -y -f rsa-2048-private.pem > id_rsa.pub leitet die authorized_keys-Zeile aus der heruntergeladenen Datei ab. Ed25519-Schlüssel von hier sind es nicht, weil OpenSSH die PKCS#8-Form ablehnt. Für SSH-Zugriff bleibt ssh-keygen -t ed25519 auf der Maschine, die den Schlüssel braucht, die bessere Antwort — damit bewegst du überhaupt keinen privaten Schlüssel. Für JWT-Signaturen, signierte CI-Releases und Webhook-Prüfung ist der PKCS#8-Schlüssel dieser Seite genau das, was diese Werkzeuge wollen. 
 
 Kann ich den privaten Schlüssel mit einer Passphrase schützen? 
 Hier nicht. Verschlüsseltes PKCS#8 erfordert eine Schlüsselableitung, die die Web Crypto API nicht anbietet — es umzusetzen hieße, Kryptografie in JavaScript selbst zu bauen. Ergänze die Passphrase stattdessen lokal: openssl pkcs8 -topk8 -in private.pem -out encrypted.pem liest die heruntergeladene Datei und fragt nach einer. 
 
 Wofür ist der Fingerprint gut? 
 Er ist ein SHA-256-Digest der öffentlichen Schlüsselstruktur, kurz genug, um ihn per Sprache oder in einer Chatnachricht abzugleichen. Wenn du jemandem einen öffentlichen Schlüssel schickst, bestätigt der Abgleich der Fingerprints über einen zweiten Kanal, dass angekommen ist, was du abgeschickt hast. Er identifiziert nur den öffentlichen Schlüssel und verrät nichts über die private Hälfte. Beachte: Es ist nicht die Zahl, die ssh-keygen -l ausgibt — OpenSSH bildet den Hash über sein eigenes Übertragungsformat statt über die SPKI-Struktur, weshalb die beiden für denselben Schlüssel nie übereinstimmen. 
 
 
 
 
   
  
 
 
Verwandte Werkzeuge
  Alle Werkzeuge anzeigen →
 
 
  
 
  
  
  
 
 
AES-Entschlüsselungstool — OpenSSL- & CryptoJS-kompatibel
 
 
Sicherheitswerkzeuge
 
AES online entschlüsseln — GCM/CBC/CTR, Passphrase oder Rohschlüssel, erkennt automatisch das OpenSSL- & CryptoJS-Format „U2FsdGVkX1“. 100 % im Browser, Schlüssel verlassen die Seite nie.
 
 
   
  
 
  
  
  
 
 
AES-Verschlüsselungstool — GCM, CBC & CTR
 
 
Sicherheitswerkzeuge
 
Kostenloses Online-Tool für AES-Verschlüsselung — AES-128/192/256, GCM/CBC/CTR, Passphrase (PBKDF2) oder Rohschlüssel. Läuft zu 100 % im Browser; nichts wird hochgeladen.
 
 
   
  
 
  
  
  
 
 
Bcrypt-Hash-Generator & Verifizierer
 
 
Sicherheitswerkzeuge
 
Bcrypt-Passwort-Hashes online erzeugen und prüfen — einstellbarer Kostenfaktor, $2b$/$2a$/$2y$. 100 % im Browser; dein Passwort wird nie hochgeladen.
 
 
   
  
 
  
  
  
 
 
HMAC-Generator & Signaturprüfer
 
 
Sicherheitswerkzeuge
 
Kostenloser HMAC-Generator und -Prüfer online. Berechne HMAC-SHA256/SHA1/SHA384/SHA512 mit Schlüsseln als Text, Hex oder Base64 und Ausgabe als Hex/Base64/Base64URL. 100 % in deinem Browser — Schlüssel verlassen nie die Seite.
 
 
   
  
 
  
  
  
 
 
JWT-Dekodierer
 
 
Sicherheitswerkzeuge
 
Dekodieren Sie JWT-Token online mit unserem kostenlosen JWT-Dekodierer. Inspizieren Sie sofort Header, Payload, Signatur, Ablauf und Claims. 100 % Browser — Ihr Token verlässt niemals Ihr Gerät. Keine Anmeldung, kein Tracking.
 
 
   
  
 
  
  
  
 
 
JWT-Kodierer & -Generator
 
 
Sicherheitswerkzeuge
 
Kostenloser Online-JWT-Generator & -Kodierer. Erstellen Sie Header und Payload und signieren Sie sofort mit HS256, RS256 oder ES256. 100 % im Browser — Ihr Geheimnis und Ihr Schlüssel verlassen niemals Ihr Gerät.