Symmetrisch ist schnell, asymmetrisch löst das Schlüsselproblem – aber keines von beiden allein reicht für die Praxis. Die Lösung: Kombiniert beides. Ihr begegnet hybrider Verschlüsselung bei jedem HTTPS-Aufruf, jeder SSH-Verbindung und jeder GPG-verschlüsselten E-Mail – auch wenn ihr es selten so nennt.

Nach diesem Block könnt ihr:

• erklären, warum weder symmetrische noch asymmetrische Verschlüsselung allein ausreicht
• das Prinzip hybrider Verschlüsselung beschreiben (asymmetrisch für Session Key, symmetrisch für Daten)
• erklären, warum für jede Verbindung ein frischer Session Key generiert wird (Perfect Forward Secrecy)
• Protokolle benennen, die hybride Verschlüsselung nutzen (TLS, SSH, PGP, Signal)
• eine hybride Verschlüsselung mit OpenSSL praktisch durchführen

Das Problem, das es löst

Stellt euch vor, ihr wollt eine große Datei sicher an jemanden schicken, den ihr noch nie getroffen habt.

Option 1 – nur symmetrisch: AES verschlüsselt die Datei blitzschnell. Aber wie bekommt der Empfänger den Schlüssel, ohne dass ein Angreifer ihn abfängt? Das ist das Schlüsseltauschproblem aus Block 02 – ungelöst.

Option 2 – nur asymmetrisch: RSA löst das Schlüsselproblem elegant. Aber RSA kann keine großen Datenmengen direkt verarbeiten – es ist 100- bis 1000-mal langsamer als AES und für Dateien ab einigen Kilobytes schlicht unpraktisch.

Die Antwort ist eleganter als sie klingt: Ihr verschlüsselt die Datei nicht mit RSA. Ihr nutzt RSA nur dafür, einen einzigen, zufällig generierten AES-Schlüssel zu verschlüsseln – den Session Key. Der Session Key ist winzig (256 Bit), RSA kann das problemlos verarbeiten. Die eigentliche Datei verschlüsselt ihr dann mit diesem Session Key über AES – schnell, effizient, für beliebig große Daten.

Das Beste aus beiden Welten

Sender                                                 Empfänger
  │                                                        │
  │  1. Zufälligen Session-Key (symmetrisch) generieren    │
  │     z.B. AES-256-Schlüssel                             │
  │                                                        │
  │  2. Nutzdaten mit Session-Key verschlüsseln (schnell!) │
  │     Klartext + Session-Key → Geheimtext                │
  │                                                        │
  │  3. Session-Key mit Public Key des Empfängers          │
  │     verschlüsseln (klein, also RSA geeignet)           │
  │     Session-Key + Public Key → Verschl. Session-Key    │
  │                                                        │
  │     Geheimtext + verschlüsselter Session-Key ─────────►│
  │                                                        │
  │                         4. Session-Key mit Private Key │
  │                            entschlüsseln               │
  │                                                        │
  │                         5. Geheimtext mit Session-Key  │
  │                            entschlüsseln → Klartext    │

Was beim Empfänger ankommt: zwei Dinge – der verschlüsselte Geheimtext und der verschlüsselte Session Key. Mit seinem Private Key entschlüsselt er zuerst den Session Key, damit dann den Geheimtext. Ein Angreifer, der beides abfängt, hat nichts: Er kann weder den Session Key entschlüsseln (kein Private Key) noch die Daten lesen (kein Session Key).

Warum ein frischer Session Key pro Verbindung?

In modernen Protokollen wie TLS wird für jede Verbindung ein neuer, zufälliger Session Key generiert – er gilt nur für diese eine Session und wird danach verworfen. Das ist kein Zufall.

Stellt euch vor, ein Angreifer zeichnet monatelang verschlüsselten Traffic auf und stiehlt später den Private Key des Servers. Mit einem statischen, wiederverwendeten Session Key könnte er rückwirkend alles entschlüsseln. Mit einem frischen Session Key pro Session: unmöglich – die alten Keys existieren schlicht nicht mehr.

Das nennt sich Perfect Forward Secrecy (PFS). Block 08 zeigt, wie das in HTTPS konkret umgesetzt ist.

Wo hybride Verschlüsselung eingesetzt wird

• TLS/HTTPS: ECDHE handelt den Session Key aus, AES-GCM verschlüsselt die Daten
• SSH: Diffie-Hellman für den Schlüsselaustausch, symmetrisch für die Verbindung
• PGP / GPG: Zufälliger Session Key pro Nachricht, mit dem Public Key des Empfängers verschlüsselt
• Signal-Protokoll: Verfeinerte hybride Verschlüsselung mit ständig wechselnden Keys (Double Ratchet)

Merke: Hybride Verschlüsselung ist keine Kompromisslösung – sie ist die Standardlösung der modernen Kryptografie. Asymmetrisch für den Schlüsselaustausch, symmetrisch für die Daten. Wenn jemand fragt, wie HTTPS funktioniert: Das hier ist die Kernidee. Kein modernes Protokoll verwendet ausschließlich RSA oder ECC für Massendaten.

Praktisches Beispiel: Hybrid mit OpenSSL

# Schritt 1: Zufälligen symmetrischen Schlüssel generieren
openssl rand -base64 32 > session_key.bin    # 256 Bit zufälliger Schlüssel

# Schritt 2: Datei mit Session-Key verschlüsseln
openssl enc -aes-256-cbc -in geheime_datei.txt -out verschluesselt.enc \
    -pass file:session_key.bin -pbkdf2

# Schritt 3: Session-Key mit RSA Public Key verschlüsseln
openssl pkeyutl -encrypt -inkey public.pem -pubin \
    -in session_key.bin -out session_key.enc

# Senden: verschluesselt.enc + session_key.enc
# (session_key.bin und geheime_datei.txt lokal löschen!)

# ── Auf Empfängerseite ──

# Schritt 4: Session-Key mit Private Key entschlüsseln
openssl pkeyutl -decrypt -inkey private.pem \
    -in session_key.enc -out session_key_decrypted.bin

# Schritt 5: Datei mit Session-Key entschlüsseln
openssl enc -d -aes-256-cbc -in verschluesselt.enc -out entschluesselt.txt \
    -pass file:session_key_decrypted.bin -pbkdf2

Probiert es selbst:

1. Erstellt ein RSA-Schlüsselpaar (falls nicht vorhanden): openssl genrsa -out private.pem 4096 und openssl rsa -in private.pem -pubout -out public.pem
2. Erstellt eine Testdatei: echo "Streng geheime Projektdaten" > geheim.txt
3. Führt die hybride Verschlüsselung Schritt für Schritt durch (alle Befehle aus dem Block oben)
4. Löscht danach session_key.bin und geheim.txt – könnt ihr die Daten nur mit verschluesselt.enc und session_key.enc wiederherstellen? Probiert es mit dem Private Key.
5. Diskutiert: Warum ist es wichtig, den Session Key nach der Übertragung zu löschen?

Zusammenfassung

• Hybride Verschlüsselung kombiniert das Beste aus beiden Welten: asymmetrisch für den Schlüsselaustausch, symmetrisch für die Daten
• Ein zufälliger Session Key wird pro Verbindung generiert, mit dem Public Key des Empfängers verschlüsselt und nach der Session gelöscht
• Perfect Forward Secrecy: Frische Session Keys pro Verbindung verhindern, dass kompromittierte Server-Keys vergangenen Traffic entschlüsseln
• Hybride Verschlüsselung ist keine Kompromisslösung – sie ist die Standardlösung in TLS, SSH, PGP und Signal

Selbsttest

1. Warum verschlüsselt man die eigentlichen Daten nicht direkt mit RSA?
2. Was passiert, wenn für alle Verbindungen derselbe Session Key verwendet wird – und warum ist das ein Problem?
3. Erklärt in zwei Sätzen, wie HTTPS hybride Verschlüsselung nutzt.

Wie geht es weiter?

Jetzt wisst ihr, wie Verschlüsselung in der Praxis funktioniert. Aber woher weiß der Browser, dass der Public Key wirklich zu bank.de gehört? Block 06 erklärt Zertifikate und die Public Key Infrastructure – das Vertrauenssystem, das asymmetrische Kryptografie erst nutzbar macht.