mirror of
https://github.com/theoleuthardt/hwr-notes.git
synced 2026-06-06 01:01:08 +00:00
docs: add obsidian hwr docs
This commit is contained in:
theoleuthardt
parent
b2636f4b92
commit
850aa3455d
245 changed files with 30757 additions and 0 deletions
302
Kryptografie/zusammenfassungen/kr1 - zusammenfassung.md
Normal file
302
Kryptografie/zusammenfassungen/kr1 - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,302 @@
|
|||
# Kryptographie – Zusammenfassung Vorlesung 1
|
||||
|
||||
**Prof. Dr. Björn Grohmann | HWR Berlin | 16.02.2026**
|
||||
|
||||
---
|
||||
|
||||
## 1. Einführung: Die Geschichte von Maria Stuart
|
||||
|
||||
Die Vorlesung beginnt mit einem historischen Beispiel: Maria Stuart (1542–1587), Königin von Schottland, wurde durch das Scheitern ihrer verschlüsselten Kommunikation zum Tode verurteilt. Im sogenannten **Babington-Plot (1586)** kommunizierte sie über geheime Briefe mit Anthony Babington, die in Bierfässern geschmuggelt wurden. Sir Francis Walsingham (Geheimdienstchef von Elizabeth I.) und sein Kryptoanalyst Thomas Phelippes fingen die Briefe ab und entschlüsselten sie. Maria Stuarts Chiffre – eine einfache monoalphabetische Substitution mit Symbolen für Buchstaben und häufige Wörter – bot keinen ausreichenden Schutz.
|
||||
|
||||
**Was fehlte für sichere Kommunikation?**
|
||||
|
||||
- **Vertraulichkeit (Confidentiality):** Nur berechtigte Empfänger sollen den Inhalt lesen können.
|
||||
- **Integrität (Integrity):** Die Nachricht darf nicht unbemerkt verändert werden.
|
||||
- **Authentizität (Authenticity):** Der Absender muss zweifelsfrei identifizierbar sein.
|
||||
|
||||
---
|
||||
|
||||
## 2. Häufigkeitsanalyse
|
||||
|
||||
Einfache Substitutionschiffren lassen sich durch **Häufigkeitsanalyse** brechen: Man zählt, wie oft jedes Symbol im Geheimtext vorkommt, und vergleicht die Verteilung mit der bekannten Buchstabenhäufigkeit der Sprache.
|
||||
|
||||
Im Englischen ist z. B. **E** mit ca. 11,16 % der häufigste Buchstabe, gefolgt von A (8,50 %), R (7,58 %), I (7,54 %), O (7,16 %) usw. Samuel Morse nutzte diese Erkenntnis bereits für sein Morsealphabet – häufige Buchstaben bekamen kurze Codes.
|
||||
|
||||
---
|
||||
|
||||
## 3. Klassische Chiffren
|
||||
|
||||
### 3.1 Caesar-Chiffre
|
||||
|
||||
Jeder Buchstabe wird um eine feste Anzahl *n* im Alphabet verschoben:
|
||||
|
||||
- **Verschlüsselung:** E_n(x) = x + n mod 26
|
||||
- **Entschlüsselung:** D_n(x) = x − n mod 26
|
||||
|
||||
Beispiel (n = 3): A → X, B → Y, E → B. Der Schlüsselraum ist mit nur 25 möglichen Verschiebungen trivial klein und per Brute-Force sofort zu brechen.
|
||||
|
||||
### 3.2 Vigenère-Chiffre
|
||||
|
||||
Eine polyalphabetische Substitution: Ein Schlüsselwort wird wiederholt über den Klartext gelegt. Jeder Buchstabe wird mit einem anderen Caesar-Shift verschlüsselt.
|
||||
|
||||
- **Verschlüsselung:** C_i = M_i + K_i mod 26
|
||||
- **Entschlüsselung:** M_i = C_i − K_i mod 26
|
||||
|
||||
Beispiel: Plaintext „attackatdawn" + Key „LEMONLEMONLE" → Ciphertext „LXFOPVEFRNHR"
|
||||
|
||||
**Schwäche:** Durch den **Kasiski-Test** lässt sich die Schlüssellänge ermitteln. Wiederholt sich ein Muster im Klartext und fällt es auf dieselbe Schlüsselposition, entsteht ein identisches Muster im Geheimtext. Der Abstand solcher Wiederholungen ist ein Vielfaches der Schlüssellänge.
|
||||
|
||||
### 3.3 Homophone Chiffren
|
||||
|
||||
Versuch, die Häufigkeitsanalyse zu erschweren: Jedem Buchstaben werden mehrere Symbole zugeordnet, proportional zu seiner Häufigkeit. Trotzdem bieten sie keinen vollständigen Schutz.
|
||||
|
||||
### 3.4 Beale-Chiffren
|
||||
|
||||
Ein berühmtes ungelöstes Kryptorätsel: Drei Chiffretexte (Zahlenfolgen) sollen den Standort eines vergrabenen Schatzes beschreiben. Chiffretext 2 wurde mithilfe der US-Unabhängigkeitserklärung als Schlüsseltext entschlüsselt (jede Zahl verweist auf das Anfangswort im Dokument). Chiffretexte 1 und 3 sind bis heute ungeknackt.
|
||||
|
||||
---
|
||||
|
||||
## 4. Informationstheoretische Sicherheit
|
||||
|
||||
### 4.1 Informationsgehalt und Entropie
|
||||
|
||||
**Informationsgehalt** eines Zeichens x mit Wahrscheinlichkeit p_x:
|
||||
|
||||
> I_x = log(1/p_x) = −log(p_x)
|
||||
|
||||
Je seltener ein Zeichen, desto größer sein Informationsgehalt.
|
||||
|
||||
**Entropie** H(X) – der mittlere Informationsgehalt einer Zufallsvariable:
|
||||
|
||||
> H(X) = −∑_x p_x · log(p_x)
|
||||
|
||||
**Bedingte Entropie:**
|
||||
|
||||
> H(X|Y) = H(X, Y) − H(Y)
|
||||
>
|
||||
> H(X, Y) ≤ H(X) + H(Y)
|
||||
|
||||
### 4.2 Perfekte Sicherheit (Shannon)
|
||||
|
||||
Claude Shannon (1916–2001) definierte: Ein Verschlüsselungssystem hat **perfekte Sicherheit (Perfect Secrecy)**, genau dann wenn:
|
||||
|
||||
> **H(M|E) = H(M)**
|
||||
|
||||
Das bedeutet: Die bedingte Entropie der Nachricht M gegeben den Geheimtext E ist gleich der Entropie von M allein. Anders formuliert: **M und E sind stochastisch unabhängig** – der Geheimtext verrät keinerlei Information über den Klartext. Jeder Chiffretext ist unabhängig vom Klartext gleich wahrscheinlich.
|
||||
|
||||
### 4.3 One-Time Pad (OTP)
|
||||
|
||||
Das einzige Verfahren, das perfekte Sicherheit erreicht:
|
||||
|
||||
- Der Schlüssel wird per **XOR** mit dem Klartext verknüpft: E = P ⊕ K
|
||||
- Der Schlüssel muss **echt zufällig** sein
|
||||
- Der Schlüssel muss **mindestens so lang wie die Nachricht** sein
|
||||
- Der Schlüssel darf **nur einmal** verwendet werden
|
||||
|
||||
**Problem:** Der Schlüssel muss genauso lang sein wie die Nachricht und sicher übertragen werden – in der Praxis meist nicht handhabbar.
|
||||
|
||||
---
|
||||
|
||||
## 5. Kryptographische Primitive
|
||||
|
||||
### 5.1 Einwegfunktionen (One-Way Functions – OWF)
|
||||
|
||||
Eine Funktion f : {0,1}* → {0,1}* mit |f(x)| = |x| ist eine Einwegfunktion, wenn:
|
||||
|
||||
1. **Leicht zu berechnen:** Es existiert ein Polynomialzeit-Algorithmus A mit A(x) = f(x) für alle x.
|
||||
2. **Schwer umzukehren:** Für jeden probabilistischen Polynomialzeit-Algorithmus A', jedes Polynom p(.) und alle hinreichend großen n gilt: Pr[A'(f(U_n)) = f⁻¹ ∘ f(U_n)] < 1/p(n)
|
||||
|
||||
Anschaulich: x → f(x) ist einfach und schnell, f(x) → x erfordert exponentiellen Aufwand.
|
||||
|
||||
### 5.2 Pseudo-Zufallszahlengeneratoren (PRG/PRNG)
|
||||
|
||||
Eine Funktion G : {0,1}* → {0,1}* mit Streckungsfunktion l(n) ist ein PRG, wenn:
|
||||
|
||||
1. G ist ein **Polynomialzeit-Algorithmus**
|
||||
2. Für jedes x gilt: |G(x)| = l(|x|) > |x| (Ausgabe ist länger als Eingabe)
|
||||
3. Die Verteilungen {G(U_n)} und {U_l(n)} sind **berechnungsmäßig ununterscheidbar** (computational indistinguishability)
|
||||
|
||||
**Berechnungsmäßige Ununterscheidbarkeit** (Definition 13.4): Zwei Wahrscheinlichkeitsensembles {X_n} und {Y_n} sind berechnungsmäßig ununterscheidbar, wenn für jeden probabilistischen Polynomialzeit-Algorithmus A und jedes Polynom p(.) ab einem N gilt:
|
||||
|
||||
> |Pr(A(X_n) = 1) − Pr(A(Y_n) = 1)| < 1/p(n)
|
||||
|
||||
**Amplifikation der Streckungsfunktion** (Theorem 13.10): Hat man einen PRG mit Streckungsfunktion n + 1, dann existiert für jedes Polynom l(n) ein PRG mit Streckungsfunktion l(n). Dies geschieht durch iteriertes Anwenden von G₁.
|
||||
|
||||
### 5.3 Zusammenhang OWF ↔ PRG
|
||||
|
||||
> **Theorem: Pseudo-Zufallszahlengeneratoren existieren genau dann, wenn Einwegfunktionen existieren.**
|
||||
|
||||
**PRG → OWF:** Aus einem PRG G : {0,1}^n → {0,1}^{2n} kann man eine OWF konstruieren: f(xy) = G(x) wobei |x| = |y| = n. Die Funktion „vergisst" die Hälfte der Eingabe.
|
||||
|
||||
**OWF → PRG:** Über den Umweg eines **Hardcore-Prädikats (HCP)**. Sei f eine OWF, dann ist b(x, r) = Skalarprodukt von x und r mod 2 ein Hardcore-Prädikat von f'(x,r) = (f(x), r). Der PRG ergibt sich als G(s) = f'(s) ∘ b(s). Ein HCP ist leicht zu berechnen, aber aus f(x) allein nicht vorhersagbar (Wahrscheinlichkeit < 1/2 + 1/p(n)).
|
||||
|
||||
---
|
||||
|
||||
## 6. Symmetrische Verschlüsselung
|
||||
|
||||
Eine Chiffre heißt **symmetrisch**, wenn für Ver- und Entschlüsselung dasselbe Schlüsselmaterial verwendet wird.
|
||||
|
||||
### 6.1 Strom-Chiffren
|
||||
|
||||
Prinzip: Ein kurzer Schlüssel (Seed) wird durch einen PRNG zu einem langen Schlüsselstrom gestreckt, der per XOR mit dem Klartext verknüpft wird.
|
||||
|
||||
**ChaCha20** – eine moderne Strom-Chiffre:
|
||||
|
||||
- **Eingaben:** 256-Bit Schlüssel, 32-Bit Zähler, 96-Bit Nonce, beliebig langer Klartext
|
||||
- **Ausgabe:** Geheimtext gleicher Länge
|
||||
- **Kernoperation – Quarter Round:** Arbeitet auf vier 32-Bit-Werten (a, b, c, d) mit Addition, XOR und Rotation:
|
||||
1. a += b; d ^= a; d <<<= 16
|
||||
2. c += d; b ^= c; b <<<= 12
|
||||
3. a += b; d ^= a; d <<<= 8
|
||||
4. c += d; b ^= c; b <<<= 7
|
||||
- Ein **inner_block** besteht aus 8 Quarter Rounds (4 Spalten + 4 Diagonalen)
|
||||
- **chacha20_block:** Zustand = Konstanten | Key | Counter | Nonce → 10× inner_block → Zustand addieren → serialisieren
|
||||
- Verschlüsselung: Für jeden 64-Byte-Block wird ein Schlüsselstrom erzeugt und per XOR verknüpft
|
||||
|
||||
### 6.2 Block-Chiffren
|
||||
|
||||
Ein Klartextblock fester Größe wird mit einem Schlüssel in einen Geheimtextblock gleicher Größe transformiert. Die zentrale Frage: Wie verschlüsselt man Daten, die länger als ein Block sind? → **Betriebsmodi**
|
||||
|
||||
---
|
||||
|
||||
## 7. Betriebsmodi (Modes of Operation)
|
||||
|
||||
### 7.1 ECB (Electronic Codebook)
|
||||
|
||||
Jeder Block wird unabhängig verschlüsselt. **Problem:** Identische Klartextblöcke ergeben identische Geheimtextblöcke → Muster bleiben sichtbar. Nicht IND-CPA-sicher.
|
||||
|
||||
### 7.2 CBC (Cipher Block Chaining)
|
||||
|
||||
Jeder Klartextblock wird vor der Verschlüsselung mit dem vorherigen Geheimtextblock XOR-verknüpft. Der erste Block wird mit einem **Initialization Vector (IV)** verknüpft. **Achtung:** Anfällig für **Padding Oracle Attacks** – wenn das System bei der Entschlüsselung zwischen Padding-Fehlern und anderen Fehlern unterscheidet, kann der Klartext ohne Schlüsselkenntnis rekonstruiert werden.
|
||||
|
||||
### 7.3 CTR (Counter Mode)
|
||||
|
||||
Wandelt eine Block-Chiffre in eine Strom-Chiffre um: Nonce + fortlaufender Zähler werden verschlüsselt und per XOR mit dem Klartext verknüpft. Vorteil: Parallelisierbar, kein Padding nötig.
|
||||
|
||||
### 7.4 OFB (Output Feedback)
|
||||
|
||||
Der IV wird verschlüsselt, das Ergebnis als nächster Eingabeblock verwendet. Der Schlüsselstrom ist unabhängig vom Klartext.
|
||||
|
||||
### 7.5 CFB (Cipher Feedback)
|
||||
|
||||
Ähnlich wie OFB, aber der Geheimtext (statt des Verschlüsselungsoutputs) wird als nächster Eingabeblock verwendet.
|
||||
|
||||
### 7.6 Cipher Text Stealing
|
||||
|
||||
Ein Verfahren, das Padding vermeidet, indem der letzte vollständige und der letzte unvollständige Block geschickt vertauscht und kombiniert werden.
|
||||
|
||||
---
|
||||
|
||||
## 8. Kryptoanalyse und Angriffsmodelle
|
||||
|
||||
Die Angriffstypen sind nach aufsteigender Stärke des Angreifers geordnet:
|
||||
|
||||
| Angriffstyp | Fähigkeit des Angreifers |
|
||||
|---|---|
|
||||
| **Ciphertext-only** | Kennt nur den Geheimtext |
|
||||
| **Known Plaintext** | Kennt Paare von Klartext und Geheimtext |
|
||||
| **Chosen Plaintext (CPA)** | Kann beliebige Klartexte verschlüsseln lassen |
|
||||
| **Adaptive Chosen Plaintext** | Wie CPA, kann aber Anfragen adaptiv stellen |
|
||||
| **Chosen Ciphertext (CCA)** | Kann beliebige Geheimtexte entschlüsseln lassen |
|
||||
| **Adaptive Chosen Ciphertext** | Wie CCA, adaptiv |
|
||||
|
||||
### IND-CPA-Sicherheit
|
||||
|
||||
Das „Find-then-Guess"-Spiel: Ein Angreifer A interagiert mit einem Challenger C. C erzeugt einen Schlüssel k und ein Bit b ∈ {0,1}. A darf beliebig viele Klartexte verschlüsseln lassen, wählt dann zwei Nachrichten M₁, M₂ gleicher Länge. C verschlüsselt M_b und gibt den Geheimtext zurück. A muss b erraten. Die Chiffre ist IND-CPA-sicher, wenn der Vorteil von A vernachlässigbar ist: Adv(A) = |Pr[b = b'] − 1/2| ≈ 0.
|
||||
|
||||
---
|
||||
|
||||
## 9. DES und AES
|
||||
|
||||
### 9.1 Data Encryption Standard (DES, 1977)
|
||||
|
||||
- **Blockgröße:** 64 Bit
|
||||
- **Schlüssellänge:** 56 Bit (effektiv)
|
||||
- **Struktur:** Feistel-Netzwerk mit 16 Runden
|
||||
- **Feistel-Netzwerk:** Der Block wird in zwei Hälften (L, R) geteilt. Pro Runde: L_{i+1} = R_i und R_{i+1} = L_i ⊕ F(R_i, K_i). Die Entschlüsselung funktioniert durch Anwenden der Rundenschlüssel in umgekehrter Reihenfolge.
|
||||
- **Kritik (Diffie & Hellman):** Die 56-Bit-Schlüssellänge ist zu kurz für exhaustive Suche. Empfehlung: mindestens 128 Bit.
|
||||
- **Heute als unsicher eingestuft.**
|
||||
|
||||
### 9.2 Advanced Encryption Standard (AES, 2001)
|
||||
|
||||
- **Blockgröße:** 128 Bit
|
||||
- **Schlüssellängen:** 128, 192 oder 256 Bit
|
||||
- **Runden:** 10 (AES-128), 12 (AES-192) oder 14 (AES-256)
|
||||
- **Gilt als sicher**
|
||||
|
||||
**AES-128 Algorithmus** (Pseudocode):
|
||||
|
||||
1. Schlüsselexpansion: K → (K₀, ..., K₁₀)
|
||||
2. s ← M ⊕ K₀
|
||||
3. Für r = 1 bis 10:
|
||||
- s ← SubBytes(s)
|
||||
- s ← ShiftRows(s)
|
||||
- Falls r ≤ 9: s ← MixColumns(s)
|
||||
- s ← s ⊕ K_r
|
||||
|
||||
**Die vier Transformationen:**
|
||||
|
||||
- **SubBytes:** Nichtlineare Byte-Substitution über eine S-Box. Jedes Byte wird durch sein multiplikatives Inverses in GF(2⁸) ersetzt und anschließend affin transformiert.
|
||||
- **ShiftRows:** Zeilenweises zyklisches Verschieben (Zeile 0: kein Shift, Zeile 1: 1 Byte, Zeile 2: 2 Bytes, Zeile 3: 3 Bytes).
|
||||
- **MixColumns:** Spaltenweise Multiplikation mit einem festen Polynom c(x) über GF(2⁸). Sorgt für Diffusion.
|
||||
- **AddRoundKey:** XOR des Zustands mit dem Rundenschlüssel.
|
||||
|
||||
### Mathematik hinter der AES-S-Box
|
||||
|
||||
AES arbeitet im endlichen Körper **GF(2⁸)** mit dem irreduziblen Polynom:
|
||||
|
||||
> m(x) = x⁸ + x⁴ + x³ + x + 1
|
||||
|
||||
- **Addition:** XOR der Koeffizienten (entspricht XOR der Bytes)
|
||||
- **Multiplikation:** Polynommultiplikation modulo m(x)
|
||||
- **Multiplikatives Inverses:** Berechnung mittels des **erweiterten euklidischen Algorithmus**: Finde a(x), c(x) sodass b(x)·a(x) + m(x)·c(x) = 1
|
||||
|
||||
Die S-Box-Konstruktion ist zweistufig: (1) Multiplikatives Inverses in GF(2⁸), dann (2) affine Transformation über GF(2), dargestellt als Matrixmultiplikation plus Konstantenvektor.
|
||||
|
||||
---
|
||||
|
||||
## 10. Anwendungen kryptographischer Primitive
|
||||
|
||||
### 10.1 Lamport's One-Time-Signature
|
||||
|
||||
Ein digitales Signaturverfahren, das nur auf Einwegfunktionen basiert:
|
||||
|
||||
- **Schlüsselerzeugung:** Generiere 2 × 256 Zufallswerte r_i^0 und r_i^1 (geheimer Schlüssel sk). Der öffentliche Schlüssel pk besteht aus den Bildern unter einer OWF h: y_i^b = h(r_i^b).
|
||||
- **Signatur:** Für jedes Bit b_i der Nachricht (als 256-Bit-Hash) wird r_i^{b_i} veröffentlicht.
|
||||
- **Verifikation:** Berechne h auf die Signaturwerte und vergleiche mit den passenden Werten im öffentlichen Schlüssel.
|
||||
- **Einmal-Eigenschaft:** Jeder Schlüssel darf nur für eine Signatur verwendet werden.
|
||||
|
||||
### 10.2 Bit Commitment Protokoll
|
||||
|
||||
Ein Zweiphasen-Verfahren, bei dem Alice sich auf ein Bit b festlegt (Commit), ohne dass Bob es kennt, und es später enthüllt (Reveal).
|
||||
|
||||
**Naiver Ansatz (mit PRG):**
|
||||
|
||||
- Commit: Alice wählt Seed s, sendet G_m(s) und B_{m+1}(s) ⊕ b
|
||||
- Reveal: Alice sendet s, Bob verifiziert
|
||||
|
||||
**Problem:** Alice könnte zwei Seeds finden, die in den ersten m Bits übereinstimmen, aber im (m+1)-ten Bit differieren → Betrug möglich.
|
||||
|
||||
**Verbessertes Protokoll:**
|
||||
|
||||
- Bob sendet einen zufälligen Vektor R = (r₁, ..., r_{3n})
|
||||
- Alice wählt Seed s und sendet d_i = B_i(s) wenn r_i = 0, bzw. d_i = B_i(s) ⊕ b wenn r_i = 1
|
||||
- Die Wahrscheinlichkeit, dass Alice betrügen kann, ist höchstens 2^{−n}
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung der Kernkonzepte
|
||||
|
||||
| Konzept | Kernaussage |
|
||||
|---|---|
|
||||
| Perfect Secrecy | H(M\|E) = H(M), erfordert Schlüssel ≥ Nachrichtenlänge |
|
||||
| One-Time Pad | Einziges perfekt sicheres Verfahren, aber unpraktisch |
|
||||
| Einwegfunktion | Leicht zu berechnen, schwer umzukehren |
|
||||
| PRG | Streckt kurzen Seed zu pseudo-zufälligem, langem Output |
|
||||
| OWF ↔ PRG | Existieren genau dann, wenn das jeweils andere existiert |
|
||||
| Symmetrische Chiffre | Gleicher Schlüssel für Ver- und Entschlüsselung |
|
||||
| Strom-Chiffre | PRNG + XOR (z. B. ChaCha20) |
|
||||
| Block-Chiffre | Feste Blockgröße, verschiedene Betriebsmodi |
|
||||
| DES | 56-Bit Schlüssel, heute unsicher |
|
||||
| AES | 128/192/256-Bit Schlüssel, Arithmetik in GF(2⁸), sicher |
|
||||
| IND-CPA | Standardsicherheitsbegriff für symmetrische Verschlüsselung |
|
||||
4
Kryptografie/zusammenfassungen/kr2 - additional notes.md
Normal file
4
Kryptografie/zusammenfassungen/kr2 - additional notes.md
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
# Vorlesung 2
|
||||
|
||||
## AEAD
|
||||
Additional Data können z.B. Metadaten sein wie die MAC-/IP-Adresse des Absenders/Empfängers sein.
|
||||
366
Kryptografie/zusammenfassungen/kr2 - zusammenfassung.md
Normal file
366
Kryptografie/zusammenfassungen/kr2 - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,366 @@
|
|||
# Kryptographie – Zusammenfassung Vorlesung 2
|
||||
_Prof. Dr. Björn Grohmann · HWR Berlin_ _Nur neuer Inhalt (ab Folie 73) – Wiederholungen aus Vorlesung 1 ausgelassen_
|
||||
|
||||
---
|
||||
|
||||
## Message Authentication Code (MAC)
|
||||
|
||||
Ein **MAC** (Message Authentication Code) ist ein kurzer Tag `t`, der mit einem symmetrischen Schlüssel `k` aus einer Nachricht `m` berechnet wird:
|
||||
|
||||
```
|
||||
t = MAC(k, m)
|
||||
```
|
||||
|
||||
MAC bietet **Integrität** und **Authentizität**, aber keine Vertraulichkeit. Sender und Empfänger teilen denselben Schlüssel.
|
||||
|
||||
### Angriffsvektoren auf MACs (von stark → schwach)
|
||||
|
||||
|Stärke|Angriff|Beschreibung|
|
||||
|---|---|---|
|
||||
|Stärkster|**Total Break**|Alle Systemparameter sind gebrochen; Angreifer kann für beliebige Nachricht einen MAC erzeugen|
|
||||
||**Selective Forgery**|MAC für eine Nachricht erzeugbar, die _vor_ dem Angriff vom Angreifer gewählt wurde|
|
||||
|Schwächster|**Existential Forgery**|MAC für _irgendeine_ Nachricht erzeugbar (auch sinnlose)|
|
||||
|
||||
---
|
||||
|
||||
## Wie man lange Nachrichten NICHT mit einem MAC versehen sollte
|
||||
|
||||
Mehrere naive Konstruktionen sind unsicher:
|
||||
|
||||
1. **Kein Schlüssel im MAC**: Angreifer kann eigene Blöcke einfügen.
|
||||
2. **Alle Blöcke mit demselben Schlüssel unabhängig MACen** (`t_i = MAC(k, m_i)`): Reihenfolge der Blöcke kann vertauscht werden (Reordering-Angriff).
|
||||
3. **Mit laufender Blocknummer** (`t_i = MAC(k, i || m_i)`): Blöcke aus verschiedenen Nachrichten können gemischt werden.
|
||||
4. **Nachrichten-ID hinzufügen** (`t_i = MAC(k, id || i || m_i)`): Letzter Block kann weggelassen werden (Truncation-Angriff).
|
||||
5. **Länge im letzten Block kodieren**: Erst dann ist die Konstruktion sicher (CBC-MAC-Variante).
|
||||
|
||||
---
|
||||
|
||||
## HMAC (Hash-MAC)
|
||||
|
||||
```
|
||||
HMAC(k, m) = H( (k XOR opad) || H( (k XOR ipad) || m ) )
|
||||
```
|
||||
|
||||
**H** ist eine kryptographische Hash-Funktion mit den Eigenschaften:
|
||||
|
||||
- Effizient zu berechnen
|
||||
- Schwer zu invertieren (Einwegfunktion)
|
||||
- Kollisionsresistenz: schwer, zwei Eingaben mit gleichem Hash zu finden
|
||||
- Kleine Eingabeänderungen → große Ausgabeänderungen (Diffusion / Lawineneffekt)
|
||||
|
||||
`opad` und `ipad` sind feste Konstanten (Byte-Padding).
|
||||
|
||||
---
|
||||
|
||||
## Kombinationen von Verschlüsselung und MAC
|
||||
|
||||
Es gibt drei Möglichkeiten, Verschlüsselung (Enc) und MAC zu kombinieren:
|
||||
|
||||
|Variante|Schema|Empfehlung|
|
||||
|---|---|---|
|
||||
|**Encrypt-then-MAC**|`c = Enc(k₁, m)` → `t = MAC(k₂, c)`|✅ Empfohlen (z. B. TLS 1.3)|
|
||||
|**MAC-then-Encrypt**|`t = MAC(k₂, m)` → `c = Enc(k₁, m \| t)`|⚠️ Problematisch (z. B. Padding-Oracle-Angriff in TLS < 1.3)|
|
||||
|**Encrypt-and-MAC**|`c = Enc(k₁, m)` und `t = MAC(k₂, m)` parallel|⚠️ MAC kann Klartextinfo leaken|
|
||||
|
||||
**Encrypt-then-MAC** ist die sichere Variante: Der MAC schützt den Chiffretext, sodass manipulierte Ciphertexte sofort erkannt werden, bevor sie entschlüsselt werden.
|
||||
|
||||
---
|
||||
|
||||
## Authenticated Encryption with Associated Data (AEAD)
|
||||
|
||||
**AEAD** kombiniert Verschlüsselung und Authentifizierung in einem einzigen Algorithmus:
|
||||
|
||||
```
|
||||
(c, t) = AEAD_Enc(k, nonce, m, aad)
|
||||
m = AEAD_Dec(k, nonce, c, t, aad)
|
||||
```
|
||||
|
||||
- `m` = Plaintext (wird verschlüsselt **und** authentifiziert)
|
||||
- `aad` = _Associated Authenticated Data_ (wird nur authentifiziert, nicht verschlüsselt, z. B. Header)
|
||||
- Gibt `⊥` zurück, wenn die Authentifizierung fehlschlägt
|
||||
|
||||
### Beispiel: ChaCha20-Poly1305
|
||||
|
||||
- **ChaCha20**: Stromchiffre (Verschlüsselung)
|
||||
- **Poly1305**: MAC über den Ciphertext
|
||||
- Eingaben: 256-bit Key, 96-bit Nonce, Plaintext
|
||||
- Weit verbreitet in TLS 1.3, SSH, WireGuard
|
||||
|
||||
### Beispiel: Galois Counter Mode (GCM)
|
||||
|
||||
- Kombiniert **CTR-Mode** (Verschlüsselung mit AES) und **GHASH** (MAC über das Galois-Feld GF(2¹²⁸))
|
||||
- Standard für AES-GCM in TLS 1.3
|
||||
|
||||
---
|
||||
|
||||
## Symmetric Search over Encrypted Data
|
||||
|
||||
Problem: Wie kann man auf verschlüsselten Daten (z. B. in der Cloud) suchen, ohne den Schlüssel preiszugeben?
|
||||
|
||||
|Ansatz|Idee|Problem|
|
||||
|---|---|---|
|
||||
|**1. Idee**|Alice gibt Bob Wort `W` + Schlüssel `k`|Bob kennt den Schlüssel → kein Datenschutz|
|
||||
|**2. Idee**|Alice gibt Bob `Enc(W)` + zugehörigen Schlüssel|Deterministisches Enc → gleiche Wörter → gleiche Ciphertexte → Häufigkeitsanalyse möglich|
|
||||
|**3. Idee**|Pseudorandom Function (PRF)-basierter Index: Alice erstellt eine verschlüsselte Lookup-Tabelle. Für jedes Wort `w` wird ein Token `T = PRF(k, w)` erzeugt und der zugehörige Index verschlüsselt gespeichert.|Leakt _access pattern_ (welche Dokumente abgerufen werden)|
|
||||
|
||||
Die dritte Idee ist die Grundlage von **Searchable Symmetric Encryption (SSE)**. Sie erlaubt Bob, anhand eines Tokens zu suchen, ohne `k` oder `w` zu kennen.
|
||||
|
||||
---
|
||||
|
||||
## Public-Key-Kryptographie
|
||||
|
||||
### Das Schlüsselaustauschproblem
|
||||
|
||||
Bei symmetrischer Kryptographie müssen beide Parteien denselben geheimen Schlüssel kennen – aber wie tauscht man ihn sicher aus, wenn nur ein unsicherer Kanal verfügbar ist?
|
||||
|
||||
### Merkle Puzzle (1974)
|
||||
|
||||
Alice erzeugt `n` verschlüsselte Rätsel mit je einer ID und einem Schlüssel. Bob löst zufällig eines davon (brute force, O(n)). Ein Angreifer muss im Durchschnitt `n/2` Rätsel lösen (O(n)). Vorteil ist quadratisch: O(n) Aufwand für Alice/Bob, O(n²) für Angreifer. Praktisch zu ineffizient.
|
||||
|
||||
### Idee: Virtual Black Box (VBB) Obfuscator
|
||||
|
||||
Idee: Ein Programm so verschleiern, dass man es zwar ausführen, aber nicht "verstehen" kann. Ein VBB-Obfuscator würde Public-Key-Kryptographie aus einer OWF ermöglichen. **Leider existiert kein allgemeiner VBB-Obfuscator** (Barak et al. 2001 bewiesen Unmöglichkeit). Schwächere Varianten (_Indistinguishability Obfuscation_, iO) sind noch Forschungsthema.
|
||||
|
||||
---
|
||||
|
||||
## Diffie-Hellman-Schlüsselaustausch
|
||||
|
||||
Ermöglicht zwei Parteien, über einen öffentlichen Kanal einen gemeinsamen geheimen Schlüssel zu vereinbaren.
|
||||
|
||||
```
|
||||
Öffentlich bekannt: Primzahl q, Generator α
|
||||
|
||||
Alice wählt Xₐ (geheim), sendet Yₐ = α^Xₐ mod q
|
||||
Bob wählt X_b (geheim), sendet Y_b = α^X_b mod q
|
||||
|
||||
Gemeinsames Geheimnis: K = α^(Xₐ·X_b) mod q
|
||||
```
|
||||
|
||||
Sicherheit basiert auf dem **Diskreten-Logarithmus-Problem (DLP)**: Gegeben `g`, `p` und `g^a mod p`, ist es schwer, `a` zu berechnen.
|
||||
|
||||
---
|
||||
|
||||
## Das Diskrete-Logarithmus-Problem (DLP)
|
||||
|
||||
**Definition:**
|
||||
|
||||
- Gegeben: Gruppe `G`, Generator `g`, Element `y = g^x`
|
||||
- Gesucht: `x = log_g(y)`
|
||||
|
||||
Das Berechnen von `g^x` ist effizient (schnelle Exponentiation: O(log x) Multiplikationen). Die Umkehrung (diskreter Logarithmus) ist für große Gruppen rechnerisch schwer (kein effizienter Algorithmus bekannt für klassische Computer).
|
||||
|
||||
---
|
||||
|
||||
## Einheitengruppe eines endlichen Körpers: ModP
|
||||
|
||||
Die Menge `ℤ_p* = {1, 2, ..., p-1}` mit Multiplikation modulo `p` (p prim) bildet eine **zyklische Gruppe** der Ordnung `p-1`.
|
||||
|
||||
- Es gibt einen **Generator** `g`, sodass `{g^0, g^1, ..., g^(p-2)} = ℤ_p*`
|
||||
- Für Diffie-Hellman wählt man `p` und `g` so, dass die Gruppe groß genug ist (heute ≥ 2048 Bit)
|
||||
|
||||
**Fermat'scher kleiner Satz:**
|
||||
`a^(p-1) ≡ 1 (mod p)` für alle `a` mit `ggT(a,p) = 1`
|
||||
|
||||
---
|
||||
|
||||
## Elliptische Kurven
|
||||
|
||||
Elliptische Kurven bieten dieselbe Sicherheit wie ModP-Gruppen, aber mit **viel kleineren Schlüsseln**.
|
||||
|
||||
**Kurvendefinition** (Weierstraß-Form):
|
||||
|
||||
```
|
||||
y² = x³ + ax + b (über einem Körper K)
|
||||
```
|
||||
|
||||
mit Bedingung `4a³ + 27b² ≠ 0` (keine Singularitäten).
|
||||
|
||||
### Gruppengesetz auf elliptischen Kurven
|
||||
|
||||
Punkte auf der Kurve bilden eine abelsche Gruppe mit:
|
||||
|
||||
- **Neutrales Element**: Punkt im Unendlichen `O`
|
||||
- **Addition** `P + Q`: Schneide die Linie durch `P` und `Q` mit der Kurve; reflektiere den dritten Schnittpunkt an der x-Achse
|
||||
- **Verdoppelung** `2P`: Tangente an `P`; reflektiere zweiten Schnittpunkt
|
||||
|
||||
### ECDLP (Elliptic Curve Discrete Logarithm Problem)
|
||||
Gegeben Punkte P und Q = k·P, finde k. Gilt als schwerer als DLP in ModP → kleinere Schlüssel möglich.
|
||||
|
||||
Schlüssel und Verschlüsselung mit elliptischen Kurven
|
||||
|
||||
Öffentliche Parameter (für alle gleich):
|
||||
- Kurve (a, b, Körper)
|
||||
- Basispunkt P auf der Kurve (= Generator)
|
||||
- Ordnung n von P
|
||||
|
||||
Schlüsselerzeugung:
|
||||
Privater Schlüssel: d (zufällig, 1 ≤ d ≤ n-1)
|
||||
Öffentlicher Schlüssel: Q = d·P (d-mal Punktaddition)
|
||||
|
||||
ECDH (Diffie-Hellman auf elliptischen Kurven):
|
||||
Alice wählt a (geheim), veröffentlicht A = a·P
|
||||
Bob wählt b (geheim), veröffentlicht B = b·P
|
||||
Gemeinsames Geheimnis: K = a·B = b·A = (ab)·P
|
||||
|
||||
→ Funktioniert, weil Punktmultiplikation kommutativ ist:
|
||||
a·(b·P) = b·(a·P)
|
||||
|
||||
→ Angreifer sieht P, A, B, müsste aber a oder b berechnen = ECDLP
|
||||
|
||||
---
|
||||
|
||||
## RSA (Rivest–Shamir–Adleman, 1977)
|
||||
|
||||
### Schlüsselgenerierung
|
||||
|
||||
```
|
||||
1. Wähle zwei große Primzahlen p, q
|
||||
2. n = p · q (öffentlich, RSA-Modulus)
|
||||
3. φ(n) = (p-1)(q-1) (Eulersche Phi-Funktion, geheim)
|
||||
4. Wähle e mit ggT(e, φ(n)) = 1 (öffentlicher Exponent, oft e = 65537)
|
||||
5. Berechne d = e⁻¹ mod φ(n) (privater Exponent)
|
||||
|
||||
Öffentlicher Schlüssel: (n, e)
|
||||
Privater Schlüssel: (n, d)
|
||||
```
|
||||
|
||||
### Ver- und Entschlüsselung
|
||||
|
||||
```
|
||||
Verschlüsselung: c = m^e mod n
|
||||
Entschlüsselung: m = c^d mod n
|
||||
```
|
||||
|
||||
Korrektheit folgt aus dem **Satz von Euler**: `m^(φ(n)) ≡ 1 (mod n)`, daher `m^(e·d) ≡ m (mod n)`.
|
||||
|
||||
---
|
||||
|
||||
## Das Faktorisierungsproblem
|
||||
|
||||
Sicherheit von RSA basiert auf der Annahme, dass es schwer ist, `n = p · q` in seine Primfaktoren zu zerlegen.
|
||||
|
||||
- Multiplikation `p · q → n`: effizient (O(log²n))
|
||||
- Faktorisierung `n → p, q`: schwer (bester klassischer Algorithmus: Zahlkörpersieb, subexponentiell aber nicht polynomial)
|
||||
|
||||
**Wichtig**: Faktorisierungsproblem ≠ RSA-Sicherheit direkt. Es ist nicht bewiesen, dass Faktorisierung äquivalent zu RSA-Brechen ist, aber kein besserer Angriff ist bekannt.
|
||||
|
||||
---
|
||||
|
||||
## Wie misst man Sicherheit? (3. Ansatz: IND-CCA)
|
||||
|
||||
**IND-CCA** (_Indistinguishability under Chosen Ciphertext Attack_) ist das stärkste gängige Sicherheitsmodell für Public-Key-Verschlüsselung.
|
||||
|
||||
Erweiterung des IND-CPA-Spiels: Der Angreifer darf zusätzlich ein **Decryption Oracle** befragen (außer für den Challenge-Ciphertext).
|
||||
|
||||
Setup:
|
||||
Challenger erzeugt Schlüsselpaar (k_e, k_d)
|
||||
Challenger schickt öffentlichen Schlüssel k_e an Angreifer
|
||||
Challenger wählt zufälliges Bit b ∈ {0,1}
|
||||
|
||||
Phase 1 (vor der Challenge):
|
||||
Angreifer darf beliebige Ciphertexte c₁, c₂, ... an den
|
||||
Challenger schicken und bekommt die Entschlüsselung zurück.
|
||||
→ Er hat also ein Entschlüsselungsorakel!
|
||||
|
||||
Challenge:
|
||||
Angreifer schickt zwei Nachrichten (M₀, M₁) an den Challenger
|
||||
Challenger verschlüsselt M_b (je nach seinem geheimen Bit)
|
||||
Angreifer bekommt den Ciphertext c zurück
|
||||
|
||||
Phase 2 (nach der Challenge):
|
||||
Angreifer darf weiterhin Ciphertexte entschlüsseln lassen
|
||||
ABER: er darf nicht c selbst zum Entschlüsseln schicken!
|
||||
|
||||
Ergebnis:
|
||||
Angreifer gibt sein Rateversuch b' aus
|
||||
Er gewinnt, wenn b' = b
|
||||
|
||||
Ein Schema ist **IND-CCA-sicher**, wenn kein effizienter Angreifer einen Vorteil `> negl(n)` hat.
|
||||
|
||||
**Naives RSA (textbook RSA) ist NICHT IND-CPA-sicher**, da es deterministisch ist. Lösung: Padding-Schemata.
|
||||
|
||||
---
|
||||
|
||||
## OAEP (Optimal Asymmetric Encryption Padding)
|
||||
|
||||
**OAEP** macht RSA probabilistisch und erreicht IND-CCA2-Sicherheit im Random-Oracle-Modell.
|
||||
|
||||
```
|
||||
Eingabe: Nachricht m, zufällige Seed r
|
||||
|
||||
X = (m || 0...0) XOR G(r) (G = Pseudozufallsfunktion)
|
||||
Y = r XOR H(X) (H = Hashfunktion)
|
||||
|
||||
RSA-Input: (X || Y)
|
||||
```
|
||||
|
||||
**Entschlüsselung**: RSA anwenden, dann OAEP umkehren. In der Praxis: **RSA-OAEP** aus PKCS#1 v2.x.
|
||||
|
||||
---
|
||||
|
||||
### ElGamal-Verschlüsselung
|
||||
Auf Diffie-Hellman basierendes Public-Key-Verfahren (Taher Elgamal, 1985).
|
||||
|
||||
#### Grundidee:
|
||||
Bei DH einigen sich beide Seiten auf ein gemeinsames Geheimnis.
|
||||
ElGamal nutzt das aus: Der Sender macht quasi einen "einmaligen DH"
|
||||
mit dem öffentlichen Schlüssel des Empfängers und maskiert damit
|
||||
die Nachricht.
|
||||
|
||||
#### Schlüsselgenerierung
|
||||
Wähle zyklische Gruppe G der Ordnung n mit Generator α
|
||||
Privater Schlüssel: a (zufällig, 1 ≤ a ≤ n-1)
|
||||
Öffentlicher Schlüssel: (α, α^a)
|
||||
→ α^a ist wie der öffentliche DH-Anteil des Empfängers
|
||||
|
||||
#### Verschlüsselung (probabilistisch)
|
||||
Sender will Nachricht m an Empfänger schicken:
|
||||
|
||||
Wähle zufälliges k (1 ≤ k ≤ n-1) ← jedes Mal ein neues!
|
||||
γ = α^k ← "einmaliger DH-Anteil" des Senders
|
||||
δ = m · (α^a)^k ← Nachricht maskiert mit dem
|
||||
gemeinsamen DH-Geheimnis
|
||||
Ciphertext: (γ, δ)
|
||||
|
||||
Wichtig: Durch das zufällige k ergibt dieselbe Nachricht jedes Mal
|
||||
einen anderen Ciphertext → probabilistisch, nicht deterministisch
|
||||
wie rohes RSA.
|
||||
|
||||
#### Entschlüsselung
|
||||
Empfänger kennt privaten Schlüssel a:
|
||||
|
||||
Berechne γ^a = (α^k)^a = α^(ka) ← gemeinsames DH-Geheimnis
|
||||
Berechne γ^(-a) ← Inverses davon
|
||||
m = δ · γ^(-a) ← Maskierung aufheben
|
||||
|
||||
#### Korrektheit:
|
||||
δ · γ^(-a) = m · (α^a)^k · (α^k)^(-a)
|
||||
= m · α^(ak) · α^(-ak)
|
||||
= m
|
||||
|
||||
#### Sicherheit:
|
||||
- Basiert auf der DDH-Annahme (Decisional Diffie-Hellman):
|
||||
Es ist nicht unterscheidbar, ob ein Tupel (α, α^a, α^k, α^(ak))
|
||||
oder (α, α^a, α^k, zufällig) vorliegt.
|
||||
- ElGamal ist IND-CPA-sicher unter DDH.
|
||||
- Aber NICHT IND-CCA-sicher: Ein Angreifer kann aus einem
|
||||
gültigen Ciphertext (γ, δ) einen neuen gültigen Ciphertext
|
||||
(γ, δ·m') erzeugen, der m·m' verschlüsselt (Malleability).
|
||||
|
||||
#### Nachteil:
|
||||
Ciphertext (γ, δ) ist doppelt so lang wie die Nachricht m,
|
||||
weil zwei Gruppenelemente übertragen werden müssen.
|
||||
|
||||
---
|
||||
|
||||
## Übersicht: Symmetrische vs. Asymmetrische Kryptographie
|
||||
|
||||
|Eigenschaft|Symmetrisch (z. B. AES, ChaCha20)|Asymmetrisch (z. B. RSA, ElGamal)|
|
||||
|---|---|---|
|
||||
|Schlüssel|Ein gemeinsamer geheimer Schlüssel|Schlüsselpaar (öffentlich/privat)|
|
||||
|Geschwindigkeit|Schnell|Langsam (10–1000× langsamer)|
|
||||
|Schlüsselaustausch|Problem (sicherer Kanal nötig)|Kein sicherer Kanal nötig|
|
||||
|Anwendung|Bulk-Datenverschlüsselung|Schlüsselaustausch, Signaturen|
|
||||
|Praxis|Beide kombiniert in **Hybrid-Kryptographie**||
|
||||
|
||||
In der Praxis: Asymmetrische Kryptographie tauscht einen Session-Key aus, der dann für symmetrische Verschlüsselung verwendet wird (z. B. TLS Handshake).
|
||||
411
Kryptografie/zusammenfassungen/kr3 - zusammenfassung.md
Normal file
411
Kryptografie/zusammenfassungen/kr3 - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,411 @@
|
|||
# KR3 – Zusammenfassung
|
||||
**Vorlesung:** Kryptographie & Rechnernetze 3
|
||||
**Dozent:** Prof. Dr. Björn Grohmann
|
||||
**Datum:** 02.03.2026
|
||||
|
||||
---
|
||||
## 1. Digitale Signaturen
|
||||
### Grundprinzip
|
||||
|
||||
Eine digitale Signatur ermöglicht es, die **Integrität**, **Authentizität** und **Non-Repudiation** (Nicht-Abstreitbarkeit) einer Nachricht zu gewährleisten.
|
||||
|
||||
**Ablauf:**
|
||||
|
||||
- **Sender:** Nachricht `M` + `PrivateKey` → Secure Signature Algorithm → `Sign`
|
||||
- **Empfänger:** Verifiziert mit `PublicKey`, berechnet `Sign'` und prüft `Sign == Sign'`
|
||||
|
||||
### Formale Algorithmen
|
||||
|
||||
|Algorithmus|Funktion|
|
||||
|---|---|
|
||||
|`keygen(1^k) → (sk, pk)`|Schlüsselpaar generieren|
|
||||
|`sign(m, sk) → σ`|Nachricht signieren|
|
||||
|`verify(σ, m, pk) → d`|Signatur verifizieren|
|
||||
|
||||
### Mögliche Angriffsziele (Adversarial Goals)
|
||||
|
||||
- **Total Break:** Angreifer Oscar kann Alices privaten Signieralgorithmus vollständig ableiten.
|
||||
- **Selective Forgery:** Oscar kann eine gültige Signatur für eine von jemand anderem gewählte Nachricht erstellen (mit nicht-vernachlässigbarer Wahrscheinlichkeit).
|
||||
- **Existential Forgery** _(relevant für Praxis)_: Oscar kann eine gültige Signatur für mindestens eine beliebige Nachricht erstellen.
|
||||
|
||||
---
|
||||
|
||||
## 2. Beispiel: RSA-Signatur
|
||||
|
||||
### Signaturformel
|
||||
|
||||
$$s = m^d \pmod{n}$$
|
||||
|
||||
- `s` = Signatur
|
||||
- `m` = zu signierende Nachricht
|
||||
- `d` = privater Exponent
|
||||
- `n` = öffentlicher Modulus
|
||||
|
||||
### Existential Forgery Attack gegen RSA
|
||||
|
||||
Oscar kennt Bobs öffentlichen Schlüssel `k_pub = (n, e)`. Er:
|
||||
|
||||
1. Wählt eine beliebige Signatur `s ∈ ℤ_n`
|
||||
2. Berechnet die „Nachricht": `x ≡ s^e mod n`
|
||||
3. Präsentiert Alice das Paar `(x, s)`
|
||||
|
||||
Alice verifiziert: `s^e ≡ x' mod n` → da `x' = x` → **gültige Signatur!**
|
||||
|
||||
> ⚠️ RSA ohne Padding ist anfällig für Existential Forgery!
|
||||
|
||||
---
|
||||
|
||||
## 3. RSA-PSS (Probabilistic Signature Scheme)
|
||||
|
||||
RSA-PSS verhindert die oben genannte Attacke durch gezieltes **Padding** vor der Signatur:
|
||||
|
||||
**Prozess:**
|
||||
|
||||
1. Nachricht `M` wird gehasht → `mHash`
|
||||
2. `M' = [8 × 0x00 Bytes | mHash | salt]` wird erneut gehasht → `H`
|
||||
3. `DB = [PS | 0x01 | salt]`
|
||||
4. `maskedDB = DB ⊕ MGF(H)` (Mask Generation Function)
|
||||
5. Encoded Message: `EM = [maskedDB | H | TF]`
|
||||
|
||||
---
|
||||
|
||||
## 4. ECDSA – Elliptic Curve Digital Signature Algorithm
|
||||
|
||||
### Signieren (Alice, Nachricht `m`)
|
||||
|
||||
1. `e = HASH(m)` (z.B. SHA-2)
|
||||
2. `z` = die `L_n` linksten Bits von `e`
|
||||
3. Wähle zufälliges `k ∈ [1, n-1]`
|
||||
4. Berechne Kurvenpunkt: `(x₁, y₁) = k × G` _(G = Generator der EC-Gruppe)_
|
||||
5. `r = x₁ mod n`
|
||||
6. `s = k⁻¹(z + r·d_A) mod n` _(d_A = geheimer Schlüssel von Alice)_
|
||||
7. Signatur: `(r, s)`
|
||||
|
||||
### Verifizieren (Bob)
|
||||
|
||||
1. Überprüfe, dass `Q_A` (Alices öffentlicher Schlüssel) ein gültiger Kurvenpunkt ist
|
||||
2. Berechne `e = HASH(m)`, `z` = linkste `L_n` Bits
|
||||
3. `u₁ = zs⁻¹ mod n`, `u₂ = rs⁻¹ mod n`
|
||||
4. `(x₁, y₁) = u₁ × G + u₂ × Q_A`
|
||||
5. Signatur gültig wenn `r ≡ x₁ (mod n)`
|
||||
|
||||
---
|
||||
|
||||
## 5. Zertifikate (Certificates)
|
||||
|
||||
### Kernproblem
|
||||
|
||||
> _Wie kann Alice sicher sein, dass ein Public Key wirklich zu Bob gehört?_
|
||||
|
||||
### Lösung: Certificate Authority (CA)
|
||||
|
||||
Eine vertrauenswürdige Instanz (CA) bestätigt die Identität einer Person und signiert deren Public Key mit ihrem eigenen Private Key.
|
||||
|
||||
**Inhalt eines Zertifikats (X.509):**
|
||||
|
||||
- Name, Organisation, Adresse, Land
|
||||
- Gültigkeitszeitraum
|
||||
- Public Key des Inhabers
|
||||
- Digitale Signatur der CA
|
||||
|
||||
### Zertifikatskette (Chain of Trust)
|
||||
|
||||
```
|
||||
Endnutzer-Zertifikat
|
||||
← signiert von CA
|
||||
CA-Zertifikat
|
||||
← signiert von Root CA
|
||||
Root CA (selbstsigniert, vertrauensanker)
|
||||
```
|
||||
|
||||
### X.509-Struktur (RFC 5280)
|
||||
|
||||
```
|
||||
Certificate ::= SEQUENCE {
|
||||
tbsCertificate TBSCertificate,
|
||||
signatureAlgorithm AlgorithmIdentifier,
|
||||
signature BIT STRING
|
||||
}
|
||||
```
|
||||
|
||||
### Zertifikatswiderruf
|
||||
|
||||
**CRL (Certificate Revocation List):** Wird periodisch heruntergeladen.
|
||||
**OCSP (Online Certificate Status Protocol):** Status wird bei Bedarf online abgefragt.
|
||||
|
||||
**Widerrufsgründe (RFC 5280):** `unspecified`, `keyCompromise`, `cACompromise`, `affiliationChanged`, `superseded`, `cessationOfOperation`, `certificateHold`, `removeFromCRL`, `privilegeWithdrawn`, `aACompromise`
|
||||
|
||||
---
|
||||
|
||||
## 6. Identity-Based Encryption (IBE)
|
||||
|
||||
**Grundidee (Boneh & Franklin, 2001):** Der öffentliche Schlüssel ist die **Identität** (z.B. eine E-Mail-Adresse), kein separater Schlüssel wird benötigt.
|
||||
|
||||
### Beteiligte Instanz: PKG (Private Key Generator)
|
||||
|
||||
- Kennt den Master-Key `sk_PKG`
|
||||
- Gibt nach Authentifizierung den privaten Schlüssel `sk_ID_Bob` heraus
|
||||
|
||||
### Mathematische Grundlage: Bilineare Abbildung
|
||||
|
||||
Eine bilineare Abbildung `ê: G₁ × G₁ → G₂` mit den Eigenschaften:
|
||||
|
||||
1. **Bilinear:** `ê(aP, bQ) = ê(P, Q)^ab`
|
||||
2. **Nicht-degeneriert**
|
||||
3. **Effizient berechenbar**
|
||||
|
||||
### IBE-Algorithmen (Boneh-Franklin)
|
||||
|
||||
- **Setup:** Generiert Parameter `(q, G₁, G₂, ê, n, P, P_pub, H₁, H₂)`, Master-Key `s ∈ ℤ_q*`
|
||||
- **Extract:** `d_ID = s · Q_ID` wobei `Q_ID = H₁(ID)`
|
||||
- **Encrypt:** `C = ⟨rP, M ⊕ H₂(g_ID^r)⟩` mit `g_ID = ê(Q_ID, P_pub)`
|
||||
- **Decrypt:** `V ⊕ H₂(ê(d_ID, U)) = M`
|
||||
|
||||
Das funktioniert, da: `e(d, U) = e(sQ, rP) = e(Q, sP)^r`
|
||||
|
||||
---
|
||||
|
||||
## 7. Historisches Beispiel: The Babington Plot (1586)
|
||||
|
||||
### Schichtenmodell der Kommunikationssicherheit
|
||||
|
||||
Das historische Beispiel mit Maria Stuart und Anthony Babington illustriert ein **dreischichtiges Sicherheitsmodell**:
|
||||
|
||||
|Schicht|Beschreibung|Akteure|
|
||||
|---|---|---|
|
||||
|**Conspiracy Layer**|Inhalt der geheimen Kommunikation|Maria Stuart ↔ Babington|
|
||||
|**Carrier Layer**|Übertragungsweg|Gilbert Gifford als Bote|
|
||||
|**Beer Barrel Layer**|Physisches Medium|Bierfass als Versteck|
|
||||
|
||||
### Security der einzelnen Schichten
|
||||
|
||||
**Beer Barrel Layer:** Walsingham kompromittierte das physische Medium (fing die Nachrichten ab).
|
||||
|
||||
**Carrier Layer:** Gilbert Gifford arbeitete als Doppelagent für Walsingham.
|
||||
|
||||
**Conspiracy Layer:**
|
||||
|
||||
- **Verschlüsselung:** Substitutionschiffre (angreifbar durch Frequenzanalyse)
|
||||
- **Authenticated Encryption:** AES-CTR-Mode + GMAC
|
||||
- **Schlüsselaustausch:** Diffie-Hellman (`a^x mod p` ↔ `a^y mod p`)
|
||||
- **Problem:** Man-in-the-Middle-Angriff möglich ohne Authentifizierung
|
||||
- **Lösung:** Public Key + digitale Signatur `Sign(sk_A, M)` + Zertifikate (PKI)
|
||||
|
||||
---
|
||||
|
||||
## 8. Transport Layer Security (TLS)
|
||||
|
||||
### Ziel (RFC 8446, TLS 1.3)
|
||||
|
||||
Sicherer Kanal zwischen zwei kommunizierenden Parteien mit:
|
||||
|
||||
- **Authentication:** Server wird immer, Client optional authentifiziert
|
||||
- **Confidentiality:** Daten nur für Endpunkte sichtbar
|
||||
- **Integrity:** Manipulationen werden erkannt
|
||||
|
||||
### Einordnung im OSI-Modell
|
||||
|
||||
TLS liegt zwischen **Session/Presentation Layer** (OSI 5/6) und **Transport Layer** (OSI 4):
|
||||
|
||||
```
|
||||
Application → TLS/SSL → TCP/UDP → Network → Data Link → Physical
|
||||
```
|
||||
|
||||
### TLS-Komponenten
|
||||
|
||||
- **Handshake Layer:** Handshake, Alert, Change Cipher Spec (nur für Kompatibilität in v1.3)
|
||||
- **Record Layer:** Fragmentierung, Kompression (entfernt in v1.3), Authentifizierung, Verschlüsselung
|
||||
|
||||
### TLS Handshake (vereinfacht)
|
||||
|
||||
```
|
||||
Client Server
|
||||
ClientHello (key_share, etc.) →
|
||||
← ServerHello, {EncryptedExtensions},
|
||||
{Certificate}, {CertificateVerify}, {Finished}
|
||||
{Certificate}, {CertificateVerify}, {Finished} →
|
||||
[Application Data] ↔ [Application Data]
|
||||
```
|
||||
|
||||
### TLS Key Exchange Modi
|
||||
|
||||
- **(EC)DHE** – Diffie-Hellman über finite Felder oder elliptische Kurven
|
||||
- **PSK-only** – Pre-Shared Key
|
||||
- **PSK mit (EC)DHE**
|
||||
|
||||
### SSL/TLS Versionshistorie
|
||||
|
||||
|Version|Jahr|Status|
|
||||
|---|---|---|
|
||||
|SSL 1.0|–|Unveröffentlicht|
|
||||
|SSL 2.0|1995|Deprecated 2011|
|
||||
|SSL 3.0|1996|Deprecated 2015|
|
||||
|TLS 1.0|1999|Deprecated 2021|
|
||||
|TLS 1.1|2006|Deprecated 2021|
|
||||
|TLS 1.2|2008|Noch in Nutzung|
|
||||
|**TLS 1.3**|**2018**|**Aktuell**|
|
||||
|
||||
### Bekannte TLS-Angriffe
|
||||
|
||||
> _"Attacks always get better; they never get worse"_
|
||||
|
||||
BEAST, POODLE, LOGJAM, RC4 (Harmful?), Heartbleed, LUCKY 13, Raccoon Attack, ALPACA Attack, TLS-RENEGOTIATION, u.v.m.
|
||||
|
||||
### Cipher-Sicherheit (Auswahl)
|
||||
|
||||
- **Sicher in TLS 1.3:** AES-GCM, AES-CCM, ChaCha20-Poly1305
|
||||
- **Unsicher/Entfernt:** AES-CBC (abhängig von Mitigations), 3DES, RC4 (verboten in TLS 1.1+)
|
||||
- **Datenintegrität in TLS 1.3:** Nur AEAD
|
||||
|
||||
### TLS-Anwendungsprotokolle
|
||||
|
||||
|Protokoll|Beschreibung|
|
||||
|---|---|
|
||||
|HTTPS|HTTP über TLS/TCP|
|
||||
|SMTPS|Sicheres Mail-Transfer-Protokoll|
|
||||
|POP3S|Post-Office-Protokoll (sicher)|
|
||||
|IMAPS|Internet Message Access (sicher)|
|
||||
|FTPS|File Transfer (sicher)|
|
||||
|SIPS|Session Initiation (sicher)|
|
||||
|
||||
---
|
||||
|
||||
## 9. QUIC
|
||||
|
||||
QUIC kombiniert TLS-Sicherheit mit UDP-basiertem Transport und ersetzt den TCP+TLS-Stack:
|
||||
|
||||
```
|
||||
Traditionell: HTTP/2 | TLS | TCP | IP
|
||||
QUIC: HTTP/2 | QUIC (Multistream, Encryption, Congestion, Reliability) | UDP | IP
|
||||
```
|
||||
|
||||
**QUIC-Vorteile:** Eingebettete Verschlüsselung, Multistream, schnellerer Handshake (0-RTT möglich), bessere Performance bei Paketverlusten.
|
||||
|
||||
---
|
||||
|
||||
## 10. IPSec
|
||||
|
||||
IPSec arbeitet auf **Layer 3 (Network Layer)** des OSI-Modells.
|
||||
|
||||
### Modi
|
||||
|
||||
**Tunnel Mode:** Das gesamte ursprüngliche IP-Paket wird verschlüsselt und in ein neues IP-Paket eingebettet (Gateway zu Gateway).
|
||||
|
||||
### Protokolle
|
||||
|
||||
|Header|Bietet|
|
||||
|---|---|
|
||||
|**AH (Authentication Header)**|Authentifizierung des gesamten Pakets (kein Verschlüsseln)|
|
||||
|**ESP (Encapsulating Security Payload)**|Verschlüsselung + Authentifizierung der Daten|
|
||||
|
||||
---
|
||||
|
||||
## 11. Quantenmechanik – Grundlagen
|
||||
|
||||
### Relevante Phänomene
|
||||
|
||||
- **Nondeterminismus:** Messung eines Quantenzustands ergibt zufälliges, nicht vorhersagbares Ergebnis → echte Zufallszahlengeneratoren (QRNG)
|
||||
- **Superposition:** Ein Qubit kann gleichzeitig `|0⟩` und `|1⟩` sein: `1/√2 |alive⟩ + 1/√2 |dead⟩`
|
||||
- **Verschränkung (Entanglement):** Zwei Qubits sind korreliert, auch über Distanz: `|↑⟩|↑⟩ + |↓⟩|↓⟩`
|
||||
- **Unschärfe (Uncertainty):** Heisenbergsche Unschärferelation – Ort und Impuls nicht gleichzeitig exakt messbar
|
||||
|
||||
---
|
||||
|
||||
## 12. Quantum Key Distribution – BB84 Protokoll
|
||||
|
||||
**Erfinder:** Charles Bennett & Gilles Brassard (1984)
|
||||
|
||||
### Ablauf
|
||||
|
||||
1. Alice wählt zufällige Bits und kodiert sie in Photonen (mit zufällig gewählten Basen)
|
||||
2. Bob misst die Photonen mit zufällig gewählten Basen
|
||||
3. Alice und Bob vergleichen ihre Basen (öffentlich)
|
||||
4. Bits mit übereinstimmenden Basen ergeben den **Sifted Key**
|
||||
|
||||
**Sicherheit:** Jede Messung durch Eve verändert den Quantenzustand (Messung = Störung). In 25 % der Fälle führt Eves Abhören zu einem Bitfehler → Eve ist **nachweisbar**.
|
||||
|
||||
### No-Cloning-Theorem
|
||||
|
||||
Quantenzustände können **nicht kopiert** werden → klassische Repeater funktionieren nicht → Lösung: **Quantum Repeater**
|
||||
|
||||
### Satellite-QKD
|
||||
|
||||
BB84 über Satelliten ermöglicht Quantenkommunikation über >1000 km (z.B. Micius-Satellit).
|
||||
|
||||
---
|
||||
|
||||
## 13. Quantencomputer & Auswirkungen auf Kryptographie
|
||||
|
||||
### Shors Algorithmus
|
||||
|
||||
Peter Shor (1994): Kann **ganzzahlige Faktorisierung** und **diskrete Logarithmen** in **polynomialer Zeit** lösen.
|
||||
|
||||
**Konsequenz:**
|
||||
|
||||
|Algorithmus|Verwendung|Pre-Shor-Sicherheit|Post-Shor-Sicherheit|
|
||||
|---|---|---|---|
|
||||
|RSA-3072|Verschlüsselung/Signatur|128 Bit|**keine**|
|
||||
|DH-3072|Schlüsselaustausch|128 Bit|**keine**|
|
||||
|DSA-3072|Signatur|128 Bit|**keine**|
|
||||
|256-bit ECDH/ECDSA|Schlüsselaustausch/Signatur|128 Bit|**keine**|
|
||||
|
||||
### Grovers Algorithmus
|
||||
|
||||
Lov Grover: Findet eine Nadel im Heuhaufen der Größe N in **O(√N)** Schritten.
|
||||
|
||||
**Konsequenz:** Halbierung der effektiven Schlüssellänge symmetrischer Verfahren.
|
||||
|
||||
|Algorithmus|Pre-Grover-Sicherheit|Post-Grover-Sicherheit|
|
||||
|---|---|---|
|
||||
|AES-128|128 Bit|**64 Bit**|
|
||||
|AES-256|256 Bit|128 Bit ✓|
|
||||
|SHA-256|256 Bit*|128 Bit* ✓|
|
||||
|SHA-3|256 Bit*|128 Bit* ✓|
|
||||
|
||||
### Simons Algorithmus
|
||||
|
||||
Löst Simons Problem exponentiell schneller als klassische Algorithmen:
|
||||
|
||||
- Klassisch: `Ω(2^(n/2))` Anfragen
|
||||
- Quantum: `O(n)` Anfragen
|
||||
|
||||
### Im Quantenzeitalter gebrochene Konstruktionen
|
||||
|
||||
Durch quantenbasierte Angriffe (insbesondere via Simons Algorithmus) sind viele klassische Konstruktionen **gebrochen**:
|
||||
|
||||
- Even-Mansour
|
||||
- 3-Runden-Feistel
|
||||
- LRW
|
||||
- CBC-MAC
|
||||
- GMAC
|
||||
- PMAC
|
||||
- GCM
|
||||
- OCB
|
||||
- … (und viele weitere)
|
||||
|
||||
> ⚠️ Dies motiviert die Notwendigkeit von **Post-Quantum Cryptography (PQC)**.
|
||||
|
||||
---
|
||||
|
||||
## Überblick: Key Takeaways
|
||||
|
||||
|Thema|Kernaussage|
|
||||
|---|---|
|
||||
|Digitale Signaturen|Bieten Integrität, Authentizität, Non-Repudiation|
|
||||
|RSA-Signatur|Ohne Padding anfällig für Existential Forgery|
|
||||
|RSA-PSS|Sicheres Padding schützt vor Forgery-Angriffen|
|
||||
|ECDSA|Effizientere Alternative zu RSA auf Basis elliptischer Kurven|
|
||||
|Zertifikate (X.509)|PKI löst das Problem der Public-Key-Authentizität|
|
||||
|IBE|Identität als öffentlicher Schlüssel, PKG verteilt private Schlüssel|
|
||||
|TLS 1.3|Modernes Protokoll: AEAD, keine Kompression, PFS durch (EC)DHE|
|
||||
|QUIC|TLS-Sicherheit direkt in UDP eingebettet, schnellerer Verbindungsaufbau|
|
||||
|IPSec|Sicherheit auf Netzwerkschicht, Tunnel- und Transportmodus|
|
||||
|Quantenmechanik|Nondeterminismus, Superposition, Verschränkung als Grundlage für QKD|
|
||||
|BB84|Quantenschlüsselaustausch, sicher durch No-Cloning-Theorem|
|
||||
|Shors Algorithmus|Bricht RSA, DH, ECDH, ECDSA vollständig|
|
||||
|Grovers Algorithmus|Halbiert effektive Schlüssellänge symmetrischer Verfahren|
|
||||
|Post-Quantum-Krypto|Notwendigkeit neuer quantenresistenter Verfahren|
|
||||
|
||||
---
|
||||
|
||||
_Tags: #Kryptographie #TLS #Signaturen #RSA #ECDSA #Zertifikate #IBE #QuantumCryptography #BB84 #PostQuantum #HWR_
|
||||
338
Kryptografie/zusammenfassungen/kr4 - zusammenfassung.md
Normal file
338
Kryptografie/zusammenfassungen/kr4 - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,338 @@
|
|||
# Zusammenfassung Vorlesung 4
|
||||
**Hochschule für Wirtschaft und Recht Berlin – 09.03.2026** **Folien 79–139 (61 Folien)**
|
||||
|
||||
---
|
||||
## 1. Komplexitätsklassen-Übersicht (Folien 79, 101)
|
||||
Die Vorlesung beginnt mit einem Venn-Diagramm der wichtigsten Komplexitätsklassen und ordnet kryptographische Probleme darin ein:
|
||||
|
||||
- **P** liegt im Zentrum als Klasse der effizient lösbaren Probleme.
|
||||
- **NP** und **Co-NP** umschließen P und überlappen sich teilweise.
|
||||
- **PP** enthält NP und beherbergt MAJSAT.
|
||||
- **PSPACE** ist die äußerste dargestellte Klasse und umfasst alle anderen, inklusive LEMMINGS.
|
||||
- **BQP** (Bounded-Error Quantum Polynomial Time) erstreckt sich als grüne Fläche über mehrere Klassen hinweg – es überlappt mit NP, Co-NP und ragt teils über P hinaus.
|
||||
- **Co-AM** umfasst große Teile von Co-NP und BQP.
|
||||
|
||||
**Einordnung kryptographischer Probleme:**
|
||||
- **DLOG** (Diskreter Logarithmus) und **RSA** liegen in der Schnittmenge von NP ∩ Co-NP, nahe an P.
|
||||
- **SAT** liegt in NP (aber außerhalb von P, sofern P ≠ NP).
|
||||
- **Co-SAT** liegt in Co-NP.
|
||||
- **GI** (Graph-Isomorphismus) liegt in NP ∩ Co-AM ∩ BQP.
|
||||
- **MAJSAT** liegt in PP.
|
||||
- **LEMMINGS** liegt in PSPACE, aber außerhalb von NP und Co-NP.
|
||||
|
||||
Auf Folie 101 wird das gleiche Diagramm erneut gezeigt, nun ergänzt um **GapSVP_γ** (das zentrale Gitterproblem). Je nach Approximationsfaktor γ wandert GapSVP_γ zwischen verschiedenen Komplexitätsklassen: Bei γ ~ 1 liegt es nahe an NP-hart, bei γ ~ √n oder größer nähert es sich P an. Die dargestellten Werte sind γ ~ 1, 2^{(log n)^{1-ε}}, √(n/log n), √n und 2^{n(log log n)²/log n}.
|
||||
|
||||
---
|
||||
## 2. PQC-Strategien – Überblick (Folie 80)
|
||||
Post-Quantum Cryptography (PQC) verfolgt verschiedene Ansätze, um Kryptographie gegen Quantencomputer abzusichern:
|
||||
|
||||
- **Lattice-based** (Gitter-basiert)
|
||||
- **Code-based** (Code-basiert)
|
||||
- **Multivariate polynomials** (Multivariate Polynome)
|
||||
- **Isogenies** (Isogenien)
|
||||
- **Hash-based** (Hash-basiert)
|
||||
- **Trotziges Kind** (humorvolle Bezeichnung für den „PQ-RSA"-Ansatz)
|
||||
- **MPC in the Head**
|
||||
- und weitere
|
||||
|
||||
---
|
||||
|
||||
## 3. „Trotziges Kind" – PQ-RSA (Folie 81)
|
||||
Der Ansatz „Trotziges Kind" beschreibt die Idee, RSA einfach mit extrem großen Parametern weiterzuverwenden, anstatt auf neue Algorithmen umzusteigen:
|
||||
|
||||
- **PQ-RSA**: RSA mit einem Modulus von ca. **1 Terabyte**, zusammengesetzt als Produkt von **4096-Bit-Primzahlen**.
|
||||
- **Kosten für einen Quantenangreifer**: ca. **2^100** Operationen.
|
||||
- **Kosten für den Besitzer des geheimen Schlüssels**: ca. **2^50** Operationen.
|
||||
|
||||
Dieser Ansatz ist zwar theoretisch sicher, aber aufgrund der enormen Schlüsselgrößen praktisch kaum umsetzbar.
|
||||
|
||||
---
|
||||
## 4. Hash-basierte Kryptographie (Folien 82–85)
|
||||
|
||||
### Grundprinzip (Folie 82)
|
||||
Bei hash-basierten Signaturen besteht das Schlüsselpaar aus:
|
||||
- **Öffentlicher Schlüssel**: Paar von Hash-Werten h(x) || h(y)
|
||||
- **Privater Schlüssel**: Das Paar (x, y) selbst
|
||||
|
||||
### Merkle-Baum (Folie 83)
|
||||
Ein binärer Hash-Baum wird dargestellt mit Ebenen j = 0 (Blätter) bis j = h (Wurzel). Die Blätter enthalten Einmal-Signaturen (z. B. Lamport- oder Winternitz-Signaturen). Die inneren Knoten werden durch Hashing ihrer Kindknoten berechnet. Ein Authentifizierungspfad (grau markierte Knoten) ermöglicht die Verifikation.
|
||||
|
||||
### XMSS-Konstruktion (Folie 84)
|
||||
Die erweiterte Darstellung zeigt die Konstruktion des Knotens N_{i,j}:
|
||||
- Zwei Kindknoten N_{2i,j-1} und N_{2i+1,j-1} werden zusammen mit einer Bitmaske Q_j per XOR verknüpft.
|
||||
- Das Ergebnis wird gehasht (H), um den Elternknoten zu erzeugen.
|
||||
|
||||
### SPHINCS-Hypertree (Folie 85)
|
||||
SPHINCS verwendet eine hierarchische Baumstruktur:
|
||||
- Mehrere TREE-Ebenen (TREE_{d-1}, TREE_{d-2}, ..., TREE_0) mit jeweils Höhe h/d.
|
||||
- Jede Ebene signiert die nächste mit einer Winternitz-Signatur (σ_{W,i}).
|
||||
- Am Ende steht ein HORST-Baum (Höhe log t) mit der eigentlichen Nachrichtensignatur σ_H.
|
||||
|
||||
---
|
||||
|
||||
## 5. Isogenien-basierte Kryptographie (Folien 86–89)
|
||||
|
||||
### Elliptische Kurven (Folie 86)
|
||||
Grundlage ist die Punktaddition auf elliptischen Kurven: Gegeben zwei Punkte P und Q auf einer Kurve, ergibt die geometrische Konstruktion (Gerade durch P und Q, Schnittpunkt mit der Kurve, Spiegelung) den Punkt R = P + Q.
|
||||
|
||||
### Skalare Multiplikation (Folie 87)
|
||||
Die Abbildung [n]: E → E multipliziert einen Punkt n-mal mit sich selbst: [n]P = P + P + ... + P (n-mal). Als Beispiel wird die Kurve E: y² = x³ + x gezeigt, für die die Verdopplungsabbildung [2] durch eine explizite rationale Funktion gegeben ist.
|
||||
|
||||
### Isogenien (Folie 88)
|
||||
Eine Isogenie φ: E → E' ist ein Gruppenhomomorphismus zwischen elliptischen Kurven, gegeben durch rationale Funktionen: φ(x,y) = (f₁(x,y)/g₁(x,y), f₂(x,y)/g₂(x,y)).
|
||||
|
||||
### SIDH-Schlüsselaustausch (Folie 89)
|
||||
Das Protokoll funktioniert analog zu Diffie-Hellman, aber mit Isogenien statt Exponentialfunktionen:
|
||||
|
||||
- Alice sendet (Φ_A(E), Δ_A) an Bob.
|
||||
- Bob sendet (Φ_B(E), Δ_B) an Alice.
|
||||
- Beide berechnen denselben j-Invarianten als gemeinsames Geheimnis: j(Φ'_A(Φ_B(E))) = k = j(Φ'_B(Φ_A(E))).
|
||||
|
||||
---
|
||||
|
||||
## 6. Multivariate Polynome (Folien 90–92)
|
||||
|
||||
### Hilberts 10. Problem (Folie 90)
|
||||
Die Folie zeigt ein Porträt von Hilbert und zitiert sein 10. Problem (auf Deutsch): Gegeben eine diophantische Gleichung, soll ein Verfahren angegeben werden, das in endlich vielen Schritten entscheidet, ob sie ganzzahlig lösbar ist. (Dieses Problem ist bekanntlich unentscheidbar – Matijasevic, 1970.)
|
||||
|
||||
### MQ-Problem (Folie 91)
|
||||
|
||||
Das System besteht aus m quadratischen Polynomen in n Variablen über einem endlichen Körper 𝔽_q:
|
||||
|
||||
p^(k)(x₁,...,xₙ) = Σ γ_{ij}^(k) xᵢxⱼ + Σ β_i^(k) xᵢ + α^(k)
|
||||
|
||||
Das **MQ-Problem** (Multivariate Quadratic): Gegeben eine quadratische Polynomabbildung 𝒫: 𝔽_q^n → 𝔽_q^m, finde x ∈ 𝔽_q^n mit 𝒫(x) = 0. Dieses Problem ist NP-hart.
|
||||
|
||||
### Oil-and-Vinegar-Konstruktion (Folie 92)
|
||||
Die Signatur basiert auf einer Trapdoor-Struktur:
|
||||
|
||||
- **Öffentlicher Schlüssel**: Die zusammengesetzte Abbildung 𝒫(x) = h(m), wobei 𝒫 = T ∘ 𝒬 ∘ S.
|
||||
- T und S sind geheime affine Transformationen (invertierbar).
|
||||
- 𝒬 ist ein System mit spezieller Struktur, das effizient invertierbar ist.
|
||||
- Die „Oil-and-Vinegar"-Variablen (symbolisiert durch Öl- und Essigflaschen) erzeugen die Trapdoor.
|
||||
|
||||
---
|
||||
|
||||
## 7. Code-basierte Kryptographie (Folien 93–95)
|
||||
|
||||
### Binary Symmetric Channel (Folie 93)
|
||||
Die Folie zeigt ein Porträt von Claude Shannon und das Modell eines binären symmetrischen Kanals: Bits werden mit Wahrscheinlichkeit (1-p) korrekt übertragen und mit Wahrscheinlichkeit p verfälscht.
|
||||
|
||||
### Syndrome-Decoding / Coset Weights (Folie 94)
|
||||
|
||||
Grundlegende Konstruktion:
|
||||
- Ein Codewort c gehört zum Code 𝒞 ⊆ 𝔽₂ⁿ genau dann, wenn cH = 0 (H ist die Prüfmatrix).
|
||||
- Ein empfangenes Wort (c + e) hat das Syndrom s = eH.
|
||||
- **Coset-Weights-Problem**: Gegeben s und H, finde x mit Gewicht ν(x) ≤ t und xH = s.
|
||||
|
||||
### McEliece-Kryptosystem (Folie 95)
|
||||
- **Öffentlicher Schlüssel**: H* = PHS, wobei P eine Permutationsmatrix und S eine invertierbare Matrix ist.
|
||||
- **Verschlüsselung**: c = mH*
|
||||
- **Entschlüsselung**: m = δ_H(cS⁻¹)P⁻¹, wobei δ_H der effiziente Dekodieralgorithmus für den geheimen Code ist.
|
||||
|
||||
Die Sicherheit beruht darauf, dass das allgemeine Dekodierungsproblem NP-hart ist, während der Besitzer von P, H und S effizient dekodieren kann.
|
||||
|
||||
---
|
||||
## 8. Gitter-basierte Kryptographie (Folien 96–103)
|
||||
|
||||
### Gitter-Grundlagen (Folien 96–99)
|
||||
Ein Gitter wird durch Basisvektoren b₁ und b₂ aufgespannt. Die Punkte bilden ein regelmäßiges Muster im Raum.
|
||||
|
||||
- **Folie 97**: Das Closest Vector Problem (CVP) wird illustriert – ein Punkt (rot markiert) nahe einem Gitterpunkt soll dem nächsten Gitterpunkt zugeordnet werden.
|
||||
- **Folie 98**: Basisreduktion wird gezeigt – der Vektor b₁ - b₂ (rot) ist kürzer als b₁ und liefert eine „bessere" Basis.
|
||||
- **Folie 99**: Das Shortest Vector Problem (SVP) wird visualisiert – der kürzeste Nicht-Null-Vektor im Gitter liegt in einem Ring (Donut-förmige Region) um den Ursprung.
|
||||
|
||||
### GapSVP_γ (Folie 100)
|
||||
Das Entscheidungsproblem GapSVP_γ ist formal definiert:
|
||||
|
||||
- **Eingabe**: Basis **B**, Distanz d.
|
||||
- **Ausgabe**: „Yes", falls λ(**B**) ≤ d; „No", falls λ(**B**) > γd; sonst beliebig.
|
||||
|
||||
### Worst-Case zu Average-Case Reduktion (Folie 102)
|
||||
Ein zentraler Vorteil gitter-basierter Kryptographie: Es existieren **Worst-Case-zu-Average-Case-Reduktionen** von GapSVP_γ zu den Problemen **LWE** (Learning With Errors) und **SIS** (Short Integer Solution) für γ = poly(n). Das bedeutet: Wenn LWE/SIS im Durchschnitt leicht wäre, wäre GapSVP im schlimmsten Fall leicht – was als unwahrscheinlich gilt.
|
||||
|
||||
### Regev's Public-Key-Kryptosystem (Folie 103)
|
||||
Ein konkretes Beispiel basierend auf LWE:
|
||||
|
||||
- **Privater Schlüssel**: s ∈ ℤ_q^n, zufällig gewählt.
|
||||
- **Öffentlicher Schlüssel**: m Paare (aᵢ, bᵢ) mit bᵢ = ⟨aᵢ, s⟩/q + eᵢ, wobei eᵢ aus einer Fehlerverteilung χ stammt und 𝕋 = ℝ/ℤ.
|
||||
- **Verschlüsselung** eines Bits x: Wähle eine zufällige Teilmenge S ⊂ [m], berechne Enc(x) = (Σᵢ∈S aᵢ, x/2 + Σᵢ∈S bᵢ).
|
||||
- **Entschlüsselung**: Prüfe, ob b - ⟨a, s⟩/q näher an 0 oder an 1/2 liegt.
|
||||
|
||||
Das LWE-Problem besteht darin, s aus den verrauschten Skalarprodukt-Samples zu bestimmen.
|
||||
|
||||
---
|
||||
|
||||
## 9. Wie dringend ist die Quantenbedrohung? (Folien 104–107)
|
||||
### Moscas Theorem (Folie 105)
|
||||
Drei Zeitparameter werden definiert:
|
||||
|
||||
- **x**: Wie lange muss die Verschlüsselung sicher bleiben?
|
||||
- **y**: Wie lange dauert die Umstellung bestehender Infrastruktur auf quantensichere Lösungen?
|
||||
- **z**: Wie lange dauert es, bis ein großskaliger Quantencomputer gebaut wird?
|
||||
|
||||
**Moscas Theorem**: Falls **x + y > z**, dann sollte man sich **jetzt** Sorgen machen. Denn wenn die Umstellungszeit plus die Geheimhaltungsdauer die Zeit bis zum Quantencomputer übersteigt, sind heutige Daten bereits gefährdet („Harvest now, decrypt later").
|
||||
|
||||
### Gartner Hype Cycles (Folien 106–107)
|
||||
- **2017**: Quantum Computing befindet sich am Anfang des „Innovation Trigger", mit einer geschätzten Reife von „mehr als 10 Jahren".
|
||||
- **2018**: Quantum Computing ist weiter aufgestiegen (Richtung „Peak of Inflated Expectations"), die Reifeschätzung bleibt bei „5–10 Jahren".
|
||||
|
||||
---
|
||||
|
||||
## 10. NIST PQC-Standardisierung (Folie 108)
|
||||
- **1. Runde** startete im November 2017 mit **69 Kandidaten**.
|
||||
- **Ausgewählte Algorithmen** (2022):
|
||||
- **CRYSTALS-Kyber** – Key Encapsulation Mechanism (KEM)
|
||||
- **CRYSTALS-Dilithium** – Digitale Signatur (DSA)
|
||||
- **Falcon** – Digitale Signatur (DSA)
|
||||
- **SPHINCS+** – Digitale Signatur (DSA)
|
||||
- **2022–2024**: Entwürfe der Standards wurden veröffentlicht.
|
||||
|
||||
---
|
||||
|
||||
## 11. Drei Dimensionen des Datenschutzes (Folie 109)
|
||||
Daten existieren in drei Zuständen, die jeweils unterschiedliche Schutzziele erfordern:
|
||||
|
||||
- **Data at rest** (Daten in Ruhe): Vertraulichkeit, Integrität, ...
|
||||
- **Data in transit** (Daten in Übertragung): Vertraulichkeit, Integrität, Authentizität, ...
|
||||
- **Data in use** (Daten in Verarbeitung): Vertraulichkeit, ...
|
||||
|
||||
Das Modell zeigt den Datenfluss: Quelldaten (Input Parties) → Statistische Analyse (Computing Parties) → Statistische Produkte (Result Parties).
|
||||
|
||||
---
|
||||
|
||||
## 12. Weitere Schutzziele (Folien 110–111)
|
||||
Über die klassischen Schutzziele hinaus gibt es:
|
||||
|
||||
- **Input Privacy**: Schutz der Eingabedaten der Datenlieferanten.
|
||||
- **Output Privacy**: Schutz der Ergebnisse vor unberechtigtem Zugriff.
|
||||
- **Policy Enforcement**: Durchsetzung von Nutzungsregeln.
|
||||
|
||||
Das Diagramm auf Folie 111 zeigt diese drei Ziele im Kontext des Datenflusses: Input Privacy umschließt die Quelldaten, Output Privacy die statistischen Produkte, und Policy Enforcement umrahmt das Gesamtsystem.
|
||||
|
||||
---
|
||||
|
||||
## 13. Privacy Goals and Technologies (Folie 112)
|
||||
Ein Venn-Diagramm zeigt die Beziehung zwischen den drei Privacy-Zielen und Technologien:
|
||||
|
||||
- **Policy Enforcement** wird durch _Non-Disclosure Agreements_ (NDAs) und ähnliche vertragliche Maßnahmen adressiert.
|
||||
- **Input Privacy** und **Output Privacy** überlappen sich im Bereich der _Aggregation_ (statistische Zusammenfassung als Datenschutzmaßnahme).
|
||||
|
||||
---
|
||||
|
||||
## 14. Homomorphe Verschlüsselung (Folien 113–125)
|
||||
### Grundidee (Folien 113–117)
|
||||
Die zentrale Frage: „Kann man nicht auch auf verschlüsselten Daten rechnen?"
|
||||
|
||||
Homomorphe Verschlüsselung ermöglicht es, eine Funktion f auf verschlüsselten Daten auszuführen, ohne die Daten zu entschlüsseln:
|
||||
|
||||
- Aus **Enc(m)** wird direkt **Enc(f(m))** berechnet.
|
||||
- Die Kerngleichung: **Enc(m₁) ⋆ Enc(m₂) = Enc(m₁ ∘ m₂)**, wobei ⋆ eine Operation auf Chiffretexten und ∘ die entsprechende Operation auf Klartexten ist.
|
||||
|
||||
### Klassifizierung (Folie 118)
|
||||
Es gibt drei Stufen homomorpher Verschlüsselung, dargestellt als Trade-off zwischen Performance und Funktionalität:
|
||||
|
||||
- **PHE** (Partially Homomorphic Encryption): Unterstützt **eine Operation** (z. B. nur Addition oder nur Multiplikation), diese aber beliebig oft. Höchste Performance.
|
||||
- **SWHE** (Somewhat Homomorphic Encryption): Unterstützt **zwei Operationen**, mindestens eine davon ist in der Anzahl beschränkt.
|
||||
- **FHE** (Fully Homomorphic Encryption): Volle, unbeschränkte Funktionalität für beliebige Berechnungen. Niedrigste Performance.
|
||||
|
||||
### Beispiel: RSA als PHE (Folie 119)
|
||||
RSA ist multiplikativ homomorph:
|
||||
|
||||
- E(M₁) · E(M₂) = E(M₁ · M₂)
|
||||
- Das Produkt zweier Chiffretexte entspricht dem Chiffretext des Produkts der Klartexte.
|
||||
- RSA unterstützt also beliebig viele Multiplikationen auf Chiffretexten.
|
||||
|
||||
### Beispiel: Paillier als PHE (Folien 120–121)
|
||||
Paillier ist **additiv homomorph**:
|
||||
|
||||
- Schlüsselerzeugung: n = p·q, g = n+1, λ = φ(n), μ = φ(n)⁻¹ mod n.
|
||||
- Verschlüsselung: c = g^m · r^n mod n².
|
||||
- Entschlüsselung: m = L(c^λ mod n²) · μ mod n, mit L(x) = (x-1)/n.
|
||||
- **Homomorphe Eigenschaft**: D(E(m₁,r₁) · E(m₂,r₂) mod n²) = m₁ + m₂ mod n.
|
||||
- Das Produkt zweier Chiffretexte entspricht der **Summe** der Klartexte.
|
||||
|
||||
### Beispiel: SWHE (Folien 122–123)
|
||||
Ein einfaches SWHE-Schema wird vorgestellt:
|
||||
|
||||
- **Verschlüsselung** eines Bits b: c₁ = b₁ + 2r₁ + r₂p, wobei b das Nachrichtenbit, r₁ und r₂ zufällige Werte und p eine geheime Primzahl sind.
|
||||
- **Entschlüsselung**: Erst modulo p (entfernt r₂p), dann modulo 2 (entfernt 2r₁), ergibt b.
|
||||
- **Addition**: c₁ + c₂ = b₁ + b₂ + 2(r₁ + s₁) + p(r₂ + s₂) → Berechnung in GF(2), also XOR der Klartextbits.
|
||||
- **Multiplikation**: c₁ · c₂ = b₁b₂ + 2(…) + p(…) → AND der Klartextbits.
|
||||
- **Einschränkung**: Die Fehlerwerte wachsen bei Multiplikation, daher ist die Tiefe der Berechnungen beschränkt (Anforderungen an die Intervalle der r's und s's).
|
||||
|
||||
### HE vs. Klassischer Ansatz (Folien 124–125)
|
||||
**Klassisch** (Folie 124): Daten werden verschlüsselt übertragen, aber für die Verarbeitung entschlüsselt. Der Server sieht die Klartextdaten.
|
||||
|
||||
**Homomorphe Verschlüsselung** (Folie 125): Daten bleiben durchgehend verschlüsselt. Der Evaluationsalgorithmus arbeitet auf verschlüsselten Daten und liefert verschlüsselte Ergebnisse zurück. Nur der Datenbesitzer kann mit seinem privaten Schlüssel entschlüsseln. Mehrere verschlüsselte Datensätze können kombiniert werden, ohne dass der Verarbeiter die Rohdaten sieht.
|
||||
|
||||
---
|
||||
|
||||
## 15. Multi-Party Computation – MPC (Folien 126–132)
|
||||
### Millionärsproblem (Folie 126)
|
||||
|
||||
Die Motivationsfrage (in Anlehnung an Yaos Millionärsproblem): „Wie können Lucy und Linus herausfinden, wer von beiden mehr Bonbons besitzt, ohne die Anzahl ihrer Bonbons preiszugeben?"
|
||||
|
||||
### Grundmodell (Folien 127–129)
|
||||
- **Ideales Modell** (Folie 128): Beide Parteien senden ihre geheimen Eingaben A und B an eine vertrauenswürdige dritte Partei, die f(A, B) berechnet und das Ergebnis zurückgibt.
|
||||
- **Reales Modell** (Folie 129): Die zentrale Frage: „Geht das auch ohne vertrauenswürdige dritte Partei?" – Ja, durch kryptographische Protokolle können die Parteien gemeinsam f(A, B) berechnen, ohne ihre Eingaben preiszugeben.
|
||||
|
||||
### Dating-Problem (Folien 130–132)
|
||||
|
||||
Ein weiteres anschauliches Beispiel: „Wie können Lucy und Linus herausfinden, ob beide zusammen zum Fasching gehen wollen, ohne sich ‚einen Korb' zu holen?"
|
||||
|
||||
**Lösung mit Spielkarten** (Folien 131–132):
|
||||
- Lucy und Linus kodieren ihre Antwort (Ja/Nein) durch die Reihenfolge zweier Karten (Linus-Karte und Lucy-Karte):
|
||||
- „Ja, ich will" → Linus-Karte links, Lucy-Karte rechts.
|
||||
- „Auf keinen Fall" → Lucy-Karte links, Linus-Karte rechts.
|
||||
- Die Karten werden verdeckt gelegt und dann aufgedeckt:
|
||||
- Wenn beide „Ja" gewählt haben, ergibt sich ein bestimmtes Muster → „Lass uns zusammen gehen".
|
||||
- In allen anderen Fällen kann keiner ableiten, was der andere gewählt hat → „Danke, und nichts für ungut".
|
||||
|
||||
---
|
||||
|
||||
## 16. Oblivious Transfer – OT (Folien 133–139)
|
||||
|
||||
### Definition nach Rabin (Folie 133)
|
||||
Rabin definierte 1981 den „Oblivious Transfer": Eine Informationsübertragung, bei der der Sender nicht weiß, ob der Empfänger die Information tatsächlich erhalten hat.
|
||||
|
||||
### Drei Varianten (Folien 134–135)
|
||||
- **Definition 1 (O.T.)**: Alice kennt ein Bit b. Bob erhält b mit Wahrscheinlichkeit 1/2. Bob weiß, ob er b erhalten hat. Alice weiß nicht, ob Bob b erhalten hat.
|
||||
- **Definition 2 (1-out-of-2 O.T.)**: Alice kennt zwei Bits b₀ und b₁. Bob erhält genau eines davon (b_k), jeweils mit Wahrscheinlichkeit 1/2 für k=0 oder k=1. Bob weiß, welches er erhalten hat. Alice weiß nicht, welches Bob erhalten hat.
|
||||
- **Definition 3 (p-O.T.)**: Wie Definition 1, aber Bob erhält b mit beliebiger Wahrscheinlichkeit p.
|
||||
|
||||
### Protokoll für 1-out-of-2 O.T. (Folie 136)
|
||||
Ein konkretes Protokoll wird beschrieben: Alice und Bob einigen sich auf einen Sicherheitsparameter s. Alice nutzt wiederholte p-O.T.-Aufrufe, Bob teilt die Indizes in zwei Mengen U und V und sendet eine (möglicherweise vertauschte) Version an Alice. Alice berechnet daraus maskierte Versionen beider Bits, von denen Bob genau eines entschlüsseln kann.
|
||||
|
||||
### DH-basiertes O.T.-Protokoll (Folie 137)
|
||||
Ein elegantes Protokoll auf Basis des Diffie-Hellman-Problems:
|
||||
|
||||
- Der Sender hat Eingabe (M₀, M₁), der Empfänger hat Auswahlbit c.
|
||||
- Der Sender wählt a, sendet A = g^a.
|
||||
- Der Empfänger wählt b und setzt B = g^b (falls c=0) oder B = Ag^b (falls c=1).
|
||||
- Beide berechnen Schlüssel: Der Sender k₀ = H(B^a) und k₁ = H((B/A)^a); der Empfänger k_R = H(A^b).
|
||||
- Der Empfänger kann genau M_c entschlüsseln, da k_R = k_c.
|
||||
|
||||
### Alternatives O.T.-Protokoll (Folie 138)
|
||||
Ein weiteres Protokoll basierend auf Public-Key-Verschlüsselung, bei dem die Sicherheit darauf beruht, dass ein Chiffretext nicht von einem Nicht-Chiffretext unterschieden werden kann.
|
||||
|
||||
### Abschluss (Folie 139)
|
||||
Die Vorlesung endet mit einem Zitat von Benjamin Franklin (1783): „À quoi bon l'enfant qui vient de naître?" – „Was nutzt das Kind, das gerade geboren wird?" – als philosophische Reflexion über den Nutzen neuer kryptographischer Primitive.
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung der Kernthemen
|
||||
|
||||
|Thema|Kernaussage|
|
||||
|---|---|
|
||||
|Komplexitätsklassen|Kryptographische Sicherheit basiert auf der vermuteten Schwierigkeit bestimmter Probleme in NP|
|
||||
|PQ-RSA|Theoretisch möglich, aber unpraktisch wegen Terabyte-großer Schlüssel|
|
||||
|Hash-basiert|Sicherheit basiert nur auf Hashfunktionen; SPHINCS+ ist NIST-standardisiert|
|
||||
|Isogenien|Eleganter Ansatz analog zu Diffie-Hellman, aber SIKE wurde 2022 gebrochen|
|
||||
|Multivariate Polynome|MQ-Problem ist NP-hart; Oil-and-Vinegar als Trapdoor-Konstruktion|
|
||||
|Code-basiert|McEliece-Kryptosystem seit 1978; basiert auf Syndrome-Decoding|
|
||||
|Gitter-basiert|Stärkstes theoretisches Fundament durch Worst-Case-Reduktionen; CRYSTALS-Kyber/Dilithium standardisiert|
|
||||
|Mosca-Theorem|x + y > z → jetzt handeln|
|
||||
|Homomorphe Verschlüsselung|Rechnen auf verschlüsselten Daten; PHE → SWHE → FHE|
|
||||
|Multi-Party Computation|Gemeinsame Berechnung ohne Preisgabe der Eingaben|
|
||||
|Oblivious Transfer|Fundamentaler Baustein für MPC-Protokolle|
|
||||
291
Kryptografie/zusammenfassungen/kr5 - zusammenfassung.md
Normal file
291
Kryptografie/zusammenfassungen/kr5 - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,291 @@
|
|||
# Zusammenfassung Vorlesung 5
|
||||
**Hochschule für Wirtschaft und Recht Berlin – 16.03.2026** **Folien 65–105 (41 Folien)**
|
||||
|
||||
---
|
||||
## 1. Yao's Millionärsproblem (Folie 65)
|
||||
|
||||
Das **Yao's Millionaires Problem** (Andrew Yao, 1982) ist das klassische Motivationsbeispiel für Secure Multi-Party Computation: Zwei Millionäre möchten herausfinden, wer reicher ist, ohne ihre jeweiligen Vermögen preiszugeben. Die Lösung dieses Problems führte zur Entwicklung von **Garbled Circuits**.
|
||||
|
||||
---
|
||||
|
||||
## 2. Garbled Circuits (Folien 66–70)
|
||||
|
||||
### Grundprinzip (Folien 66–68)
|
||||
|
||||
Garbled Circuits (auch „Yao's Garbled Circuits") sind ein Verfahren, um beliebige Funktionen als Boolesche Schaltkreise sicher zwischen zwei Parteien auszuwerten:
|
||||
|
||||
1. **Alice (Garbler)** erstellt den Schaltkreis:
|
||||
- Für jedes Gate im Schaltkreis wird eine **verschlüsselte Wahrheitstabelle** erzeugt.
|
||||
- Jeder Draht erhält zwei zufällige Labels (eines für 0, eines für 1).
|
||||
- Die Zeilen der Wahrheitstabelle werden mit den Input-Labels verschlüsselt und dann **zufällig permutiert** (damit die Reihenfolge keine Information verrät).
|
||||
|
||||
2. **Bob (Evaluator)** wertet den Schaltkreis aus:
|
||||
- Er erhält den „garbled circuit" und kann genau eine Zeile pro Gate entschlüsseln.
|
||||
- Er lernt nur das Ergebnis, nicht die Zwischenwerte.
|
||||
|
||||
### Eingaben (Folie 69)
|
||||
|
||||
- **Alice** codiert ihre eigenen Eingaben, indem sie die entsprechenden Labels direkt einsetzt.
|
||||
- **Bob wählt seine Eingaben via Oblivious Transfer (OT)**: Er erhält genau die Labels für seine Eingabebits, ohne dass Alice erfährt, welche Bits Bob gewählt hat. Alice wiederum kennt nicht die Labels, die Bob erhalten hat.
|
||||
|
||||
### Sicherheit (Folie 70)
|
||||
|
||||
- **Alice** lernt nichts über Bobs Eingabe (durch OT geschützt).
|
||||
- **Bob** lernt nichts über Alices Eingabe (durch die Garbled-Tabellen geschützt).
|
||||
- Beide lernen nur das Ergebnis der Funktion f(A, B).
|
||||
|
||||
---
|
||||
|
||||
## 3. Arithmetic Circuits (Folie 71)
|
||||
|
||||
Während Garbled Circuits auf **Booleschen Schaltkreisen** (AND, OR, XOR Gates) arbeiten, nutzen **Arithmetic Circuits** arithmetische Operationen:
|
||||
|
||||
- Operationen über einem endlichen Körper (oder Ring): **Addition (+)** und **Multiplikation (×)**.
|
||||
- Arithmetic Circuits sind besonders effizient für Berechnungen, die natürlicherweise arithmetisch formuliert sind (z. B. Summen, Durchschnitte, Polynomauswertungen).
|
||||
- Sie bilden die Grundlage für MPC-Protokolle auf Basis von **Secret Sharing**.
|
||||
|
||||
---
|
||||
|
||||
## 4. Additive Secret Sharing (Folien 72–73)
|
||||
|
||||
### Grundprinzip (Folie 72)
|
||||
|
||||
Beim **Additive Secret Sharing** wird ein Geheimnis x in n Anteile (Shares) aufgeteilt:
|
||||
|
||||
- **Aufteilen**: Wähle zufällige Werte x₁, x₂, ..., x_{n-1} und setze x_n = x - (x₁ + x₂ + ... + x_{n-1}).
|
||||
- **Rekonstruktion**: x = x₁ + x₂ + ... + x_n (alle Shares zusammen ergeben das Geheimnis).
|
||||
- **Sicherheit**: Jede echte Teilmenge der Shares verrät **keinerlei Information** über x (informationstheoretische Sicherheit).
|
||||
|
||||
### Addition mit Shares (Folie 73)
|
||||
|
||||
Addition ist trivial möglich:
|
||||
- Gegeben Shares [x] = (x₁, ..., x_n) und [y] = (y₁, ..., y_n).
|
||||
- [x + y] = (x₁ + y₁, ..., x_n + y_n) – jede Partei addiert lokal ihre Shares.
|
||||
- **Addition mit einer Konstanten c**: Nur der **erste** Share wird angepasst: (x₁ + c, x₂, ..., x_n).
|
||||
|
||||
**Problem**: Multiplikation ist nicht trivial, da das Produkt zweier Shares nicht direkt das Share des Produkts ergibt.
|
||||
|
||||
---
|
||||
|
||||
## 5. Beaver Triples (Folien 74–75)
|
||||
|
||||
### Idee (Folie 74)
|
||||
|
||||
**Beaver Triples** (Donald Beaver, 1991) lösen das Multiplikationsproblem im Secret Sharing:
|
||||
|
||||
Ein **Beaver Triple** ist ein vorberechnetes Tripel ([a], [b], [c]) mit c = a · b, wobei a und b zufällig sind.
|
||||
|
||||
### Multiplikationsprotokoll (Folie 75)
|
||||
|
||||
Um [x · y] zu berechnen:
|
||||
|
||||
1. Die Parteien öffnen (offenbaren) **d = x - a** und **e = y - b** (da a und b zufällig sind, verraten d und e nichts über x und y).
|
||||
2. Berechne: **x · y = d · e + d · [b] + e · [a] + [c]**
|
||||
- d · e ist eine öffentliche Konstante.
|
||||
- d · [b] und e · [a] sind Multiplikationen mit öffentlichen Konstanten (einfach).
|
||||
- [c] ist bereits als Share vorhanden.
|
||||
|
||||
**Formaler Zusammenhang**: Falls w = x · y + r₁ und c = a · b + r₂, dann ist h = r · r₁ - r₂ (die Korrektur zwischen den Fehlertermen).
|
||||
|
||||
**Vorteil**: Die aufwändige Erzeugung der Triples kann in einer **Offline-Phase** (vor der eigentlichen Berechnung) stattfinden, z. B. mittels Homomorpher Verschlüsselung oder Oblivious Transfer.
|
||||
|
||||
---
|
||||
|
||||
## 6. SPDZ-Protokoll (Folie 76)
|
||||
|
||||
**SPDZ** (ausgesprochen „Speedz") wurde 2012 von Ivan Damgård, Valerio Pastro, Nigel P. Smart und Sarah Zakarias vorgestellt.
|
||||
|
||||
Es ist eines der wichtigsten praktischen MPC-Protokolle und kombiniert:
|
||||
|
||||
- **Additive Secret Sharing** für die Online-Phase.
|
||||
- **Beaver Triples** für Multiplikationen.
|
||||
- **MACs** (Message Authentication Codes) auf den Shares zur Sicherstellung von **Integrität** (Schutz gegen aktive/malicious Angreifer).
|
||||
- Eine **Offline-Phase** zur Erzeugung der vorberechneten Materialien (Triples, MACs), z. B. mittels Somewhat Homomorphic Encryption.
|
||||
|
||||
**Eigenschaften**:
|
||||
- Unterstützt **beliebig viele Parteien** (n ≥ 2).
|
||||
- Sicher gegen **aktive Angreifer**, die bis zu n-1 Parteien korrumpieren.
|
||||
- Effiziente Online-Phase, da nur einfache Additionen und vorberechnete Multiplikationen nötig sind.
|
||||
|
||||
---
|
||||
|
||||
## 7. Zero Knowledge Proofs (Folien 77–91)
|
||||
|
||||
### Motivation (Folie 78)
|
||||
|
||||
Zero Knowledge Proofs beantworten fundamentale Fragen:
|
||||
- „Kann man beweisen, dass man **älter als 18** ist, ohne sein Geburtsdatum preiszugeben?"
|
||||
- „Kann man beweisen, dass man **kreditwürdig** ist, ohne seinen Kontostand preiszugeben?"
|
||||
- „Kann man beweisen, dass man die **Lösung** für ein Problem hat, ohne die Lösung preiszugeben?"
|
||||
|
||||
### Drei Eigenschaften (Folie 79)
|
||||
|
||||
Ein Zero Knowledge Proof muss drei Eigenschaften erfüllen:
|
||||
|
||||
| Eigenschaft | Bedeutung |
|
||||
|---|---|
|
||||
| **Completeness** (Vollständigkeit) | Wenn die Aussage wahr ist, wird der Verifier überzeugt |
|
||||
| **Soundness** (Korrektheit) | Wenn die Aussage falsch ist, kann der Prover den Verifier nicht überzeugen |
|
||||
| **Zero Knowledge** | Der Verifier lernt **nichts anderes** außer der Tatsache, dass die Aussage wahr ist |
|
||||
|
||||
### Interaktives Protokoll (Folie 80)
|
||||
|
||||
Ein Zero Knowledge Proof ist ein interaktives Protokoll zwischen:
|
||||
- **Prover (P)**: Besitzt das Geheimnis und möchte die Wahrheit einer Aussage beweisen.
|
||||
- **Verifier (V)**: Möchte sich von der Wahrheit überzeugen, ohne das Geheimnis zu erfahren.
|
||||
|
||||
Das Protokoll besteht aus mehreren Runden von Challenges und Responses.
|
||||
|
||||
### Beispiel: Graph-Isomorphismus (Folien 81–85)
|
||||
|
||||
**Problem**: Der Prover kennt einen Isomorphismus π zwischen zwei Graphen G₀ und G₁ (d. h. G₁ = π(G₀)) und möchte dies beweisen, ohne π preiszugeben.
|
||||
|
||||
**Protokoll**:
|
||||
1. **Prover** wählt eine zufällige Permutation σ und berechnet H = σ(G_b) für ein zufällig gewähltes b ∈ {0, 1}.
|
||||
2. **Prover** sendet H an den Verifier.
|
||||
3. **Verifier** sendet ein Challenge-Bit c ∈ {0, 1}.
|
||||
4. **Prover** antwortet mit dem passenden Isomorphismus:
|
||||
- Falls c = b: sendet σ.
|
||||
- Falls c ≠ b: sendet σ ∘ π (oder σ ∘ π⁻¹).
|
||||
5. **Verifier** prüft, ob die Antwort H korrekt auf G_c abbildet.
|
||||
|
||||
**Warum Zero Knowledge?** Der Prover kann sich in jeder Runde neu aussuchen, welchen Graphen er als Basis wählt. Falls die Graphen **nicht** isomorph wären, würde der Prover schnell erwischt werden (Soundness). Nach vielen Runden ist die Wahrscheinlichkeit eines Betrugs exponentiell klein: (1/2)^n.
|
||||
|
||||
### Weitere ZK-Protokolle (Folien 86–89)
|
||||
|
||||
Auf den folgenden Folien werden Zero Knowledge Proofs für verschiedene Probleme skizziert:
|
||||
|
||||
| Problem | Public | Secret |
|
||||
|---|---|---|
|
||||
| **Graph-Isomorphismus** (Folie 85) | Die beiden Graphen G₀, G₁ | Der Isomorphismus π |
|
||||
| **Quadratic Residues** (Folie 86) | n, y | x mit x² ≡ y mod n |
|
||||
| **Diskreter Logarithmus** (Folie 87) | g, h = g^x | x (der diskrete Logarithmus) |
|
||||
| **Signatur-Schema** (Folie 89) | Public Key | Secret Key |
|
||||
|
||||
Die Struktur ist stets ähnlich: Der Prover demonstriert Kenntnis des Geheimnisses durch ein Challenge-Response-Protokoll, ohne das Geheimnis selbst zu offenbaren.
|
||||
|
||||
### MPC in the Head (Folien 90–91)
|
||||
|
||||
**MPC in the Head** ist eine Technik, um Zero Knowledge Proofs aus MPC-Protokollen zu konstruieren:
|
||||
|
||||
1. Der Prover **simuliert** ein MPC-Protokoll im Kopf (d. h. er spielt alle Parteien selbst).
|
||||
2. Er teilt sein Geheimnis in Shares auf und führt das Protokoll virtuell durch.
|
||||
3. Der Verifier wählt eine Teilmenge der virtuellen Parteien aus und überprüft deren Transkripte.
|
||||
4. Da der Verifier nicht alle Parteien sieht, kann er das Geheimnis nicht rekonstruieren (Zero Knowledge).
|
||||
5. Da der Prover sich auf die Transkripte festgelegt hat (Commitment), kann er nicht betrügen (Soundness).
|
||||
|
||||
**Vorteil**: Jedes MPC-Protokoll kann automatisch in einen ZK-Proof umgewandelt werden.
|
||||
|
||||
---
|
||||
|
||||
## 8. Differential Privacy (Folien 92–101)
|
||||
|
||||
### Motivation (Folien 92–93)
|
||||
|
||||
Die zentrale Frage: „Wie bringt man Marcie dazu, eine **Tabu-Frage** wahrheitsgemäß zu beantworten?"
|
||||
|
||||
Das Problem: Bei sensiblen Umfragen (z. B. „Haben Sie schon einmal gestohlen?") lügen Befragte häufig, weil sie negative Konsequenzen fürchten.
|
||||
|
||||
### Randomized Response (Folien 93–96)
|
||||
|
||||
Eine elegante Lösung mittels **Münzwurf-Technik**:
|
||||
|
||||
1. **Marcie wirft eine Münze** (für sich, unsichtbar).
|
||||
2. **Kopf** → Marcie sagt die **Wahrheit**.
|
||||
3. **Zahl** → Marcie **lügt** (gibt die entgegengesetzte Antwort).
|
||||
|
||||
**Analyse** (Folie 96):
|
||||
- In **3/4 der Fälle** steht bei Marcie die richtige Antwort (sie sagt die Wahrheit, oder sie lügt, hat aber ohnehin „Nein" als wahre Antwort).
|
||||
- In **1/4 der Fälle** steht die falsche Antwort.
|
||||
|
||||
**Rückrechnung**: Der tatsächliche Anteil der „Ja"-Antworten lässt sich statistisch rekonstruieren:
|
||||
|
||||
```
|
||||
Prozent tatsächliche "Ja" = 2 × (Prozent gemessene "Ja" - 0,25)
|
||||
```
|
||||
|
||||
**Beispiel**: Bei 37,5% gemessenen „Ja"-Antworten:
|
||||
- 3/4 × 25% = 18,75%
|
||||
- 1/4 × 75% = 18,75%
|
||||
- 2 × (0,375 - 0,25) = **0,25 = 25%** tatsächliche „Ja"-Antworten.
|
||||
|
||||
**Vorteil**: Jede einzelne Antwort ist **plausibel abstreitbar** (Plausible Deniability), da sie auf den Münzwurf zurückgeführt werden könnte.
|
||||
|
||||
### Formale Definition (Folien 97–99)
|
||||
|
||||
**Epsilon (ε) – Privacy Budget** (Folie 98):
|
||||
|
||||
Der Parameter ε bestimmt, wie viel Privatsphäre „geopfert" wird:
|
||||
|
||||
- **Kleines ε** → mehr Privatsphäre, weniger Genauigkeit.
|
||||
- **Großes ε** → weniger Privatsphäre, mehr Genauigkeit.
|
||||
|
||||
**Sensitivität** (Folie 99):
|
||||
|
||||
Die **Sensitivität** einer Funktion gibt an, wie stark sich der Funktionswert ändert, wenn **ein einzelner Datensatz** hinzugefügt oder entfernt wird (Erhöhung der Eingabe um 1). Sie bestimmt, wie viel Rauschen hinzugefügt werden muss.
|
||||
|
||||
### Mechanismen (Folien 100–101)
|
||||
|
||||
Drei potentielle Möglichkeiten, **Noise (Rauschen)** hinzuzufügen:
|
||||
|
||||
| Mechanismus | Beschreibung |
|
||||
|---|---|
|
||||
| **Laplace-Mechanismus** | Addiert Rauschen aus der Laplace-Verteilung, skaliert mit Sensitivität/ε |
|
||||
| **Gaußscher Mechanismus** | Addiert Gaußsches Rauschen, benötigt (ε, δ)-Differential Privacy |
|
||||
| **Exponentieller Mechanismus** | Für nicht-numerische Ausgaben; wählt Ergebnisse mit exponentiell gewichteter Wahrscheinlichkeit |
|
||||
|
||||
---
|
||||
|
||||
## 9. Trusted Execution Environments – TEE (Folien 102–104)
|
||||
|
||||
### Virtual Black Box Obfuscator (Folie 103)
|
||||
|
||||
Der ideale Ansatz wäre ein **Virtual Black Box Obfuscator**: Ein Programm so verschleiern, dass man es ausführen, aber nicht verstehen kann. **Problem**: Es wurde bewiesen, dass ein solcher Obfuscator **nicht existieren kann** (Barak et al., 2001).
|
||||
|
||||
### TEE-Architektur (Folie 104)
|
||||
|
||||
**Trusted Execution Environments** bieten einen praktischen Kompromiss:
|
||||
|
||||
- Eine hardware-geschützte **Enclave**, in der **attestierter Code** läuft.
|
||||
- **Daten-I/O findet ausschließlich verschlüsselt statt** – alle Daten werden beim Eintritt in die Enclave entschlüsselt und beim Verlassen wieder verschlüsselt.
|
||||
- Selbst ein **kompromittiertes Betriebssystem** hat keinen Zugriff auf die Daten der Enclave.
|
||||
- Beispiele: Intel SGX, ARM TrustZone, AMD SEV.
|
||||
|
||||
**Attestierung**: Die Hardware kann kryptographisch beweisen, welcher Code in der Enclave läuft, sodass externe Parteien überprüfen können, dass der korrekte Code ausgeführt wird.
|
||||
|
||||
---
|
||||
|
||||
## 10. Privacy Enhancing Technologies – Gesamtübersicht (Folie 105)
|
||||
|
||||
Die Vorlesung schließt mit einer Übersicht aller behandelten Technologien im Kontext der drei Privacy-Ziele:
|
||||
|
||||
| Technologie | Input Privacy | Output Privacy | Policy Enforcement |
|
||||
|---|---|---|---|
|
||||
| **MPC** | ✅ | — | — |
|
||||
| **TEE** | ✅ | — | — |
|
||||
| **HE/FHE** | ✅ | — | — |
|
||||
| **ZK Proofs** | ✅ | — | — |
|
||||
| **Differential Privacy** | — | ✅ | — |
|
||||
| **Aggregation** | — | ✅ | — |
|
||||
| **Non-Disclosure Agreements** | — | — | ✅ |
|
||||
|
||||
**Einordnung**:
|
||||
- **Input Privacy** (links): MPC, TEE, HE/FHE und ZK Proofs schützen die Eingabedaten.
|
||||
- **Output Privacy** (rechts): Differential Privacy und Aggregation schützen die Ergebnisse.
|
||||
- **Policy Enforcement** (oben): Non-Disclosure Agreements und vertragliche Regelungen erzwingen Richtlinien.
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung der Kernthemen
|
||||
|
||||
| Thema | Kernaussage |
|
||||
|---|---|
|
||||
| Garbled Circuits | Beliebige Funktionen als verschlüsselte Boolesche Schaltkreise auswerten; Eingaben via OT |
|
||||
| Additive Secret Sharing | Geheimnis in Shares aufteilen; Addition trivial, Multiplikation erfordert Beaver Triples |
|
||||
| Beaver Triples | Vorberechnete (a, b, c=ab)-Tripel ermöglichen effiziente Multiplikation auf Shares |
|
||||
| SPDZ | Praktisches MPC-Protokoll mit Shares + MACs; sicher gegen aktive Angreifer |
|
||||
| Zero Knowledge Proofs | Beweisen, dass eine Aussage wahr ist, ohne etwas anderes preiszugeben |
|
||||
| MPC in the Head | ZK-Proofs aus simulierten MPC-Protokollen konstruieren |
|
||||
| Differential Privacy | Rauschen hinzufügen, um statistische Ergebnisse zu veröffentlichen, ohne Individuen zu identifizieren |
|
||||
| TEE | Hardware-Enclaven für sichere Berechnung; selbst kompromittiertes OS hat keinen Zugriff |
|
||||
| PET-Übersicht | Input Privacy (MPC, TEE, HE, ZK) vs. Output Privacy (DP, Aggregation) vs. Policy Enforcement (NDA) |
|
||||
Loading…
Add table
Add a link
Reference in a new issue