hwr-notes/Kryptografie/zusammenfassungen/kr5 - zusammenfassung.md

# 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) |