docs: add obsidian hwr docs

Kryptografie/zusammenfassungen/kr5 - zusammenfassung.md

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