← Startseite
🔐

Vorlesung 9

Sicherheit II — Verschlüsselung
Wie schickt man ein Geheimnis durch ein offenes Netz?

Fortgeschrittene Algorithmen und Programmierung
Prof. Dr. Alexandra Mikityuk
HTW Berlin

Caesar & XOR AES Public Key

Lernziele

  • Den Unterschied zwischen Hashing (letzte Woche) und Verschlüsselung (heute) sauber erklären können
  • Mit Caesar und XOR selbst ver- und entschlüsseln — auf Papier und in C
  • Verstehen, warum es symmetrische und asymmetrische Verschlüsselung gibt — und wann man welche nimmt
  • Begreifen, wie HTTPS beides kombiniert — und was das Schloss 🔒 im Browser bedeutet
  • Die goldene Regel verinnerlichen: „Don't roll your own crypto."

Unsere Reise heute — die Landkarte

Wir starten ganz einfach (von Hand rechenbar) und arbeiten uns Stück für Stück bis zu dem vor, was euer Browser gerade jetzt benutzt. Jeder Schritt repariert ein Problem des vorigen.

1️⃣ Caesar 2️⃣ XOR 3️⃣ AES
(symmetrisch)
4️⃣ Schlüssel-
problem
5️⃣ RSA
(asymmetrisch)
6️⃣ HTTPS 🔒
(beides)

🧮 Erst von Hand

Caesar und XOR rechnen wir mit Bleistift mit — so fühlt man, was Verschlüsseln eigentlich ist.

⚙️ Dann in C

Jede Idee schreiben wir kurz in C — und sehen, wo die einfachen Versionen scheitern.

🌍 Zuletzt: die echte Welt

AES, RSA und HTTPS — das, was Banken, WhatsApp und euer Browser wirklich nutzen.

Rückblick: letzte Woche haben wir etwas kaputt gemacht — mit Absicht

Hashing war eine Einbahnstraße: Passwort rein → Hash raus → nie wieder zurück. Genau das wollten wir.

"sommer2024"
Hash
5e88489...
⊗ kein Weg zurück
Aber heute ist alles anders: manchmal wollen wir die Daten wieder zurück! Eine WhatsApp-Nachricht, eine E-Mail, eine Kreditkartennummer — die soll der Empfänger ja lesen können. Ein Hash würde hier nichts nützen.
Heute lernen wir den Gegenspieler: Verschlüsselung — eine Straße, die in beide Richtungen führt. Geheim hin, lesbar zurück. Aber nur mit dem richtigen Schlüssel.

Stell dir vor: das Internet ist eine Postkarte

Deine Nachricht reist über viele fremde Stationen: WLAN-Router, Provider, Server. Jede kann mitlesen.

📱 Du
📡 WLAN
🌐 Provider
🖥️ Server
👤 Empfänger

📮 Ohne Verschlüsselung = Postkarte

Jeder Briefträger, jede Poststelle kann lesen: „Treffen um 18 Uhr, PIN ist 4321." Im Netz heißt das: jeder Hotspot-Betreiber im Café liest mit.

✉️ Mit Verschlüsselung = versiegelter Brief

Unterwegs sieht jeder nur Zeichensalat. Öffnen kann den Brief nur, wer den passenden Schlüssel hat — der Empfänger.

Heute bauen wir den versiegelten Brief — von der ganz einfachen Version (Caesar) bis zu der, die euer Browser gerade jetzt benutzt (HTTPS).

Der wichtigste Unterschied der ganzen Vorlesung

Hashing und Verschlüsselung werden ständig verwechselt. Merkt euch diesen einen Unterschied:

🔒 Hashing (VL 8)

Einbahnstraße. Kein Schlüssel. Man kommt nie zurück.

Zweck: prüfen, ob etwas gleich ist (Passwörter), ohne es zu speichern.

Text Hash

🔁 Verschlüsselung (heute)

Hin- und Rückweg. Mit Schlüssel kommt man wieder zurück.

Zweck: etwas geheim transportieren und beim Empfänger wieder lesbar machen.

Text Geheim
Eselsbrücke: Hash = Reißwolf (zerstört, kommt nie zurück). Verschlüsselung = Safe (zu und wieder auf — wenn du den Schlüssel hast).

Was ist Verschlüsselung? — die vier Wörter

Verschlüsselung ist ein Safe: du legst den Klartext rein, schließt mit dem Schlüssel ab — und nur mit demselben (oder einem passenden) Schlüssel kommst du wieder ran.

Klartext
"Hallo Bob"
🔑 verschlüsseln
Geheimtext
"Kdoor Ere"
🔑 entschlüsseln
Klartext
"Hallo Bob"
DeutschEnglischWas ist es?
KlartextPlaintextDie lesbare Original-Nachricht
GeheimtextCiphertextDer verschlüsselte Zeichensalat
SchlüsselKeyDas Geheimnis, mit dem ab- und aufgeschlossen wird
AlgorithmusCipherDas Rezept, wie ver-/entschlüsselt wird (z. B. Caesar, AES)
Wichtig: der Algorithmus ist meist öffentlich bekannt (jeder weiß, wie Caesar oder AES funktioniert). Geheim ist nur der Schlüssel. Das nennt man Kerckhoffs' Prinzip — die Sicherheit darf nicht davon abhängen, dass der Algorithmus geheim ist.

Die älteste Idee: die Caesar-Verschlüsselung

Schon Julius Caesar hat sie benutzt: jeden Buchstaben um eine feste Zahl im Alphabet weiterschieben. Der Schlüssel ist diese Zahl.

🔁 Schlüssel = Verschiebung um 3

Klartext:    A  B  C  D  E ... H ... L ... O ... X  Y  Z
                              ↓  ↓  ↓  ↓  ↓     ↓     ↓     ↓     ↓  ↓  ↓  (+3)
Geheimtext:  D  E  F  G  H ... K ... O ... R ... A  B  C   (X Y Z wickeln um!)
Beispiel:
"HALLO"  →  H+3=K   A+3=D   L+3=O   L+3=O   O+3=R"KDOOR"
Entschlüsseln = das Gegenteil: einfach um 3 zurück schieben. "KDOOR" → K−3=H, D−3=A, … → "HALLO". Derselbe Schlüssel (3), andere Richtung.

🤔 Halt — wie würden WIR das in C umsetzen?

„Einen Buchstaben um 3 weiterschieben" — klingt nach Alphabet-Tabelle. Aber erinnert ihr euch an den Trick aus VL 8?

💭 Auffrischung aus der letzten Woche:

In C ist char in Wahrheit eine kleine Zahl (ASCII). 'A' = 65, 'B' = 66

🤔 Denkfrage 1

Wenn 'A' die Zahl 65 ist — was passiert dann wohl bei 'A' + 3?

💭 Denkfrage 2

Und was tun wir bei 'Z' + 3? Da gibt es kein „Ä, Å, Æ" — wir müssen wieder bei 'A' anfangen. Wie?

Tipp: „wieder von vorn anfangen, wenn man über das Ende läuft" — genau dafür hatten wir letzte Woche schon ein Werkzeug: Modulo (%).

Kurzer Einschub: Modulo (%) ist ein Zifferblatt

Bevor wir Caesar in C schreiben: % gibt den Rest beim Teilen. Am einfachsten merkt man sich das als Uhr — die zählt auch immer im Kreis.

🕐 Die ganz normale Uhr = % 12

0 1 2 3 4 5 6 7 8 9 10 11

Nach der 11 kommt wieder 0 — die Uhr „springt zurück". Genau das macht % 12.

🔢 In Zahlen

 0 % 12 = 0      // Mitternacht
 5 % 12 = 5
11 % 12 = 11
12 % 12 = 0     // zurück auf 0!
13 % 12 = 1     // 13 Uhr = 1 Uhr
25 % 12 = 1     // 1 Tag + 1 Stunde

Egal wie groß die Zahl wird — das Ergebnis bleibt im Kreis 0…11. Bei % 12 sind das die 12 Stunden, bei % 26 die 26 Buchstaben.

Für Caesar: stellt euch eine Uhr mit 26 Zahlen vor (A=0 … Z=25). Verschieben = den Zeiger weiterdrehen. Läuft er über die Z hinaus, kommt automatisch wieder die A — das ist % 26. Z. B. X(23)+3 = 26 → 26 % 26 = 0 → A.
Achtung beim Rückwärtsdrehen (Entschlüsseln): über die A hinaus zurück landet man bei Z. In C wird daraus eine negative Zahl — und negatives Modulo verhält sich anders. Deshalb drehen wir lieber vorwärts weiter (Schlüssel 23 statt −3).

Tiefer gedacht: Rest ist nicht ganz dasselbe wie Modulo

Bei positiven Zahlen merkt man keinen Unterschied. Bei negativen schon — und dann versteht man erst, was Modulo wirklich ist.

Der Stolperstein: -3 % 26 ist in C gleich -3, in Python aber 23. Wer hat recht? Beide — sie wählen nur eine andere Antwort aus derselben Familie.

Die Idee: −3 und 23 sind auf der 26er-Uhr dieselbe Position

−55 −29 −3 23 49 75

Jeder Schritt ist +26 (einmal ganz um die Uhr). Alle diese Zahlen landen auf demselben Punkt — sie sind „gleich modulo 26": −3 ≡ 23 (mod 26), weil 23 − (−3) = 26.

🖥️ Rest — was C's % macht

C löst diese Gleichung auf (Division wird Richtung 0 abgeschnitten):

a == (a / b) * b + (a % b)

-3 / 26 = 0   // zu 0 hin gerundet
-3 % 26 = -3  // damit Gleichung stimmt

Das Vorzeichen folgt dem Dividenden (links). Negativ rein → negativ raus.

📐 Modulo — die mathematische Idee

Modulo teilt alle ganzen Zahlen in 26 Familien (Klassen) ein:

[0]  = …,-52,-26, 0, 26, 52,…
[23] = …,-29, -3,23, 49, 75,…

Modulo fragt nicht „welcher Rest?", sondern „welche Familie?". Es wählt dann den einen Vertreter 0…25 — deshalb 23.

Kernsatz: der Rest ist nur eine bequeme Art, aus jeder Modulo-Familie einen Vertreter zu picken. C pickt den mit dem Vorzeichen der Division, Python & die Mathematik picken immer 0…25. Für Caesar wollen wir 0…25 — deshalb beim Rückwärtsrechnen in C + 26 (oder gleich vorwärts mit Schlüssel 23).

Caesar in C — überraschend kurz

Wir rechnen mit den ASCII-Werten. Der Trick: relativ zu 'A' rechnen, um 3 schieben, mit % 26 umwickeln.

#include <stdio.h>
#include <string.h>

void caesar(char text[], int schluessel) {
    for (int i = 0; text[i] != '\0'; i++) {
        char c = text[i];
        // nur Großbuchstaben A-Z verschieben
        if (c >= 'A' && c <= 'Z') {
            int pos = c - 'A';              // Buchstabe → 0..25  (A=0, B=1, …)
            pos = (pos + schluessel) % 26;   // schieben und bei Z umwickeln
            text[i] = pos + 'A';           // 0..25 → ASCII-Buchstabe zurück
        }
    }
}

int main(void) {
    char nachricht[] = "HALLO";
    caesar(nachricht, 3);    printf("%s\n", nachricht);  // → KDOOR
    caesar(nachricht, 23);   printf("%s\n", nachricht);  // → HALLO (23 = -3 zurück)
    return 0;
}
Der Modulo-Trick im Detail (für 'Z', Schlüssel 3): 'Z'-'A' = 25 → 25+3 = 2828 % 26 = 22 + 'A' = 'C'. Z wird also zu C — sauber umgewickelt, kein „Ä".
Entschlüsseln ohne Minus: statt „−3" nehmen wir „+23" (denn 3 + 23 = 26 = einmal ganz herum). So vermeiden wir negative Zahlen beim Modulo. Schlüssel 3 zum Ver-, Schlüssel 23 zum Entschlüsseln.

Selbst rechnen — Caesar mit Bleistift

Nehmt euch 30 Sekunden. Wir verschlüsseln und entschlüsseln — und sehen, dass wir genau dort wieder rauskommen, wo wir gestartet sind.

🔒 Verschlüsseln: "KATZE", Schlüssel 4

K (+4) → O
A (+4) → E
T (+4) → X
Z (+4) → D   // 25+4=29, %26=3 → D
E (+4) → I

"KATZE" → "OEXDI"

🔓 Entschlüsseln: "OEXDI", Schlüssel 4 zurück

O (−4) → K
E (−4) → A
X (−4) → T
D (−4) → Z   // wickelt zurück
I (−4) → E

"OEXDI" → "KATZE"

⚠️ Warum Caesar nichts taugt

Caesar hat ein fatales Problem: es gibt nur 25 mögliche Schlüssel. Ein Computer probiert die alle in Mikrosekunden durch.

🔨 Brute Force: alle 25 probieren

Geheimtext: "KDOOR"
+1 → JCNNQ   +2 → IBMMP
+3 → HALLO ← ergibt Sinn!
+4 → GZKKN   +5 → FYJJM ...

Der Mensch erkennt sofort, welche Zeile sinnvolles Deutsch ist. Spätestens nach 25 Versuchen ist Schluss.

📊 Sogar ohne Probieren: Häufigkeitsanalyse

Im Deutschen ist E der häufigste Buchstabe. Der häufigste Buchstabe im Geheimtext ist also vermutlich ein verschobenes E → Schlüssel verraten.

Caesar verschiebt alle Buchstaben gleich → das Muster der Sprache bleibt sichtbar.

Die Lektion: ein guter Algorithmus braucht einen riesigen Schlüsselraum (zu viele Schlüssel zum Durchprobieren) und darf keine Muster der Sprache durchscheinen lassen. Caesar versagt bei beidem. Wir brauchen etwas Besseres.

Das Lieblingswerkzeug der Krypto: XOR

XOR („exklusives Oder") vergleicht zwei Bits. Ergebnis ist 1, wenn sie verschieden sind, sonst 0. In C ist das der Operator ^.

📋 Die XOR-Tabelle

ABA ^ B
000
011
101
110

Gleich → 0, verschieden → 1. Das ist die ganze Regel.

Die magische Eigenschaft

Wendet man XOR mit demselben Schlüssel zweimal an, ist man wieder am Anfang:

Daten ^ Key ^ Key = Daten

Genau das brauchen wir! Einmal XOR = verschlüsseln. Nochmal dasselbe XOR = entschlüsseln. Ver- und Entschlüsseln sind dieselbe Operation.

Warum ist das so genial? Wir brauchen nur eine Funktion statt zwei. Und der Schlüssel kann eine beliebige Bitfolge sein — kein „nur 25 Möglichkeiten"-Problem wie bei Caesar.

Selbst rechnen — XOR Bit für Bit

Wir verschlüsseln den Buchstaben 'H' (ASCII 72 = 01001000) mit dem Schlüsselbyte 75 (01001011).

🔒 Verschlüsseln: 'H' ^ Key

  H    01001000   (72)
  Key  01001011   (75)
  XOR  --------
       00000011   (3)

// Geheimtext-Byte = 3

🔓 Entschlüsseln: Geheim ^ Key

       00000011   (3)
  Key  01001011   (75)
  XOR  --------
       01001000   (72 = 'H') ✓

// gleicher Key → 'H' zurück!
Spalte für Spalte vergleichen: bei jedem Bit fragt ihr nur „sind die zwei gleich?" → 0, „verschieden?" → 1. Macht das zweimal mit demselben Key, landet ihr bitgenau wieder beim Original. Das ist die XOR-Magie aus der vorigen Slide — jetzt von Hand bewiesen.

XOR-Verschlüsselung in C — eine Funktion für beides

Weil Ver- und Entschlüsseln dasselbe sind, brauchen wir nur eine Funktion. Wir XOR-en jedes Byte mit einem (sich wiederholenden) Schlüssel.

#include <stdio.h>
#include <string.h>

// XOR-t jedes Zeichen mit dem Schlüssel (der sich wiederholt)
void xor_crypt(char text[], int len, char key[], int keylen) {
    for (int i = 0; i < len; i++) {
        text[i] = text[i] ^ key[i % keylen];   // ^ ist XOR, % wiederholt den Key
    }
}

int main(void) {
    char nachricht[] = "Geheim";
    char key[]       = "K";

    xor_crypt(nachricht, strlen(nachricht), key, 1);  // → Zeichensalat
    xor_crypt(nachricht, strlen(nachricht), key, 1);  // → "Geheim" zurück!

    printf("%s\n", nachricht);
    return 0;
}
Zweimal aufrufen = wieder am Start. Beim ersten Aufruf wird verschlüsselt, beim zweiten (gleicher Key!) entschlüsselt. Das ist die XOR-Eigenschaft Daten ^ Key ^ Key = Daten direkt in Code.
Neu hier: i % keylen — ist der Schlüssel kürzer als der Text, fangen wir vorne im Schlüssel wieder an. Bei einem 1-Zeichen-Key wird jedes Byte mit demselben Zeichen ge-XOR-t. Genau das ist auch das Problem — siehe nächste Slide.

Warum auch unser XOR (noch) schwach ist

Ein kurzer, sich wiederholender Schlüssel hinterlässt Muster — wie bei Caesar. Aber XOR steckt eine geniale Idee in sich.

Kurzer Key wiederholt sich

Key „K" (1 Byte) auf 1000 Zeichen → das gleiche Muster 1000-mal. Mit Statistik (wie Häufigkeitsanalyse) wieder knackbar.

Auch: zwei gleiche Klartext-Bytes ergeben zwei gleiche Geheim-Bytes → Muster sichtbar.

One-Time-Pad: theoretisch perfekt

Ist der Schlüssel so lang wie die Nachricht, echt zufällig und wird nur einmal benutzt → mathematisch unknackbar. Bewiesen!

Problem: so einen Riesen-Schlüssel sicher zum Empfänger bringen ist in der Praxis unmöglich.

Die Brücke zu „echter" Verschlüsselung: moderne Algorithmen wie AES machen im Kern genau das — XOR + kräftiges Durchmischen, über viele Runden (erinnert ihr euch an „State mixen" bei SHA-256 in VL 8?). So entsteht aus einem kurzen Schlüssel ein Effekt wie bei einem riesigen Zufalls-Schlüssel.

Kurzer Zwischenstand — wo stehen wir?

Wir haben zwei eigene Verschlüsselungen gebaut. Beide funktionieren — beide sind aber zu schwach. Warum eigentlich?

1️⃣ Caesar — gelernt & verworfen

  • Idee: jeden Buchstaben um N schieben
  • ❌ Nur 25 Schlüssel → in Millisekunden durchprobiert
  • ❌ Sprach-Muster bleibt sichtbar (Häufigkeit)

2️⃣ XOR — besser, aber…

  • Idee: Bits mit Schlüssel ver-XOR-en
  • ✅ Beliebig große Schlüssel möglich, ✅ ver = entschlüsseln
  • ❌ Kurzer Key wiederholt sich → wieder Muster
Was uns fehlt: ein großer Schlüsselraum und kräftiges Durchmischen, damit keine Muster durchscheinen. Genau das liefern professionelle Algorithmen. Zeit für den echten Standard: AES.
Wichtig zu merken: wir bauen AES nicht selbst — wir haben Caesar & XOR nur gebaut, um zu verstehen, was darin steckt. Ab jetzt nutzen wir geprüfte Libraries.

AES — der heutige Standard (symmetrisch)

Symmetrisch heißt: ein Schlüssel für beide Richtungen — derselbe Schlüssel ver- und entschlüsselt. Genau wie unser XOR, nur viel stärker.

Klartext
🔑 AES
(gleicher Schlüssel)
Geheimtext
🔑 AES
(gleicher Schlüssel)
Klartext

📜 Was ist AES?

Advanced Encryption Standard, seit 2001 weltweiter Standard. Verschlüsselt in Blöcken zu je 16 Bytes.

🔑 Schlüsselgröße

128 oder 256 Bit. Bei 256 Bit gibt es 2²⁵⁶ Schlüssel — mehr als Atome im Universum. Brute Force chancenlos.

Schnell

Moderne CPUs haben AES sogar in Hardware eingebaut → Gigabytes pro Sekunde. Ideal für viele Daten.

Goldene Regel (wie bei Hashing in VL 8): AES selbst zu implementieren ist ein Minenfeld. Ihr nutzt eine geprüfte Library — ihr schreibt sie nicht. „Don't roll your own crypto."

AES in C — die richtige Library nutzen

Mit OpenSSL läuft AES über die EVP-Schnittstelle. Hier die Idee — Details im Labor. Kompilieren wie in VL 8: gcc datei.c -lcrypto.

#include <openssl/evp.h>
#include <openssl/rand.h>

// --- vereinfacht: Fehlerprüfung weggelassen, Logik im Fokus ---

unsigned char key[32];   // 32 Bytes = 256-Bit-Schlüssel
unsigned char iv[16];    // Initialisierungsvektor (Zufalls-Startwert)

RAND_bytes(key, 32);     // echter Zufall — wie das Salt in VL 8!
RAND_bytes(iv,  16);

EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();

// "Nimm AES mit 256-Bit-Schlüssel, mische die Blöcke (CBC)"
EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv);
EVP_EncryptUpdate(ctx, out, &len, klartext, klartext_len);
EVP_EncryptFinal_ex(ctx, out + len, &rest);
// 'out' enthält jetzt den Geheimtext
💡 Was ist der IV (Initialisierungsvektor)? Ein zufälliger Startwert, der dafür sorgt, dass dieselbe Nachricht mit demselben Schlüssel jedes Mal anderen Geheimtext ergibt. Genau wie das Salt beim Hashing (VL 8) verhindert er, dass Muster sichtbar werden. Er ist nicht geheim — wird neben dem Geheimtext gespeichert.
Entschlüsseln ist dasselbe in grün: EVP_DecryptInit/Update/Final mit demselben Schlüssel und IV. Symmetrisch eben — ein Schlüssel, beide Richtungen.

🤔 Das große Problem: wie tauscht man den Schlüssel?

Symmetrische Verschlüsselung ist toll — aber sie hat eine fiese Lücke. Denkt eine Minute darüber nach.

💭 Die Zwickmühle:

Anna will Bob eine verschlüsselte Nachricht schicken. Beide brauchen denselben Schlüssel. Anna würfelt einen aus — aber wie bekommt Bob ihn?

Sie kann den Schlüssel nur übers Internet schicken — genau das unsichere Netz, das doch das Problem war!

🐔🥚 Das Henne-Ei-Problem

Um den Schlüssel sicher zu schicken, bräuchte sie … einen sicheren Kanal. Aber den wollte sie ja erst herstellen. Ein Lauscher fängt den Schlüssel ab und liest alles mit.

🤔 Denkfrage

Könnte man Verschlüsselung so bauen, dass der Schlüssel zum Abschließen ein anderer ist als der zum Aufschließen? Dann könnte Anna den Abschließ-Schlüssel ruhig öffentlich verteilen …

Die geniale Lösung: zwei Schlüssel statt einem

Asymmetrische Verschlüsselung: jeder hat ein Schlüsselpaar — einen öffentlichen (darf jeder kennen) und einen privaten (streng geheim).

📬 Die Briefkasten-Analogie

Bobs Briefkasten steht auf der Straße. Der Schlitz ist öffentlich — jeder kann einen Brief einwerfen (= verschlüsseln mit Bobs öffentlichem Schlüssel).

Aber den Briefkasten aufschließen kann nur Bob — er allein hat den privaten Schlüssel.

🔑🔑 Das Schlüsselpaar

  • Öffentlicher Schlüssel 🌍 — verteilt Bob frei. Damit kann man nur abschließen.
  • Privater Schlüssel 🔒 — behält Bob für sich. Nur damit kann man aufschließen.

Was mit dem einen verschlüsselt wurde, geht nur mit dem anderen wieder auf.

Das löst das Henne-Ei-Problem: Anna braucht nur Bobs öffentlichen Schlüssel — den darf sie ruhig übers offene Netz bekommen. Selbst wenn ein Lauscher ihn kennt, kann er die Nachricht nicht entschlüsseln. Kein geheimer Schlüsseltausch nötig!

Asymmetrisch — der Ablauf, Schritt für Schritt

Anna schickt Bob eine geheime Nachricht. Achtet darauf: Annas Schlüssel kommen gar nicht vor — nur Bobs.

Anna: "Hallo Bob"
🌍 Bobs ÖFFENTLICHER
Schlüssel → verschlüsseln
Geheimtext
reist durchs Netz
↓   ein Lauscher sieht nur Geheimtext + den öffentlichen Schlüssel — nutzlos   ↓
Geheimtext
kommt bei Bob an
🔒 Bobs PRIVATER
Schlüssel → entschlüsseln
Bob liest: "Hallo Bob"
Der Knackpunkt: verschlüsselt wird mit dem öffentlichen Schlüssel des Empfängers, entschlüsselt mit dessen privatem. Wer Bob schreiben will, braucht nichts Geheimes — nur Bobs öffentlichen Schlüssel, den er offen verteilt.
Häufiger Denkfehler: Anna verschlüsselt nicht mit ihrem eigenen Schlüssel und nicht mit einem gemeinsamen — sondern mit Bobs öffentlichem. Sonst könnte Bob es nicht öffnen.

Aber warum kann man aus „öffentlich" nicht „privat" berechnen?

Die zwei Schlüssel hängen mathematisch zusammen. Der Trick: eine Richtung ist leicht, die Rückrichtung praktisch unmöglich. Eine Einwegfunktion mit Falltür.

✖️ Leicht: zwei Primzahlen malnehmen

   61 × 53 = ?

→ 3233   (in 1 Sekunde)

Multiplizieren ist kinderleicht — auch mit 300-stelligen Primzahlen.

Schwer: das Produkt zerlegen

  3233 = ? × ?

→ welche zwei Primzahlen?
  (ausprobieren … mühsam)

Bei riesigen Zahlen bräuchten alle Computer der Welt länger als das Alter des Universums.

Das ist RSA (Rivest–Shamir–Adleman, 1977): der öffentliche Schlüssel basiert auf dem Produkt, der private auf den Primfaktoren. Erinnert ihr euch an Komplexität aus VL 5? Multiplizieren ist „leicht" (O(n²)), Faktorisieren ist „brutal teuer" — und genau diese Asymmetrie der Laufzeit macht die ganze Sache sicher. Auch Primzahlen treffen wir wieder (wie das ×31 in VL 8).

Symmetrisch vs. Asymmetrisch — wann was?

Beide haben Stärken und Schwächen. Die spannende Frage: kann man nicht beide kombinieren?

Symmetrisch (AES)Asymmetrisch (RSA)
Schlüssel1 gemeinsamer2 (öffentlich + privat)
Geschwindigkeit⚡ sehr schnell🐢 ~1000× langsamer
Schlüsseltausch❌ das große Problem✅ gelöst
Gut fürgroße DatenmengenSchlüssel sicher austauschen
Seht ihr das Muster? Asymmetrisch löst genau das Problem, das symmetrisch hat (Schlüsseltausch) — ist aber zu langsam für viele Daten. Symmetrisch ist schnell — kann aber den Schlüssel nicht sicher verteilen. Sie ergänzen sich perfekt.

Das Beste aus beiden Welten: HTTPS

Euer Browser macht das gerade jetzt. Der Trick: asymmetrisch nur, um einmal einen symmetrischen Schlüssel zu vereinbaren — dann schnell symmetrisch weiter.

1️⃣ Browser holt den
ÖFFENTLICHEN Schlüssel
des Servers
2️⃣ würfelt einen zufälligen
AES-Schlüssel, verschlüsselt
ihn damit, schickt ihn hin
3️⃣ ab jetzt: alles mit
schnellem AES
(symmetrisch)
Warum so? Der langsame asymmetrische Teil wird nur einmal ganz kurz benutzt — nur für die paar Bytes des AES-Schlüssels. Der ganze Rest (die Webseite, das Video, der Download) läuft über schnelles AES. Schlüsseltausch-Problem gelöst und volle Geschwindigkeit.
Das ist „TLS" hinter dem 🔒. Erinnert ihr euch an VL 8: „HTTPS überall"? Genau das passiert dabei — eine Mischung aus allem von heute. Und der Server beweist mit einer digitalen Signatur (nächste Slide), dass er wirklich er ist.

Bonus: dieselbe Technik rückwärts = digitale Signatur

Was, wenn man die Schlüssel vertauscht? Mit privat „verschlüsseln", mit öffentlich „entschlüsseln" — das beweist, wer etwas geschrieben hat.

✍️ Signieren (nur Bob kann das)

Bob bildet den Hash seiner Nachricht (VL 8!) und „verschlüsselt" diesen mit seinem privaten Schlüssel → die Signatur.

Nur Bob hat den privaten Schlüssel — also kann nur Bob diese Signatur erzeugen.

Prüfen (jeder kann das)

Jeder nimmt Bobs öffentlichen Schlüssel, „entschlüsselt" die Signatur → bekommt den Hash. Stimmt er mit dem Hash der Nachricht überein?

→ Dann ist sie echt von Bob und unverändert.

Hier kommt alles zusammen: Signaturen verbinden Hashing (VL 8, für Integrität) mit asymmetrischer Krypto (heute, für Echtheit). So beweist eine Webseite beim HTTPS-Verbindungsaufbau, dass sie wirklich eure Bank ist — und nicht ein Betrüger.

Wo ihr Verschlüsselung jeden Tag benutzt

Ihr habt heute schon dutzendfach verschlüsselt — ohne es zu merken.

🔒 Das Browser-Schloss

Das 🔒 in der Adresszeile = HTTPS/TLS aktiv. Alles zwischen euch und der Seite ist verschlüsselt. Kein Schloss → Postkarte!

💬 Ende-zu-Ende

WhatsApp, Signal: nur Sender und Empfänger haben die Schlüssel. Nicht mal der Anbieter kann mitlesen.

💾 Festplatten

BitLocker, FileVault, LUKS verschlüsseln eure ganze Platte mit AES. Laptop geklaut? Daten bleiben geheim.

Achtung beim Schloss: 🔒 bedeutet „die Verbindung ist verschlüsselt" — nicht „die Seite ist vertrauenswürdig". Auch Betrüger-Seiten können HTTPS haben. Immer die Adresse selbst prüfen!

Was kann ich tun — als User & als Entwickler?

🙋 Als User

  • Auf das 🔒 achten — keine Passwörter/Karten ohne HTTPS eingeben
  • Ende-zu-Ende-Messenger bevorzugen (Signal, WhatsApp)
  • Festplatte verschlüsseln (FileVault / BitLocker) — ein Klick
  • Updates installieren — Krypto-Lücken werden gefixt

👩‍💻 Als Entwickler

  • „Don't roll your own crypto" — nutzt OpenSSL / libsodium
  • Immer TLS für Netzwerkverkehr
  • Schlüssel nie in den Code/ins Git hardcoden
  • Zufall nur aus echter Quelle (RAND_bytes, nie rand()) — wie das Salt in VL 8
Der rote Faden aus VL 8 & 9: Sicherheit baut man nicht selbst aus dem Nichts — man nutzt geprüfte Werkzeuge richtig. Verstehen warum sie funktionieren (das war heute) macht euch zu guten Entwicklern.

Das große Ganze — welches Werkzeug wofür?

VL 8 + VL 9 in einem Bild. Fragt euch immer zuerst: will ich die Daten je wieder lesen können?

❓ Will ich die Daten
später zurück-lesen?

🙅 NEIN → Hashing (VL 8)

Passwörter prüfen, Datei-Integrität. Einbahnstraße, kein Schlüssel.

→ bcrypt / SHA-256

🙆 JA → Verschlüsselung (heute)

Nachrichten, Dateien, Netzwerkverkehr. Hin- und Rückweg mit Schlüssel.

→ weiter fragen ↓

Viele Daten, Schlüssel schon geteilt?

Symmetrisch → AES. Schnell, ein Schlüssel.

🤝 Schlüssel sicher tauschen?

Asymmetrisch → RSA. Öffentlich + privat.

🌐 Beides, in der Praxis?

Hybrid → HTTPS/TLS. Das 🔒 im Browser.

Eine Frage entscheidet alles: „zurück-lesen?" → Nein = Hash, Ja = Verschlüsselung. Den Rest (symmetrisch / asymmetrisch / hybrid) wählt ihr je nach Geschwindigkeit und Schlüsseltausch.

🤔 Mini-Quiz

Anna will Bob eine geheime Nachricht übers Internet schicken (asymmetrisch). Mit welchem Schlüssel verschlüsselt sie?

A) Mit ihrem eigenen privaten Schlüssel
B) Mit Bobs öffentlichem Schlüssel
C) Mit ihrem eigenen öffentlichen Schlüssel
D) Mit einem Schlüssel, den beide vorher tauschen mussten
Warum B: verschlüsselt wird immer mit dem öffentlichen Schlüssel des Empfängers. Nur Bob hat den passenden privaten Schlüssel zum Aufschließen. Antwort D beschreibt das symmetrische Verfahren — und genau dessen Schlüsseltausch-Problem löst die asymmetrische Krypto ja.

🤔 Mini-Quiz — Runde 2

Warum nutzt HTTPS beide Verfahren (asymmetrisch und symmetrisch), statt nur asymmetrisch?

A) Asymmetrisch ist unsicher, symmetrisch gleicht das aus
B) Asymmetrisch ist langsam — man nutzt es nur einmal, um einen schnellen AES-Schlüssel auszutauschen
C) Aus Tradition — früher gab es nur asymmetrisch
D) Damit zwei verschiedene Firmen mitverdienen
Warum B: asymmetrische Krypto löst zwar den Schlüsseltausch, ist aber ~1000× langsamer. Deshalb der Hybrid-Trick: einmal asymmetrisch einen zufälligen AES-Schlüssel sicher übergeben, dann den ganzen Rest schnell symmetrisch. Beste aus beiden Welten.

Zusammenfassung — in einer Slide

  • Hash ≠ Verschlüsselung: Hash = Einbahnstraße (VL 8). Verschlüsselung = Hin- und Rückweg mit Schlüssel.
  • Caesar & XOR: einfache Ideen zum Selber-Rechnen — aber zu schwach (zu wenig Schlüssel / Muster).
  • Symmetrisch (AES): ein Schlüssel, sehr schnell — aber Schlüsseltausch ist das Problem.
  • Asymmetrisch (RSA): öffentlich + privat — löst den Schlüsseltausch, ist aber langsam.
  • HTTPS = Hybrid: asymmetrisch einmal für den Schlüssel, dann schnell symmetrisch. Das ist das 🔒.
  • Goldene Regel: „Don't roll your own crypto." — Library richtig nutzen, nicht selbst bauen.

📚 Quellen & weiterführende Literatur

Was ihr lesen/anschauen solltet, wenn ihr tiefer einsteigen wollt:

📖 Standards & Guidelines

  • OWASP Cryptographic Storage Cheat Sheetcheatsheetseries.owasp.org
  • NIST FIPS 197 — der AES-Standard selbst
  • BSI TR-02102-1 — empfohlene Krypto-Verfahren (Deutsch)

🔬 Akademisch & Tools

  • Rivest, Shamir, Adleman (1977): das RSA-Paper
  • Diffie & Hellman (1976): „New Directions in Cryptography"
  • CrypTool — Krypto interaktiv ausprobieren (Caesar, RSA, …)

💻 C-Libraries

  • OpenSSLopenssl/evp.h (AES), openssl/rsa.h
  • libsodium — modern, schwer falsch zu nutzen (crypto_box)

🎥 Zum Anschauen

  • Computerphile: „Public Key Cryptography", „AES Explained" (YouTube)
  • Cryptopals Challenges: cryptopals.com — XOR/AES selbst angreifen
Im Labor: ihr baut Caesar und XOR selbst in C — und nutzt dann OpenSSL für „echtes" AES. Erst selbst basteln, dann verstehen, warum man's lieber der Library überlässt.

Vielen Dank!

Schönen Feierabend! 🌙

Prof. Dr. Alexandra Mikityuk

HTW Berlin · Büro Raum 308

Tel +49 30 5019-2664

Nächste Woche: Graphen I — Netzwerke & BFS

1 / …