Wie Public-Key-Kryptographie tatsächlich funktioniert
Eine praktische Einführung in asymmetrische Verschlüsselung, Schlüsselpaare und digitale Signaturen, ohne oberflächliche mathematische Analogien.
Jedes Mal, wenn du dich per SSH auf einen Server einloggst oder eine HTTPS-Seite lädst, verrichten zwei mathematisch verknüpfte Schlüssel die schwere Arbeit. Einer ist öffentlich, einer privat, und die Beziehung zwischen ihnen macht sichere Kommunikation über ein unvertrauenswürdiges Netzwerk überhaupt erst möglich.
Die Grundidee
Bei der symmetrischen Verschlüsselung sperrt und entsperrt ein Schlüssel die Daten. Das funktioniert gut, wenn beide Parteien bereits ein Geheimnis teilen, aber dieses Geheimnis sicher zu verteilen ist der schwierige Teil. Public-Key-(asymmetrische) Kryptographie löst das, indem sie ein mathematisch verknüpftes Paar erzeugt: einen öffentlichen Schlüssel, den du an jeden weitergibst, und einen privaten Schlüssel, den du nie teilst.
Daten, die mit dem öffentlichen Schlüssel verschlüsselt sind, können nur mit dem entsprechenden privaten Schlüssel entschlüsselt werden. Daten, die mit dem privaten Schlüssel signiert sind, können von jedem überprüft werden, der den öffentlichen Schlüssel hat. Diese beiden Eigenschaften decken fast alles ab, wofür wir das einsetzen: Vertraulichkeit und Authentifizierung.
RSA, das klassische Beispiel
RSA verlässt sich darauf, dass die Multiplikation zweier großer Primzahlen schnell ist, aber deren Produkt in diese Primzahlen zurückzufaktorisieren rechnerisch brutal ist. Ein 2048-Bit-RSA-Schlüssel wird aus zwei Primzahlen von je etwa 1024 Bits aufgebaut. Der öffentliche Schlüssel ist (n, e) — n ist das Produkt der Primzahlen, e ein fester Exponent wie 65537. Der private Schlüssel wird mit der Totient von n hergeleitet und setzt die Kenntnis der ursprünglichen Primzahlen voraus.
Verschlüsselung ist modulare Exponentiation: c = m^e mod n. Entschlüsselung kehrt das mit dem privaten Exponenten d um: m = c^d mod n. In der Praxis verschlüsselt niemand wirklich große Datenmengen direkt mit RSA — das ist langsam und hat Größenlimits, die an die Schlüssellänge gebunden sind. Stattdessen verpackt RSA typischerweise einen symmetrischen Sitzungsschlüssel (wie AES-256), und die symmetrische Verschlüsselung handhabt die Datenmengen. Das ist der Hybrid-Ansatz, den TLS nutzt.
Elliptische-Kurven-Kryptographie und warum sie die Kontrolle übernimmt
ECC gibt dir RSA-äquivalente Sicherheit mit viel kleineren Schlüsseln. Ein 256-Bit-ECC-Schlüssel (wie curve secp256r1 oder Curve25519) ist etwa gleich stark wie ein 3072-Bit-RSA-Schlüssel. Kleinere Schlüssel bedeuten schnellere Handshakes und weniger Bandbreite, deshalb setzen moderne TLS-Konfigurationen, SSH-Implementierungen und Signals Protokoll auf ECC.
Die Mathematik ist anders — sie basiert auf dem diskreten Logarithmus-Problem über Punkte auf einer elliptischen Kurve statt auf Ganzzahl-Faktorisierung — aber die Public-Key-Private-Key-Beziehung und die Garantien sind konzeptionell identisch.
Digitale Signaturen: die andere Hälfte der Gleichung
Verschlüsselung hält Daten vertraulich. Signaturen beweisen Authentizität und Integrität. Um eine Nachricht zu signieren, hashst du sie (typischerweise SHA-256) und verschlüsselst diesen Hash mit deinem privaten Schlüssel. Jeder mit deinem öffentlichen Schlüssel kann die Nachricht selbst hashen, deine Signatur entschlüsseln und die beiden Hashes abgleichen.
Genau das passiert, wenn du git commit -S mit einem GPG-Schlüssel ausführst, oder wenn eine Certificate Authority ein TLS-Zertifikat signiert. Der private Schlüssel der CA signiert dein Zertifikat; Browser werden mit dem öffentlichen Schlüssel der CA vorinstalliert geliefert, daher können sie die Authentizität deines Zertifikats überprüfen, ohne je direkt mit der CA zu sprechen.
Wo das im Alltag auftaucht
SSH-Schlüsselauthentifizierung ist eine direkte Anwendung: ssh-keygen -t ed25519 erzeugt ein Schlüsselpaar, du legst die öffentliche Hälfte in ~/.ssh/authorized_keys auf dem Server ab, und Authentifizierung geschieht durch einen Challenge-Response mit dem privaten Schlüssel, nie ein Passwort übertragen.
TLS-Handshakes nutzen asymmetrische Kryptographie kurz, nur um einen gemeinsamen symmetrischen Schlüssel zu etablieren (via ECDHE-Schlüsselaustausch in modernen Setups), dann wechseln sie zur schnellen symmetrischen Verschlüsselung für die eigentliche Sitzung. PGP/GPG-E-Mail-Verschlüsselung folgt auch dem Hybrid-Muster — verschlüssele die Nachricht mit einem zufälligen AES-Schlüssel, dann verschlüssele diesen AES-Schlüssel mit dem RSA- oder ECC-Schlüssel des Empfängers.
Was in der Praxis tatsächlich kaputtgeht
Die Mathematik hinter RSA und ECC wurde nicht durch klassisches Computing gebrochen. Was schiefgeht, ist fast immer Implementierung: schwache Zufallszahlengenerierung beim Erstellen von Schlüsseln (der Debian-OpenSSL-Bug von 2008 ist das Lehrbuchbeispiel), wiederverwendete Nonces in ECDSA-Signaturen, die private Schlüssel offenlegen, oder Padding-Oracle-Angriffe gegen schlecht implementiertes RSA (Bleichenbacher's Angriff gegen PKCS#1 v1.5-Padding). Quantencomputer ist die langfristige theoretische Bedrohung — Shors Algorithmus würde sowohl RSA als auch ECC brechen, wenn ein ausreichend großer Quantencomputer existierte — deshalb hat NIST bereits Post-Quanten-Algorithmen wie ML-KEM (ehemals Kyber) für zukünftige Migration standardisiert.
Wenn du das vertiefen möchtest, deckt Korra Studio's Kryptographie-Track Schlüsselaustausch-Protokolle und Hash-Funktion-Interna ausführlicher ab, und die Netzwerk-Segmente erklären, wie das alles in einen echten TLS-Handshake Byte für Byte passt.
Mit KI-Unterstützung geschrieben, von Michal Pilch (CISSP), Korra Studio, überprüft und veröffentlicht.
Das ist eine Notiz aus der Korra-Studio-Wissensdatenbank — die Plattform verbindet jedes Thema mit 1-zu-1-Mentoring.
Kostenlos startenarrow_forward