Public-Key-Kryptografie: RSA, ECDSA & PGP

Das Problem, das symmetrische Verschlüsselung nicht lösen kann

Bevor asymmetrische Kryptografie existierte, verwendete alle Verschlüsselung einen gemeinsamen geheimen Schlüssel — beide Parteien mussten dasselbe Passwort oder denselben Schlüssel kennen, bevor sie sicher kommunizieren konnten. Dies schuf ein offensichtliches Henne-Ei-Problem: Wie tauschst du den Schlüssel sicher aus? Du kannst den Schlüssel nicht mit sich selbst verschlüsseln, und persönliche Treffen lassen sich nicht auf Millionen von HTTPS-Verbindungen skalieren.

Public-Key-Kryptografie, entwickelt in den 1970er Jahren von Diffie, Hellman, Rivest, Shamir und Adleman, löst dies mit einem bemerkenswerten mathematischen Trick: Ein Schlüsselpaar, bei dem was ein Schlüssel verschlüsselt, nur der andere entschlüsseln kann. Ein Schlüssel wird öffentlich gemacht; der andere bleibt privat. Du kannst deinen öffentlichen Schlüssel im gesamten Internet verbreiten — ein Angreifer, der ihn abfängt, gewinnt damit nichts.

Wie RSA funktioniert

RSA ist der bekannteste asymmetrische Algorithmus. Seine Sicherheit beruht auf dem Integer-Faktorisierungsproblem: Zwei große Primzahlen zu multiplizieren ist trivial, aber ihr Produkt wieder in die ursprünglichen Primzahlen zu faktorisieren ist bei ausreichender Schlüsselgröße rechnerisch nicht praktikabel.

Der Schlüsselgenerierungsprozess auf hohem Niveau:

1. Wähle zwei große zufällige Primzahlen, p und q (jeweils 1024+ Bit)
2. Berechne n = p × q (den Modulus, der öffentlich gemacht wird)
3. Berechne φ(n) = (p−1)(q−1)
4. Wähle den öffentlichen Exponenten e (üblicherweise 65537)
5. Berechne den privaten Exponenten d so, dass e × d ≡ 1 (mod φ(n))

Der öffentliche Schlüssel ist (e, n). Der private Schlüssel ist (d, n). Verschlüsselung: Chiffretext = Nachricht^e mod n. Entschlüsselung: Nachricht = Chiffretext^d mod n.

RSA wird für Schlüsselaustausch und digitale Signaturen verwendet, nicht für die Massendatenverschlüsselung — es ist um Größenordnungen langsamer als AES. In TLS handelt RSA (oder ECDH) einen Sitzungsschlüssel aus, und dann übernimmt AES den eigentlichen Datenstrom.

Mindest empfohlene Schlüsselgröße: Heute 2048 Bit; 3072 oder 4096 Bit für langfristige Sicherheit.

Elliptische-Kurven-Kryptografie (ECC)

ECC bietet eine gleichwertige Sicherheit wie RSA mit deutlich kleineren Schlüsselgrößen, was sie zur bevorzugten Wahl für moderne Systeme macht. Ein 256-Bit-ECC-Schlüssel bietet ungefähr die gleiche Sicherheit wie ein 3072-Bit-RSA-Schlüssel.

Statt Primfaktorisierung stützt sich ECC auf das diskrete Logarithmusproblem auf elliptischen Kurven: Gegeben ein Startpunkt G auf einer Kurve und das Ergebnis Q = k×G, ist das Finden von k rechnerisch nicht praktikabel. Der private Schlüssel ist der Skalar k; der öffentliche Schlüssel ist der Punkt Q.

ECDSA (Elliptic Curve Digital Signature Algorithm) wird zum Signieren verwendet — damit werden Bitcoin-Transaktionen, TLS 1.3-Handshakes und Code-Signing-Zertifikate gesichert. ECDH (Elliptic Curve Diffie-Hellman) wird für den Schlüsselaustausch verwendet. Die gebräuchlichsten Kurven sind P-256 (NIST), P-384 und Curve25519 (bevorzugt wegen seiner Resistenz gegen Implementierungsfehler und potenzielle Backdoors in NIST-Kurven).

Digitale Signaturen: Authentizität beweisen

Asymmetrische Kryptografie verschlüsselt nicht nur — sie ermöglicht digitale Signaturen:

1. Der Absender berechnet einen Hash der Nachricht (z. B. SHA-256)
2. Der Absender verschlüsselt den Hash mit seinem privaten Schlüssel — das ist die Signatur
3. Der Empfänger entschlüsselt die Signatur mit dem öffentlichen Schlüssel des Absenders, um den Hash wiederherzustellen
4. Der Empfänger hasht die Nachricht unabhängig und vergleicht — wenn sie übereinstimmen, ist die Nachricht authentisch und unverändert

Digitale Signaturen bieten Authentifizierung (nur der Inhaber des privaten Schlüssels konnte es signiert haben) und Integrität (jede Änderung der Nachricht ändert den Hash). Sie bilden die Grundlage für TLS-Zertifikate, Code-Signing und E-Mail-Authentifizierung (S/MIME, DKIM).

PGP und das Web of Trust

PGP (Pretty Good Privacy) und seine Open-Source-Implementierung GPG wenden Public-Key-Kryptografie auf E-Mail- und Dateiverschlüsselung an. Der Workflow:

• Schlüsselpaar generieren: gpg --full-generate-key
• Öffentlichen Schlüssel exportieren und teilen: gpg --export --armor du@example.com
• Schlüssel eines Kontakts importieren: gpg --import ihr_schluessel.asc
• Datei verschlüsseln: gpg --encrypt --recipient sie@example.com geheim.txt
• Nachricht signieren: gpg --sign --armor nachricht.txt

PGP verwendet ein Web of Trust-Modell: Statt auf zentrale Zertifizierungsstellen (CAs) zu vertrauen, signieren Benutzer gegenseitig ihre Schlüssel, um für deren Authentizität zu bürgen. Wenn Alice Bob vertraut und Bob Carols Schlüssel signiert hat, kann Alice Carol etwas Vertrauen entgegenbringen. Dieses dezentralisierte Modell steht im Gegensatz zum hierarchischen CA-Modell, das in TLS verwendet wird.

Zertifizierungsstellen und das TLS-Vertrauensmodell

Wenn dein Browser sich mit https://bank.de verbindet, verifiziert er die Identität des Servers anhand eines TLS-Zertifikats — ein Dokument, das den öffentlichen Schlüssel des Servers enthält und von einer vertrauenswürdigen Zertifizierungsstelle signiert ist. Dein Betriebssystem und Browser sind mit ~100–150 vertrauenswürdigen Root-CAs vorinstalliert. Die Vertrauenskette: Root-CA → Zwischeninstanz-CA → Server-Zertifikat.

Dieses zentralisierte Modell hat eine bekannte Schwäche: Jede vertrauenswürdige CA kann ein Zertifikat für jede Domain signieren. Abhilfemaßnahmen umfassen Certificate Transparency (alle ausgestellten Zertifikate müssen öffentlich protokolliert werden), CAA-DNS-Einträge (schränken ein, welche CAs Zertifikate für deine Domain ausstellen dürfen) und HPKP (jetzt zugunsten von CT veraltet).

Forward Secrecy

Traditjoneller RSA-Schlüsselaustausch hat einen kritischen Fehler: Wenn ein Angreifer heute verschlüsselten Datenverkehr aufzeichnet und später den privaten Schlüssel des Servers erhält, kann er alle zuvor aufgezeichneten Sitzungen entschlüsseln. Perfect Forward Secrecy (PFS) löst dies durch die Verwendung ephemerer Diffie-Hellman- oder ECDH-Schlüssel für jede Sitzung — der Sitzungsschlüssel berührt nie die Festplatte und wird nach der Verwendung verworfen. TLS 1.3 schreibt PFS vor. Wenn du die TLS-Konfiguration eines Servers prüfst, verifiziere, dass nur ECDHE- oder DHE-Cipher-Suites aktiviert sind, nicht der statische RSA-Schlüsselaustausch.