RSA verschlüsseln / entschlüsseln

Zwei Primzahlen und eine Falltür. Ein RSA-Schlüssel beginnt mit zwei großen zufälligen Primzahlen p und q; ihr Produkt n (der Modulus, daher „2048-Bit-Schlüssel“) wird im öffentlichen Schlüssel zusammen mit einem Exponenten e veröffentlicht (fast immer 65537). Der private Schlüssel ist das Paar d, das modulare Inverse von e − berechnet aus p und q — zusammen mit Abkürzungen, die aus den Primzahlen abgeleitet werden und private Operationen um den Faktor 4 beschleunigen.

Verschlüsseln und Signieren sind dieselbe Potenzierung. Einen Nachrichtenblock m zu verschlüsseln bedeutet, m^e mod n zu berechnen; entschlüsseln ist c^d mod n. Einen vorformatierten Block mit dem privaten Exponenten zu signieren und mit dem öffentlichen zu prüfen ist dieselbe Operation in der anderen Richtung. Alles Übrige auf dieser Seite — OAEP, PSS, PKCS#1 — betrifft das sichere Formatieren dieses Blocks, damit die rohe Potenzierung nie offenliegt.

Warum es langsam ist. Eine RSA-Operation mit einem 2048-Bit-Schlüssel kostet etwa eine Million Mal mehr Rechenzeit als die Verschlüsselung eines Blocks mit AES. Deshalb verwendet TLS RSA (oder ECC) nur, um sich auf einen zufälligen AES-Schlüssel zu einigen, und wechselt dann. Dieselbe Regel gilt für alles, was Sie bauen: RSA für den Schlüssel, AES für die Daten.

Schlüsselgröße. Die Modullänge ist der Sicherheitsregler: 1024 Bit gelten nach Richtlinie als gebrochen (die Faktorisierung liegt im Bereich staatlicher Akteure), 2048 Bit ≈ 112 Bit symmetrische Stärke, 3072 Bit ≈ 128 Bit, 15360 Bit entsprächen einem symmetrischen 256-Bit-Schlüssel. Hinweis zur Post-Quanten-Ära: Der Shor-Algorithmus bricht RSA auf einem großen Quantencomputer vollständig — ein weiterer Grund, Schlüssel nur für begrenzte Zeit zu verwenden.

Das Problem mit reinem RSA. Lehrbuch-RSA (m^e mod n auf der rohen Nachricht) ist deterministisch und manipulierbar: Identische Nachrichten werden identisch verschlüsselt, ein Angreifer kann einen Chiffretext mit der Verschlüsselung von 2 multiplizieren, damit sich der Klartext verdoppelt, und kurze Nachrichten fallen dem Meet-in-the-Middle-Angriff zum Opfer. Es darf niemals direkt verwendet werden.

Was OAEP macht. OAEP (PKCS#1 v2, RFC 8017) vermischt die Nachricht mit einem zufälligen Seed über ein hashbasiertes Feistel-Netzwerk, bevor potenziert wird. Das Ergebnis: Die Verschlüsselung ist randomisiert (derselbe Klartext ergibt jedes Mal einen anderen Chiffretext — führen Sie das OAEP-Beispiel zweimal aus und vergleichen Sie), Manipulation wird bei der Entschlüsselung erkannt, und die Nachricht muss in den Modulus passen mit Platz für den Hash — die oben tabellierte Grenze k−2·hashLen−2.

Das Label. Eine optionale öffentliche Zeichenkette, die in die Füllung eingebunden wird. Beide Seiten müssen dasselbe Label angeben, sonst schlägt die Entschlüsselung fehl — wie die AAD bei AES-GCM erlaubt es, den Chiffretext an einen Kontext zu binden (einen Dateinamen, eine Algorithmus-ID). Leer ist normal.

Die PKCS#1-v1.5-Verschlüsselung fehlt mit Absicht. Die Füllung aus dem Jahr 1993 hat keine Integritätsprüfung und verrät Informationen über das Fehlerverhalten bei der Entschlüsselung (Bleichenbachers Angriff von 1998 macht aus einem Padding-Oracle mit einigen Millionen präparierten Chiffretexten eine vollständige Entschlüsselung; er bricht bis heute reale Systeme als ROBOT, 2017). WebCrypto verweigert die Implementierung; diese Seite ebenfalls.

Signieren = hashen, dann auffüllen, dann potenzieren. Beide Verfahren hashen die Nachricht (hier SHA-256/384/512), formatieren den Digest in einen Block und wenden den privaten Exponenten an. Die Prüfung formatiert den Block mit dem öffentlichen Schlüssel neu und vergleicht. Der Unterschied liegt in der Formatierung:

Welches wählen. Neue Entwürfe: PSS. Interoperabilität mit bestehenden Zertifikaten, JWTs (RS256) oder älteren Gegenstellen: v1.5. Beide sind als Signaturverfahren sicher — die Katastrophengeschichte von v1.5 betrifft die *Verschlüsselungs*füllung, eine andere Konstruktion trotz des ähnlichen Namens.

PEM ist nur Base64 um DER. Eine PEM-Datei besteht aus einer Kennzeichnung und dem Base64 einer DER-Struktur (binäres ASN.1). Die Kennzeichnung sagt Ihnen, welche Struktur vorliegt — und darin liegt der ganze Unterschied zwischen den vier Formaten, die diese Seite erzeugt:

Derselbe Schlüssel, andere Hüllen. Alle vier Felder oben enthalten nach dem Erzeugen dasselbe Schlüsselpaar — SPKI und PKCS#1 öffentlich enthalten identische n, e; PKCS#8 und PKCS#1 privat enthalten identische private Werte. Diese Seite wandelt verlustfrei zwischen ihnen um (ihr Selbsttest prüft die Umwandlungen in beide Richtungen). Verwechselte Formate sind die häufigste Ursache für Fehler „ungültiger Schlüssel“ beim Einfügen von Schlüsseln zwischen Werkzeugen.

Verschlüsselte PEMs (-----BEGIN ENCRYPTED PRIVATE KEY-----) sind PKCS#8 mit einer passwortbasierten Verschlüsselungsschicht. Diese Seite akzeptiert sie nicht — entschlüsseln Sie sie zuerst offline (openssl pkcs8 -in enc.pem -out plain.pem).

• Massendaten mit RSA verschlüsseln. Abgesehen von der harten OAEP-Größengrenze ist das absurd langsam. Das Muster lautet: einen zufälligen AES-Schlüssel erzeugen, den AES-Schlüssel mit RSA-OAEP verschlüsseln, die Daten mit AES-GCM verschlüsseln und beide Teile senden.
• Den privaten Schlüssel ausliefern, weil „es nur ein Test ist“. Die Beispielschlüssel in den Referenzvektoren dieser Seite sind bewusst veröffentlicht — sie können nur Testdaten signieren. Ihre Schlüssel sind nicht so.
• Mit dem privaten Schlüssel prüfen. Das „funktioniert“ mathematisch meist, und manche Werkzeuge erlauben es, aber einen privaten Schlüssel an Prüfer zu verteilen, hebelt das ganze Modell aus. Prüfen Sie mit dem öffentlichen Schlüssel (diese Seite erzwingt es).
• Signaturen Byte für Byte vergleichen, um Code zu prüfen. PSS (und OAEP) sind randomisiert: Zwei korrekte Durchläufe erzeugen unterschiedliche Ausgaben. Vergleichen Sie durch Prüfen, nicht durch Gleichheit — nur v1.5-Signaturen sind deterministisch.
• 1024-Bit-Schlüssel „weil sie schneller sind“. Sie liegen außerdem im Bereich gut finanzierter Faktorisierung. Das Geschwindigkeitsargument ist mit der hybriden Verschlüsselung entfallen: RSA läuft einmal pro Sitzung, nicht pro Byte.
• Eine andere Salt-Länge als die Hash-Länge für PSS festlegen. Der Prüfer muss zustimmen; die Hash-Länge (die Wahl dieser Seite und der Parameter -sigopt rsa_pss_saltlen:32 von OpenSSL) ist der interoperable Standard.

Warum ist meine Entschlüsselung mit „falscher Schlüssel, falscher Hash oder beschädigter Chiffretext“ fehlgeschlagen? Die OAEP-Entschlüsselung schlägt fehl, wenn einer der folgenden Fälle zutrifft: Es ist nicht der passende private Schlüssel, der Hash weicht von der Verschlüsselungsseite ab, das Label ist anders, oder ein Byte des Chiffretexts hat sich geändert. Die Fehlermeldung ist bewusst für alle Fälle gleich — zu verraten, welche Prüfung fehlschlug, wäre selbst ein Padding-Oracle-Leck.

Kann ich den öffentlichen Schlüssel aus dem privaten gewinnen? Ja — die privaten Formate enthalten n und e ebenfalls. Diese Seite zeigt nach dem Erzeugen beide an; OpenSSL erledigt das mit openssl pkey -in priv.pem -pubout.

Warum 65537 als Exponent? Sie ist eine Primzahl, hat nur zwei Bits mit dem Wert 1 (schnelle Potenzierung) und ist groß genug, um die Angriffe mit kleinem Exponenten zu vermeiden, die e=3 treffen. Sie ist seit den 1990er-Jahren die Standardwahl; ein „ungewöhnlicher“ Exponent bedeutet meist einen schwachen oder nicht standardkonformen Schlüssel.

Ist RSA wegen Quantencomputern erledigt? Noch nicht — es gibt keine Maschine, die den Shor-Algorithmus auf einen 2048-Bit-Modulus anwenden kann. Doch Daten, die bis in die 2030er-Jahre und darüber geheim bleiben müssen, werden bereits migriert; hybride PQC-Verfahren sind die technische Antwort.

Was ist mit openssl rsautl? Er ist der veraltete Vorgänger von pkeyutl. Standardmäßig verwendet er die Verschlüsselungsfüllung nach v1.5 — ein weiterer Grund, warum er außer Dienst gestellt wurde.