SVP — Lernzusammenfassung
+Alle Erklärungen und Visualisierungen aus der Tutoring-Session. Zum Wiederholen vor dem Vortrag.
+ + +1. Was ist ein Gitter?
+ +Ein Gitter ist die Menge aller ganzzahligen Kombinationen von Basisvektoren. Stell dir schiefes Karopapier vor — die Ecken der Parallelogramme sind die Gitterpunkte, und die Seitenvektoren bilden die Basis.
+ +Formal: L = { z₁b₁ + z₂b₂ + ... + zₙbₙ | zᵢ ∈ ℤ }
Der entscheidende Unterschied zur linearen Algebra: Bei Vektorräumen darfst du reelle Zahlen verwenden und erreichst jeden Punkt. Bei Gittern nur ganze Zahlen → du bekommst diskrete Punkte.
+ +
+
+
+Merkregel
+ Mit einer Kombination aus den Basisvektoren (nur ganzzahlige Koeffizienten!) kann man das gesamte Gitter abbilden. Kein Punkt fehlt, keiner kommt dazu. Die Basis definiert das Gitter.
+Basen sind nicht eindeutig: Dasselbe Gitter kann durch komplett unterschiedliche Basisvektoren beschrieben werden. Manche Basen sind „gut" (kurze, fast senkrechte Vektoren → SVP leicht lösbar), manche „schlecht" (lange, fast parallele Vektoren → SVP schwer). Man kann nicht einfach orthonormalisieren, weil das reelle Koeffizienten bräuchte — erlaubt sind nur ganzzahlige unimodulare Transformationen (det = ±1).
+ +Grundidee der Gitter-Krypto: Öffentlicher Schlüssel = schlechte Basis, privater Schlüssel = gute Basis desselben Gitters.
+ + +
+
+
+
+
+
+
+
+
+
+2. SVP, γ-SVP und CVP
+ +Exaktes SVP
+Gegeben eine Basis B, finde den kürzesten Nicht-Null-Vektor. Die Länge dieses Vektors heißt λ₁(L). Minkowski hat 1889 bewiesen, dass so ein Vektor immer existiert — aber ihn finden ist das Problem.
+ +γ-SVP (Approximation)
+Statt den exakt kürzesten Vektor zu finden, reicht einer, der höchstens γ-mal so lang ist. Drei Varianten:
+Suchversion (SVP_γ): Finde einen Vektor v mit ‖v‖ ≤ γ · λ₁.
+Schätzversion (EstSVP_γ): Gib die Länge λ₁ bis auf Faktor γ genau an.
+Entscheidungsversion (GapSVP_γ): Gegeben Basis B und Wert d, unterscheide: Ist λ₁ ≤ d (YES) oder λ₁ > γ·d (NO)? Alles dazwischen ist Grauzone (Promise-Problem) — dort darf die Antwort beliebig sein. In der Visualisierung: blauer Kreis = YES-Grenze (d), oranger Kreis = NO-Grenze (γ·d), gelbe Zone dazwischen = der „verbotene" Bereich, den das Problem ignoriert.
+ +
+
+
+
+
+ Dazwischen: Terra incognita — niemand weiß wo es kippt. +
+
+Die Komplexitätslandschaft von γ
+ γ = 1 → NP-hart (Ajtai 1998)+
γ = Konstante → NP-hart (Micciancio 2001)+
γ ≈ √n → NP ∩ coNP (Aharonov & Regev 2005)+
γ = 2^O(n) → in P (LLL löst das)+ Dazwischen: Terra incognita — niemand weiß wo es kippt. +
CVP (Closest Vector Problem)
+Gegeben ein Gitter und einen externen Punkt t (nicht im Gitter), finde den nächstgelegenen Gitterpunkt. In der Visualisierung: roter Punkt mit Kreuz = Zielpunkt t, grün umringter Punkt = nächster Gitterpunkt, gestrichelte Linie = minimale Distanz.
+Verhältnis zu SVP: SVP ≤p CVP (Polynomialzeit-Reduktion: Man kann SVP auf CVP reduzieren, indem man Basis verdoppelt und t geschickt wählt). Die Umkehrung ist unbekannt — CVP gilt als das natürlich schwerere Problem. Typische Anwendung in der Kryptografie: t ist ein verrauschter Geheimtext, der nächste Gitterpunkt ist die eigentliche Nachricht.
+ + +3. Komplexitätstheoretische Einordnung
+ +Schnell-Glossar
+P = effizient lösbar. NP = Lösung schnell überprüfbar. NP-hart = mindestens so schwer wie alles in NP. coNP = Ablehnung schnell verifizierbar. NP ∩ coNP = beides verifizierbar → vermutlich nicht NP-hart.
+ +NP-Härte (Ajtai 1998)
+Ajtai hat SAT auf SVP reduziert: Aus jeder SAT-Formel baut er ein Gitter, bei dem der kürzeste Vektor verrät, ob die Formel erfüllbar ist. Aber: Die Reduktion braucht Zufall (randomisiert). Ob es deterministisch geht, ist seit 26 Jahren offen.
+Micciancio (2001) verschärft: Selbst Approximation bis auf jeden konstanten Faktor γ bleibt NP-hart.
+ +GapSVP in NP ∩ coNP (Aharonov & Regev 2005)
+Ab γ ≈ √n liegt GapSVP in NP ∩ coNP. Die NP-Seite ist trivial (kurzen Vektor vorzeigen). Die coNP-Seite ist der Durchbruch:
+ + +
+
+
+
+
+
+
+
+
+
+
+Der coNP-Beweis in einem Satz
+ Du beweist Abwesenheit (kein kurzer Vektor im Gitter) durch Anwesenheit (kurze Vektoren im dualen Gitter). Wegen der Wippe (Transference-Theorem) schließt das eine das andere aus.
+Fun Fact: Aharonov & Regev haben das zuerst quantenmechanisch bewiesen (QMA) und dann "dequantisiert" — den Quantenbeweis in einen klassischen umgewandelt.
+ + +4. Worst-Case-to-Average-Case-Reduktion
+ +Das Problem mit RSA
+RSA sagt: "Faktorisieren zufälliger Zahlen ist hoffentlich schwer." Aber es gibt keinen Beweis dafür. Vielleicht sind 99% der zufälligen Instanzen leicht — dann wäre RSA unsicher. Bogdanov & Trevisan haben gezeigt, dass so eine Worst-Case-to-Average-Case-Verbindung für allgemeine NP-Probleme vermutlich unmöglich ist.
+ +Ajtais Durchbruch (1996)
+Für Gitter ist es anders: Wenn du zufällige SIS-Instanzen lösen kannst, kannst du jede beliebige Worst-Case-SVP-Instanz lösen. Die Reduktion baut aus der schwierigsten SVP-Instanz zufällige SIS-Instanzen. Löst jemand die, kannst du die Lösung zurückübersetzen.
+ +SIS (Short Integer Solution): Gegeben eine zufällige Matrix A, finde einen kurzen Vektor z mit Az = 0 mod q.
+ +
+
+
+
+Warum das einzigartig ist
+ Bei Gittern gibt es keine "leichten zufälligen Instanzen". Entweder ALLE sind schwer, oder ALLE sind leicht. Es gibt kein Dazwischen. Das ist bei keinem anderen kryptografisch relevanten Problem der Fall.
+
+
+
+
+
+
+
+
+
+5. Algorithmen
+ +LLL (Lenstra-Lenstra-Lovász, 1982)
+Nimmt eine "schlechte" Basis und macht sie "besser". Zwei Bedingungen:
+Größenreduktion: Gram-Schmidt-Koeffizienten |μ| ≤ ½ — jeder Vektor zeigt so wenig wie möglich in Richtung der vorherigen.
+Lovász-Bedingung: Die Gram-Schmidt-Vektoren dürfen nicht zu schnell kürzer werden.
+Funktioniert wie Bubble Sort — vergleiche Nachbarn, tausche wenn nötig. Polynomielle Laufzeit, aber exponentieller Approximationsfaktor 2^{(n-1)/2}.
+ + +
+
+
+
+
+
+
+
+Exakte Algorithmen
+Enumeration (Kannan 1983): Erst Basis reduzieren, dann systematisch alle Vektoren durchprobieren. Wie Baumsuche mit Pruning. Laufzeit n^{O(n)} (superexponentiell), aber nur poly(n) Speicher. Praxistauglich bis Dimension ~60-80.
+Sieving (AKS 2001): Starte mit vielen zufälligen Gittervektoren, finde nahe Paare, ersetze durch ihre Differenz. Wie ein Sieb, das immer kürzere Vektoren erzeugt. Laufzeit 2^{n+o(n)} (besser), aber auch 2^{n+o(n)} Speicher (schlechter).
+ +Übersichtstabelle
+| Algorithmus | +Faktor γ | +Laufzeit | +Speicher | +
|---|---|---|---|
| LLL (1982) | 2^{(n-1)/2} | poly(n) | poly(n) | +
| BKZ-k | 2^{O(n/k)} | 2^{O(k)} | poly(n) | +
| Enumeration (1983) | 1 (exakt) | n^{O(n)} | poly(n) | +
| Sieving (2001) | 1 (exakt) | 2^{n+o(n)} | 2^{n+o(n)} | +
| Voronoi (2010) | 1 (exakt) | Õ(4^n) | Õ(2^n) | +
+
+
+
+Offene Frage (kann der Prof fragen)
+ Kann SVP in 2^{O(n)} Zeit mit 2^{o(n)} Speicher gelöst werden? Also das Beste aus Enumeration (wenig Speicher) und Sieving (wenig Zeit)?
+6. Post-Quantum-Krypto (Kurzfassung für den Vortrag)
+ +RSA und ECC werden durch Shors Algorithmus gebrochen. Die NIST-Standards seit August 2024 basieren auf Gitterproblemen:
+ML-KEM (Kyber): Schlüsselaustausch, basiert auf Module-LWE.
+ML-DSA (Dilithium): Digitale Signaturen, basiert auf Module-LWE + Module-SIS.
+SLH-DSA (SPHINCS+): Hashbasiertes Backup, falls Gitter gebrochen werden.
+ +
+
+
+
+Der Schlüsselsatz für deinen Vortrag
+ "Die Sicherheit von Kyber und Dilithium basiert nicht auf der Hoffnung, dass zufällige Instanzen schwer sind — sondern auf der beweisbaren Worst-Case-Härte von SVP. Das ist eine fundamental stärkere Aussage als alles, was RSA bieten kann."
+7. Wahrscheinliche Prof-Fragen
+ +
+
+
+1. Warum ist SVP für Post-Quantum-Krypto relevant?
+ Worst-Case-Härte überträgt sich auf Average-Case. Kein bekannter Quantenvorteil. NIST-Standards basieren darauf.
+
+
+
+2. Was leistet LLL, und wo sind seine Grenzen?
+ Polynomielle Laufzeit, aber Approximationsfaktor 2^{(n-1)/2} — exponentiell in der Dimension. Reicht für kleine Dimensionen, nicht für kryptografische Parameter (n ≈ 1000).
+
+
+
+3. Was ist der Unterschied zwischen SVP und CVP?
+ SVP: kürzester Nicht-Null-Vektor im Gitter (Länge = λ₁). CVP: nächster Gitterpunkt zu einem externen Punkt t ∉ L. SVP ≤p CVP — man kann SVP auf CVP reduzieren (Einbettungstrick: verdopple die Basis und wähle t so, dass der nächste Gitterpunkt dem kürzesten Vektor entspricht). Umkehrung unbekannt. GapCVP ist ebenfalls NP-hart und liegt für große γ in NP ∩ coNP.
+
+
+
+4. Was bedeutet die Worst-Case-to-Average-Case-Reduktion?
+ Ajtai 1996: Zufällige SIS-Instanzen lösen = Worst-Case-SVP lösen. Einzigartig — bei RSA/SAT gibt es das nicht. Bogdanov & Trevisan zeigten Barrieren für allgemeine NP-Probleme.
+
+
+
+5. Wie ordnet sich SVP in die Komplexitätslandschaft ein?
+ NP-hart für exakte Lösung (randomisierte Reduktion), für γ ≈ √n in NP ∩ coNP, für γ = 2^{O(n)} in P. Die genaue Grenze ist offen.
+
+
+
+6. Was ist LWE?
+ Gleichungssystem b = As + e mit kleinem Fehler e. Ohne Fehler trivial (Gauß-Elimination), mit Fehler schwer. Regev 2005: LWE lösen → GapSVP im Worst-Case lösen (braucht Quantenreduktion). Peikert 2009: klassisch, aber nur für große Moduli.
++
Zuletzt aktualisiert: April 2026. Alle Visualisierungen sind interaktiv — klick dich durch die Tabs.
+ + + \ No newline at end of file diff --git a/Komplexitätstheorie/vortrag/Quellenverzeichnis.md b/Komplexitätstheorie/vortrag/Quellenverzeichnis.md new file mode 100644 index 0000000..73f08c7 --- /dev/null +++ b/Komplexitätstheorie/vortrag/Quellenverzeichnis.md @@ -0,0 +1,162 @@ +# Quellenverzeichnis: Shortest Vector Problem Präsentation +## Primärliteratur +### NP-Härte und Komplexität von SVP +1. **Ajtai, M.** (1996). "Generating hard instances of lattice problems (extended abstract)." _Proceedings of the 28th ACM Symposium on Theory of Computing (STOC)_, S. 99–108. ACM. + - _Worst-Case-to-Average-Case-Reduktion für Gitterprobleme; Einführung des SIS-Problems._ +2. **Ajtai, M.** (1998). "The shortest vector problem in ℓ₂ is NP-hard for randomized reductions (extended abstract)." _Proceedings of the 30th ACM Symposium on Theory of Computing (STOC)_, S. 10–19. ACM. + - _Erster Beweis der NP-Härte von SVP in der euklidischen Norm unter randomisierten Reduktionen._ +3. **Micciancio, D.** (2001). "The Shortest Vector in a Lattice is Hard to Approximate to within Some Constant." _SIAM Journal on Computing_, 30(6), S. 2008–2035. + - _NP-Härte der Approximation von SVP für jeden konstanten Faktor._ + - URL: https://cseweb.ucsd.edu/~daniele/papers/SVP.pdf +4. **Dinur, I.** (2002). "Approximating SVP∞ to within almost-polynomial factors is NP-hard." _Theoretical Computer Science_, 285(1), S. 55–71. + - _NP-Härte für fast-polynomielle Approximationsfaktoren._ +5. **Haviv, I. & Regev, O.** (2007). "Tensor-based hardness of the shortest vector problem to within almost polynomial factors." _Proceedings of the 39th ACM Symposium on Theory of Computing (STOC)_, S. 469–477. ACM. + - _Hardness Amplification durch Tensor-Produkte._ +6. **van Emde Boas, P.** (1981). "Another NP-Complete Problem and the Complexity of Computing Short Vectors in a Lattice." Technical Report, University of Amsterdam. + - _NP-Härte von SVP in der ℓ∞-Norm unter deterministischen Reduktionen._ +### GapSVP in NP ∩ coNP und verwandte Strukturresultate +7. **Lagarias, J. C., Lenstra, H. W. Jr. & Schnorr, C.-P.** (1990). "Korkin-Zolotarev bases and successive minima of a lattice and its reciprocal lattice." _Combinatorica_, 10(4), S. 333–348. + - _GapSVP_{n^{1.5}} ∈ coNP; Transference-Theoreme._ +8. **Banaszczyk, W.** (1993). "New bounds in some transference theorems in the geometry of numbers." _Mathematische Annalen_, 296, S. 625–635. + - _Verbesserte Transference-Bounds; GapSVP_n ∈ coNP._ +9. **Goldreich, O. & Goldwasser, S.** (2000). "On the limits of nonapproximability of lattice problems." _Journal of Computer and System Sciences_, 60(3), S. 540–563. Preliminary version in STOC 1998. + - _GapSVP_{O(√(n/log n))} ∈ coAM._ +10. **Aharonov, D. & Regev, O.** (2003). "A Lattice Problem in Quantum NP." _Proceedings of the 44th Annual IEEE Symposium on Foundations of Computer Science (FOCS)_, S. 210–219. IEEE. + - _coGapSVP_{√n} ∈ QMA; erster nicht-trivialer quantenmechanischer Oberschranken-Beweis für ein Gitterproblem._ + - URL: https://arxiv.org/abs/quant-ph/0307220 +11. **Aharonov, D. & Regev, O.** (2005). "Lattice problems in NP ∩ coNP." _Journal of the ACM_, 52(5), S. 749–765. Preliminary version in FOCS 2004. + - _GapSVP_{O(√n)} ∈ NP ∩ coNP; Dequantisierung des QMA-Resultats._ + - URL: https://dl.acm.org/doi/10.1145/1089023.1089025 + - PDF: https://cims.nyu.edu/~regev/papers/cvpconp.pdf +12. **Peikert, C.** (2008). "Limits on the Hardness of Lattice Problems in ℓp Norms." _Computational Complexity_, 17(2), S. 300–351. Preliminary version in CCC 2007. + - _Verallgemeinerung der coNP-Resultate auf alle ℓp-Normen._ + - URL: https://web.eecs.umich.edu/~cpeikert/pubs/lp_norms.pdf + +### Worst-Case-to-Average-Case-Reduktionen +13. **Ajtai, M.** (2004). "Generating hard instances of lattice problems." _Complexity of Computations and Proofs_, Quad. Mat. 13, Dept. Math., Seconda Univ. Napoli, Caserta, Italy, S. 1–32. + - _Erweiterte Version des STOC-1996-Papers._ +14. **Cai, J.-Y. & Nerurkar, A.** (1997). "An improved worst-case to average-case connection for lattice problems." _Proceedings of the 38th Annual IEEE Symposium on Foundations of Computer Science (FOCS)_, S. 468–477. + - _Verbesserung des Verbindungsfaktors auf n^{4+ε}._ +15. **Micciancio, D.** (2004). "Almost perfect lattices, the covering radius problem, and applications to Ajtai's connection factor." _SIAM Journal on Computing_, 34(1), S. 118–169. + - _Verbesserung des Verbindungsfaktors auf n³ · ω(√(log n · log log n))._ + - URL: https://cseweb.ucsd.edu/~daniele/papers/LatticeHash.html +16. **Micciancio, D. & Regev, O.** (2007). "Worst-case to average-case reductions based on Gaussian measures." _SIAM Journal on Computing_, 37(1), S. 267–302. Preliminary version in FOCS 2004. + - _Verbindungsfaktor Õ(n) für SVP, SIVP, CRP; Einführung der Gauß-Maß-Technik._ + - URL (Journal): https://epubs.siam.org/doi/10.1137/S0097539705447360 + - URL (Preprint): https://cims.nyu.edu/~regev/papers/average.pdf +17. **Langlois, A. & Stehlé, D.** (2015). "Worst-case to average-case reductions for module lattices." _Designs, Codes and Cryptography_, 75(3), S. 565–599. + - _Worst-Case-to-Average-Case-Reduktionen für Module-SIS und Module-LWE._ + - URL: https://eprint.iacr.org/2012/090.pdf +### Learning With Errors (LWE) +18. **Regev, O.** (2009). "On lattices, learning with errors, random linear codes, and cryptography." _Journal of the ACM_, 56(6), Artikel 34. Preliminary version in STOC 2005. + - _Einführung von LWE; quantenmechanische Reduktion von GapSVP/SIVP auf LWE._ + - URL (Journal): https://dl.acm.org/doi/10.1145/1568318.1568324 + - URL (Full paper): https://cims.nyu.edu/~regev/papers/qcrypto.pdf + - URL (arXiv, 2024 revision): https://arxiv.org/abs/2401.03703 +19. **Peikert, C.** (2009). "Public-key cryptosystems from the worst-case shortest vector problem." _Proceedings of the 41st ACM Symposium on Theory of Computing (STOC)_, S. 333–342. ACM. + - _Klassische Reduktion von GapSVP auf LWE (für große Moduli)._ + - URL: https://web.eecs.umich.edu/~cpeikert/pubs/svpcrypto.pdf +20. **Brakerski, Z., Langlois, A., Peikert, C., Regev, O. & Stehlé, D.** (2013). "Classical hardness of learning with errors." _Proceedings of the 45th ACM Symposium on Theory of Computing (STOC)_, S. 575–584. + - _Klassische Reduktion für polynomielle Moduli via Modulus-Reduktion._ + +### Algorithmen für SVP +21. **Lenstra, A. K., Lenstra, H. W. Jr. & Lovász, L.** (1982). "Factoring polynomials with rational coefficients." _Mathematische Annalen_, 261, S. 515–534. + - _Der LLL-Algorithmus; erster polynomialzeitlicher Gitterbasis-Reduktionsalgorithmus._ +22. **Schnorr, C.-P.** (1987). "A hierarchy of polynomial time lattice basis reduction algorithms." _Theoretical Computer Science_, 53(2–3), S. 201–224. + - _BKZ-Verallgemeinerung von LLL mit verbesserten Approximationsfaktoren._ +23. **Kannan, R.** (1983). "Improved algorithms for integer programming and related lattice problems." _Proceedings of the 15th ACM Symposium on Theory of Computing (STOC)_, S. 193–206. + - _Enumerationsalgorithmus für SVP/CVP mit Laufzeit n^{O(n)}._ +24. **Ajtai, M., Kumar, R. & Sivakumar, D.** (2001). "A sieve algorithm for the shortest lattice vector problem." _Proceedings of the 33rd ACM Symposium on Theory of Computing (STOC)_, S. 601–610. + - _Erster Sieving-Algorithmus; erste 2^{O(n)}-Lösung für SVP._ +25. **Micciancio, D. & Voulgaris, P.** (2010). "A deterministic single exponential time algorithm for most lattice problems based on Voronoi cell computations." _Proceedings of the 42nd ACM Symposium on Theory of Computing (STOC)_, S. 351–358. + - _Deterministischer Õ(4^n)-Algorithmus für SVP und CVP via Voronoi-Zellen._ +26. **Micciancio, D. & Voulgaris, P.** (2010). "Faster exponential time algorithms for the shortest vector problem." _Proceedings of the 21st ACM-SIAM Symposium on Discrete Algorithms (SODA)_, S. 1468–1480. + - _ListSieve und GaussSieve; praktischere Sieving-Varianten._ + - URL: https://cseweb.ucsd.edu/~daniele/papers/Sieve.pdf +27. **Nguyen, P. Q. & Vidick, T.** (2008). "Sieve algorithms for the shortest vector problem are practical." _Journal of Mathematical Cryptology_, 2(2), S. 181–207. + - _Heuristische Sieving-Variante mit Laufzeit (4/3+ε)^n; erste praktische Implementierung._ + - URL: https://people.csail.mit.edu/vidick/JoMC08.pdf +28. **Aggarwal, D., Dadush, D., Regev, O. & Stephens-Davidowitz, N.** (2015). "Solving the shortest vector problem in 2^n time via discrete Gaussian sampling." _Proceedings of the 47th ACM Symposium on Theory of Computing (STOC)_, S. 733–742. + - _Aktuell schnellster beweisbarer Algorithmus für SVP: 2^{n+o(n)}._ +29. **Aggarwal, D., Chen, Y., Kumar, R. & Shen, Y.** (2021). "Improved (Provable) Algorithms for the Shortest Vector Problem." _Proceedings of STACS 2021_, LIPIcs vol. 187, Artikel 4. + - _Time-Space Tradeoff: Laufzeit q^{O(n)}, Speicher q^{O(n/q²)}._ + - URL: https://drops.dagstuhl.de/storage/00lipics/lipics-vol187-stacs2021/LIPIcs.STACS.2021.4/LIPIcs.STACS.2021.4.pdf +## Surveys und Übersichtsartikel +30. **Peikert, C. & Stephens-Davidowitz, N.** (2023). "The Complexity of the Shortest Vector Problem." _ACM SIGACT News_, 54(1). + - _Umfassendster aktueller Survey zur Komplexität von SVP._ + - URL: https://www.cs.umd.edu/~gasarch/open/svp-color.pdf + - URL (ACM): https://dl.acm.org/doi/10.1145/3586165.3586172 +31. **Regev, O.** (2010). "The Learning with Errors Problem (Invited Survey)." _Proceedings of the 25th Annual IEEE Conference on Computational Complexity (CCC)_, S. 191–204. + - _Survey über LWE: Definition, Härte, kryptografische Anwendungen._ + - URL: https://cims.nyu.edu/~regev/papers/lwesurvey.pdf +32. **Micciancio, D. & Goldwasser, S.** (2002). _Complexity of Lattice Problems: A Cryptographic Perspective._ Kluwer Academic Publishers, Boston. + - _Standardwerk zur Komplexität von Gitterproblemen._ +33. **Micciancio, D. & Regev, O.** (2009). "Lattice-based cryptography." In: Bernstein, D. J., Buchmann, J. & Dahmen, E. (Hrsg.), _Post-Quantum Cryptography_, S. 147–191. Springer. + - _Übersichtskapitel zu gitterbasierter Kryptografie._ +34. **Cai, J.-Y.** (1999). "Some Recent Progress on the Complexity of Lattice Problems." _Electronic Colloquium on Computational Complexity (ECCC)_, Report No. 6. + - _Früher Survey über Ajtais Durchbrüche und Folgearbeiten._ + - URL: https://eccc.weizmann.ac.il/report/1999/006/download/ +35. **Micciancio, D.** (2005). "Shortest Vector Problem." In: _Encyclopedia of Cryptography and Security_. Springer. + - _Kompakter Enzyklopädie-Eintrag zu SVP._ + - URL: https://cseweb.ucsd.edu/~daniele/papers/CryptoEncyclopediaSVP.pdf +36. **Hanrot, G., Pujol, X. & Stehlé, D.** (2011). "Algorithms for the Shortest and Closest Lattice Vector Problems." In: _Coding and Cryptology_, IWCC 2011, LNCS vol. 6639, S. 159–190. Springer. + - _Survey über Algorithmen für SVP und CVP._ + - URL: https://link.springer.com/chapter/10.1007/978-3-642-20901-7_10 +37. **Balbás, D.** (2021). "The Hardness of LWE and Ring-LWE: A Survey." + - _Detaillierter Survey über LWE-Härteresultate und deren Beweise._ + - URL: https://eprint.iacr.org/2021/1358.pdf +38. **Bogdanov, A. & Trevisan, L.** (2006). "On Worst-Case to Average-Case Reductions for NP Problems." _SIAM Journal on Computing_, 36(4), S. 1119–1159. + - _Barrieren gegen allgemeine Worst-Case-to-Average-Case-Reduktionen für NP._ + - URL: https://lucatrevisan.github.io/pubs/redux-sicomp.pdf +39. **Regev, O.** (2004). "On the Complexity of Lattice Problems with Polynomial Approximation Factors." In: _The LLL Algorithm_, Information Security and Cryptography. Springer. + - _Übersicht über die Komplexität von Gitterproblemen mit polynomiellen Faktoren._ + - URL: https://cims.nyu.edu/~regev/papers/lll.pdf +## Vorlesungsskripte und Lecture Notes +40. **Regev, O.** (2004). "Lattices in Computer Science." Lecture Notes, Tel Aviv University / NYU. + - Lecture 7: "GapCVP in coNP" — https://cims.nyu.edu/~regev/teaching/lattices_fall_2004/ln/gg.pdf + - Lecture 12: "Average-case Hardness" — https://cims.nyu.edu/~regev/teaching/lattices_fall_2004/ln/averagecase.pdf + - Lecture: "The LLL Algorithm" — https://cims.nyu.edu/~regev/teaching/lattices_fall_2004/ln/lll.pdf +41. **Vaikuntanathan, V.** (2015). "6.876: Advanced Topics in Cryptography — Lattices." Lecture Notes, MIT. + - Lecture 2: "Lattices, Minkowski" — https://people.csail.mit.edu/vinodv/6876-Fall2015/L2.pdf + - Lecture 3: "SVP, CVP, Complexity" — https://people.csail.mit.edu/vinodv/6876-Fall2015/L3.pdf + - Lecture 7: "Sieving Algorithms" — https://people.csail.mit.edu/vinodv/6876-Fall2015/L7.pdf +42. **Vaikuntanathan, V.** (2020). "CS 294: Foundations of Lattice-based Cryptography." Lecture Notes, UC Berkeley. + - Lecture 4: "Worst-Case to Average-Case Reduction for LWE" — https://people.csail.mit.edu/vinodv/CS294/lecture4.pdf +43. **Peikert, C.** (2013–2015). "CSE 660 / CSE 840: Lattice-based Cryptography." Lecture Notes, University of Michigan. + - Lecture 2: "SVP, Gram-Schmidt, Minkowski" — https://web.eecs.umich.edu/~cpeikert/lic13/lec02.pdf + - Lecture 3: "The LLL Algorithm" — https://web.eecs.umich.edu/~cpeikert/lic15/lec03.pdf +44. **Micciancio, D.** (2012–2017). "CSE 206A: Lattice Algorithms and Applications." Lecture Notes, UC San Diego. + - Lecture 2: "Minkowski's theorem" — https://cseweb.ucsd.edu/classes/wi16/cse206A-a/lec2.pdf + - Lecture 3: "The LLL Algorithm" — https://cseweb.ucsd.edu/classes/wi12/cse206A-a/lec3.pdf +45. **MIT OpenCourseWare** (2009). "18.409: Topics in Theoretical Computer Science — An Algorithmist's Toolkit." Scribe Notes, MIT. + - Lecture 19: "Minkowski's theorem, SVP, CVP" — https://ocw.mit.edu/courses/18-409-topics-in-theoretical-computer-science-an-algorithmists-toolkit-fall-2009/08cea721b6c9e44aedcefa080de2ff6e_MIT18_409F09_scribe19.pdf + - Lecture 20: "LLL algorithm" — https://ocw.mit.edu/courses/18-409-topics-in-theoretical-computer-science-an-algorithmists-toolkit-fall-2009/eaa6bc3cd49d94630490cfe3227fa5dc_MIT18_409F09_scribe20.pdf +## NIST-Standards und Post-Quantum-Kryptografie +46. **NIST** (2024). "NIST Releases First 3 Finalized Post-Quantum Encryption Standards." Pressemitteilung, 13. August 2024. + - URL: https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards +47. **NIST** (2024). "Post-Quantum Cryptography FIPS Approved." CSRC, 13. August 2024. + - URL: https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved +48. **NIST** (laufend). "PQC Standardization Process." Computer Security Resource Center. + - URL: https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization +49. **NIST** (laufend). "Post-Quantum Cryptography — Übersichtsseite." CSRC. + - URL: https://csrc.nist.gov/projects/post-quantum-cryptography +50. **Federal Register** (2024). "Announcing Issuance of FIPS 203, FIPS 204, and FIPS 205." Vol. 89, No. 157, 14. August 2024. + - URL: https://www.federalregister.gov/documents/2024/08/14/2024-17956/announcing-issuance-of-federal-information-processing-standards-fips-fips-203-module-lattice-based +51. **Wikipedia** (laufend). "NIST Post-Quantum Cryptography Standardization." + - URL: https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography_Standardization +## Weitere Referenzen +52. **Dietzfelbinger, M. et al.** (2020). "Formalizing the LLL Basis Reduction Algorithm and the LLL Factorization Algorithm in Isabelle/HOL." _Journal of Automated Reasoning_, 64, S. 1–47. Springer. + - URL: https://link.springer.com/article/10.1007/s10817-020-09552-1 +53. **Voulgaris, P.** (2013). "Algorithms for the Closest and Shortest Vector Problems on General Lattices." Dissertation, UC San Diego. + - URL: https://escholarship.org/uc/item/4zt7x45z +54. **Jagielski, M.** (2016). "Sieving Algorithms for Lattice Problems." Undergraduate Report, University of Oregon. + - URL: https://www.cs.uoregon.edu/Reports/UG-201606-Jagielski.pdf +55. **Aggarwal, D., Mukhopadhyay, P. & Stephens-Davidowitz, N.** (2019). "Faster Provable Sieving Algorithms for the Shortest Vector Problem and the Closest Vector Problem." arXiv:1907.04406. + - URL: https://arxiv.org/pdf/1907.04406 +56. **Stephens-Davidowitz, N.** (2018). "Introduction and Minkowski's Theorem." Lecture Notes, Mini-course on Lattices. + - URL: http://www.noahsd.com/mini_lattices/01__intro_and_Minkowski.pdf +57. **Nguyen, P. Q. & Stehlé, D.** (2014). "Structural Lattice Reduction: Generalized Worst-Case to Average-Case Reductions and Homomorphic Cryptosystems." ePrint 2014/283. + - URL: https://eprint.iacr.org/2014/283.pdf +58. **Peikert, C., Regev, O. & Stephens-Davidowitz, N.** (2017). "Pseudorandomness of Ring-LWE for Any Ring and Modulus." _Proceedings of the 49th ACM Symposium on Theory of Computing (STOC)_, S. 461–473. +59. **Lyubashevsky, V., Peikert, C. & Regev, O.** (2013). "On ideal lattices and learning with errors over rings." _Journal of the ACM_, 60(6), Artikel 43. +60. **Peikert, C.** (2016). "A Decade of Lattice Cryptography." _Foundations and Trends in Theoretical Computer Science_, 10(4), S. 283–424. \ No newline at end of file diff --git a/Komplexitätstheorie/vortrag/Randbedingungen_Struktur.md b/Komplexitätstheorie/vortrag/Randbedingungen_Struktur.md new file mode 100644 index 0000000..87cc8ad --- /dev/null +++ b/Komplexitätstheorie/vortrag/Randbedingungen_Struktur.md @@ -0,0 +1,42 @@ +# Vortrag +### Randbedingungen +**Thema**: Shortest Vector Problem +**Dauer**: 10-15min +**Präsi-Software**: RevealJS +### Gliederung +**1. Einleitung & Motivation (~1–2 min)** +- Warum Gitterprobleme? Kurzer Kontext: Post-Quantum-Kryptografie baut auf der _Härte_ von Gitterproblemen auf — SVP ist das zentrale davon. +- Ziel des Vortrags: SVP als Problem der Komplexitätstheorie verstehen. + +**2. Grundlagen: Was ist ein Gitter? (~2 min)** +- Mathematische Definition (Linearkombinationen über ℤ einer Basis B ∈ ℝⁿˣⁿ) +- Anschauliches 2D-Beispiel (Visualisierung Gitterpunkte + Basisvektoren) +- Begriffe: Basis, Dimension, kürzester Vektor (Minimum λ₁) + +**3. Problemdefinition: SVP und Varianten (~2 min)** +- **Exact SVP**: Finde einen Gittervektor mit Norm = λ₁ +- **Entscheidungsvariante (GapSVP_γ)**: Gegeben Gitter L und Schwelle d — ist λ₁(L) ≤ d oder λ₁(L) > γ·d? (Promise-Problem!) +- Warum die Gap-Variante? → Approximationsfaktor γ ist der Schlüssel zur Komplexitätsanalyse. +- Kurzer Hinweis auf verwandte Probleme (CVP — Closest Vector Problem) + +**4. Komplexitätstheoretische Einordnung (~4–5 min)** ← Herzstück +- **NP-Härte**: Ajtai (1998) — SVP ist NP-hart unter randomisierten Reduktionen. Micciancio (2001) verschärft das auf bestimmte Approximationsfaktoren. +- **GapSVP_γ ∈ NP ∩ coNP** für γ ≥ √n — was bedeutet das? (Zertifikate für JA- und NEIN-Instanzen) +- **Nicht bekannt ob NP-vollständig** — warum? (Promise-Problem, keine bekannte deterministische Reduktion) +- **Worst-Case zu Average-Case Reduktion** (Ajtai 1996): Einzigartig in der Komplexitätstheorie — wenn man _zufällige_ Instanzen lösen kann, kann man auch _alle_ lösen. Bedeutung für Kryptografie. +- Optional: Bezug zur Polynomiellen Hierarchie / Vermutung SVP ∉ P + +**5. Algorithmen & bekannte Schranken (~2 min)** +- **LLL-Algorithmus** (Lenstra, Lenstra, Lovász 1982): Polynomialzeit, aber nur Approximation mit exponentiell großem γ = 2^(n/2) +- **Exakte Algorithmen**: Enumeration (superexponentiell), Sieving (2^O(n)) — kein bekannter Polynomialzeit-Algorithmus +- Einordnung: Die Lücke zwischen „effizient approximierbar" und „exakt hart" spiegelt die Komplexitätslandschaft wider. + +**6. Bedeutung für Post-Quantum-Kryptografie (~1–2 min)** +- NIST-Standards (Kyber/ML-KEM, Dilithium/ML-DSA) basieren auf Gitterproblemen (LWE → verwandt mit GapSVP) +- Sicherheitsannahme: GapSVP ist für kleine γ auch für Quantencomputer hart +- Verbindung zurück zur Komplexitätstheorie: Worst-Case-Härte als Fundament kryptografischer Sicherheit + +**7. Zusammenfassung & offene Fragen (~1 min)** +- SVP: eines der seltenen Probleme mit Worst-Case-to-Average-Case-Reduktion +- Offene Fragen: Exakte Komplexität von SVP? Optimale Approximationsgrenzen? Quantenalgorithmen? + diff --git a/Komplexitätstheorie/vortrag/Recherche.md b/Komplexitätstheorie/vortrag/Recherche.md new file mode 100644 index 0000000..11026ce --- /dev/null +++ b/Komplexitätstheorie/vortrag/Recherche.md @@ -0,0 +1,512 @@ +# Das Shortest Vector Problem (SVP) — Ausführliche Recherche für den Komplexitätstheorie-Vortrag + +--- +## 1. Einleitung & Motivation + +### Warum Gitterprobleme? + +Gitter (Lattices) sind geometrische Objekte, die als die Menge aller Schnittpunkte eines unendlichen, regelmäßigen (aber nicht notwendigerweise orthogonalen) n-dimensionalen Gitters beschrieben werden können. Sie spielen eine zentrale Rolle in zahlreichen Bereichen der Informatik und Mathematik: ganzzahlige Programmierung, Codierungstheorie, Kryptoanalyse und insbesondere der Entwurf sicherer Kryptosysteme. Historisch reicht die Beschäftigung mit Gittern bis ins 19. Jahrhundert zurück — Gauß gab bereits einen Algorithmus an, um den kürzesten Vektor in einem zweidimensionalen Gitter zu finden. + +Das **Shortest Vector Problem (SVP)** ist das wichtigste und am intensivsten untersuchte Berechnungsproblem auf Gittern. Es fragt: Gegeben eine Basis eines Gitters, finde den kürzesten Nicht-Null-Vektor. Diese scheinbar einfache geometrische Frage entpuppt sich als eines der reichhaltigsten Probleme der Komplexitätstheorie — mit Verbindungen zu NP-Härte, interaktiven Beweisen, Quanteninformatik und kryptografischer Sicherheit. + +### Warum SVP in der Komplexitätstheorie besonders ist + +SVP nimmt eine **einzigartige Stellung** in der Komplexitätstheorie ein: + +**1. Worst-Case-to-Average-Case-Reduktion:** Im Gegensatz zu fast allen anderen NP-harten Problemen (SAT, Graph Coloring, Traveling Salesman) gibt es für Gitterprobleme eine beweisbare Reduktion von der Worst-Case-Härte auf die Average-Case-Härte. Das bedeutet: Wenn man _zufällige_ Instanzen lösen kann, kann man _jede_ Instanz lösen. Für SAT zum Beispiel sind zufällige Instanzen oft leicht lösbar, obwohl das Worst-Case-Problem NP-vollständig ist. Bogdanov und Trevisan haben sogar gezeigt, dass unter bestimmten Annahmen eine solche Verbindung für allgemeine NP-Probleme relativ zu einem Orakel unmöglich ist. Gitterprobleme sind daher in dieser Hinsicht wirklich einzigartig. + +**2. Feine Komplexitätsstruktur:** Die Komplexität von SVP variiert stark mit dem Approximationsfaktor γ. Für kleine γ ist das Problem NP-hart, für große γ liegt es in NP ∩ coNP — und dazwischen liegt eine noch nicht vollständig verstandene Übergangszone. Diese „Komplexitätslandschaft" ist deutlich reicher als bei typischen NP-vollständigen Problemen. + +**3. Post-Quantum-Kryptografie:** Die Sicherheit der neuen NIST-Standards (ML-KEM/Kyber, ML-DSA/Dilithium), die im August 2024 veröffentlicht wurden, basiert letztlich auf der Annahme, dass bestimmte Gitterprobleme auch für Quantencomputer schwer bleiben. Im Gegensatz zu RSA und elliptischen Kurven, die durch Shors Algorithmus gebrochen werden können, gibt es keinen bekannten Quantenvorteil für SVP. + +**Quellen:** + +- Micciancio: "The Shortest Vector in a Lattice is Hard to Approximate" — https://cseweb.ucsd.edu/~daniele/papers/SVP.pdf +- Peikert/Stephens-Davidowitz: "The Complexity of the Shortest Vector Problem" — https://www.cs.umd.edu/~gasarch/open/svp-color.pdf +- Cai: "Some Recent Progress on the Complexity of Lattice Problems" — https://eccc.weizmann.ac.il/report/1999/006/download/ +- Bogdanov & Trevisan: "On Worst-Case to Average-Case Reductions for NP Problems" — https://lucatrevisan.github.io/pubs/redux-sicomp.pdf +- NIST: Post-Quantum Encryption Standards — https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards + +--- + +## 2. Grundlagen: Was ist ein Gitter? + +### 2.1 Mathematische Definition + +Ein **Gitter** L ist eine diskrete additive Untergruppe von ℝⁿ. Äquivalent dazu kann man ein Gitter als die Menge aller ganzzahligen Linearkombinationen von n linear unabhängigen Vektoren b₁, ..., bₙ ∈ ℝⁿ definieren: + +L = L(B) = { Σᵢ zᵢbᵢ | zᵢ ∈ ℤ } = { Bx | x ∈ ℤⁿ } + +Die Matrix B := (b₁, ..., bₙ) ∈ ℝⁿˣⁿ heißt **Basis** von L. Der Wert n ist die **Dimension** des Gitters. + +**Anschaulich in 2D:** Man stelle sich ein Blatt kariertes Papier vor, das schief gedruckt ist — die Gitterpunkte sind die Ecken der verzerrten „Kästchen". Die zwei Seitenvektoren eines Kästchens bilden eine Basis. Ein Standard-Koordinatensystem mit Achsen im rechten Winkel ist das einfachste Gitter (ℤ²), aber im Allgemeinen stehen die Basisvektoren nicht senkrecht aufeinander. + +### 2.2 Basen sind nicht eindeutig + +Ein fundamentaler Unterschied zur linearen Algebra über Körpern: Ein Gitter hat **viele verschiedene Basen**. Zwei Basen B und B' erzeugen genau dann dasselbe Gitter, wenn eine unimodulare Matrix U (ganzzahlige Matrix mit det(U) = ±1) existiert, sodass B' = BU. Da die Ganzzahligkeitsbedingung erhalten bleiben muss, ist der Basiswechsel bei Gittern deutlich rigider als bei Vektorräumen — man kann im Allgemeinen **keine orthonormale Basis** finden. + +Diese Nicht-Eindeutigkeit ist sowohl Segen als auch Fluch: Eine „gute" (kurze, fast orthogonale) Basis kann Probleme leicht lösbar machen, während eine „schlechte" (lange, fast parallele Vektoren) Basis das Problem extrem schwer erscheinen lässt. Dies ist genau die Grundidee der gitterbasierten Kryptografie — der öffentliche Schlüssel ist eine „schlechte" Basis, der private Schlüssel eine „gute" Basis desselben Gitters. + +### 2.3 Determinante und Fundamentalparallelotop + +Das **Fundamentalparallelotop** einer Basis B ist definiert als P(B) = { Bx | x ∈ [0,1)ⁿ }. Es ist die fundamentale Wiederholungseinheit, die den gesamten Raum durch Verschiebung um Gittervektoren parkettiert — ähnlich wie ein einzelnes Kästchen das karierte Papier erzeugt. + +Die **Determinante** (oder das **Kovolumen**) des Gitters ist det(L) = |det(B)| = Vol(P(B)). Eine entscheidende Eigenschaft: Die Determinante ist **basisunabhängig** — verschiedene Basen desselben Gitters liefern stets denselben Wert. Intuitiv misst die Determinante die „Dichte" des Gitters: Je kleiner det(L), desto dichter liegen die Gitterpunkte, und desto kürzer muss der kürzeste Vektor sein. Je größer det(L), desto „dünner" ist das Gitter und desto weiter können die Punkte auseinander liegen. + +### 2.4 Kürzester Vektor und sukzessive Minima + +Die Länge des kürzesten Nicht-Null-Vektors im Gitter wird als **erstes Minimum** λ₁(L) bezeichnet: + +λ₁(L) = min { ‖v‖ : v ∈ L, v ≠ 0 } + +Allgemeiner definiert man die **sukzessiven Minima** λ₁(L) ≤ λ₂(L) ≤ ... ≤ λₙ(L), wobei λᵢ die kleinste Zahl r ist, sodass die abgeschlossene Kugel B(0,r) mindestens i linear unabhängige Gittervektoren enthält. Die sukzessiven Minima liefern detaillierte Informationen über die geometrische Struktur des Gitters. + +**Beispiel:** Für das Gitter erzeugt von (1,0) und (0,3) in ℝ² ist λ₁ = 1 (der Vektor (1,0)) und λ₂ = 3 (der Vektor (0,3)). Beachte, dass der Vektor (2,0), obwohl er kürzer als (0,3) ist, nicht zählt, da er linear abhängig von (1,0) ist. + +### 2.5 Minkowskis erster Satz + +Ein Eckpfeiler der Geometrie der Zahlen ist **Minkowskis Konvexkörper-Theorem** (1889), das eine obere Schranke für den kürzesten Vektor liefert: + +> **Minkowskis Konvexkörper-Satz:** Sei L ein n-dimensionales Vollrang-Gitter und S ⊂ ℝⁿ ein konvexer, bezüglich des Ursprungs symmetrischer Körper mit Vol(S) > 2ⁿ · det(L). Dann enthält S einen Nicht-Null-Gitterpunkt. + +**Beweisskizze (über Blichfeldts Lemma):** + +1. Betrachte die Menge S/2 = {x : 2x ∈ S}. Da Vol(S/2) = 2⁻ⁿ Vol(S) > det(L), folgt aus dem Satz von Blichfeldt (jede Menge mit Volumen > det(L) enthält zwei Punkte, deren Differenz ein Gittervektor ist): Es existieren z₁, z₂ ∈ S/2 mit z₁ ≠ z₂ und z₁ − z₂ ∈ L \ {0}. +2. Da 2z₁, 2z₂ ∈ S und S symmetrisch ist, gilt auch −2z₂ ∈ S. +3. Wegen Konvexität: z₁ − z₂ = (2z₁ + (−2z₂))/2 ∈ S. +4. Also ist z₁ − z₂ ein Nicht-Null-Gittervektor in S. + +**Korollar — Schranke für den kürzesten Vektor:** Wendet man den Satz auf die euklidische Kugel B(0, r) an und wählt r so, dass Vol(B(0,r)) = 2ⁿ · det(L), erhält man: + +λ₁(L) ≤ √n · det(L)^{1/n} + +Diese Schranke garantiert die **Existenz** kurzer Vektoren — sie sagt, dass in jedem n-dimensionalen Gitter mindestens ein Nicht-Null-Vektor existiert, der kürzer als √n · det(L)^{1/n} ist. Aber sie sagt nichts darüber aus, wie man diesen Vektor **findet** — und genau diese algorithmische Frage führt zum SVP. Das Finden des durch Minkowski garantierten Vektors wird manchmal als Minkowski's Vector Problem (MVP) bezeichnet und ist eng mit SVP verwandt. + +### 2.6 Gram-Schmidt-Orthogonalisierung als untere Schranke + +Die Gram-Schmidt-Orthogonalisierung b̃₁, ..., b̃ₙ einer Basis B liefert eine wichtige **untere Schranke** für die Minimum-Distanz: + +λ₁(L) ≥ minᵢ ‖b̃ᵢ‖ + +**Beweis (Intuition für 2D):** Man kann die Gitterpunkte v = Bz in „Schichten" gemäß dem Koeffizienten z₂ von b₂ einteilen. Wenn z₂ = 0, dann ist v ein Vielfaches von b₁, also ‖v‖ ≥ ‖b₁‖ = ‖b̃₁‖. Wenn z₂ ≠ 0, hat v eine Komponente in Richtung b̃₂ (orthogonal zu b₁), und diese Komponente hat Länge mindestens |z₂| · ‖b̃₂‖ ≥ ‖b̃₂‖. Also ist ‖v‖ ≥ min(‖b̃₁‖, ‖b̃₂‖). Per Induktion über die Dimension folgt die allgemeine Aussage. + +Diese Schranke ist effizient berechenbar und bildet den konzeptuellen Ausgangspunkt des LLL-Algorithmus: Die Idee ist, eine Basis zu finden, deren Gram-Schmidt-Vektoren möglichst lang und „ausgeglichen" sind — denn dann ist die untere Schranke möglichst nah am tatsächlichen λ₁. + +**Quellen:** + +- Peikert: Lecture Notes "SVP" (U. Michigan) — https://web.eecs.umich.edu/~cpeikert/lic13/lec02.pdf +- MIT OCW: "Minkowski's theorem, shortest/closest vector problem" — https://ocw.mit.edu/courses/18-409-topics-in-theoretical-computer-science-an-algorithmists-toolkit-fall-2009/08cea721b6c9e44aedcefa080de2ff6e_MIT18_409F09_scribe19.pdf +- Micciancio: CSE 206A Lecture 2 — https://cseweb.ucsd.edu/classes/wi16/cse206A-a/lec2.pdf +- Vaikuntanathan: Lecture 2, 6.876 (MIT, 2015) — https://people.csail.mit.edu/vinodv/6876-Fall2015/L2.pdf +- Stephens-Davidowitz: "Introduction and Minkowski's Theorem" — http://www.noahsd.com/mini_lattices/01__intro_and_Minkowski.pdf +- Wikipedia: Minkowski's theorem — https://en.wikipedia.org/wiki/Minkowski's_theorem + +--- + +## 3. Problemdefinition: SVP und Varianten + +### 3.1 Exaktes SVP (Search-Version) + +Gegeben eine Basis B ∈ ℚⁿˣⁿ eines Gitters L, finde einen Nicht-Null-Vektor v ∈ L mit ‖v‖ = λ₁(L). + +Das Problem kann bezüglich jeder Norm definiert werden, aber die **euklidische Norm** (ℓ₂) ist die gebräuchlichste. Die Wahl der Norm hat allerdings signifikante Auswirkungen auf die Komplexität: Für die Uniform-Norm (ℓ∞) ist SVP seit van Emde Boas (1981) als NP-hart bekannt, während die NP-Härte für ℓ₂ erst 1998 durch Ajtai bewiesen wurde und zudem nur unter randomisierten Reduktionen gilt. + +Eine **Besonderheit** des SVP ist, dass sogar die Berechnung der _Länge_ des kürzesten Vektors (ohne den Vektor selbst zu finden) als schwer gilt. In der Komplexitätstheorie wird oft diese reine Längenberechnung studiert, da die Entscheidungsversion für formale Komplexitätsaussagen besser geeignet ist. + +### 3.2 γ-Approximate SVP und GapSVP + +Da das exakte SVP vermutlich sehr schwer ist, untersucht man Approximationsversionen. Für einen Approximationsfaktor γ = γ(n) ≥ 1 (typischerweise eine monoton wachsende Funktion der Dimension) gibt es drei Varianten: + +**1. Entscheidungsversion (GapSVP_γ) — „Gap"-Version:** Gegeben eine Gitterbasis B und ein positives d, unterscheide: + +- **YES-Instanz:** λ₁(L(B)) ≤ d (der kürzeste Vektor ist kurz) +- **NO-Instanz:** λ₁(L(B)) > γ · d (der kürzeste Vektor ist lang) + +Dies ist ein **Promise-Problem**: Für Instanzen, bei denen d < λ₁(L(B)) ≤ γ·d, ist jede Antwort akzeptabel. Der Algorithmus muss also nur „klare" Fälle korrekt entscheiden — die Grauzone dazwischen darf beliebig beantwortet werden. Diese Promise-Struktur hat wichtige technische Konsequenzen: GapSVP ist kein gewöhnliches Entscheidungsproblem im Sinne einer Sprache L ⊆ {0,1}*, und die üblichen Definitionen von NP-Vollständigkeit und Reduktionen müssen sorgfältig angepasst werden. + +**2. Schätzversion (EstSVP_γ):** Gegeben eine Gitterbasis B, berechne λ₁(L(B)) bis auf einen Faktor γ, d.h. gib einen Wert r aus mit λ₁ ≤ r ≤ γ · λ₁. + +**3. Suchversion (SVP_γ):** Gegeben eine Gitterbasis B, finde einen Nicht-Null-Vektor v ∈ L(B) mit ‖v‖ ≤ γ · λ₁(L(B)). + +**Wichtige Beobachtungen:** + +- Für γ = 1 ergeben sich die exakten Versionen. +- Die Probleme werden **strikt leichter** mit wachsendem γ: GapSVP_{γ'} ≤ GapSVP_γ für γ' ≥ γ (die bessere Approximation reduziert sich auf die schlechtere — nicht umgekehrt!). +- Es ist ein **wichtiges offenes Problem**, ob SVP_γ auf GapSVP_γ reduzierbar ist für nicht-triviales γ > 1. Für den exakten Fall (γ = 1) existiert eine einfache Reduktion über Binärsuche, aber die Verallgemeinerung auf approximative Versionen ist offen. + +### 3.3 Verwandtes Problem: CVP (Closest Vector Problem) + +Das **Closest Vector Problem (CVP)** fragt: Gegeben eine Gitterbasis B und einen Zielvektor t ∈ ℚⁿ, finde den nächsten Gittervektor zu t. + +CVP gilt als mindestens so schwer wie SVP — es gibt eine einfache, approximationsfaktor-erhaltende Reduktion von SVP auf CVP: Für eine Gitterbasis B = [b₁,...,bₙ] definiere für jedes i das modifizierte Gitter Lᵢ = L(b₁,...,bᵢ₋₁, 2bᵢ, bᵢ₊₁,...,bₙ). Dann gilt: Wenn v = Σ cⱼbⱼ der kürzeste Vektor in L ist, muss mindestens ein cⱼ ungerade sein (sonst wäre v/2 ein kürzerer Gittervektor). Für dieses j ist v + bⱼ der nächste Vektor zu bⱼ im Gitter Lⱼ, und ‖(v + bⱼ) − bⱼ‖ = ‖v‖ = λ₁. Also findet man den kürzesten Vektor, indem man n CVP-Instanzen löst und die kürzeste Differenz nimmt. + +Diese Reduktion zeigt: CVP ist mindestens so schwer wie SVP. Umgekehrt ist nicht bekannt, ob SVP mindestens so schwer wie CVP ist — tatsächlich ist CVP in gewissem Sinne das „natürlich schwerere" Problem. + +**Quellen:** + +- Wikipedia: Lattice problem — https://en.wikipedia.org/wiki/Lattice_problem +- Peikert: Lecture Notes — https://web.eecs.umich.edu/~cpeikert/lic13/lec02.pdf +- Micciancio: CSE 206A Lecture 2 (2014) — https://cseweb.ucsd.edu/classes/sp14/cse206A-a/lec2.pdf +- Vaikuntanathan: Lecture 3, 6.876 (MIT, 2015) — https://people.csail.mit.edu/vinodv/6876-Fall2015/L3.pdf + +--- + +## 4. Komplexitätstheoretische Einordnung ★ + +Dies ist das Herzstück des Vortrags. + +### 4.1 NP-Härte von SVP + +#### Frühe Ergebnisse: ℓ∞-Norm + +Die erste NP-Härte für SVP wurde von **van Emde Boas (1981)** für die Uniform-Norm (ℓ∞) gezeigt, wobei ‖x‖∞ = maxᵢ |xᵢ|. Dieses Ergebnis nutzt eine direkte Reduktion und gilt unter deterministischen Reduktionen. + +#### Ajtais Durchbruch (1998): ℓ₂-Norm + +Für die kryptografisch relevantere **euklidische Norm** (ℓ₂) blieb die NP-Härte über 15 Jahre lang offen. **Ajtai (1998)** bewies schließlich, dass das exakte SVP in ℓ₂ NP-hart ist, aber mit einem entscheidenden Caveat: Die Reduktion ist **randomisiert**. + +Die Randomisierung ist hier kein technisches Artefakt. In Ajtais Beweis wird eine SAT-Instanz in eine Gitterinstanz transformiert, wobei die Konstruktion zufällige Wahlen trifft, um ein Gitter mit bestimmten geometrischen Eigenschaften zu erzeugen. Die Konstruktion funktioniert mit hoher Wahrscheinlichkeit (über die Zufallswahlen), aber nicht deterministisch. Es bleibt eine **offene Frage** (seit über 25 Jahren!), ob SVP in ℓ₂ unter deterministischen Reduktionen NP-hart ist. + +#### Härte der Approximation: Micciancio (2001) + +**Micciancio (2001)** verschärfte Ajtais Ergebnis erheblich: Die Approximation von SVP bis auf jeden **konstanten Faktor** γ ist NP-hart unter randomisierten Reduktionen. Genauer: γ-SVP liegt nicht in RP, es sei denn NP = RP. + +Die zentrale Technik ist eine alternative Konstruktion von Ajtais Variante des Sauer-Lemmas, die den Originalbeweis stark vereinfacht. Der Beweis konstruiert ein „lokal dichtes" Gitter — ein Gitter, das in einer bestimmten Region viel dichter ist als die globale Dichte vermuten lässt. Die NP-harte Eigenschaft ist dann, diese lokal dichte Region zu finden. + +Unter einer zusätzlichen zahlentheoretischen Vermutung (über die Verteilung quadratfreier glatter Zahlen) konnte Micciancio sogar eine echte NP-Härte unter deterministischen Many-One-Reduktionen zeigen. + +#### Weitere Verbesserungen + +- **Haviv & Regev (2007):** Nutzten Tensor-Produkte zur „Verstärkung" der Härte (Hardness Amplification). Tensor-Produkte erlauben es, die Approximationslücke zu vergrößern. +- **Dinur (2002):** Zeigte NP-Härte für fast-polynomielle Faktoren γ = n^{c/log log n} unter der Annahme NP ⊄ RSUBEXP. + +**Zusammenfassung:** + +|Faktor γ|Ergebnis|Annahme|Referenz| +|---|---|---|---| +|1 (exakt)|NP-hart|Randomisierte Reduktion|Ajtai 1998| +|Jede Konstante|NP-hart|NP ≠ RP|Micciancio 2001| +|2^{(log n)^{1-ε}}|NP-hart|NP ⊄ RTIME(2^{poly(log n)})|Khot 2005| +|n^{c/log log n}|NP-hart|NP ⊄ RSUBEXP|Haviv/Regev 2007| + +### 4.2 GapSVP in NP ∩ coNP: Obere Schranken + +Die vielleicht überraschendste Facette der SVP-Komplexität: Für hinreichend große Approximationsfaktoren liegt GapSVP in erstaunlich niedrigen Komplexitätsklassen. + +#### Die NP-Seite (trivial) + +Dass GapSVP_γ ∈ NP liegt, ist für jedes γ ≥ 1 einfach: Ein kurzer Gittervektor v mit ‖v‖ ≤ d dient als polynomiell verifizierbar Zeuge für eine YES-Instanz. Der Verifizierer prüft: (a) v ≠ 0, (b) v ∈ L(B) (durch Lösen von Bx = v über ℤ), (c) ‖v‖ ≤ d. Da ‖v‖ ≤ d, ist die Bitlänge von v polynomiell beschränkt. + +#### Die coNP-Seite (schwierig und überraschend) + +Die Frage „Wie beweist man, dass ein Gitter **keinen** kurzen Vektor hat?" ist viel subtiler. Schließlich gibt es exponentiell viele Gittervektoren, die potenziell kurz sein könnten — wie kann man alle gleichzeitig ausschließen? Man braucht einen einzelnen, polynomiell langen Zeugen, der den Verifizierer davon überzeugt, dass kein kurzer Vektor existiert. + +**Historische Entwicklung:** + +**Lagarias, Lenstra & Schnorr (1990):** GapSVP_{n^{1.5}} ∈ coNP. Die Technik nutzt das **duale Gitter** L* = {u ∈ ℝⁿ : ⟨u,v⟩ ∈ ℤ für alle v ∈ L}. Sogenannte Transference-Theoreme verbinden die Minimum-Distanz eines Gitters mit der seines Duals: Wenn das duale Gitter viele kurze Vektoren hat, dann hat das ursprüngliche Gitter keinen kurzen Vektor. + +**Banaszczyk (1993):** Verbesserung auf GapSVP_n ∈ coNP durch schärfere Transference-Bounds. Banaszcyks Resultate nutzen tiefe Ergebnisse aus der Geometrie der Zahlen. + +**Goldreich & Goldwasser (2000):** Ein anderer Ansatz — GapSVP_{O(√(n/log n))} ∈ **coAM** (Komplement von Arthur-Merlin). Hierbei wird ein interaktives Protokoll verwendet: Der allmächtige Beweiser (Prover) überzeugt den computatorisch beschränkten Verifizierer (Arthur) davon, dass ein Punkt weit vom Gitter entfernt ist. Der Verifizierer wirft eine Münze und stellt dem Beweiser eine Aufgabe, die nur lösbar ist, wenn der kürzeste Vektor tatsächlich lang ist. Die coAM-Containment hat die Implikation, dass GapSVP für diesen Faktor vermutlich nicht NP-hart ist (da NP ⊆ coAM den Kollaps der polynomiellen Hierarchie implizieren würde). + +**Aharonov & Regev (2005) — Der entscheidende Durchbruch:** + +> **Theorem:** GapSVP_{c√n} ∈ NP ∩ coNP für eine Konstante c > 0. + +Dieses Ergebnis verdient besondere Aufmerksamkeit: + +**Der coNP-Zeuge** besteht aus einer Liste von N = n^{4ℓ} Vektoren w₁, ..., wₙ aus dem dualen Gitter (ℓ ist ein Polynomialzeit-berechenbarer Parameter). Diese Vektoren definieren eine Funktion f_W : ℝⁿ → [0,1], die als „Periodizitätsdetektor" fungiert — sie misst, wie „periodisch" ein Punkt bezüglich des Gitters ist. Der Verifizierer führt drei Tests durch: + +- **Periodizitätstest:** f_W muss periodisch über L sein (d.h. f_W(x) = f_W(x + v) für alle v ∈ L). +- **Glatttest:** f_W darf nur wenig um ihren Mittelwert schwanken. +- **Punkttest:** f_W muss am Ursprung einen hohen Wert haben. + +Für NO-Instanzen (kürzester Vektor ist lang ≥ γd) kann ein Zeuge konstruiert werden, der alle drei Tests besteht. Für YES-Instanzen (kurzer Vektor existiert) schlägt mindestens ein Test fehl, weil ein kurzer Gittervektor die Periodizitätsstruktur stört. + +**Historischer Kontext — von Quanten zu Klassisch:** Dieses Ergebnis entstand auf einem ungewöhnlichen Weg. Aharonov und Regev zeigten zunächst **2003**, dass coGapSVP_{√n} ∈ **QMA** liegt (QMA = Quantum Merlin-Arthur, die Quantenversion von NP). Der Quantenzeuge bestand aus einer Überlagerung von Zuständen, die Informationen über die Gitterstruktur kodieren. Erst danach fanden die Autoren den Weg, den Quantenzeugen durch einen rein klassischen Zeugen zu ersetzen — ein Prozess, den sie als „Dequantisierung" bezeichneten. Dieser ungewöhnliche Weg „von quantenmechanisch zu klassisch" ist selbst ein methodisch interessantes Ergebnis. Die Technik basiert auf einer **Fourier-Approximation** von Funktionen über das Gitter — Funktionen auf ℝⁿ, die über L periodisch sind, können durch ihre Fourier-Koeffizienten (die auf dem dualen Gitter leben) sukzessiv approximiert werden. + +### 4.3 Implikationen für die Polynomielle Hierarchie + +Da GapSVP_{O(√n)} in NP ∩ coNP liegt, hat dies weitreichende Konsequenzen: + +> **Theorem:** Wenn GapSVP_γ für γ ≥ c·√n NP-hart ist (selbst unter Cook-Reduktionen), dann kollabiert die polynomielle Hierarchie: NP ⊆ coNP. + +Der Beweis erfordert Sorgfalt, da GapSVP ein Promise-Problem ist. Für „totale" Probleme (gewöhnliche Sprachen) ist die Argumentation „Problem in NP ∩ coNP und NP-hart ⟹ NP = coNP" Standard. Für Promise-Probleme müssen zusätzliche Argumente gemacht werden — Aharonov und Regev zeigten, wie man die MAYBE-Instanzen (die weder YES noch NO sind) sorgfältig behandelt. + +**Was das praktisch bedeutet — die Komplexitätslücke:** + +``` +γ = 1 γ ≈ n^{c/lll} γ ≈ √n γ ≈ 2^{O(n)} + | | | | + NP-hart NP-hart NP ∩ coNP in P (LLL) + |←——————————————————→|←———— ??? ————→|←—————————————————→| + bekannt schwer Terra incognita vermutlich nicht leicht + NP-hart +``` + +Die genaue Grenze, an der die Härte „kippt", ist eine der großen offenen Fragen. Liegt sie bei γ = n^ε? Bei γ = √n / polylog(n)? Niemand weiß es. + +### 4.4 Worst-Case zu Average-Case Reduktion + +Dies ist das vielleicht bemerkenswerteste Strukturergebnis und ein Alleinstellungsmerkmal von Gitterproblemen. + +#### Ajtais Entdeckung (1996) + +**Ajtai** entdeckte 1996 eine erstaunliche Verbindung: + +> **Ajtais Theorem (informell):** Wenn es einen effizienten Algorithmus gibt, der das **Short Integer Solution (SIS)** Problem für zufällig gewählte Instanzen mit nicht-vernachlässigbarer Wahrscheinlichkeit löst, dann gibt es einen effizienten Algorithmus, der _jede beliebige_ Instanz des approximativen SVP (und verwandter Probleme) löst. + +Das **SIS-Problem:** Gegeben eine zufällig gewählte Matrix A ∈ ℤ_q^{n×m}, finde einen kurzen Nicht-Null-Vektor z ∈ ℤ^m mit Az = 0 mod q. Dieses Problem kann auch als „Finden von Kollisionen in einer generalized Subset-Sum-Funktion" interpretiert werden. + +#### Warum ist das so spektakulär? + +Für die meisten NP-harten Probleme gibt es **keine** solche Verbindung und es wird allgemein angenommen, dass es keine geben kann: + +- **SAT:** NP-vollständig im Worst-Case, aber zufällige SAT-Instanzen sind (für geeignete Klausel-zu-Variablen-Verhältnisse) oft leicht. Bogdanov und Trevisan zeigten starke Barrieren gegen generelle Worst-Case-to-Average-Case-Reduktionen für NP-Probleme. +- **Faktorisierung:** RSA-Sicherheit basiert auf der _Average-Case_-Annahme „Faktorisieren zufällig gewählter Zahlen ist schwer", aber es gibt keine bekannte Reduktion vom Worst-Case. +- **Permanent:** Hier gibt es eine Worst-Case-to-Average-Case-Verbindung (Lipton 1991), aber der Permanent ist vermutlich nicht in NP. + +Für Gitterprobleme ist die Situation fundamental anders: Wenn jemand einen Algorithmus findet, der SIS für zufällige Instanzen effizient löst, dann kann man damit _jede beliebige_ Worst-Case-Instanz des approximativen SVP lösen. Für die Kryptografie bedeutet das: Die Sicherheit basiert nicht auf einer „hoffentlich schwierigen" Annahme über typische Instanzen, sondern auf der **Worst-Case-Schwierigkeit** eines gut untersuchten mathematischen Problems. + +#### Verbesserungen des Verbindungsfaktors + +Der „Verbindungsfaktor" γ wurde über die Jahre schrittweise verbessert: + +|Referenz|Verbindungsfaktor γ| +|---|---| +|Ajtai (1996)|> n⁸ (von Cai geschätzt)| +|Cai & Nerurkar (1997)|n^{4+ε}| +|Micciancio (2004)|n³ · ω(√(log n · log log n))| +|**Micciancio & Regev (2007)**|**Õ(n)** — fast linear!| + +Das Ergebnis von **Micciancio und Regev** ist besonders bedeutsam: Der Verbindungsfaktor Õ(n) gilt für SVP, SIVP, CRP und BDD gleichzeitig. Die Hauptwerkzeuge sind **Gauß-Verteilungen über Gittern** und die hochdimensionale **Fourier-Transformation**. Sie definieren einen neuen Gitterparameter (den „Smoothing-Parameter"), der bestimmt, wie viel Gaußsches Rauschen man einem Gitter hinzufügen muss, um eine nahezu gleichmäßige Verteilung zu erhalten. Dieser Parameter ermöglicht eine elegante und einheitliche Behandlung aller vier Probleme. + +**Grenze der Technik:** Der Verbindungsfaktor Õ(n) liegt nahe an der Grenze √n, ab der GapSVP in NP ∩ coNP liegt. Eine weitere Verbesserung auf o(√n) würde die Worst-Case-Annahme in eine Region bringen, die möglicherweise „zu leicht" für kryptografische Zwecke ist. + +### 4.5 Die Reduktionskette zur Kryptografie: LWE + +**Regev (2005)** führte das **Learning With Errors (LWE)** Problem ein, das die Brücke zwischen Gitterproblemen und moderner Kryptografie schlägt. + +#### Das LWE-Problem + +LWE-Instanz: Gegeben sind m Paare (aᵢ, bᵢ) ∈ ℤ_q^n × ℤ_q, wobei bᵢ = ⟨aᵢ, s⟩ + eᵢ mod q. Hier ist s ∈ ℤ_q^n ein geheimer Vektor, die aᵢ sind zufällig und uniform gewählt, und die eᵢ sind kleine Fehlerterme (aus einer diskreten Gauß-Verteilung mit Parameter α·q). + +- **Search-LWE:** Finde s. +- **Decision-LWE:** Unterscheide (aᵢ, ⟨aᵢ, s⟩ + eᵢ) von uniform zufälligen Paaren (aᵢ, uᵢ). + +Ohne die Fehler eᵢ wäre dies trivial (Gauß-Elimination). Die kleinen Fehler machen das Problem drastisch schwerer — sie „verwischen" die lineare Struktur gerade genug. Die kryptografische Idee: (A, b = As + e) ist der öffentliche Schlüssel, s der private Schlüssel. Ein Bit wird verschlüsselt, indem mehrere Gleichungen addiert und das Bit im Ergebnis versteckt wird. + +#### Regevs Reduktion + +> **Regevs Hauptresultat (2005):** Wenn es einen effizienten Algorithmus für LWE gibt, dann gibt es einen effizienten **Quanten**algorithmus für GapSVP und SIVP mit Approximationsfaktor Õ(n/α). + +Die Reduktion ist quantenmechanisch — sie nutzt Quantenüberlagerungen, um aus einem LWE-Orakel Samples von einer diskreten Gauß-Verteilung über das Gitter zu erzeugen. Ob die Quantenmechanik hier notwendig ist, war eine zentrale offene Frage. + +**Peikert (2009)** beantwortete diese teilweise: Er zeigte eine **klassische** Reduktion von GapSVP auf LWE, allerdings nur für große Moduli q ≥ 2^{n/2}. Für polynomielle Moduli nutzt Peikert eine neue Variante ζ-to-γ-GapSVP, die möglicherweise leichter ist, aber basierend auf dem Stand der Algorithmen immer noch exponentiell schwer erscheint. + +**Brakerski et al. (2013)** gaben eine Modulus-Reduktion: LWE mit exponentiellem Modulus in Dimension n reduziert sich auf LWE mit polynomiellem Modulus in Dimension n² — klassisch, ohne Quantenmechanik. + +#### Die vollständige Reduktionskette + +``` +Worst-Case GapSVP/SIVP (n-dim, Faktor Õ(n/α)) + ↓ Ajtai 1996, Micciancio-Regev 2007 +Average-Case SIS (schwer für zufällige Instanzen) + ↓ Regev 2005, Peikert 2009 +Average-Case LWE (schwer für zufällige Instanzen) + ↓ kryptografische Konstruktionen +ML-KEM (FIPS 203), ML-DSA (FIPS 204), FHE, ... +``` + +**Quellen:** + +- Micciancio: "SVP Hard to Approximate" — https://cseweb.ucsd.edu/~daniele/papers/SVP.pdf +- Peikert/Stephens-Davidowitz: "Complexity of SVP" — https://www.cs.umd.edu/~gasarch/open/svp-color.pdf +- Regev: Lecture Notes "Average-case Hardness" — https://cims.nyu.edu/~regev/teaching/lattices_fall_2004/ln/averagecase.pdf +- Micciancio & Regev: "Worst-case to Average-case Reductions based on Gaussian Measures" — https://cims.nyu.edu/~regev/papers/average.pdf +- Aharonov & Regev: "Lattice Problems in NP ∩ coNP" (J. ACM, 2005) — https://dl.acm.org/doi/10.1145/1089023.1089025 +- Aharonov & Regev: "A Lattice Problem in Quantum NP" — https://arxiv.org/abs/quant-ph/0307220 +- Regev: "On Lattices, Learning with Errors..." — https://cims.nyu.edu/~regev/papers/qcrypto.pdf +- Regev: "The Learning with Errors Problem" (Survey) — https://cims.nyu.edu/~regev/papers/lwesurvey.pdf +- Peikert: "Public-Key Cryptosystems from the Worst-Case SVP" — https://web.eecs.umich.edu/~cpeikert/pubs/svpcrypto.pdf +- Regev: Lecture Notes "GapCVP in coNP" — https://cims.nyu.edu/~regev/teaching/lattices_fall_2004/ln/gg.pdf +- Peikert: "Limits on Hardness in ℓp Norms" — https://web.eecs.umich.edu/~cpeikert/pubs/lp_norms.pdf + +--- + +## 5. Algorithmen & bekannte Schranken + +### 5.1 Der LLL-Algorithmus (1982) + +Der **Lenstra-Lenstra-Lovász (LLL)** Algorithmus ist einer der einflussreichsten Algorithmen der theoretischen Informatik und berechnet eine „reduzierte" Gitterbasis in **polynomieller Zeit**. + +#### Was ist eine LLL-reduzierte Basis? + +Eine Basis B = {b₁, ..., bₙ} heißt δ-LLL-reduziert (typischerweise δ = 3/4), wenn zwei Bedingungen erfüllt sind: + +1. **Größenreduktion:** |μᵢ,ⱼ| ≤ 1/2 für alle i > j. Die Gram-Schmidt-Koeffizienten μᵢ,ⱼ = ⟨bᵢ, b̃ⱼ⟩/⟨b̃ⱼ, b̃ⱼ⟩ messen, wie viel jeder Basisvektor in Richtung der vorherigen Gram-Schmidt-Vektoren zeigt. Die Bedingung |μᵢ,ⱼ| ≤ 1/2 bedeutet, dass man die ganzzahligen Vielfachen der vorherigen Vektoren so weit wie möglich subtrahiert hat — analog zur Größenreduktion bei der Gram-Schmidt-Orthogonalisierung, aber unter Beibehaltung der Ganzzahligkeit. + +2. **Lovász-Bedingung:** ‖b̃ᵢ₊₁‖² ≥ (δ − μ²ᵢ₊₁,ᵢ) · ‖b̃ᵢ‖² für alle i. Diese Bedingung stellt sicher, dass die Gram-Schmidt-Vektoren nicht „zu schnell" kürzer werden. Für n = 2 entspricht sie der Bedingung, dass die Basisvektoren in der richtigen Reihenfolge stehen (der kürzere zuerst). In höheren Dimensionen verallgemeinert sie diese Ordnungsbedingung. + + +#### Der Algorithmus + +LLL arbeitet iterativ und ist konzeptuell einfach: + +1. Berechne die Gram-Schmidt-Orthogonalisierung. +2. Für k = 2, ..., n: Führe Größenreduktion durch (subtrahiere ganzzahlige Vielfache vorheriger Vektoren). +3. Prüfe die Lovász-Bedingung für k und k−1. +4. Falls verletzt: Tausche b_k und b_{k-1} und gehe zurück zu k−1. +5. Falls erfüllt: Gehe weiter zu k+1. + +**Terminierung:** Die Potentialfunktion D = Π_{i=1}^n det(L(b₁,...,bᵢ))² ist eine positive ganze Zahl, die bei jedem Swap um mindestens den Faktor 1/δ < 1 abnimmt. Da D ≥ 1 (weil die Determinanten ganzzahliger Gitter ganzzahlig sind), terminiert der Algorithmus nach höchstens O(n² log(max ‖bᵢ‖)) Swaps. Jeder Swap und jede Größenreduktion erfordern polynomiell viele Operationen, also ist die **Gesamtlaufzeit polynomiell**. + +#### Approximationsgarantie + +Der erste Vektor b₁ einer LLL-reduzierten Basis erfüllt: + +‖b₁‖ ≤ 2^{(n-1)/2} · λ₁(L) + +Also liefert LLL eine **2^{(n-1)/2}-Approximation** des kürzesten Vektors — exponentiell im schlimmsten Fall. Durch Schnorrs **BKZ-Verallgemeinerung** (die die Lovász-Bedingung auf Blöcke von k Vektoren erweitert und intern exaktes SVP in Dimension k löst) erreicht man bessere Faktoren von 2^{O(n(log log n)²/log n)} in Polynomialzeit. + +#### Anwendungen + +Trotz des exponentiellen Worst-Case-Faktors ist LLL extrem nützlich: Brechen von Knapsack-Kryptosystemen, Faktorisierung von Polynomen über ℤ, ganzzahlige Programmierung in fester Dimension, Finden algebraischer Relationen, und viele Anwendungen in der Kryptoanalyse. + +### 5.2 Exakte Algorithmen + +#### Enumeration (Kannan, 1983) + +Kombiniert Basisreduktion mit erschöpfender Aufzählung. Grundidee: Nach einer guten Basisreduktion als Preprocessing werden systematisch alle Gittervektoren v = Σ zᵢbᵢ aufgezählt, deren projizierte Längen innerhalb bestimmter Schranken liegen. Die Schranken ergeben sich aus der reduzierten Basis und der Gram-Schmidt-Orthogonalisierung. + +- **Laufzeit:** n^{O(n)} — superexponentiell +- **Speicher:** poly(n) — der große Vorteil gegenüber Sieving! +- In der Praxis (bis Dimension ≈60-80) oft schneller als Sieving, da die Worst-Case-Analyse sehr pessimistisch ist + +#### Sieving (AKS, 2001) + +Die konzeptionell eleganteste Methode. **Grundidee:** Man startet mit exponentiell vielen (~2^{10n}) zufälligen Gittervektoren in einer großen Kugel. Dann werden iterativ Paare naher Vektoren durch ihre Differenz ersetzt — ein „Sieb", das immer kürzere Vektoren erzeugt. Nach genügend Runden enthält die Menge den kürzesten Vektor. + +**Warum funktioniert das?** Statt an „Vektoren" zu denken, betrachte man Gitterpunkte modulo dem kürzesten Vektor. Wenn zwei Punkte nahe am gleichen Gitterpunkt liegen, ist ihre Differenz kurz. Durch ein Packing-Argument (Kugeln vom Radius λ₁/2 um verschiedene Gitterpunkte sind disjoint) kann man zeigen, dass genügend solche Paare gefunden werden. + +**Laufzeit-Entwicklung:** + +- AKS (2001): 2^{O(n)} (erste einfach-exponentielle Lösung) +- Nguyen-Vidick (2008, heuristisch): (4/3+ε)^n ≈ 2^{0.415n} — zeigte, dass Sieving praktisch ist +- Best provable (Aggarwal et al.): 2^{n+o(n)} — optimal up to lower-order terms + +**GaussSieve (Micciancio-Voulgaris, 2010):** Eine praktischere Variante, die statt einer Batch-Verarbeitung inkrementell arbeitet — neue Vektoren werden einzeln eingefügt und gegen die bestehende Liste reduziert. In Experimenten deutlich effizienter als die theoretisch analysierten Varianten. + +#### Voronoi-Zellen (Micciancio & Voulgaris, 2010) + +Ein fundamentaler anderer Ansatz: Berechne die Voronoi-Zelle des Gitters (die Menge aller Punkte, die näher am Ursprung sind als an jedem anderen Gitterpunkt). Aus der Voronoi-Zelle kann man CVP, SVP und die meisten anderen Gitterprobleme in NP lösen. + +- **Deterministisch** (kein Zufall nötig) +- **Laufzeit:** Õ(4^n), **Speicher:** Õ(2^n) +- Löst nicht nur SVP, sondern auch CVP — der erste deterministische 2^{O(n)}-Algorithmus für CVP + +### 5.3 Übersichtstabelle + +|Ansatz|γ|Laufzeit|Speicher| +|---|---|---|---| +|LLL (1982)|2^{(n-1)/2}|poly(n)|poly(n)| +|BKZ-k (Schnorr)|2^{O(n/k)}|2^{O(k)}|poly(n)| +|Enumeration (Kannan)|1 (exakt)|n^{O(n)}|poly(n)| +|Sieving (best provable)|1 (exakt)|2^{n+o(n)}|2^{n+o(n)}| +|Voronoi (MV 2010)|1 (exakt)|Õ(4^n)|Õ(2^n)| + +**Offene Frage:** Kann SVP in 2^{O(n)} Zeit mit 2^{o(n)} Speicher gelöst werden? + +**Quellen:** + +- Wikipedia: LLL Algorithm — https://en.wikipedia.org/wiki/Lenstra%E2%80%93Lenstra%E2%80%93Lov%C3%A1sz_lattice_basis_reduction_algorithm +- Micciancio: CSE 206A Lecture 3 — https://cseweb.ucsd.edu/classes/wi12/cse206A-a/lec3.pdf +- MIT OCW: "LLL algorithm" — https://ocw.mit.edu/courses/18-409-topics-in-theoretical-computer-science-an-algorithmists-toolkit-fall-2009/ +- Nguyen & Vidick: "Sieve Algorithms for SVP are Practical" — https://people.csail.mit.edu/vidick/JoMC08.pdf +- Voulgaris: "Algorithms for closest and shortest vector problems" — https://escholarship.org/uc/item/4zt7x45z +- Aggarwal et al.: "Faster Provable Sieving" — https://arxiv.org/pdf/1907.04406 +- Aggarwal et al.: "Improved Algorithms for SVP" (STACS 2021) — https://drops.dagstuhl.de/storage/00lipics/lipics-vol187-stacs2021/LIPIcs.STACS.2021.4/LIPIcs.STACS.2021.4.pdf + +--- + +## 6. Bedeutung für Post-Quantum-Kryptografie + +### 6.1 Das Problem mit RSA und ECC + +RSA und ECC (elliptische Kurven) können durch **Shors Algorithmus** effizient gebrochen werden. Die Gefahr des „Harvest now, decrypt later"-Angriffs: Verschlüsselte Daten werden heute abgefangen und in Zukunft entschlüsselt. + +### 6.2 NIST-Standards (August 2024) + +Am 13. August 2024 veröffentlichte NIST die ersten drei Post-Quantum-Standards: + +**FIPS 203 — ML-KEM:** Basierend auf Kyber. Primärer Standard für Schlüsselaustausch. Sicherheit basiert auf Module-LWE. Drei Stufen: ML-KEM-512 (~128-bit), ML-KEM-768 (~192-bit, empfohlen), ML-KEM-1024 (~256-bit). Schlüsselgrößen ~1.5 KB, sub-Millisekunden Handshakes. + +**FIPS 204 — ML-DSA:** Basierend auf Dilithium. Primärer Standard für digitale Signaturen. Basiert auf Module-LWE und Module-SIS. Signaturen 2-5 KB, schnelle Verifikation, seitenkanalresistent. + +**FIPS 205 — SLH-DSA:** Basierend auf SPHINCS+. Hashbasiert, als Backup falls Gitter gebrochen werden. + +Weitere: FALCON (FIPS 206, noch in Arbeit) für kleine Signaturen; HQC (März 2025) als codebasiertes Backup für ML-KEM. + +### 6.3 Die Sicherheitsargumentation + +Die vollständige Kette: + +1. **Worst-Case-Härte:** GapSVP/SIVP gelten als schwer — kein bekannter Quanten- oder klassischer Algorithmus besser als 2^{Ω(n)}. +2. **Worst-Case → Average-Case:** Ajtai/Regev/Peikert: Wenn GapSVP im Worst-Case schwer ist, ist LWE als Average-Case-Problem schwer. +3. **LWE → Kryptografie:** ML-KEM/ML-DSA basieren auf Module-LWE/Module-SIS. Langlois & Stehlé (2015) zeigten Worst-Case-to-Average-Case-Reduktionen für Module-Varianten. + +**Einzigartigkeit:** Während RSA/ECC auf Average-Case-Annahmen beruhen, bieten gitterbasierte Systeme Worst-Case-Sicherheit. + +**Quellen:** + +- NIST Post-Quantum Standards — https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards +- NIST PQC Standardization — https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization +- Wikipedia: NIST PQC — https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography_Standardization +- Langlois & Stehlé: "Module Lattice Reductions" — https://eprint.iacr.org/2012/090.pdf + +--- + +## 7. Zusammenfassung & offene Fragen + +### Zusammenfassung + +|Eigenschaft|Status| +|---|---| +|SVP exakt (ℓ₂): NP-hart?|Ja, randomisierte Reduktion (Ajtai 1998)| +|SVP exakt (ℓ∞): NP-hart?|Ja, deterministisch (van Emde Boas 1981)| +|Konstante Approximation: NP-hart?|Ja, randomisiert (Micciancio 2001)| +|GapSVP_{O(√(n/log n))} ∈ coAM?|Ja (Goldreich & Goldwasser 2000)| +|GapSVP_{O(√n)} ∈ NP ∩ coNP?|Ja (Aharonov & Regev 2005)| +|Worst-Case = Average-Case?|Ja, Faktor Õ(n) (Micciancio-Regev 2007)| +|Bester exakter Algorithmus|2^{n+o(n)} (Sieving)| +|Beste Poly-Zeit-Approximation|2^{O(n)} (LLL)| +|Quantenvorteil bekannt?|Nein| + +### Zentrale offene Fragen + +1. **Deterministische NP-Härte** von SVP in ℓ₂? (Offen seit 1998) +2. **Wo kippt die Härte?** Zwischen n^{c/log log n} und √n liegt eine unverstandene Zone. +3. **Ist GapSVP_{n^{2+ε}} NP-hart?** Falls ja → LWE-Kryptografie sicher allein aus P ≠ NP. +4. **Quantenalgorithmen für SVP?** Keine bekannt — eine der wichtigsten offenen Fragen. +5. **SVP in 2^{O(n)} Zeit, 2^{o(n)} Speicher?** +6. **Vollständige Dequantisierung** der LWE-Reduktion für polynomielle Moduli? + +--- + +## Literaturverzeichnis + +|Kürzel|Referenz| +|---|---| +|[Ajt96]|Ajtai. "Generating hard instances of lattice problems." STOC 1996.| +|[Ajt98]|Ajtai. "SVP in ℓ₂ is NP-hard for randomized reductions." STOC 1998.| +|[AKS01]|Ajtai, Kumar, Sivakumar. "A sieve algorithm for SVP." STOC 2001.| +|[AR05]|Aharonov, Regev. "Lattice problems in NP ∩ coNP." J. ACM 2005.| +|[GG00]|Goldreich, Goldwasser. "Limits of nonapproximability of lattice problems." JCSS 2000.| +|[Kan83]|Kannan. "Improved algorithms for integer programming." STOC 1983.| +|[LLL82]|Lenstra, Lenstra, Lovász. "Factoring polynomials." Math. Annalen 1982.| +|[Mic01]|Micciancio. "SVP hard to approximate to within some constant." SICOMP 2001.| +|[MR07]|Micciancio, Regev. "Worst-case to average-case via Gaussian measures." SICOMP 2007.| +|[MV10]|Micciancio, Voulgaris. "Deterministic 2^{O(n)} for lattice problems." STOC 2010.| +|[Pei09]|Peikert. "Public-key cryptosystems from worst-case SVP." STOC 2009.| +|[PS23]|Peikert, Stephens-Davidowitz. "Complexity of SVP." SIGACT News 2023.| +|[Reg05]|Regev. "On lattices, learning with errors..." STOC 2005 / J. ACM 2009.| \ No newline at end of file diff --git a/Komplexitätstheorie/vortrag/Zeitplan.md b/Komplexitätstheorie/vortrag/Zeitplan.md new file mode 100644 index 0000000..bcdc183 --- /dev/null +++ b/Komplexitätstheorie/vortrag/Zeitplan.md @@ -0,0 +1,75 @@ +# SVP-Vortrag Vorbereitung — Zeitplan +## Tag 1 — Inhalt & Folien (4–5h) +### Block 1: Tiefgang ins Thema (4 Pomodoros · ~2h) + +| # | Dauer | Fokus | +| --- | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| 🍅1 | 25min | **Problemverständnis vertiefen:** SVP formal definieren, Approximationsfaktoren (γ-SVP) verstehen, Abgrenzung zu CVP | +| ☕ | 5min | Pause | +| 🍅2 | 25min | **Härte & Reduktionen:** NP-Härte von SVP, Worst-Case-to-Average-Case-Reduktion (Ajtai), warum das für Krypto so besonders ist | +| ☕ | 5min | Pause | +| 🍅3 | 25min | **Algorithmen:** LLL-Algorithmus einordnen (polynomiell, aber nur exponentielle Approximation), Schnorr-Euchner, warum exakte Lösung so schwer bleibt | +| ☕ | 5min | Pause | +| 🍅4 | 25min | **Krypto-Verbindung:** Lattice-based Crypto (NTRU, LWE/SIS als verwandte Probleme), Relevanz für Post-Quantum-Kryptografie, NIST-Standardisierung | +| ☕ | 15min | **Lange Pause** — aufstehen, Wasser, kurz raus | + +### Block 2: Folien anpassen (3 Pomodoros · ~1,5h) + +|# |Dauer|Fokus | +|--|-----|-----------------------------------------------------------------------------------------------------------------------| +|🍅5|25min|**Folien durchgehen:** Reveal.js öffnen, Lücken identifizieren, neue Erkenntnisse aus Block 1 einarbeiten | +|☕ |5min |Pause | +|🍅6|25min|**Folien fertigstellen:** Visualisierungen prüfen, Übergänge zwischen Folien glätten, Speaker-Notes ergänzen | +|☕ |5min |Pause | +|🍅7|25min|**Erster Trockenlauf:** Einmal komplett durchsprechen (gerne mit Stoppuhr), Timing notieren, holprige Stellen markieren| +|☕ |15min|**Lange Pause** | + +### Block 3: Nachschliff (1–2 Pomodoros · ~0,5–1h) + +|# |Dauer|Fokus | +|--|-----|----------------------------------------------------------------------------------------------------------------------| +|🍅8|25min|**Zweiter Trockenlauf:** Holprige Stellen gezielt verbessern, nochmal komplett durchsprechen | +|☕ |5min |Pause | +|🍅9|25min|*(Optional)* **Prof-Fragen vorbereiten:** 3–4 wahrscheinliche Fragen aufschreiben + Stichpunkt-Antworten (siehe unten)| + +----- + +## Tag 2 — Feinschliff & Üben (1–2h) + +> Heute hast du auch deinen anderen Vortrag — danach nur noch SVP polieren, keine neuen Inhalte! + +### Block 1: Generalprobe (2–3 Pomodoros · ~1–1,5h) + +|# |Dauer|Fokus | +|--|-----|----------------------------------------------------------------------------------------------------------| +|🍅1|25min|**Dritter Trockenlauf:** Komplett durchsprechen, Timing prüfen (Ziel: 10–15min), letzte Folien-Tweaks | +|☕ |5min |Pause | +|🍅2|25min|**Prof-Fragen durchgehen:** Antworten laut durchsprechen, nicht nur lesen — das macht den Unterschied | +|☕ |5min |Pause | +|🍅3|25min|*(Falls Zeit)* **Letzter Durchlauf:** Einmal sauber von vorne bis hinten, dann Laptop zuklappen und fertig| + +----- + +## Wahrscheinliche Prof-Fragen + +Bereite dir auf jede Frage 3–4 Sätze als Antwort vor: + +1. **Warum ist SVP für Post-Quantum-Krypto relevant?** + → Worst-Case-Härte überträgt sich auf Average-Case → Kryptosysteme basieren auf der Annahme, dass SVP schwer bleibt, auch für Quantencomputer +2. **Was leistet der LLL-Algorithmus, und wo sind seine Grenzen?** + → Polynomielle Laufzeit, aber Approximationsfaktor exponentiell in der Dimension → reicht für kleine Dimensionen, nicht für kryptografische Parameter +3. **Was ist der Unterschied zwischen SVP und CVP?** + → SVP: kürzester Vektor im Gitter, CVP: nächster Gitterpunkt zu einem beliebigen Punkt → CVP ist mindestens so schwer wie SVP +4. **Was bedeutet die Worst-Case-to-Average-Case-Reduktion?** + → Ajtai 1996: Wenn man zufällige Instanzen von SIS lösen kann, kann man auch Worst-Case-SVP lösen → einzigartig in der Kryptografie, bei den meisten Problemen (RSA, DLP) basiert Sicherheit nur auf Average-Case-Annahmen +5. **Wie ordnet sich SVP in die Komplexitätslandschaft ein?** + → NP-hart für exakte Lösung (Ajtai, 1998), für bestimmte Approximationsfaktoren in NP ∩ coNP → nicht NP-vollständig unter üblichen Annahmen + +----- + +## Regeln für dich selbst + +- Handy in einen anderen Raum während Pomodoros +- Nach Tag 1 keine neuen Quellen mehr lesen +- Lieber einmal mehr üben als eine Folie perfektionieren +- Du musst nicht alles wissen — du musst zeigen, dass du es verstanden hast \ No newline at end of file diff --git a/Komplexitätstheorie/zusammenfassungen/Grundlagen.md b/Komplexitätstheorie/zusammenfassungen/Grundlagen.md new file mode 100644 index 0000000..2e73bef --- /dev/null +++ b/Komplexitätstheorie/zusammenfassungen/Grundlagen.md @@ -0,0 +1,397 @@ +# Komplexitätstheorie – Grundlagen, Entscheidbarkeit & Probleme + +**Basierend auf:** KO1 & KO2 (Prof. Dr. Björn Grohmann, HWR Berlin) + +----- + +## 1. Die Turing-Maschine + +### Was ist eine Turing-Maschine? + +Eine Turing-Maschine (TM) ist ein abstraktes Berechnungsmodell – im Grunde der einfachste denkbare „Computer”. Sie besteht aus drei Teilen: + +- **Ein unendlich langes Band**, unterteilt in Zellen. Jede Zelle enthält genau ein Symbol. +- **Ein Lese-/Schreibkopf**, der sich auf dem Band nach links oder rechts bewegen kann, Symbole lesen und schreiben kann. +- **Eine endliche Steuerung**, die anhand des aktuellen Zustands und des gelesenen Symbols entscheidet, was als nächstes passiert. + +### Formale Definition + +Eine TM ist ein 7-Tupel $(Q, \Sigma, \Gamma, \delta, q_0, q_{\text{accept}}, q_{\text{reject}})$: + +|Bestandteil |Bedeutung | +|-------------------|------------------------------------------------------------------------------| +|$Q$ |Endliche Zustandsmenge | +|$\Sigma$ |Eingabealphabet (ohne Blanksymbol $\sqcup$) | +|$\Gamma$ |Bandalphabet ($\sqcup \in \Gamma$, $\Sigma \subseteq \Gamma$) | +|$\delta$ |Übergangsfunktion: $Q \times \Gamma \rightarrow Q \times \Gamma \times {L, R}$| +|$q_0$ |Startzustand | +|$q_{\text{accept}}$|Akzeptierzustand – die Maschine sagt „Ja” | +|$q_{\text{reject}}$|Ablehnungszustand – die Maschine sagt „Nein” | + +Die Übergangsfunktion $\delta$ ist das Herzstück: Sie sagt „Wenn du im Zustand $q$ bist und Symbol $a$ liest, dann schreibe Symbol $b$, wechsle in Zustand $q’$ und bewege den Kopf nach links oder rechts.” + +### Konfiguration + +Eine Konfiguration ist eine Momentaufnahme der TM zu einem bestimmten Zeitpunkt. Sie umfasst den aktuellen Zustand, den Bandinhalt und die Kopfposition. + +Beispiel: $1011q_701111$ bedeutet, dass auf dem Band „101101111” steht, die Maschine im Zustand $q_7$ ist und der Kopf auf dem Zeichen direkt rechts von $q_7$ steht (also auf der „0”). + +### Was bedeutet „halten”? + +Eine Turing-Maschine **hält**, wenn sie irgendwann in den Akzeptier- oder Ablehnungszustand gelangt und damit ihre Berechnung beendet. Wenn sie das nie tut, läuft sie endlos weiter – sie „hält nicht”. Das ist so, als würde ein Programm in einer Endlosschleife stecken und nie ein Ergebnis liefern. + +----- + +## 2. Varianten von Turing-Maschinen + +### Mehrband-TM (Multitape TM) + +Eine TM mit $k$ separaten Bändern und $k$ unabhängigen Köpfen. Die Übergangsfunktion hat die Form: + +$$\delta: Q \times \Gamma^k \rightarrow Q \times \Gamma^k \times {L, R, S}^k$$ + +Jede Mehrband-TM kann durch eine Einband-TM simuliert werden (alle Bänder werden hintereinander auf ein Band geschrieben, getrennt durch #-Symbole). Die Simulation kostet quadratischen Zeitoverhead: $O(T(n)^2)$. + +### Nichtdeterministische TM (NTM) + +Die Übergangsfunktion liefert statt eines einzigen Nachfolgezustands eine **Menge** von möglichen Übergängen: + +$$\delta: Q \times \Gamma \rightarrow \mathcal{P}(Q \times \Gamma \times {L, R})$$ + +Man kann sich das so vorstellen: An jedem Schritt „verzweigt” sich die Berechnung in mehrere parallele Pfade. Die NTM akzeptiert, wenn **mindestens ein** Pfad akzeptiert. Sie lehnt ab, wenn **alle** Pfade ablehnen. + +Jede NTM kann durch eine deterministische TM simuliert werden, allerdings mit exponentiellem Zeitverlust: Eine $t(n)$-Zeit-NTM wird zu einer $2^{O(t(n))}$-Zeit-DTM. + +### Universelle Turing-Maschine (UTM) + +Eine UTM $\mathcal{U}$ kann jede andere TM simulieren. Sie bekommt als Eingabe die Beschreibung einer TM $M$ (kodiert als Bitfolge, die sogenannte **Gödelnummer**) und eine Eingabe $x$ und berechnet dann $M(x)$. + +Die UTM ist im Grunde der theoretische Vorläufer des modernen Computers: Ein Gerät, das beliebige Programme ausführen kann. + +----- + +## 3. Äquivalente Berechnungsmodelle + +Mehrere andere Berechnungsmodelle sind **genauso mächtig** wie die Turing-Maschine. Das stützt die Church-Turing-These. + +|Modell |Kernidee | +|-------------------|---------------------------------------------------------------------------------------| +|**WHILE-Programme**|Schleifen mit Inkrement/Dekrement auf Variablen | +|**GOTO-Programme** |Nummerierte Anweisungen mit Sprungbefehlen | +|**Lambda-Kalkül** |Funktionsdefinition und -anwendung (Grundlage funktionaler Programmierung) | +|**Rule 110** |Eindimensionaler Zellularautomat – selbst dieses einfache System ist Turing-vollständig| + +### Church-Turing-These + +> „Jede effektiv berechenbare Funktion kann durch eine Turing-Maschine berechnet werden.” + +Das ist keine bewiesene Aussage, sondern eine These. Sie besagt: Es gibt kein Berechnungsmodell, das mehr berechnen kann als eine TM. Bisher wurde kein Gegenbeispiel gefunden. + +----- + +## 4. Entscheidbarkeit + +### Turing-erkennbar (semi-entscheidbar) + +Eine Sprache $L$ ist **Turing-erkennbar**, wenn es eine TM gibt, die so arbeitet: + +- Eingabe $w \in L$: Die TM akzeptiert (hält und sagt „Ja”). +- Eingabe $w \notin L$: Die TM lehnt ab **oder läuft endlos weiter**. + +Das Problem: Man weiß nie, ob die Maschine noch rechnet oder ob sie in einer Endlosschleife steckt. + +### Turing-entscheidbar (entscheidbar) + +Eine Sprache $L$ ist **Turing-entscheidbar**, wenn es eine TM gibt, die so arbeitet: + +- Eingabe $w \in L$: Die TM akzeptiert. +- Eingabe $w \notin L$: Die TM lehnt ab. +- **Die TM hält immer** – sie liefert auf jeder Eingabe eine definitive Antwort. + +### Der Zusammenhang + +Eine Sprache ist entscheidbar **genau dann, wenn** sie sowohl Turing-erkennbar als auch co-Turing-erkennbar ist. Die Idee: Man lässt zwei Maschinen parallel laufen – eine für $L$, eine für das Komplement $\overline{L}$. Eine von beiden wird irgendwann akzeptieren, und dann hat man die Antwort. + +### Hierarchie der Berechenbarkeit + +``` +Entscheidbar ⊂ Semi-entscheidbar ⊂ Alle Sprachen +(TM hält immer) (TM hält für w ∈ L) (manche sind gar nicht berechenbar) +``` + +----- + +## 5. Unentscheidbare Probleme + +### Das Halteproblem ($HALT_{\text{TM}}$) + +$$HALT_{\text{TM}} = {\langle M, w \rangle \mid M \text{ ist eine TM und } M \text{ hält auf Eingabe } w}$$ + +**Frage:** Kann man im Voraus entscheiden, ob ein beliebiges Programm auf einer beliebigen Eingabe irgendwann anhält oder ewig weiterläuft? + +**Antwort:** Nein – das Halteproblem ist unentscheidbar. + +### Die Akzeptanzsprache ($A_{\text{TM}}$) + +$$A_{\text{TM}} = {\langle M, w \rangle \mid M \text{ ist eine TM und } M \text{ akzeptiert } w}$$ + +$A_{\text{TM}}$ ist semi-entscheidbar (man kann $M$ auf $w$ simulieren), aber **nicht entscheidbar**. + +### Beweis durch Diagonalisierung + +Der Beweis nutzt dieselbe Idee wie Cantors Diagonalisierung: + +1. **Annahme:** Es gibt einen Entscheider $H$, der für jede TM $M$ und jede Eingabe $w$ korrekt entscheidet, ob $M$ die Eingabe $w$ akzeptiert. +2. **Konstruktion:** Baue eine „teuflische” Maschine $D$, die bei Eingabe $\langle M \rangle$ den Entscheider $H$ auf $\langle M, \langle M \rangle \rangle$ aufruft – also fragt „akzeptiert $M$ sich selbst?” – und dann **das Gegenteil tut**. +3. **Widerspruch:** Was passiert bei $D(\langle D \rangle)$? +- Falls $H$ sagt „$D$ akzeptiert sich selbst” → $D$ lehnt ab. Aber dann akzeptiert $D$ sich selbst nicht – Widerspruch zu dem, was $H$ gesagt hat. +- Falls $H$ sagt „$D$ akzeptiert sich selbst nicht” → $D$ akzeptiert. Aber dann akzeptiert $D$ sich selbst doch – wieder Widerspruch. +1. **Schlussfolgerung:** $H$ kann nicht existieren. + +Man kann sich das auch als Tabelle vorstellen: Zeilen sind TMs, Spalten sind Eingaben, Einträge sind 0 (lehnt ab) oder 1 (akzeptiert). $D$ nimmt die Diagonale und invertiert sie – und kann daher in keiner Zeile der Tabelle vorkommen, obwohl $D$ selbst eine TM ist. + +### Postsches Korrespondenzproblem (PCP) + +**Gegeben:** Wortpaare $(x_1, y_1), \ldots, (x_k, y_k)$, dargestellt als Dominosteine mit Ober- und Unterseite. + +**Gefragt:** Kann man eine Folge von Dominosteinen (mit Wiederholung) so aneinanderlegen, dass die obere und die untere Zeichenkette identisch sind? + +Das PCP ist unentscheidbar, aber semi-entscheidbar (man kann systematisch alle Kombinationen durchprobieren). + +### Hilberts 10. Problem + +**Frage (1900):** Gibt es ein Verfahren, das für jede Polynomgleichung mit ganzzahligen Koeffizienten entscheidet, ob sie eine ganzzahlige Lösung hat? + +**Antwort (Matijassewitsch, 1970):** Nein – unentscheidbar. + +### Weitere unentscheidbare Probleme + +|Problem |Frage |Semi-entscheidbar? | +|-----------------------------------|-----------------------------------------------|------------------------------| +|$E_{\text{TM}}$: Leerheitsproblem |Ist $L(M) = \emptyset$? |Nein (co-Turing-erkennbar) | +|$EQ_{\text{TM}}$: Äquivalenzproblem|Gilt $L(M_1) = L(M_2)$? |Nein | +|$REGULAR_{\text{TM}}$ |Ist $L(M)$ regulär? |Nein | +|$MIN_{\text{TM}}$ |Ist $M$ eine minimale TM? |Nicht einmal semi-entscheidbar| +|Erfüllbarkeit (Prädikatenlogik) |Ist ein prädikatenlogischer Ausdruck erfüllbar?|Ja, aber unentscheidbar | +|Gültigkeit (Prädikatenlogik) |Ist ein Ausdruck allgemeingültig? |Ja, aber unentscheidbar | + +----- + +## 6. Zeitkomplexität + +### Laufzeit + +Die Laufzeit (Running Time) einer deterministischen TM $M$ ist die Funktion $f(n)$, die angibt, wie viele Schritte $M$ **im schlimmsten Fall** auf einer Eingabe der Länge $n$ benötigt. + +Bei einer nichtdeterministischen TM zählt man die maximale Schrittzahl über **alle Berechnungspfade** (auch die nicht-akzeptierenden). + +### Zeitkonstruierbarkeit + +Eine Funktion $t(n)$ heißt zeitkonstruierbar, wenn man den Wert $t(n)$ selbst in $O(t(n))$ Schritten berechnen kann. Beispiele: $n$, $n \log n$, $n^2$, $2^n$. + +### Simulationskosten + +|Transformation |Zeitoverhead | +|-----------------------------------------------------|----------------------------| +|Alphabetreduktion (auf ${0,1,\sqcup,\triangleright}$)|$O(\log | +|$k$ Bänder → 1 Band |$O(k \cdot T(n)^2)$ | +|NTM → DTM |$2^{O(T(n))}$ (exponentiell)| +|Bidirektional → Unidirektional |$O(T(n))$ | + +----- + +## 7. Komplexitätsklassen + +### Die wichtigsten Klassen im Überblick + +|Klasse |Definition |Intuition |Beispiele | +|-----------|--------------------------------|------------------------------------|--------------------------------------------| +|**P** |$\bigcup_k \text{TIME}(n^k)$ |Effizient lösbar |Sortieren, kürzeste Wege, Primzahltest (AKS)| +|**NP** |$\bigcup_k \text{NTIME}(n^k)$ |Lösung effizient überprüfbar |SAT, Hamiltonkreis, TSP, Knapsack | +|**co-NP** |Komplemente der NP-Sprachen |„Nein”-Antwort effizient überprüfbar|UNSAT, Tautologie | +|**PSPACE** |$\bigcup_k \text{SPACE}(n^k)$ |Polynomieller Speicher reicht |TQBF | +|**EXPTIME**|$\bigcup_k \text{TIME}(2^{n^k})$|Exponentielle Zeit |Generalisiertes Schach | + +### Die Inklusionskette + +$$P \subseteq NP \subseteq PSPACE = NPSPACE \subseteq EXPTIME$$ + +Die Gleichheit $PSPACE = NPSPACE$ folgt aus Savitch’s Theorem. + +### P vs. NP – Die zentrale offene Frage + +**P** = Probleme, die ein Computer effizient **lösen** kann. +**NP** = Probleme, deren Lösung ein Computer effizient **überprüfen** kann. + +Die Frage „Ist P = NP?” fragt im Kern: Ist jedes Problem, dessen Lösung leicht zu überprüfen ist, auch leicht zu finden? Die meisten Informatiker vermuten Nein. Das Problem ist eines der sieben Millennium-Probleme (Preisgeld: 1 Million Dollar). + +### Speicherkomplexität + +$$\text{SPACE}(f(n)) = {L \mid L \text{ wird von einer det. TM in } O(f(n)) \text{ Speicher entschieden}}$$ + +$$\text{NSPACE}(f(n)) = {L \mid L \text{ wird von einer nichtdet. TM in } O(f(n)) \text{ Speicher entschieden}}$$ + +### Savitch’s Theorem + +$$\text{NSPACE}(f(n)) \subseteq \text{SPACE}(f^2(n))$$ + +Nichtdeterministischer Speicher lässt sich deterministisch mit nur quadratischem Mehraufwand simulieren. Die Kernidee ist die CANYIELD-Prozedur: Um zu prüfen, ob Konfiguration $c_2$ von $c_1$ in $t$ Schritten erreichbar ist, probiert man alle möglichen Zwischenkonfigurationen $c_m$ und prüft rekursiv, ob $c_1 \to c_m$ in $t/2$ Schritten und $c_m \to c_2$ in $t/2$ Schritten möglich ist. Die Rekursionstiefe ist $O(\log t)$, jede Ebene braucht $O(f(n))$ Speicher, also insgesamt $O(f(n)^2)$. + +----- + +## 8. NP-Vollständigkeit + +### Polynomialzeit-Reduktion + +Eine Sprache $A$ ist polynomialzeit-reduzierbar auf $B$ (geschrieben $A \leq_P B$), wenn es eine in Polynomialzeit berechenbare Funktion $f$ gibt mit: + +$$w \in A \iff f(w) \in B$$ + +Intuition: Wenn man $B$ lösen kann, kann man auch $A$ lösen – man wandelt einfach jede $A$-Instanz mittels $f$ in eine $B$-Instanz um. $B$ ist also **mindestens so schwer** wie $A$. + +### Definition: NP-vollständig + +Eine Sprache $B$ ist NP-vollständig, wenn: + +1. $B \in NP$ (die Lösung ist effizient überprüfbar), **und** +2. $A \leq_P B$ für **jedes** $A \in NP$ (jedes NP-Problem lässt sich auf $B$ reduzieren). + +Erfüllt $B$ nur Bedingung 2, heißt $B$ **NP-hard** (NP-schwer). NP-harte Probleme müssen nicht selbst in NP liegen. + +$$\text{NP-vollständig} = NP \cap \text{NP-hard}$$ + +### Cook-Levin-Theorem (1971/1973) + +**SAT ist NP-vollständig.** Das war der erste Beweis, dass überhaupt ein NP-vollständiges Problem existiert. Daraus folgt: Könnte man SAT in Polynomialzeit lösen, wäre $P = NP$. + +### PSPACE-Vollständigkeit + +Eine Sprache $B$ ist PSPACE-vollständig, wenn $B \in PSPACE$ und jedes $A \in PSPACE$ polynomiell auf $B$ reduzierbar ist. + +**TQBF** (True Quantified Boolean Formula) ist PSPACE-vollständig. TQBF fragt, ob eine voll quantifizierte Boolesche Formel (mit $\forall$ und $\exists$) wahr ist. TQBF verallgemeinert SAT: Während SAT nur fragt „Gibt es eine erfüllende Belegung?” ($\exists$), erlaubt TQBF auch Allquantoren ($\forall$), was das Problem härter macht. + +----- + +## 9. Die wichtigsten NP-vollständigen Probleme + +### SAT (Erfüllbarkeitsproblem) + +**Eingabe:** Eine Boolesche Formel $\phi$ (z.B. $(x \lor \bar{y}) \land (\bar{x} \lor z)$). +**Frage:** Gibt es eine Belegung der Variablen mit wahr/falsch, sodass die Formel wahr wird? +**Zertifikat:** Die erfüllende Belegung selbst – man setzt die Werte ein und prüft. + +### Hamiltonkreis + +**Eingabe:** Ein ungerichteter Graph. +**Frage:** Gibt es einen Rundweg, der **jeden Knoten genau einmal** besucht und zum Startknoten zurückkehrt? +**Zertifikat:** Der Rundweg selbst – man prüft, ob er jeden Knoten genau einmal enthält. + +Die NP-Vollständigkeit wird durch Reduktion von SAT bewiesen, wobei eine Formel in einen Graphen mit speziellen Gadgets übersetzt wird (Variablenpfade, XOR-Gadgets, OR-Gadgets, Kreuzungs-Gadgets). + +### Traveling Salesman Problem (TSP) + +**Eingabe:** Städte mit Entfernungen und ein Budget $k$. +**Frage:** Gibt es eine Rundreise durch alle Städte mit Gesamtlänge $\leq k$? +**Zertifikat:** Die Rundreise selbst. + +### Knapsack (Rucksackproblem) + +**Eingabe:** Gegenstände mit Gewichten und Werten, ein Rucksack mit Kapazität $W$ und ein Zielwert $V$. +**Frage:** Kann man Gegenstände so auswählen, dass das Gesamtgewicht $\leq W$ ist und der Gesamtwert $\geq V$? +**Zertifikat:** Die Auswahl der Gegenstände. + +### Minesweeper + +**Eingabe:** Ein teilweise aufgedecktes Minesweeper-Feld. +**Frage:** Gibt es eine konsistente Minenbelegung für die verdeckten Felder? + +Die NP-Vollständigkeit wird gezeigt, indem man logische Schaltkreise (Drähte, NOT-Gates, AND-Gates) innerhalb eines Minesweeper-Spielfelds simuliert. Damit lässt sich jede SAT-Instanz als Minesweeper-Konfiguration kodieren. + +### Karp’s Liste (1972) + +Richard Karp bewies 1972, dass 21 Probleme NP-vollständig sind, alle durch Reduktionen ausgehend von SAT. Dazu gehören unter anderem Clique, Node Cover, Chromatic Number, Set Covering, Exact Cover, 3D-Matching, Partition und Max Cut. + +----- + +## 10. NP-Härte von Videospielen + +Viele Videospiele sind NP-hard. Dafür gibt es allgemeine Metatheorems: + +### Metatheorem 1: Location Traversal + Single-Use Paths + +Wenn ein Spiel bestimmte Punkte vorschreibt, die besucht werden müssen, und Wege nur einmal benutzbar sind, ist es NP-hard (Reduktion vom Hamiltonkreisproblem). + +### Metatheorem 2: Tokens, Toll Roads, Location Traversal + +Ein Spiel ist NP-hard, wenn es sammelbare Tokens, kostenpflichtige Wege und zu besuchende Orte hat. Beispiel: In Pac-Man sind Power Pills die Tokens und Geisterkorridore die Toll Roads. + +### Metatheorem 3: Keys, Doors, One-Way Paths + +Wie Metatheorem 2, aber mit Schlüsseln statt Tokens und Türen statt Toll Roads. + +### Metatheorem 4: Doors + Pressure Plates + +Türen und Druckplatten (die Türen öffnen/schließen) machen ein Spiel NP-hard, selbst wenn keine zwei Druckplatten dieselbe Tür steuern. + +### Metatheorem 5: Doors + k-Buttons + +Buttons, bei denen der Spieler entscheiden kann, ob er sie drückt, und die $k$ Türen gleichzeitig beeinflussen, machen ein Spiel NP-hard für $k \geq 2$. + +----- + +## 11. Zusammenfassung: Was ist wo? + +### Entscheidbarkeit + +|Problem |Entscheidbar?|Semi-entscheidbar? | +|------------------------------------------|-------------|--------------------------| +|$A_{\text{TM}}$ (akzeptiert M w?) |Nein |Ja | +|$HALT_{\text{TM}}$ (hält M auf w?) |Nein |Ja | +|PCP |Nein |Ja | +|Hilberts 10. Problem |Nein |Ja | +|$E_{\text{TM}}$ (ist $L(M)$ leer?) |Nein |Nein (co-Turing-erkennbar)| +|$EQ_{\text{TM}}$ (sind $L(M_1) = L(M_2)$?)|Nein |Nein | +|$MIN_{\text{TM}}$ (ist M minimal?) |Nein |Nein | + +### Komplexität + +|Problem |Klasse | +|------------------------|------------------| +|Sortieren, kürzeste Wege|P | +|Primzahltest (AKS) |P | +|SAT |NP-vollständig | +|Hamiltonkreis |NP-vollständig | +|TSP |NP-vollständig | +|Knapsack |NP-vollständig | +|Minesweeper |NP-vollständig | +|TQBF |PSPACE-vollständig| +|Generalisiertes Schach |EXPTIME | + +### Beziehungen zwischen den Klassen + +``` +Entscheidbar: P ⊆ NP ⊆ PSPACE = NPSPACE ⊆ EXPTIME + +Unentscheidbar: Halteproblem, A_TM, PCP, Hilberts 10. Problem, ... +``` + +----- + +## 12. Glossar + +| Begriff | Bedeutung | +| ---------------------------- | ------------------------------------------------------------ | +| **Turing-Maschine** | Abstraktes Berechnungsmodell mit Band, Kopf und Steuerung | +| **Konfiguration** | Momentaufnahme: Zustand + Band + Kopfposition | +| **Gödelnummer** | Binäre Kodierung einer TM | +| **Church-Turing-These** | Alles Berechenbare ist Turing-berechenbar | +| **Turing-erkennbar** | TM akzeptiert $w \in L$, kann auf $w \notin L$ endlos laufen | +| **Turing-entscheidbar** | TM hält immer und gibt korrekte Antwort | +| **Diagonalisierung** | Beweistechnik: Widerspruch durch Selbstreferenz + Negation | +| **Zeitkomplexität** | Maximale Schrittzahl einer TM bei Eingabelänge $n$ | +| **Speicherkomplexität** | Maximale Zahl besuchter Bandzellen bei Eingabelänge $n$ | +| **Verifier** | Algorithmus der $(w, c)$ prüft – $c$ ist das Zertifikat | +| **Polynomialzeit-Reduktion** | $A \leq_P B$: Umwandlung von $A$ in $B$ in Polynomialzeit | +| **NP-vollständig** | In NP + jedes NP-Problem reduzierbar darauf | +| **NP-hard** | Jedes NP-Problem reduzierbar darauf (muss nicht in NP sein) | +| **PSPACE-vollständig** | In PSPACE + jedes PSPACE-Problem reduzierbar darauf | diff --git a/Komplexitätstheorie/zusammenfassungen/ko1 - themenliste.md b/Komplexitätstheorie/zusammenfassungen/ko1 - themenliste.md new file mode 100644 index 0000000..77d76bb --- /dev/null +++ b/Komplexitätstheorie/zusammenfassungen/ko1 - themenliste.md @@ -0,0 +1,73 @@ +# Komplexitätstheorie – Vorlesung 1: Themenliste +**Prof. Dr. Björn Grohmann | HWR Berlin | 18.02.2026** + +--- +## 1. Turing-Maschinen + +- Historischer Hintergrund (Alan Turing, Princeton) +- Formale Definition als 7-Tupel (Q, Σ, Γ, δ, q₀, q_accept, q_reject) +- Konfigurationen einer Turing-Maschine +- Beispiel: Sprache B = {w#w | w ∈ {0,1}*} – Zustandsdiagramm +- **Church-Turing-These**: Jede effektiv berechenbare Funktion ist Turing-berechenbar + +## 2. Varianten von Turing-Maschinen + +- **Multitape Turing Machine** – Äquivalenz zur Single-Tape TM +- **Universelle Turing-Maschine** – Gödelnummer, Simulation mit O(CT log T) Schritten +- **Nichtdeterministische Turing-Maschine (NTM)** – Übergangsfunktion δ: Q × Γ → P(Q × Γ × {L,R}) +- Äquivalenz NTM ↔ DTM mit exponentiellem Zeitverlust (2^O(t(n))) + +## 3. Laufzeit & Zeitkomplexität + +- Running Time / Time Complexity einer deterministischen TM +- Running Time einer nichtdeterministischen TM (maximale Tiefe aller Zweige) +- **Time Constructibility** – Definition und Bedeutung +- Overhead-Resultate: Alphabetreduktion (4 log|Γ| · T(n)), Tape-Reduktion (5kT(n)²), Bidirektionale TM (4T(n)) + +## 4. Entscheidbarkeit + +- **Turing-erkennbar** (rekursiv aufzählbar / semi-entscheidbar) +- **Turing-entscheidbar** (rekursiv / entscheidbar) +- Satz: Eine Sprache ist entscheidbar ⟺ sie ist Turing-erkennbar und co-Turing-erkennbar + +## 5. Das Halteproblem + +- Sprache A_TM = {⟨M, w⟩ | M ist TM und M akzeptiert w} – semi-entscheidbar, aber unentscheidbar +- HALT_TM = {⟨M, w⟩ | M ist TM und M hält auf w} – unentscheidbar +- Beweis per Diagonalisierung (Widerspruchsargument) + +## 6. Weitere unentscheidbare Probleme + +- **Postsches Korrespondenzproblem (PCP)** – semi-entscheidbar +- **Hilberts 10. Problem** – Diophantische Gleichungen +- **Erfüllbarkeitsproblem** und **Gültigkeitsproblem** der Prädikatenlogik (semi-entscheidbar) +- **Unerfüllbarkeitsproblem** der Prädikatenlogik +- E_TM (leere Sprache), EQ_TM (Sprachäquivalenz), REGULAR_TM (reguläre Sprache) +- MIN_TM (minimale TM) – nicht einmal semi-entscheidbar + +## 7. Die Klasse P + +- Definition: P = ⋃_k TIME(n^k) – in Polynomialzeit entscheidbare Sprachen +- Beispielmengen: ℕ, 2ℕ, Primzahlen ℙ, Summen/Produkte von Primzahlen + +## 8. Die Klasse NP + +- Verifier-basierte Definition: polynomieller Verifier, polynomiell verifizierbar +- NP = Klasse der Sprachen mit polynomiellen Verifizierern +- Äquivalente Definition: NP = ⋃_k NTIME(n^k) +- P: schnell _entscheidbar_ vs. NP: schnell _verifizierbar_ +- Beispielmengen: Summen/Produkte von Primzahlen, Primzahlen (n ≠ p·q), SAT, UNSAT + +## 9. P vs. NP + +- Offene Frage: P ⊂ NP oder P = NP? +- Millennium-Problem (Clay Mathematics Institute, 1 Mio. Dollar Preisgeld) + +## 10. NP-Vollständigkeit & Reduktionen + +- **Polynomialzeit-berechenbare Funktion** +- **Polynomialzeit-Reduktion** (A ≤_P B) +- Definition NP-vollständig: (1) B ∈ NP, (2) jedes A ∈ NP ist polynomiell auf B reduzierbar +- **NP-hard**: nur Bedingung (2) +- Venn-Diagramm: P ⊆ NP ⊆ NP-hard, NP-complete = NP ∩ NP-hard +- **Cook-Levin Theorem**: SAT ist NP-vollständig (SAT ∈ P ⟺ P = NP) \ No newline at end of file diff --git a/Komplexitätstheorie/zusammenfassungen/ko1 - zusammenfassung.md b/Komplexitätstheorie/zusammenfassungen/ko1 - zusammenfassung.md new file mode 100644 index 0000000..8c6451c --- /dev/null +++ b/Komplexitätstheorie/zusammenfassungen/ko1 - zusammenfassung.md @@ -0,0 +1,403 @@ +# Komplexitätstheorie – Vorlesung 1: Zusammenfassung +**Prof. Dr. Björn Grohmann | HWR Berlin | 18.02.2026** + +--- +## 1. Turing-Maschinen + +### Historischer Hintergrund + +Alan Turing (geboren 23. Juni 1912 in London, gestorben 8. Juni 1954) studierte Mathematik in Cambridge (B.A. 1934) und promovierte an der Princeton University (Ph.D. 1938) mit der Dissertation „Systems of Logic Based on Ordinals". Er entwickelte das Konzept der Turing-Maschine als abstraktes Berechnungsmodell, das bis heute die Grundlage der theoretischen Informatik bildet. + +### Formale Definition + +Eine **Turing-Maschine** ist ein 7-Tupel $(Q, \Sigma, \Gamma, \delta, q_0, q_{\text{accept}}, q_{\text{reject}})$, wobei $Q$, $\Sigma$ und $\Gamma$ endliche Mengen sind: + +1. $Q$ ist die **Zustandsmenge** (set of states). +2. $\Sigma$ ist das **Eingabealphabet**, das das Blanksymbol $\sqcup$ nicht enthält. +3. $\Gamma$ ist das **Bandalphabet**, wobei $\sqcup \in \Gamma$ und $\Sigma \subseteq \Gamma$. +4. $\delta: Q \times \Gamma \rightarrow Q \times \Gamma \times \{L, R\}$ ist die **Übergangsfunktion** (transition function). +5. $q_0 \in Q$ ist der **Startzustand** (start state). +6. $q_{\text{accept}} \in Q$ ist der **Akzeptierzustand** (accept state). +7. $q_{\text{reject}} \in Q$ ist der **Ablehnungszustand** (reject state), wobei $q_{\text{reject}} \neq q_{\text{accept}}$. + +Die Turing-Maschine besteht aus einer endlichen Steuerung (control) und einem **unendlich langen Band**, auf dem Symbole gelesen und geschrieben werden. + +### Konfiguration + +Eine **Konfiguration** beschreibt den vollständigen Zustand einer TM zu einem Zeitpunkt: Sie umfasst den aktuellen Zustand, den Bandinhalt und die Position des Lese-/Schreibkopfes. Beispiel: Die Konfiguration $1011q_701111$ bedeutet, dass sich die Maschine im Zustand $q_7$ befindet und der Kopf auf dem Zeichen unmittelbar rechts von $q_7$ steht. + +### Beispiel: Sprache $B = \{w\#w \mid w \in \{0,1\}^*\}$ + +Diese Sprache besteht aus allen Wörtern, die aus zwei identischen Hälften bestehen, getrennt durch ein #-Zeichen. Die TM arbeitet wie folgt: + +- Das erste Zeichen der linken Hälfte wird gelesen, durch $x$ ersetzt und gemerkt (Zustand $q_1$). +- Der Kopf wandert nach rechts über das #-Zeichen zum entsprechenden Zeichen der rechten Hälfte. +- Stimmt das Zeichen überein, wird es ebenfalls durch $x$ ersetzt; der Kopf wandert zurück zum nächsten unmarkierten Zeichen links. +- Dieser Prozess wiederholt sich, bis alle Zeichen abgeglichen sind. +- Wenn am Ende nur $x$-Symbole und ein # auf dem Band stehen und ein Blank erreicht wird → **accept**. +- Bei jedem Mismatch → **reject**. + +Das Zustandsdiagramm umfasst die Zustände $q_1$ bis $q_8$ sowie $q_{\text{accept}}$ (und implizite reject-Pfade, die im Diagramm der Vorlesung weggelassen wurden). + +### Church-Turing-These + +> „Jede effektiv berechenbare Funktion kann durch eine Turing-Maschine berechnet werden." + +Dies ist keine mathematisch beweisbare Aussage, sondern eine **These** (Hypothese). Sie wird gestützt durch die Tatsache, dass alle bekannten Berechnungsmodelle (WHILE-Programme, GOTO-Programme, Lambda-Kalkül, Rule 110 Zellularautomaten etc.) äquivalent zur Turing-Maschine sind. + +--- + +## 2. Äquivalente Berechnungsmodelle + +### WHILE-Programme + +WHILE-Programme sind ein einfaches Berechnungsmodell mit folgender Syntax: + +- $P \rightarrow X := X + C$ (Inkrement) +- $\mid\quad X := X - C$ (Dekrement, wobei das Ergebnis nicht negativ wird) +- $\mid\quad P;\; P$ (Sequenz) +- $\mid\quad \text{WHILE } X \neq 0 \text{ DO } P \text{ END}$ (Schleife) + +WHILE-Programme sind **Turing-vollständig**, d.h. sie können genau die gleichen Funktionen berechnen wie eine Turing-Maschine. + +### GOTO-Programme + +GOTO-Programme bestehen aus nummerierten Anweisungen $M_1: A_1;\; M_2: A_2;\; \ldots;\; M_k: A_k$ mit den Operationen: + +- $x_i := x_j + n$ (Addition einer Konstante) +- $x_i := x_j - n$ (Subtraktion einer Konstante) +- $\text{GOTO } M_i$ (unbedingter Sprung) +- $\text{IF } x_i = n \text{ GOTO } M_j$ (bedingter Sprung) +- $\text{HALT}$ (Programmende) + +Auch GOTO-Programme sind äquivalent zu Turing-Maschinen. + +### Rule 110 (Zellularautomat) + +Rule 110 ist ein eindimensionaler Zellularautomat, dessen Übergangsregel durch die Binärdarstellung der Zahl 110 (01101110) definiert wird. Jede Zelle wird basierend auf ihrem eigenen Zustand und den Zuständen ihrer beiden Nachbarn aktualisiert. Es wurde bewiesen, dass Rule 110 **Turing-vollständig** ist – ein einfacher Zellularautomat kann also universelle Berechnungen durchführen. + +--- + +## 3. Varianten von Turing-Maschinen + +### Multitape Turing Machine (Mehrband-TM) + +Die Übergangsfunktion einer $k$-Band-TM hat die Form: + +$$\delta: Q \times \Gamma^k \rightarrow Q \times \Gamma^k \times \{L, R, S\}^k$$ + +Die Maschine verfügt über $k$ separate Bänder mit eigenen Köpfen (Input-Tape mit Read-Only-Head, Work-Tape und Output-Tape mit Read/Write-Heads). + +**Theorem:** Jede Multitape-TM hat eine äquivalente Single-Tape-TM. Die Simulation erfolgt, indem alle Bänder auf einem einzigen Band kodiert werden (getrennt durch #-Symbole), wobei die Kopfpositionen durch markierte Symbole (z.B. Punkte über den Zeichen) dargestellt werden. + +### Universelle Turing-Maschine (UTM) + +Es existiert eine TM $\mathcal{U}$, die für jede Eingabe $x, \alpha \in \{0,1\}^*$ das Ergebnis $\mathcal{U}(x, \alpha) = M_\alpha(x)$ berechnet, wobei $M_\alpha$ die durch die **Gödelnummer** $\alpha$ kodierte Turing-Maschine ist. + +Die UTM nutzt mehrere Arbeitsbänder: ein Input-Tape, Work-Tapes (Simulation des Arbeitsbandes von $M$, Beschreibung von $M$, aktueller Zustand von $M$) und ein Output-Tape. + +**Simulationsoverhead:** Wenn $M_\alpha$ in $T$ Schritten hält, so hält $\mathcal{U}(x, \alpha)$ in $O(CT \log T)$ Schritten, wobei $C$ eine Konstante ist, die nur von der Alphabetgröße, Bandanzahl und Zustandsanzahl von $M_\alpha$ abhängt. + +### Nichtdeterministische Turing-Maschine (NTM) + +Die Übergangsfunktion einer NTM hat die Form: + +$$\delta: Q \times \Gamma \rightarrow \mathcal{P}(Q \times \Gamma \times \{L, R\})$$ + +Statt eines einzigen Nachfolgezustands gibt es eine **Menge** möglicher Übergänge. Die NTM kann als Maschine mit drei Bändern simuliert werden: Input-Tape, Simulation-Tape und Address-Tape (das die nichtdeterministischen Entscheidungen kodiert). + +**Theorem:** Jede NTM hat eine äquivalente DTM. Jede $t(n)$-Zeit-NTM (mit $t(n) \geq n$) kann durch eine deterministische TM in Zeit $2^{O(t(n))}$ simuliert werden — also mit **exponentiellem Zeitverlust**. + +**Akzeptanzkriterium:** Eine NTM akzeptiert eine Eingabe, wenn **mindestens ein** Berechnungspfad akzeptiert. Sie lehnt ab, wenn **alle** Pfade ablehnen. + +--- + +## 4. Laufzeit und Zeitkomplexität + +### Running Time (deterministisch) + +Sei $M$ eine deterministische TM, die auf allen Eingaben hält. Die **Laufzeit** (running time / time complexity) von $M$ ist die Funktion $f: \mathbb{N} \rightarrow \mathbb{N}$, wobei $f(n)$ die **maximale Anzahl von Schritten** ist, die $M$ auf einer Eingabe der Länge $n$ benötigt. Man sagt: „$M$ läuft in Zeit $f(n)$" oder „$M$ ist eine $f(n)$-Zeit-Turing-Maschine." + +### Running Time (nichtdeterministisch) + +Sei $N$ eine nichtdeterministische TM, die ein Entscheider ist. Die **Laufzeit** von $N$ ist die Funktion $f: \mathbb{N} \rightarrow \mathbb{N}$, wobei $f(n)$ die **maximale Anzahl von Schritten** ist, die $N$ auf **irgendeinem Zweig** ihrer Berechnung bei einer Eingabe der Länge $n$ benötigt. + +### Time Constructibility + +Eine Funktion $t: \mathbb{N} \rightarrow \mathbb{N}$ mit $t(n) \geq O(n \log n)$ heißt **zeitkonstruierbar** (time constructible), wenn die Funktion, die den String $1^n$ auf die Binärdarstellung von $t(n)$ abbildet, in Zeit $O(t(n))$ berechenbar ist. + +Es gibt auch eine alternative Definition, bei der lediglich $t(n) \geq n$ gefordert wird. + +Typische zeitkonstruierbare Funktionen sind z.B. $n$, $n \log n$, $n^2$, $2^n$. + +### Overhead-Resultate (Simulationskosten) + +| Transformation | Zeitoverhead | +|---|---| +| **Alphabetreduktion** (beliebiges Alphabet → $\{0,1,\sqcup,\triangleright\}$) | $4 \log |\Gamma| \cdot T(n)$ | +| **Tape-Reduktion** ($k$ Bänder → 1 Band) | $5k \cdot T(n)^2$ | +| **Bidirektionale TM → Unidirektionale TM** | $4 \cdot T(n)$ | + +### Zeitkomplexitätsklasse TIME + +Sei $t: \mathbb{N} \rightarrow \mathbb{R}^+$ eine Funktion. Die **Zeitkomplexitätsklasse** $\text{TIME}(t(n))$ ist die Menge aller Sprachen, die von einer $O(t(n))$-Zeit-Turing-Maschine entschieden werden können. + +--- + +## 5. Entscheidbarkeit + +### Turing-erkennbar (rekursiv aufzählbar / semi-entscheidbar) + +Eine Sprache heißt **Turing-erkennbar** (Turing-recognizable), wenn es eine TM gibt, die sie erkennt. Das bedeutet: + +- Für $w \in L$: Die TM akzeptiert. +- Für $w \notin L$: Die TM lehnt ab **oder hält nicht** (läuft unendlich lange). + +### Turing-entscheidbar (rekursiv / entscheidbar) + +Eine Sprache heißt **Turing-entscheidbar** (Turing-decidable), wenn es eine TM gibt, die sie entscheidet. Das bedeutet: + +- Für $w \in L$: Die TM akzeptiert. +- Für $w \notin L$: Die TM lehnt ab. +- Die TM **hält immer** (auf jeder Eingabe). + +### Zusammenhang + +**Theorem:** Eine Sprache ist entscheidbar **genau dann, wenn** sie sowohl Turing-erkennbar als auch co-Turing-erkennbar ist. + +Beweisskizze: Man lässt die TM $M_1$ (für $L$) und $M_2$ (für $\overline{L}$) parallel auf der Eingabe $w$ laufen. Wenn $M_1$ akzeptiert → accept; wenn $M_2$ akzeptiert → reject. Da eine der beiden Maschinen für jede Eingabe irgendwann akzeptiert, hält das Verfahren immer. + +--- + +## 6. Das Halteproblem + +### $A_{\text{TM}}$ – Die Akzeptanzsprache + +$$A_{\text{TM}} = \{\langle M, w \rangle \mid M \text{ ist eine TM und } M \text{ akzeptiert } w\}$$ + +$A_{\text{TM}}$ ist **semi-entscheidbar** (Turing-erkennbar): Man simuliert $M$ auf $w$. Wenn $M$ akzeptiert → accept; wenn $M$ ablehnt → reject. Problem: Wenn $M$ nicht hält, hält auch der Simulator nicht. + +**Theorem:** $A_{\text{TM}}$ ist **unentscheidbar**. + +### $HALT_{\text{TM}}$ – Das Halteproblem + +$$HALT_{\text{TM}} = \{\langle M, w \rangle \mid M \text{ ist eine TM und } M \text{ hält auf Eingabe } w\}$$ + +**Theorem:** $HALT_{\text{TM}}$ ist **unentscheidbar**. + +### Beweis per Diagonalisierung + +Der Beweis der Unentscheidbarkeit von $A_{\text{TM}}$ verwendet ein **Diagonalisierungsargument** (Widerspruchsbeweis): + +1. Angenommen, es gibt einen Entscheider $H$ für $A_{\text{TM}}$. +2. Konstruiere daraus eine Maschine $D$, die bei Eingabe $\langle M \rangle$ die Maschine $H$ auf $\langle M, \langle M \rangle \rangle$ simuliert und das Ergebnis **invertiert**. +3. Was passiert bei $D(\langle D \rangle)$? + - Falls $D$ akzeptiert → $H$ sagt "$D$ akzeptiert $\langle D \rangle$" → $D$ sollte ablehnen. **Widerspruch!** + - Falls $D$ ablehnt → $H$ sagt "$D$ akzeptiert $\langle D \rangle$ nicht" → $D$ sollte akzeptieren. **Widerspruch!** +4. Also kann $H$ nicht existieren. + +Das Diagonalisierungsargument funktioniert über eine Matrix: Die Zeilen sind Turing-Maschinen $T_1, T_2, T_3, \ldots$, die Spalten sind Eingaben $i_1, i_2, i_3, \ldots$, und die Einträge (0 oder 1) zeigen, ob $T_i$ die Eingabe $i_j$ akzeptiert. Die Maschine $D$ invertiert die Diagonale — und erzeugt so den Widerspruch, da $D$ als Zeile in der Matrix selbst vorkommen müsste. + +--- + +## 7. Weitere unentscheidbare Probleme + +### Postsches Korrespondenzproblem (PCP) + +**Gegeben:** Eine endliche Folge von Wortpaaren $(x_1, y_1), \ldots, (x_k, y_k)$ mit $x_i, y_i \in \{0,1\}^+$ (dargestellt als Dominos mit oberer und unterer Hälfte). + +**Gefragt:** Gibt es eine endliche Folge von Indizes $i_1, \ldots, i_n \in \{1, \ldots, k\}$, sodass $x_{i_1} \ldots x_{i_n} = y_{i_1} \ldots y_{i_n}$? (Können Kopien der Dominos so aneinandergelegt werden, dass oben und unten das gleiche Wort steht?) + +Das PCP ist **unentscheidbar**, aber immerhin **semi-entscheidbar** (man kann systematisch alle Kombinationen durchprobieren). + +Benannt nach **Emil Leon Post** (1897–1957). + +### Hilberts 10. Problem + +David Hilbert formulierte 1900 die Frage: Gibt es ein Verfahren, mit dem man für eine beliebige diophantische Gleichung (Polynomgleichung mit ganzzahligen Koeffizienten) entscheiden kann, ob sie eine ganzzahlige Lösung hat? + +**Antwort (1970, Matijassewitsch):** Nein — dieses Problem ist **unentscheidbar**. + +### Probleme der Prädikatenlogik + +| Problem | Frage | Status | +|---|---|---| +| **Erfüllbarkeitsproblem** | Ist ein prädikatenlogischer Ausdruck $A$ über Signatur $S$ erfüllbar? | semi-entscheidbar, unentscheidbar | +| **Gültigkeitsproblem** | Ist $A$ allgemeingültig? | semi-entscheidbar, unentscheidbar | +| **Unerfüllbarkeitsproblem** | Ist $A$ unerfüllbar? | semi-entscheidbar, unentscheidbar | + +Das Erfüllbarkeitsproblem und das Gültigkeitsproblem sind jeweils **semi-entscheidbar**. Das Unerfüllbarkeitsproblem ist ebenfalls semi-entscheidbar (da es das Komplement des Gültigkeitsproblems ist). + +### Weitere unentscheidbare Sprachen über TMs + +| Sprache | Definition | Semi-entscheidbar? | +|---|---|---| +| $E_{\text{TM}}$ | $\{\langle M \rangle \mid M \text{ ist TM und } L(M) = \emptyset\}$ | Nein (co-Turing-erkennbar) | +| $EQ_{\text{TM}}$ | $\{\langle M_1, M_2 \rangle \mid L(M_1) = L(M_2)\}$ | Nein | +| $REGULAR_{\text{TM}}$ | $\{\langle M \rangle \mid L(M) \text{ ist regulär}\}$ | Nein | +| $MIN_{\text{TM}}$ | $\{\langle M \rangle \mid M \text{ ist eine minimale TM}\}$ | **Nicht einmal semi-entscheidbar** | + +$MIN_{\text{TM}}$ enthält die Beschreibungen aller TMs, für die es keine kürzere äquivalente TM gibt. + +--- + +## 8. Die Klasse P + +### Definition + +$$\text{P} = \bigcup_k \text{TIME}(n^k)$$ + +**P** ist die Klasse aller Sprachen, die in **polynomieller Zeit** auf einer **deterministischen** Single-Tape-Turing-Maschine entscheidbar sind. + +### Beispiele: Welche Mengen liegen in P? + +| Menge | In P? | Begründung | +|---|---|---| +| $\mathbb{N} = \{1, 2, 3, \ldots\}$ | Ja | Trivial entscheidbar (jede natürliche Zahl akzeptieren) | +| $2\mathbb{N} = \{2, 4, 6, \ldots\}$ | Ja | Letztes Bit prüfen (gerade Zahl) | +| $\mathbb{P}$ (Primzahlen) | Ja | AKS-Algorithmus (2002) läuft in Polynomialzeit | +| $\{p + q \mid p, q \in \mathbb{P}\}$ (Summen von Primzahlen) | Ja | Alle Zerlegungen $p + q = n$ durchprobieren, jeweils Primzahltest | +| $\{p \cdot q \mid p, q \in \mathbb{P}\}$ (Produkte von Primzahlen) | Ja | Faktorisierung in Polynomialzeit prüfbar (Probedivision genügt, da nur Zerlegung in zwei Primfaktoren gefragt) | + +--- + +## 9. Die Klasse NP + +### Verifier-basierte Definition + +Ein **Verifier** für eine Sprache $A$ ist ein Algorithmus $V$, sodass: + +$$A = \{w \mid V \text{ akzeptiert } \langle w, c \rangle \text{ für ein Zertifikat } c\}$$ + +Ein **polynomieller Verifier** läuft in polynomieller Zeit **bezogen auf die Länge von $w$** (nicht von $c$). + +Eine Sprache $A$ ist **polynomiell verifizierbar**, wenn sie einen polynomiellen Verifier hat. + +### Definition von NP + +$$\text{NP} = \text{die Klasse aller Sprachen mit polynomiellen Verifizierern}$$ + +**Äquivalente Definition über NTMs:** + +**Theorem:** Eine Sprache ist in NP genau dann, wenn sie von einer **nichtdeterministischen polynomialzeit-TM** entschieden wird. + +$$\text{NP} = \bigcup_k \text{NTIME}(n^k)$$ + +### Kernunterschied P vs. NP + +- **P** = Klasse der Sprachen, deren Mitgliedschaft schnell **entschieden** werden kann. +- **NP** = Klasse der Sprachen, deren Mitgliedschaft schnell **verifiziert** werden kann (gegeben ein passendes Zertifikat). + +### Beispiele: Welche Mengen liegen in NP? + +| Menge | In NP? | Begründung | +|---|---|---| +| $\{p + q \mid p, q \in \mathbb{P}\}$ | Ja | Zertifikat: die beiden Primzahlen $p, q$; Verifikation: Summe prüfen + Primzahltests | +| $\{p \cdot q \mid p, q \in \mathbb{P}\}$ | Ja | Zertifikat: die beiden Primfaktoren; Verifikation: Produkt prüfen + Primzahltests | +| $\{n \in \mathbb{N} \mid n \neq p \cdot q, \; p,q \in \mathbb{P}\}$ (Primzahlen) | Ja | Zertifikat: $n$ selbst (bzw. AKS-Test); da $\mathbb{P} \in \text{P} \subseteq \text{NP}$ | +| $\text{SAT}$ (erfüllbare Boolesche Formeln) | Ja | Zertifikat: eine erfüllende Belegung; Verifikation: Formel auswerten | +| $\text{UNSAT}$ (unerfüllbare Boolesche Formeln) | Unklar | Kein offensichtliches kurzes Zertifikat; vermutlich nicht in NP (liegt in co-NP) | + +--- + +## 10. P vs. NP + +### Die offene Frage + +Es ist unbekannt, ob $\text{P} = \text{NP}$ oder $\text{P} \subsetneq \text{NP}$ gilt. + +- Falls $\text{P} = \text{NP}$: Jedes Problem, dessen Lösung effizient überprüfbar ist, wäre auch effizient lösbar. +- Falls $\text{P} \neq \text{NP}$: Es gibt Probleme, die effizient überprüfbar, aber nicht effizient lösbar sind. + +Die meisten Informatiker vermuten $\text{P} \neq \text{NP}$. + +### Millennium-Problem + +Das P-vs-NP-Problem ist eines der sieben **Millennium-Probleme** des Clay Mathematics Institute, ausgelobt im Jahr 2000, mit einem Preisgeld von **1 Million US-Dollar** für eine Lösung. Von den sieben Problemen wurde bisher nur die **Poincaré-Vermutung** gelöst (Perelman, 2003). + +--- + +## 11. NP-Vollständigkeit und Reduktionen + +### Polynomialzeit-berechenbare Funktion + +Eine Funktion $f: \Sigma^* \rightarrow \Sigma^*$ heißt **polynomialzeit-berechenbar** (polynomial time computable function), wenn eine polynomialzeit-TM $M$ existiert, die bei Eingabe $w$ mit $f(w)$ auf dem Band hält. + +### Polynomialzeit-Reduktion + +Eine Sprache $A$ ist **polynomialzeit-reduzierbar** auf Sprache $B$ (geschrieben $A \leq_P B$), wenn eine polynomialzeit-berechenbare Funktion $f: \Sigma^* \rightarrow \Sigma^*$ existiert, sodass für alle $w$ gilt: + +$$w \in A \iff f(w) \in B$$ + +Die Funktion $f$ heißt **Polynomialzeit-Reduktion** von $A$ auf $B$. + +Intuition: Wenn $A \leq_P B$, dann ist $B$ **mindestens so schwer** wie $A$. Wenn ich $B$ lösen kann, kann ich auch $A$ lösen (indem ich erst $f$ anwende und dann den Algorithmus für $B$ benutze). + +### NP-Vollständigkeit (NP-completeness) + +Eine Sprache $B$ ist **NP-vollständig**, wenn zwei Bedingungen erfüllt sind: + +1. $B \in \text{NP}$ (das Problem liegt in NP), **und** +2. Jede Sprache $A \in \text{NP}$ ist polynomialzeit-reduzierbar auf $B$ (d.h. $A \leq_P B$ für alle $A \in \text{NP}$). + +### NP-hard (NP-schwer) + +Wenn $B$ nur die **zweite Bedingung** erfüllt (jedes Problem aus NP ist auf $B$ reduzierbar), aber $B$ nicht notwendigerweise selbst in NP liegt, heißt $B$ **NP-hard**. + +### Beziehung im Venn-Diagramm + +- $\text{P} \subseteq \text{NP} \subseteq \text{NP-hard}$ (als Inklusionskette) +- $\text{NP-complete} = \text{NP} \cap \text{NP-hard}$ (die Schnittmenge) + +Wenn man ein NP-hardes Problem effizient lösen könnte, könnte man damit **jedes** Problem in NP effizient lösen. + +### Cook-Levin-Theorem + +**Theorem (Cook 1971, Levin 1973):** $\text{SAT}$ ist **NP-vollständig**. + +$$\text{SAT} = \{\langle \phi \rangle \mid \phi \text{ ist eine erfüllbare Boolesche Formel}\}$$ + +**Konsequenz:** $\text{SAT} \in \text{P} \iff \text{P} = \text{NP}$. + +Das Cook-Levin-Theorem war das erste Resultat, das die Existenz NP-vollständiger Probleme nachwies. Es zeigt: SAT ist das „universelle" Problem in NP — wenn man SAT in Polynomialzeit lösen könnte, wären alle NP-Probleme in Polynomialzeit lösbar. + +--- + +## 12. Die Landschaft der Komplexitätsklassen (Überblick) + +Die Vorlesung zeigte das „Landscape of Computational Complexity" (University at Buffalo, 2008), das die Hierarchie der Komplexitätsklassen visualisiert: + +- **REG** ⊂ **L** ⊂ **NL** ⊂ **P** ⊂ **NP** ⊂ **PSPACE** ⊂ **EXP** ⊂ **NEXP** ⊂ **EXPSPACE** +- Auf der anderen Seite die **Arithmetische Hierarchie**: REC ⊂ RE, co-RE, und darüber TOT und höhere Stufen +- **Complexity Zoo**: Eine Sammlung von über 545 Komplexitätsklassen (gepflegt von Scott Aaronson u.a.) + +Wichtige offene Fragen umfassen unter anderem: P ≠ NP, L ≠ NL, NP ≠ co-NP, P ≠ PSPACE, und viele weitere Separierungen. + +--- + +## Glossar der wichtigsten Begriffe + +| Begriff | Definition | +|---|---| +| **Turing-Maschine (TM)** | Abstraktes Berechnungsmodell mit unendlichem Band, endlicher Steuerung und Lese-/Schreibkopf | +| **Konfiguration** | Momentaufnahme einer TM: Zustand + Bandinhalt + Kopfposition | +| **Church-Turing-These** | Jede effektiv berechenbare Funktion ist Turing-berechenbar | +| **Multitape TM** | TM mit mehreren Bändern; äquivalent zur Single-Tape TM | +| **Universelle TM** | TM, die jede andere TM simulieren kann (über deren Gödelnummer) | +| **Gödelnummer** | Binäre Kodierung einer Turing-Maschine | +| **NTM** | Nichtdeterministische TM; Übergangsfunktion liefert Menge von Möglichkeiten | +| **Zeitkomplexität** | Maximale Schrittzahl einer TM auf Eingaben der Länge $n$ | +| **Time constructible** | Funktion $t(n)$, deren Wert in $O(t(n))$ Schritten berechnet werden kann | +| **Turing-erkennbar** | TM akzeptiert alle $w \in L$, kann aber auf $w \notin L$ endlos laufen | +| **Turing-entscheidbar** | TM akzeptiert alle $w \in L$ und lehnt alle $w \notin L$ ab (hält immer) | +| **Halteproblem** | Frage, ob eine TM auf einer Eingabe hält; unentscheidbar | +| **Diagonalisierung** | Beweistechnik: Konstruktion eines Widerspruchs durch Selbstreferenz | +| **PCP** | Postsches Korrespondenzproblem; unentscheidbar, aber semi-entscheidbar | +| **P** | Klasse der in Polynomialzeit deterministisch entscheidbaren Sprachen | +| **NP** | Klasse der in Polynomialzeit verifizierbaren Sprachen | +| **Verifier** | Algorithmus, der bei Eingabe $(w, c)$ die Mitgliedschaft von $w$ in $L$ prüft | +| **Polynomialzeit-Reduktion** | Transformation $A \leq_P B$: $w \in A \iff f(w) \in B$ mit $f$ in Polynomialzeit | +| **NP-vollständig** | In NP + jedes NP-Problem ist darauf reduzierbar | +| **NP-hard** | Jedes NP-Problem ist darauf reduzierbar (muss nicht selbst in NP sein) | +| **SAT** | Erfüllbarkeitsproblem für Boolesche Formeln; erstes nachgewiesenes NP-vollständiges Problem | +| **Cook-Levin-Theorem** | SAT ist NP-vollständig; SAT ∈ P ⟺ P = NP | diff --git a/Komplexitätstheorie/zusammenfassungen/ko2 - zusammenfassung.md b/Komplexitätstheorie/zusammenfassungen/ko2 - zusammenfassung.md new file mode 100644 index 0000000..baf6591 --- /dev/null +++ b/Komplexitätstheorie/zusammenfassungen/ko2 - zusammenfassung.md @@ -0,0 +1,227 @@ +# KO2 – NP-Vollständigkeit, Space Complexity & PSPACE +**Vorlesung:** Prof. Dr. Björn Grohmann, HWR Berlin +**Datum:** 25.02.2026 +**Folien:** 72–106 + +--- +## 1. Hamiltonian Circuit Problem + +Das **Hamiltonian Circuit Problem** fragt für einen ungerichteten Graphen, ob ein Rundweg (Hamiltonkreis) existiert, der **jeden Knoten genau einmal** besucht und zum Ausgangspunkt zurückkehrt. + +Das Problem ist **NP-vollständig**, und zwar bereits dann, wenn der Graph **planar** (d.h. in der Ebene darstellbar ohne Kantenkreuzungen) und **3-regulär** (jeder Knoten hat genau 3 Nachbarn) ist. + +### Reduktion von SAT auf Hamiltonian Circuit + +Die NP-Vollständigkeit wird durch eine Konstruktion gezeigt, die eine aussagenlogische Formel in einen Graphen übersetzt. Der konstruierte Graph besitzt genau dann einen Hamiltonkreis, wenn die zugehörige Formel erfüllbar ist. + +**Beispielformel:** +$$F = (x \lor y \lor z) \land (\bar{x} \lor \bar{y} \lor w) \land (y \lor \bar{z} \lor \bar{w})$$ + +**Konstruktionselemente:** + +- **Variablenpfade:** Der linke Weg steht für „wahr", der rechte Weg für „falsch". Ein XOR-Gadget stellt sicher, dass genau einer der beiden Wege zum Pfad gehört. +- **Klausel-Gadgets (OR):** Mindestens eines der drei Literale muss „wahr" sein. +- **Kreuzungs-Gadgets:** Sorgen dafür, dass sich Kanten des Graphen nicht kreuzen (Planarität). + +--- +## 2. Graph-Gadgets im Detail + +### Tutte Fragment + +Ein spezielles planares Graphfragment mit drei Anschlüssen. Es hat die Eigenschaft, dass ein Hamiltonpfad durch das Fragment stets durch **genau einen** der drei Anschlüsse ein- und austritt. Es wird als Symbol mit einem Pfeil in einem Kreis dargestellt. Es gibt genau **6 mögliche Wege** durch das Fragment. + +### Exclusive-OR (XOR) Gadget + +Wird aus zwei Tutte-Fragmenten konstruiert. Verbindet zwei Pfade (v→v' und u→u') so, dass ein Hamiltonpfad **genau einen** der beiden Wege nutzen kann, nicht beide. Die zwei möglichen Wege entsprechen den zwei Wahrheitswerten einer Variable. + +### Kreuzungs-Gadget (Crossing) + +Ermöglicht es, zwei sich kreuzende Kanten planar darzustellen. Wird aus mehreren XOR-Gadgets zusammengesetzt. Hat vier Anschlüsse und erlaubt vier mögliche Wegkombinationen, die den beiden unabhängigen Durchquerungsrichtungen entsprechen. + +### OR-Gadget + +Verbindet zwei Pfade (v→v' und u→u') so, dass **mindestens einer** der beiden Wege durchlaufen werden muss. Es gibt insgesamt 5 mögliche Wege (alle Kombinationen außer „keiner"). + +### Triple-OR-Gadget + +Erweitert das OR-Gadget auf drei Eingänge (u→u', v→v', w→w'). Mindestens einer der drei Wege muss durchlaufen werden. Wird für 3-SAT-Klauseln mit drei Literalen benötigt. + +--- +## 3. MINESWEEPER ist NP-vollständig + +Die NP-Vollständigkeit von Minesweeper wird gezeigt, indem man logische Schaltkreise innerhalb eines Minesweeper-Spielfelds simuliert. + +### Grundidee + +In einem Minesweeper-Feld können Zellen entweder Minen enthalten oder nicht. Die Zahlen in aufgedeckten Zellen geben an, wie viele Minen sich in den benachbarten Zellen befinden. Man nutzt Variablen x und x' (Komplement), wobei x=Mine und x'=keine Mine (oder umgekehrt) einer Wahrheitsbelegung entspricht. + +### Bausteine der Reduktion + +- **Wire (Draht):** Ein horizontales Muster aus 5 Zeilen, in dem sich x und x' abwechseln. Die Randbedingungen (Zahlen 0 und 1) erzwingen, dass der Wahrheitswert konsistent entlang des Drahtes weitergeleitet wird. +- **NOT-Gate:** Invertiert den Wahrheitswert eines Drahtes. Nutzt ein Muster mit Zahlen 2, 3 und Pflichtminen (*), sodass aus x am Eingang x' am Ausgang wird. +- **Phase-Changer:** Besteht aus zwei NOT-Gates hintereinander. Verschiebt die Phase des Signals, ohne den Wahrheitswert zu ändern. +- **Wire Crossing:** Ermöglicht es, zwei Drähte zu kreuzen, ohne dass ihre Signale interferieren. Wird mit drei XOR-Gates realisiert. +- **XOR-Gate:** Kann aus AND- und NOT-Gates zusammengebaut werden (Standardkonstruktion: $A \oplus B = (A \land \lnot B) \lor (\lnot A \land B)$, äquivalent mittels NAND-Darstellung). +- **AND-Gate:** Ein komplexes Muster (Figure 13), das zwei Eingangsdrähte U und V mit einem Ausgangsdraht T verbindet. Enthält feste Minen (*) und variable Zellen, deren Belegung durch die Zahlenbedingungen erzwungen wird. + +### Gesamtargumentation + +Da man mit Wires, NOT, AND (und daraus abgeleitet OR, XOR) beliebige Boolesche Schaltkreise bauen kann, lässt sich jede SAT-Instanz als Minesweeper-Konfiguration kodieren. Die Frage „Gibt es eine konsistente Minenbelegung?" entspricht der Frage „Ist die Formel erfüllbar?". Da SAT NP-vollständig ist, ist auch Minesweeper NP-vollständig. + +--- + +## 4. „Gaming is Hard" – NP-Härte von Videospielen + +### Metatheorem 1: Location Traversal + Single-Use Paths + +Jedes Spiel, das **Location Traversal** (bestimmte Punkte müssen erreicht werden) und **Single-Use Paths** (Wege können nur einmal benutzt werden) aufweist, ist **NP-hard**. + +**Beweisskizze:** Man baut einen Level, der einen planaren, 3-regulären Graphen darstellt. Die Knoten sind die Punkte, die besucht werden müssen. Jede Kante ist ein Single-Use Path. Ein zusätzlicher Endpunkt wird mit dem Startknoten verbunden. Der Level ist genau dann lösbar, wenn ein Hamiltonkreis existiert. + +### Metatheorem 2: Tokens, Toll Roads, Location Traversal + +Ein Spiel ist **NP-hard**, wenn eine der folgenden Bedingungen gilt: + +- **(a)** Das Spiel hat **collectible tokens**, toll roads und location traversal. +- **(b)** Das Spiel hat **cumulative tokens**, toll roads und location traversal. (Spieler startet mit n+1 tokens.) +- **(c)** Das Spiel hat collectible cumulative tokens, **toll roads**, und der Avatar muss einen Ausgang erreichen. (2 tokens pro Punkt, jede Kante ist eine toll road, die Kante zwischen Start und Ende ist eine Sequenz von n toll roads.) + +**Beispiel:** Pac-Man – Power Pills sind tokens, Geisterkorridore sind toll roads. + +### Metatheorem 3: Keys, Doors, One-Way Paths + +Ein Spiel ist **NP-hard**, wenn es **doors** und **one-way paths** enthält und eine der folgenden Bedingungen gilt: + +- **(a)** Collectible keys und location traversal. +- **(b)** Cumulative keys und location traversal. +- **(c)** Collectible cumulative keys und der Avatar muss einen Ausgang erreichen. + +Funktioniert genau wie Metatheorem 2, wobei keys = tokens und doors = toll roads. + +### Metatheorem 4: Doors + Pressure Plates + +Wenn ein Spiel **doors** und **pressure plates** (Druckplatten, die Türen öffnen oder schließen) enthält und der Avatar einen Ausgang erreichen muss, dann ist das Spiel **NP-hard** – selbst wenn keine zwei Druckplatten dieselbe Tür steuern. + +**Konstruktion:** Wie bei MT 1, aber vor dem Ausgang befinden sich n Türen, die jeweils durch eine Druckplatte bei einem der Punkte geöffnet werden müssen. Single-Use Paths werden durch Druckplatten realisiert, die beim zweiten Durchgang den Weg versperren. + +### Metatheorem 5: Doors + k-Buttons + +Buttons sind wie Druckplatten, aber der Spieler kann **entscheiden**, ob er den Button drückt. Ein k-Button beeinflusst k Türen gleichzeitig. + +Wenn ein Spiel **doors** und **k-buttons** enthält und der Avatar einen Ausgang erreichen muss, dann ist das Spiel **NP-hard** für $k \geq 2$. + +--- +## 5. Übersicht NP-vollständiger Probleme + +Alle folgenden Probleme sind NP-vollständig und liegen damit in der Schnittmenge von NP und NP-hard: + +- **SAT** (Erfüllbarkeitsproblem aussagenlogischer Formeln) +- **Hamiltonkreis** +- **Traveling Salesman Problem (TSP)** +- **Knapsack** (Rucksackproblem) +- **MINESWEEPER** +- und viele weitere (Karp's Liste mit 21 Problemen) + +### Karp's Liste (1972) + +Richard Karp bewies 1972, dass 21 Probleme NP-vollständig sind, ausgehend von SAT. Die Reduktionskette verläuft u.a.: + +SATISFIABILITY → CLIQUE → NODE COVER → {FEEDBACK NODE SET, FEEDBACK ARC SET, DIRECTED HAMILTON CIRCUIT → UNDIRECTED HAMILTON CIRCUIT} + +SATISFIABILITY → 0-1 INTEGER PROGRAMMING → SET PACKING → SET COVERING + +SATISFIABILITY WITH AT MOST 3 LITERALS PER CLAUSE → CHROMATIC NUMBER → {EXACT COVER → {3-DIMENSIONAL MATCHING, KNAPSACK → {SEQUENCING, PARTITION → MAX CUT}}, HITTING SET, STEINER TREE, CLIQUE COVER} + +--- +## 6. Space Complexity + +### Definition + +Die **Speicherkomplexität (Space Complexity)** einer deterministischen Turingmaschine M ist die Funktion $f: \mathbb{N} \to \mathbb{N}$, wobei $f(n)$ die **maximale Anzahl an Bandzellen** ist, die M auf irgendeiner Eingabe der Länge n besucht. + +Für eine **nichtdeterministische** Turingmaschine ist $f(n)$ die maximale Anzahl an Bandzellen, die M auf **irgendeinem Berechnungspfad** für eine Eingabe der Länge n besucht. + +**Anmerkung:** In der Literatur wird manchmal angenommen, dass die TM ein separates Eingabe- und Arbeitsband besitzt und nur die Zellen auf dem Arbeitsband gezählt werden. + +### Speicherkomplexitätsklassen + +$$\text{SPACE}(f(n)) = {L \mid L \text{ wird von einer det. TM in } O(f(n)) \text{ Speicher entschieden}}$$ + +$$\text{NSPACE}(f(n)) = {L \mid L \text{ wird von einer nichtdet. TM in } O(f(n)) \text{ Speicher entschieden}}$$ + +--- +## 7. Savitch's Theorem + +**Satz (Savitch):** Für jede Funktion $f: \mathbb{N} \to \mathbb{R}^+$ mit $f(n) \geq n$ gilt: + +$$\text{NSPACE}(f(n)) \subseteq \text{SPACE}(f^2(n))$$ + +Der Satz gilt auch für $f(n) \geq \log(n)$. + +### Beweisskizze + +Gegeben eine nichtdeterministische TM N, die Sprache A mit Speicher $f(n)$ entscheidet, konstruieren wir eine deterministische TM M, die A in $O(f(n)^2)$ Speicher entscheidet: + +**Kernidee – CANYIELD-Prozedur:** +CANYIELD$(c_1, c_2, t)$ entscheidet, ob Konfiguration $c_2$ von Konfiguration $c_1$ in $t$ Schritten erreicht werden kann. + +- **Basisfall** ($t=1$): Prüfe direkt, ob $c_1 = c_2$ oder ob $c_1$ in einem Schritt zu $c_2$ führt. +- **Rekursion** ($t > 1$): Für jede mögliche Zwischenkonfiguration $c_m$: Prüfe CANYIELD$(c_1, c_m, t/2)$ und CANYIELD$(c_m, c_2, t/2)$. + +**Speicheranalyse:** + +- Jede Rekursionsebene benötigt $O(f(n))$ Speicher (für die Zwischenkonfiguration). +- Die Rekursionstiefe beträgt $O(\log t)$, wobei $t \leq 2^{d \cdot f(n)}$ für eine Konstante d. +- Gesamtspeicher: $O(f(n)) \cdot O(\log t) = O(f(n)) \cdot O(f(n)) = O(f(n)^2)$. + +Da $f(n)$ zu Beginn nicht bekannt ist, testet M nacheinander $f(n) = 1, 2, 3, \ldots$ + +--- +## 8. PSPACE + +### Definition + +**PSPACE** ist die Klasse aller Sprachen, die von einer deterministischen Turingmaschine in **polynomiellem Speicher** entschieden werden können: + +$$\text{PSPACE} = \bigcup_k \text{SPACE}(n^k)$$ + +### Beziehung zwischen Zeit- und Speicherkomplexität + +$$P \subseteq NP \subseteq PSPACE = NPSPACE \subseteq EXPTIME = \bigcup_k \text{TIME}(2^{n^k})$$ + +Die Gleichheit $\text{PSPACE} = \text{NPSPACE}$ folgt aus Savitch's Theorem (quadratischer Blow-up bei der Speicherkomplexität ist polynomiell). + +--- +## 9. PSPACE-Vollständigkeit + +### Definition + +Eine Sprache B ist **PSPACE-complete**, wenn: + +1. $B \in \text{PSPACE}$ +2. Jedes $A \in \text{PSPACE}$ ist in polynomieller Zeit auf B reduzierbar. + +Erfüllt B nur Bedingung 2, heißt B **PSPACE-hard**. + +### TQBF ist PSPACE-vollständig + +$$TQBF = {\langle \phi \rangle \mid \phi \text{ ist eine wahre, voll quantifizierte Boolesche Formel}}$$ + +**Theorem:** TQBF ist PSPACE-complete. + +Eine voll quantifizierte Boolesche Formel hat die Form $\forall x_1 \exists x_2 \forall x_3 \ldots \phi(x_1, x_2, x_3, \ldots)$, wobei alle Variablen gebunden sind. TQBF fragt, ob eine solche Formel wahr ist. + +TQBF verallgemeinert SAT: Während SAT nur Existenzquantoren hat ($\exists x_1 \exists x_2 \ldots$: „Gibt es eine erfüllende Belegung?"), erlaubt TQBF auch Allquantoren. Diese Erweiterung macht das Problem härter – von NP-vollständig zu PSPACE-vollständig. + +--- +## Zusammenfassung der Komplexitätsklassen + +|Klasse|Beschreibung|Beispiel| +|---|---|---| +|**P**|Deterministisch in polynomieller Zeit lösbar|Sortieren, kürzeste Wege| +|**NP**|Nichtdeterministisch in polynomieller Zeit lösbar (Lösung in Polynomialzeit verifizierbar)|SAT, Hamiltonkreis, TSP, Knapsack, Minesweeper| +|**PSPACE**|Deterministisch in polynomiellem Speicher lösbar|TQBF| +|**EXPTIME**|Deterministisch in exponentieller Zeit lösbar|Generalisiertes Schach| +|**NP-hard**|Mindestens so schwer wie jedes Problem in NP|Alle NP-vollständigen Probleme + weitere| +|**NP-vollständig**|In NP und NP-hard|SAT, Hamiltonkreis, TSP, Knapsack, Minesweeper| +|**PSPACE-vollständig**|In PSPACE und PSPACE-hard|TQBF| \ No newline at end of file diff --git a/Komplexitätstheorie/zusammenfassungen/ko3 - zusammenfassung.md b/Komplexitätstheorie/zusammenfassungen/ko3 - zusammenfassung.md new file mode 100644 index 0000000..79a161a --- /dev/null +++ b/Komplexitätstheorie/zusammenfassungen/ko3 - zusammenfassung.md @@ -0,0 +1,381 @@ +# Komplexitätstheorie – Zusammenfassung + +**Prof. Dr. Björn Grohmann – Hochschule für Wirtschaft und Recht Berlin** + +----- + +## 1. True Quantified Boolean Formulas (TQBF) + +### 1.1 Definition + +Eine **True Quantified Boolean Formula (TQBF)** ist eine vollständig quantifizierte Boolesche Formel, d.h. eine Boolesche Formel, in der **jede Variable** durch einen Existenz- ($\exists$) oder Allquantor ($\forall$) gebunden ist. Die Formel hat keinen freien Variablen und evaluiert daher zu einem festen Wahrheitswert (wahr oder falsch). + +**Beispiel:** + +$$\forall x , \exists y , (x \lor y) \land (\neg x \lor \neg y)$$ + +Das Entscheidungsproblem TQBF fragt: *Ist eine gegebene vollständig quantifizierte Boolesche Formel wahr?* + +### 1.2 TQBF ist PSPACE-vollständig + +Die Vorlesung zeigt zwei zentrale Aussagen: + +**1) TQBF ist in PSPACE:** +TQBF kann mit polynomiellem Speicher entschieden werden. Die Idee ist, die Formel rekursiv auszuwerten: Für jeden Quantor wird die entsprechende Variable nacheinander auf *wahr* und *falsch* gesetzt und rekursiv weitergerechnet. Da die Rekursionstiefe linear in der Anzahl der Variablen ist und jeder Rekursionslevel nur konstanten Zusatzspeicher benötigt, liegt der Gesamtverbrauch in $O(n)$ Speicher. + +**2) Jede Sprache in PSPACE ist auf TQBF reduzierbar (PSPACE-Härte):** +Für ein Wort $w$ und eine Sprache $A \in \text{PSPACE}$ wird eine QBF konstruiert, die genau dann wahr ist, wenn $w \in A$. + +### 1.3 Die Reduktion im Detail + +#### Grundidee + +Man konstruiert eine Formel $\phi_{c_1, c_2, t}$, die genau dann wahr ist, wenn die Turing-Maschine von der Konfiguration $c_1$ zur Konfiguration $c_2$ in höchstens $t$ Schritten gelangen kann. Die gesuchte Formel ist dann $\phi_{c_{\text{start}}, c_{\text{accept}}, h}$ mit $h = 2^{O(n^k)}$. + +#### Naiver (erster) Ansatz + +$$\phi_{c_1, c_2, t} = \exists m_1 \left[\phi_{c_1, m_1, t/2} \land \phi_{m_1, c_2, t/2}\right]$$ + +Hierbei wird eine Zwischenkonfiguration $m_1$ geraten (existenzquantifiziert), über die der Pfad von $c_1$ nach $c_2$ in zwei Hälften aufgeteilt wird. Das Problem: Durch die doppelte Rekursion **verdoppelt** sich die Formelgröße bei jedem Schritt. Da die Rekursionstiefe $O(n^k)$ beträgt, wird die Formel **exponentiell groß** – zu groß für einen polynomiellen Speicherverbrauch. + +#### Verbesserter Ansatz (Savitch-ähnlicher Trick) + +$$\phi_{c_1, c_2, t} = \exists m_1 ; \forall (c_3, c_4) \in {(c_1, m_1), (m_1, c_2)} ; \left[\phi_{c_3, c_4, t/2}\right]$$ + +Der entscheidende Unterschied: Anstatt die Formel $\phi$ zweimal hinzuschreiben (einmal für $(c_1, m_1)$ und einmal für $(m_1, c_2)$), wird ein **Allquantor** verwendet, der über die **beiden möglichen Paare** $(c_3, c_4)$ iteriert. Damit wird die Formel nur **einmal** aufgeschrieben. + +**Technisches Detail:** Die Notation $\forall x \in {y, z} [\ldots]$ steht eigentlich für $\forall x \left[(x = y \lor x = z) \rightarrow \ldots\right]$. In der tatsächlichen Formel muss die Mengenzugehörigkeit durch eine **Äquivalenzrelation** in Boolescher Logik ausgedrückt werden. + +#### Größenanalyse + +- Jeder Rekursionslevel vergrößert die Formel um $O(n^k)$ (Kodierung der Konfigurationen). +- Die Rekursionstiefe beträgt $O(n^k)$ (da $\log h = O(n^k)$). +- Gesamtgröße der Formel: $O(n^{2k})$ – **polynomiell!** + +> **Ergänzung:** Dies ist die Kernidee des Beweises von Savitch’s Theorem angewandt auf die PSPACE-Vollständigkeit von TQBF. Der Allquantor erlaubt es, die exponentielle Aufblähung zu vermeiden, indem dieselbe Teilformel für beide Hälften wiederverwendet wird. + +----- + +## 2. „Gaming is Hard”, Part II – PSPACE-Härte von Spielen + +### 2.1 Metatheorem 4 (Pressure Plates) + +> **Metatheorem 4:** Wenn ein Spiel Türen und Druckplatten enthält und der Avatar einen Ausgang erreichen muss, dann gilt: Wenn jede Tür durch **zwei Druckplatten** gesteuert werden kann, ist das Spiel **PSPACE-hard**. + +### 2.2 Level-Aufbau als TQBF-Simulation + +Ein Level wird konstruiert, der eine TQBF direkt simuliert: + +- **Obere Reihe (Quantoren-Gadgets):** Abwechselnd $\exists x$, $\forall y$, $\exists z$, $\forall w$, … + - Der Spieler traversiert diese Gadgets vom Start zum Ende. + - **Existenzquantoren** ($\exists$): Der Spieler wählt einen Pfad (oben = true, unten = false). Die Wahl setzt Druckplatten, die Variablenwerte kodieren. + - **Allquantoren** ($\forall$): Der Spieler muss **beide** Pfade durchlaufen – d.h., das Spiel erzwingt, dass beide Belegungen getestet werden. +- **Untere Reihe (Klausel-Gadgets):** Eine Reihe von Klauseln, die mit Türen realisiert werden. + - Jede Klausel prüft, ob die aktuelle Variablenbelegung die Klausel erfüllt. + - Die Türen sind durch Druckplatten gesteuert, die von den Quantor-Gadgets gesetzt werden. + +Die Gadgets für die einzelnen Komponenten nutzen Druckplatten zur Kodierung von Variablen an bestimmten Positionen. Die Variable $x$ an der Stelle $i$ wird durch die Position des Spielers und der dadurch aktivierten Druckplatten repräsentiert. + +### 2.3 Metatheorem 5 (k-Buttons) + +> **Metatheorem 5:** Wenn ein Spiel Türen und $k$-Buttons enthält und der Avatar einen Ausgang erreichen muss, dann gilt: Wenn $k \geq 3$, ist das Spiel **PSPACE-hard**. + +### 2.4 Simulation von Druckplatten durch 3-Buttons + +Die Vorlesung zeigt, wie eine Druckplatte mit Hilfe von **3-Buttons** simuliert werden kann. Das Gadget besteht aus vier Zuständen (Startkonfiguration und drei Folgezustände), die durch die Interaktion des Spielers mit den Buttons $a$, $b$, $c$, $d$ durchlaufen werden. Die Buttons steuern die Türen über $\pm x$, $\pm a$, $\pm b$, etc., wobei $+$ für „öffnen” und $-$ für „schließen” steht. + +> **Ergänzung:** Die Ergebnisse stammen aus dem Bereich der **computational complexity of games**. Die Arbeit von Viglietta (2014) und Aloupis et al. formalisiert, welche Spielmechaniken welche Komplexitätsklassen induzieren. Viele klassische Videospiele (z.B. generalisierte Versionen von Sokoban, Zelda, Pokemon) sind nachweislich PSPACE-hard. + +----- + +## 3. Hierarchy Theorems + +### 3.1 Time- und Space-Constructibility + +**Time-constructible:** +Eine Funktion $t: \mathbb{N} \to \mathbb{N}$ mit $t(n) \geq O(n \log n)$ heißt **time-constructible**, wenn die Funktion, die den String $1^n$ auf die Binärdarstellung von $t(n)$ abbildet, in Zeit $O(t(n))$ berechenbar ist. + +**Space-constructible:** +Eine Funktion $f: \mathbb{N} \to \mathbb{N}$ mit $f(n) \geq O(\log n)$ heißt **space-constructible**, wenn die Funktion, die den String $1^n$ auf die Binärdarstellung von $f(n)$ abbildet, in Platz $O(f(n))$ berechenbar ist. + +> **Ergänzung:** Die meisten „natürlichen” Funktionen wie $n$, $n^2$, $n \log n$, $2^n$ sind sowohl time- als auch space-constructible. Diese Bedingung ist nötig, damit die Maschine „weiß”, wie viel Ressourcen sie zur Verfügung hat, und einen Zähler korrekt setzen kann. + +### 3.2 Space Hierarchy Theorem + +> **Theorem (Space Hierarchy):** Für jede space-constructible Funktion $f: \mathbb{N} \to \mathbb{N}$ existiert eine Sprache $A$, die in $O(f(n))$ Speicher entscheidbar ist, aber **nicht** in $o(f(n))$ Speicher. + +#### Beweis (Skizze) + +Der Algorithmus $D$ entscheidet eine Sprache $A$ wie folgt: + +1. Sei $n$ die Länge der Eingabe $w$. +2. Berechne $f(n)$ mittels Space-Constructibility und markiere genau so viel Band. Falls spätere Stufen mehr Platz benötigen, **reject**. +3. Falls $w$ nicht die Form $\langle M \rangle 10^*$ hat (für eine TM $M$), **reject**. +4. Simuliere $M$ auf $w$ und zähle die Schritte. Falls der Zähler $2^{f(n)}$ überschreitet, **reject**. +5. Falls $M$ akzeptiert, **reject**. Falls $M$ ablehnt, **accept** (Diagonalisierung!). + +**Warum funktioniert das?** Angenommen, eine Maschine $M$ entscheidet $A$ mit $g(n)$ Speicher, wobei $g(n) \in o(f(n))$. Dann gibt es ein $n$, ab dem $D$ die Maschine $M$ korrekt simulieren kann (der Platz reicht aus). Aber $D$ tut dann das Gegenteil von $M$ – **Widerspruch**. + +#### Korollare + +- Für beliebige reelle Zahlen $0 \leq \epsilon_1 < \epsilon_2$: $\text{SPACE}(n^{\epsilon_1}) \subsetneq \text{SPACE}(n^{\epsilon_2})$. +- $\text{PSPACE} \subsetneq \text{EXPSPACE} = \bigcup_k \text{SPACE}(2^{n^k})$. + +> **Ergänzung:** Das Space Hierarchy Theorem zeigt, dass mehr Speicher echt mehr Sprachen entscheidbar macht. Die Lücke ist dabei schärfer als beim Time Hierarchy Theorem, da kein logarithmischer Faktor benötigt wird. Dies liegt daran, dass die Simulation einer TM bezüglich des Platzes effizienter ist als bezüglich der Zeit. + +### 3.3 Time Hierarchy Theorem + +> **Theorem (Time Hierarchy):** Für jede time-constructible Funktion $t: \mathbb{N} \to \mathbb{N}$ existiert eine Sprache $A$, die in $O(t(n))$ Zeit entscheidbar ist, aber **nicht** in Zeit $o(t(n) / \log t(n))$. + +#### Beweis (Skizze) + +Der Algorithmus $D$ ist analog zum Space Hierarchy Theorem aufgebaut: + +1. Sei $n$ die Länge der Eingabe $w$. +2. Berechne $t(n)$ mittels Time-Constructibility und speichere den Wert $\lfloor t(n) / \log t(n) \rfloor$ in einem Binärzähler. Dekrementiere diesen Zähler vor jedem Schritt der Stufen 3, 4 und 5. Falls der Zähler 0 erreicht, **reject**. +3. Falls $w$ nicht die Form $\langle M \rangle 10^*$ hat, **reject**. +4. Simuliere $M$ auf $w$. +5. Falls $M$ akzeptiert, **reject**. Falls $M$ ablehnt, **accept**. + +**Warum der log-Faktor?** Das Counter-Update kostet pro Simulationsschritt jeweils $O(\log t(n))$, da der Binärzähler $\log t(n)$ Bits hat. Die Gesamtlaufzeit von $D$ beträgt also $\lfloor t(n) / \log t(n) \rfloor \cdot O(\log t(n)) = O(t(n))$. + +#### Korollare + +- Für beliebige reelle Zahlen $1 \leq \epsilon_1 < \epsilon_2$: $\text{TIME}(n^{\epsilon_1}) \subsetneq \text{TIME}(n^{\epsilon_2})$. +- $\text{P} \subsetneq \text{EXPTIME}$. + +> **Ergänzung:** Die strenge Inklusion $\text{P} \subsetneq \text{EXPTIME}$ ist eines der wenigen **bewiesenen** Separationsresultate in der Komplexitätstheorie. Im Gegensatz dazu ist die Frage $\text{P} \stackrel{?}{=} \text{NP}$ nach wie vor offen. + +### 3.4 Warum ist Time-Constructibility notwendig? + +Die Voraussetzung der Time-Constructibility ist **essentiell**, wie das folgende Gap Theorem zeigt. Ohne diese Voraussetzung gibt es „pathologische” Funktionen, für die die Hierarchie zusammenbricht. + +----- + +## 4. Gap Theorem (Trakhtenbrot, Borodin) + +> **Theorem (Gap Theorem):** Es existiert eine berechenbare Funktion $f$, sodass $\text{TIME}(f(n)) = \text{TIME}(2^{f(n)})$. + +Das bedeutet: Es gibt eine Funktion $f$, bei der eine **exponentielle Erhöhung** der Zeitschranke **keine zusätzlichen Sprachen** entscheidbar macht! + +### Beweis (Skizze) + +Sei ${M_e}$ eine Aufzählung aller deterministischen TMs. Wir konstruieren $f$ schrittweise, sodass $f$ in jedem Schritt $e$ folgende Bedingung erfüllt: + +$$\forall x \left(|x| = n \land M_e(x) \downarrow \text{ in } t \text{ Schritten} \implies t \notin (f(n), 2^{f(n)}]\right)$$ + +**Konstruktion von $f(n)$:** + +Betrachte die Sequenz $k_0 = 0$, $k_{l+1} = 2^{k_l}$. Für alle Berechnungen $M_e(x)$ mit $e \leq n$ (wobei $n = |x|$), die in $t_{e,x}$ Schritten halten, wähle das kleinste $k_l$, sodass **keines** der $t_{e,x}$ im Intervall $(k_l, 2^{k_l}]$ liegt. Setze $f(n) = k_l$. + +**Warum existiert ein solches $k_l$?** Da es nur endlich viele Paare $(e, x)$ mit $e \leq n$ und $|x| = n$ gibt, gibt es auch nur endlich viele Haltezeiten $t_{e,x}$. Die Intervalle $(k_l, 2^{k_l}]$ wachsen schnell genug, um immer eine „Lücke” (gap) zu finden. + +**Konsequenz:** Jede Sprache, die in $\text{TIME}(2^{f(n)})$ liegt, wird von einer TM entschieden, deren Haltezeit **unterhalb** von $f(n)$ liegt (nicht im Intervall dazwischen), also liegt sie automatisch auch in $\text{TIME}(f(n))$. + +> **Ergänzung:** Das Gap Theorem zeigt, dass die Hierarchie-Theoreme die Bedingung der Konstruierbarkeit **wirklich** benötigen. Die Funktion $f$ aus dem Gap Theorem ist typischerweise **nicht** time-constructible. Es handelt sich um ein fundamentales Resultat der abstrakten Komplexitätstheorie (Blum-Axiome). + +----- + +## 5. Speed-Up Theorem (Blum) + +> **Theorem (Speed-Up Theorem, M. Blum):** Es existiert eine berechenbare Menge $A$, sodass es für jeden Index $e$ (d.h. jede TM $M_e$) für $A$ einen anderen Index $i$ für $A$ gibt, sodass: +> $$\forall^\infty x ; \left(\Phi_i(x) \leq \log \Phi_e(x)\right)$$ + +Dabei ist $\Phi_e(x)$ die Anzahl der Berechnungsschritte von $M_e(x)$ (falls $M_e$ auf $x$ hält), und $\forall^\infty x$ bedeutet „für fast alle $x$” (alle bis auf endlich viele). + +**Bedeutung:** Egal welche TM $M_e$ die Sprache $A$ berechnet – es gibt immer eine **exponentiell schnellere** TM $M_i$, die dasselbe tut. Die Sprache $A$ hat also **keine optimale Berechnung**. + +### Beweis (Skizze) + +#### Hilfsfolge + +Definiere $g(x) = 2^x$, $g^{(1)}(x) = g(x)$, und $g^{(n+1)}(x) = g(g^{(n)}(x))$ (iterierte Exponentiation). Für $x > e + 1$ ist dann $h_e(x) = g^{(x-e)}(0)$ eine **abnehmende Familie** von Funktionen, d.h. $g(h_{e+1}(x)) = h_e(x)$. + +#### Diagonalisierung + +Für jedes $x$ wird $A(x)$ bestimmt, indem für alle $e \leq x$ geprüft wird: + +- Ist $e$ noch nicht markiert („cancelled”)? +- Gilt $\Phi_e(x) < h_e(x)$? + +Für das **kleinste** solche $e$ definiere $A(x) = 1 - M_e(x)$ und markiere $e$. (Das ist der Diagonalisierungsschritt: $A$ tut das Gegenteil von $M_e$.) + +#### Konsequenzen + +Damit gilt für jedes $e$: Falls für unendlich viele $x$ gilt $\Phi_e(x) < h_e(x)$, folgt $M_e \neq A$. Anders geschrieben: + +$$\forall e \left(M_e = A \implies \forall^\infty x ; h_e(x) \leq \Phi_e(x)\right)$$ + +#### Speed-Up-Eigenschaft + +Um $A(x)$ zu berechnen, lässt man für jedes $e \leq x$ die Maschine $M_e(x)$ für $h_e(x)$ Schritte laufen. Mit Hilfe der endlichen Menge $F_u = {(e, x, A(x)) : e < u \land e \text{ cancelled at stage } x}$ genügt es, dies nur für $u \leq e \leq x$ zu tun. + +Die Berechnung dauert $h_u(x) + \ldots + h_x(x)$ Schritte. Die Laufzeit für die ersten $x$ Stufen ist von oben beschränkt durch $x \cdot (h_u(x) + \ldots + h_x(x)) \leq h_{u-1}(x)$ (für fast alle $x$). + +Da $u$ beliebig groß gewählt werden kann, gilt: +$$\forall e ; \exists i \left(M_i = A \land \forall^\infty x ; \Phi_i(x) \leq h_{e+1}(x)\right)$$ + +Und damit insgesamt: +$$\Phi_i(x) \leq h_{e+1}(x) \leq \log h_e(x) \leq \log \Phi_e(x)$$ + +> **Ergänzung:** Das Speed-Up Theorem ist ein tiefliegendes Resultat, das zeigt, dass nicht jede berechenbare Sprache eine „schnellste” Berechnung besitzt. Es steht im Kontext der **Blum-Axiome** der abstrakten Komplexitätstheorie. Die Funktion $h_e$ wächst dabei so schnell (iterierte Exponentiation), dass der Logarithmus von $h_e$ immer noch zu $h_{e+1}$ wird – genau das ermöglicht den exponentiellen Speed-Up. + +----- + +## 6. Orakel-Turingmaschinen + +### Definition + +Ein **Orakel** für eine Sprache $A$ ist ein Gerät, das für jeden String $w$ in **einem einzigen Schritt** berichten kann, ob $w \in A$. + +Eine **Orakel-Turingmaschine** $M^A$ ist eine modifizierte TM mit einem speziellen **Orakelband**: Wann immer $M^A$ einen String auf dieses Band schreibt, erhält sie sofort die Antwort, ob der String in $A$ liegt. + +### Komplexitätsklassen mit Orakeln + +- $\text{P}^A$: Klasse der Sprachen, die von einer **polynomialzeit**-beschränkten Orakel-TM mit Orakel $A$ entschieden werden können. +- $\text{NP}^A$: Analog für **nichtdeterministische** polynomialzeit-beschränkte Orakel-TMs. + +> **Ergänzung:** Orakel-TMs sind ein mächtiges Konzept, um die relative Stärke von Komplexitätsklassen zu untersuchen. Intuitiv simuliert das Orakel ein „Unterprogramm” mit beliebiger Mächtigkeit – die Anfrage kostet nur einen einzigen Schritt, unabhängig davon, wie schwer das Orakel-Problem eigentlich ist. + +----- + +## 7. Relativierung + +### Kernfrage + +Kann die Technik der **Relativierung** (Diagonalisierung über Orakel-TMs) dabei helfen, Komplexitätsklassen zu separieren? + +### Theorem (Baker, Gill, Solovay, 1975) + +> 1. Es existiert ein Orakel $A$, sodass $\text{P}^A \neq \text{NP}^A$. +> 2. Es existiert ein Orakel $B$, sodass $\text{P}^B = \text{NP}^B$. + +### Beweis von Teil 2 + +Wähle $B = \text{TQBF}$. Dann gilt: +$$\text{NP}^{\text{TQBF}} \subseteq \text{NPSPACE} \subseteq \text{PSPACE} \subseteq \text{P}^{\text{TQBF}}$$ + +Die letzte Inklusion gilt, weil TQBF PSPACE-vollständig ist – eine polynomialzeit Orakel-TM kann jedes PSPACE-Problem lösen, indem sie das Orakel befragt. + +### Beweis von Teil 1 (Diagonalisierung) + +Wir konstruieren ein Orakel $A$, sodass die Sprache +$$L_A = {w \mid \exists x \in A \text{ mit } |x| = |w|}$$ +**nicht** in $\text{P}^A$ liegt (aber offensichtlich in $\text{NP}^A$, da man $x$ raten und das Orakel fragen kann). + +**Konstruktion von $A$ in Schritten:** + +Sei $M_1, M_2, M_3, \ldots$ die Aufzählung aller polynomialzeit Orakel-TMs. + +- **Schritt 1:** Wähle endlich viele beliebige Strings und füge sie zu $A$ hinzu. +- **Schritt $i$:** Wähle $n$ so groß, dass $2^n > p_i(n)$ (Laufzeitschranke von $M_i$) und $n$ größer als alle bisherigen String-Längen in $A$. + - Simuliere $M_i$ auf Eingabe $1^n$. + - Falls $M_i$ das Orakel nach $y$ fragt und der Status von $y$ feststeht → antworte gemäß Status. + - Falls der Status nicht feststeht → antworte „Nein” und setze $y \notin A$. + - Falls $M_i$ **akzeptiert** → alle verbleibenden Strings der Länge $n$ erhalten den Status „nicht in $A$” (Diagonalisierung: $1^n \in L_A$, aber $M_i$ akzeptiert – Widerspruch zur korrekten Entscheidung). + - Falls $M_i$ **nicht akzeptiert** → wähle einen String der Länge $n$, nach dem $M_i$ das Orakel nicht gefragt hat, und füge ihn zu $A$ hinzu (das geht, weil $2^n > p_i(n)$, also hat $M_i$ weniger Strings abgefragt, als es gibt). + +### Konsequenz + +Da sowohl $\text{P}^A \neq \text{NP}^A$ als auch $\text{P}^B = \text{NP}^B$ möglich ist, kann **keine relativierende Beweistechnik** die P-vs-NP-Frage klären. Jeder Beweis, der für beliebige Orakel funktioniert, würde zu einem Widerspruch führen. + +> **Ergänzung:** Dies war ein bahnbrechendes Ergebnis von Baker, Gill und Solovay (1975), das zeigte, dass Diagonalisierung allein nicht ausreicht, um P ≠ NP zu beweisen. Spätere Arbeiten (Razborov, Rudich: „Natural Proofs”, 1997) zeigten weitere fundamentale Schranken für Beweistechniken. + +----- + +## 8. Polynomiale Hierarchie (PH) + +### 8.1 Definition über Quantoren + +Für eine Komplexitätsklasse $\mathcal{C}$ definieren wir: + +$$\exists \mathcal{C} = \left{x : \exists^{p(|x|)} y ; \langle x, y \rangle \in B \right}$$ + +wobei $B \in \mathcal{C}$ und „$\exists^{p(|x|)} y$” bedeutet: es existiert ein String $y$ der Länge $\leq p(|x|)$. + +Analog für den Allquantor: $\forall \mathcal{C}$. + +**Beobachtungen:** + +- $\exists \text{P} = \text{NP}$ (die existenzielle Quantifizierung über P ergibt NP) +- $\forall \text{P} = \text{co-NP}$ (die universelle Quantifizierung über P ergibt co-NP) + +### 8.2 Die Stufen der Hierarchie + +Die polynomiale Hierarchie wird induktiv definiert: + +|Stufe|$\Sigma^p$ |$\Pi^p$ |$\Delta^p$ | +|-----|--------------------------------------------------------|----------------------------------|---------------------------------------| +|0 |$\Sigma^p_0 = \text{P}$ |$\Pi^p_0 = \text{P}$ | | +|1 |$\Sigma^p_1 = \text{NP}$ |$\Pi^p_1 = \text{co-NP}$ |$\Delta^p_1 = \text{P}$ | +|2 |$\Sigma^p_2 = \exists \Pi^p_1 = \text{NP}(\text{co-NP})$|$\Pi^p_2 = \forall \Sigma^p_1$ |$\Delta^p_2 = \text{P}(\text{NP})$ | +|$n+1$|$\Sigma^p_{n+1} = \exists \Pi^p_n$ |$\Pi^p_{n+1} = \forall \Sigma^p_n$|$\Delta^p_{n+1} = \text{P}(\Sigma^p_n)$| + +Die **polynomiale Hierarchie** ist dann: +$$\text{PH} = \bigcup_{n \geq 0} \Sigma^p_n$$ + +### 8.3 Äquivalente Charakterisierung + +Eine Sprache $L$ ist in $\Sigma^p_i$ genau dann, wenn es eine polynomialzeit-TM $M$ und ein Polynom $q$ gibt, sodass: + +$$x \in L \iff \exists u_1 \in {0,1}^{q(|x|)} ; \forall u_2 \in {0,1}^{q(|x|)} ; \cdots ; Q_i u_i \in {0,1}^{q(|x|)} ; M(x, u_1, \ldots, u_i) = 1$$ + +wobei die Quantoren **alternieren** ($\exists, \forall, \exists, \forall, \ldots$) und $Q_i = \forall$ falls $i$ gerade, $Q_i = \exists$ falls $i$ ungerade. + +Analog für $\Pi^p_i$ mit umgekehrter Quantorenreihenfolge ($\forall, \exists, \forall, \exists, \ldots$). + +### 8.4 Zusammenhang mit Orakel-Klassen + +> $\Sigma^p_{n+1} = \text{NP}(\Sigma^p_n)$ + +**Beweis (Skizze):** + +- **Richtung $\Sigma^p_{n+1} \subseteq \text{NP}(\Sigma^p_n)$:** Per Definition ist jedes $S \in \Sigma^p_{n+1} = \exists \Pi^p_n$. Es gibt also ein $S’ \in \Pi^p_n$ mit $S = {x : \exists y \text{ mit } (x,y) \in S’}$. Da $\Pi^p_n \subseteq \text{NP}(\Sigma^p_n)$ (und auch $= \text{co-}\Sigma^p_{n+1}$), liegt $S$ in $\text{NP}(\Sigma^p_n)$. +- **Richtung $\text{NP}(\Sigma^p_n) \subseteq \Sigma^p_{n+1}$:** Eine NP-Maschine mit Orakel $S’ \in \Sigma^p_n$ rät zunächst ein Zertifikat $y$ und stellt dann adaptive Orakel-Anfragen. Man kann die Orakel-Antworten **mitraten** und die Korrektheit der geratenen Antworten durch die Quantorenstruktur von $\Sigma^p_n$ verifizieren. + +### 8.5 Vollständige Probleme + +Für jede Stufe $i$ der Hierarchie ist $\Sigma_i\text{SAT}$ ein vollständiges Problem: + +$$\Sigma_i\text{SAT} = \exists u_1 ; \forall u_2 ; \exists \cdots ; Q_i u_i ; \varphi(u_1, u_2, \ldots, u_i) = 1$$ + +### 8.6 Kollaps der Hierarchie + +- $\text{PH} \subseteq \text{PSPACE}$ (leicht einzusehen, da jede Stufe in PSPACE simulierbar ist). +- Falls $\text{PH} = \text{PSPACE}$, so **kollabiert** PH (auf eine endliche Stufe). +- Falls es ein **vollständiges Problem für PH** gibt, so kollabiert PH ebenfalls. + +> **Ergänzung:** Die Vermutung, dass PH **nicht** kollabiert, ist eines der zentralen offenen Probleme der Komplexitätstheorie. Ein Kollaps auf Stufe 0 würde $\text{P} = \text{NP}$ bedeuten, ein Kollaps auf Stufe 1 würde $\text{NP} = \text{co-NP}$ implizieren. Die meisten Forscher vermuten, dass die Hierarchie unendlich ist – aber ein Beweis fehlt. + +----- + +## Zusammenfassung der wichtigsten Beziehungen + +$$\text{P} \subseteq \text{NP} \subseteq \Sigma^p_2 \subseteq \cdots \subseteq \text{PH} \subseteq \text{PSPACE} \subseteq \text{EXPTIME} \subseteq \text{EXPSPACE}$$ + +**Bekannte strikte Inklusionen:** + +- $\text{P} \subsetneq \text{EXPTIME}$ (Time Hierarchy Theorem) +- $\text{PSPACE} \subsetneq \text{EXPSPACE}$ (Space Hierarchy Theorem) +- $\text{NL} \subsetneq \text{PSPACE}$ (Space Hierarchy Theorem) + +**Offene Fragen:** + +- $\text{P} \stackrel{?}{=} \text{NP}$ +- $\text{NP} \stackrel{?}{=} \text{co-NP}$ +- $\text{P} \stackrel{?}{=} \text{PSPACE}$ +- Kollabiert PH? + +----- + +## Übersicht der Schlüsselresultate + +|Resultat |Aussage |Technik | +|---------------------------|----------------------------------------------------------|----------------------------------------------| +|TQBF ist PSPACE-vollständig|Jedes PSPACE-Problem lässt sich als QBF kodieren |Formelkonstruktion mit Allquantor-Trick | +|Space Hierarchy Theorem |Mehr Platz → echt mehr Sprachen |Diagonalisierung | +|Time Hierarchy Theorem |Mehr Zeit → echt mehr Sprachen (mit log-Lücke) |Diagonalisierung + Zähler | +|Gap Theorem |$\exists f$: $\text{TIME}(f(n)) = \text{TIME}(2^{f(n)})$ |Konstruktion von Lücken in Haltezeiten | +|Speed-Up Theorem |$\exists A$: jede TM kann exponentiell beschleunigt werden|Diagonalisierung + abnehmende Funktionsfamilie| +|Baker-Gill-Solovay |Relativierung kann P vs NP nicht klären |Orakel-Konstruktion | +|PH-Definition |$\Sigma^p_{n+1} = \text{NP}(\Sigma^p_n)$ |Quantoren-Alternierung | diff --git a/Kryptografie/.DS_Store b/Kryptografie/.DS_Store new file mode 100644 index 0000000..11b5543 Binary files /dev/null and b/Kryptografie/.DS_Store differ diff --git a/Kryptografie/_Overview.md b/Kryptografie/_Overview.md new file mode 100644 index 0000000..217da93 --- /dev/null +++ b/Kryptografie/_Overview.md @@ -0,0 +1,37 @@ +# Kryptografie + +> [[Dashboard|← Zurück zum Dashboard]] + +**Dozent:** Prof. Dr. Björn Grohmann + +--- + +## Vorlesungen + +| # | Thema | Folien | Zusammenfassung | NotebookLM | Lernkarten | Status | +| --- | ------------------------------------------ | ------ | --------------------------------- | ---------- | ---------- | ------ | +| 01 | Historische Chiffren & Grundlagen | ✅ | ✅ [[kr1 - zusammenfassung\|Link]] | ✅ | ✅ | 🟢 | +| 02 | MAC & AEAD | ✅ | ✅ [[kr2 - zusammenfassung\|Link]] | ✅ | ✅ | 🟢 | +| 03 | Signaturen & Zertifikate | ✅ | ✅ [[kr3 - zusammenfassung\|Link]] | ✅ | ✅ | 🟢 | +| 04 | Komplexitätsklassen & Public Key | ✅ | ✅ [[kr4 - zusammenfassung\|Link]] | ✅ | ⬜ | 🟡 | +| 05 | MPC, Zero Knowledge & Differential Privacy | ✅ | ✅ [[kr5 - zusammenfassung\|Link]] | ✅ | ⬜ | 🟡 | +| 06 | Klausurvorbereitung | ⬜ | ⬜ | ⬜ | ⬜ | 🔴 | + +**Legende:** ⬜ Offen · ✅ Erledigt · 🔴 Nicht begonnen · 🟡 In Arbeit · 🟢 Fertig + +--- + +## Zusätzliche Materialien + +- [[02 - Areas/bdr - duales studium/hwr/Kryptografie/klausur/themenliste|Themenliste (alle Prüfungsthemen)]] +- [[kr2 - additional notes|KR2 – Zusätzliche Notizen]] +- [[kr3 - notes|KR3 – Notizen]] + +--- + +## Modul-Infos + +- **Dozent:** Prof. Dr. Björn Grohmann +- **Prüfungsform:** +- **Prüfungstermin:** +- **Besonderheiten:** diff --git a/Kryptografie/books/Grundlagen_der_Kryptographie_ Einführung_Duncan Buell_2024_Springer.pdf b/Kryptografie/books/Grundlagen_der_Kryptographie_ Einführung_Duncan Buell_2024_Springer.pdf new file mode 100644 index 0000000..ba80440 Binary files /dev/null and b/Kryptografie/books/Grundlagen_der_Kryptographie_ Einführung_Duncan Buell_2024_Springer.pdf differ diff --git a/Kryptografie/books/Kryptographie_Grundlagen, Algorithmen, Protokolle_Dietmar_Wätjen_Springer.pdf b/Kryptografie/books/Kryptographie_Grundlagen, Algorithmen, Protokolle_Dietmar_Wätjen_Springer.pdf new file mode 100644 index 0000000..83fff05 Binary files /dev/null and b/Kryptografie/books/Kryptographie_Grundlagen, Algorithmen, Protokolle_Dietmar_Wätjen_Springer.pdf differ diff --git a/Kryptografie/folien/kr1.pdf b/Kryptografie/folien/kr1.pdf new file mode 100644 index 0000000..9a32a0a Binary files /dev/null and b/Kryptografie/folien/kr1.pdf differ diff --git a/Kryptografie/folien/kr2 - ohne recap.pdf b/Kryptografie/folien/kr2 - ohne recap.pdf new file mode 100644 index 0000000..b7652e9 Binary files /dev/null and b/Kryptografie/folien/kr2 - ohne recap.pdf differ diff --git a/Kryptografie/folien/kr3 - ohne recap.pdf b/Kryptografie/folien/kr3 - ohne recap.pdf new file mode 100644 index 0000000..9aa8fb2 Binary files /dev/null and b/Kryptografie/folien/kr3 - ohne recap.pdf differ diff --git a/Kryptografie/folien/kr4 - ohne recap.pdf b/Kryptografie/folien/kr4 - ohne recap.pdf new file mode 100644 index 0000000..db447bc Binary files /dev/null and b/Kryptografie/folien/kr4 - ohne recap.pdf differ diff --git a/Kryptografie/folien/kr5 - ohne recap.pdf b/Kryptografie/folien/kr5 - ohne recap.pdf new file mode 100644 index 0000000..478bdbe Binary files /dev/null and b/Kryptografie/folien/kr5 - ohne recap.pdf differ diff --git a/Kryptografie/klausur/gesamtzusammenfassung.md b/Kryptografie/klausur/gesamtzusammenfassung.md new file mode 100644 index 0000000..bf3b936 --- /dev/null +++ b/Kryptografie/klausur/gesamtzusammenfassung.md @@ -0,0 +1,1556 @@ +# Kryptographie – Gesamtzusammenfassung zur Klausurvorbereitung + +**HWR Berlin | Prof. Dr. Björn Grohmann | Stand: 31.03.2026** + +--- +## Inhaltsverzeichnis +1. [IT-Sicherheitsbegriffe (Schutzziele)](#1-it-sicherheitsbegriffe) +2. [Klassische Kryptographie](#2-klassische-kryptographie) +3. [Informationstheoretische Sicherheit](#3-informationstheoretische-sicherheit) +4. [Kryptographische Primitive](#4-kryptographische-primitive) +5. [Bit Commitment](#5-bit-commitment) +6. [Symmetrische Verschlüsselung](#6-symmetrische-verschlüsselung) +7. [AES – Advanced Encryption Standard](#7-aes) +8. [Betriebsmodi (Modes of Operation)](#8-betriebsmodi) +9. [Angriffsmodelle & IND-CPA-Sicherheit](#9-angriffsmodelle--ind-cpa) +10. [MAC, HMAC & AEAD](#10-mac-hmac--aead) +11. [Public-Key-Kryptographie – Grundlagen](#11-public-key-kryptographie) +12. [RSA-Kryptosystem](#12-rsa) +13. [ElGamal-Verschlüsselung](#13-elgamal) +14. [IND-CCA, IND-CCA2 & Padding](#14-ind-cca-ind-cca2--padding) +15. [Digitale Signaturen](#15-digitale-signaturen) +16. [Zertifikate & PKI](#16-zertifikate--pki) +17. [TLS (Transport Layer Security)](#17-tls) +18. [IPSec](#18-ipsec) +19. [Quantencomputer & Kryptographie](#19-quantencomputer) +20. [Post-Quantum Kryptographie (PQC)](#20-post-quantum-kryptographie) +21. [Homomorphe Verschlüsselung](#21-homomorphe-verschlüsselung) +22. [Multi-Party Computation (MPC)](#22-multi-party-computation-mpc) +23. [Zero Knowledge Proofs (ZKP)](#23-zero-knowledge-proofs) +24. [Differential Privacy](#24-differential-privacy) +25. [Trusted Execution Environments (TEE)](#25-trusted-execution-environments) +26. [Privacy-Schutzziele & Technologien](#26-privacy-schutzziele--technologien) +--- +## 1. IT-Sicherheitsbegriffe +### Die 4 Sicherheitsziele (VIVA) +In der Kryptographie und IT-Sicherheit werden vier grundlegende Schutzziele unterschieden: + +| Schutzziel | Englisch | Bedeutung | +|---|---|---| +| **Vertraulichkeit** | Confidentiality | Nur berechtigte Personen können auf Daten zugreifen. Schutz vor unbefugtem Mitlesen. | +| **Integrität** | Integrity | Daten wurden nicht unbemerkt verändert. Manipulationen werden erkannt. | +| **Verfügbarkeit** | Availability | Daten und Systeme sind für Berechtigte zugänglich, wenn sie benötigt werden. | +| **Authentizität** | Authenticity | Der Absender ist zweifelsfrei identifizierbar. Die Herkunft von Daten ist verifizierbar. | + +**Zusätzlich:** **Verbindlichkeit (Non-Repudiation)** – ein Absender kann das Senden einer Nachricht nicht abstreiten. Oft als 5. Schutzziel oder als Teil der Authentizität betrachtet. + +**Historisches Beispiel:** Beim Babington-Plot (1586) fehlten alle vier Schutzziele: Maria Stuarts Chiffre bot keine echte Vertraulichkeit (Häufigkeitsanalyse), keine Integrität (Nachrichten wurden manipuliert), der Bote war ein Doppelagent (keine Authentizität), und die Existenz der Kommunikation war bekannt. + +--- + +## 2. Klassische Kryptographie +### 2.1 Häufigkeitsanalyse + +Einfache Substitutionschiffren lassen sich durch **Häufigkeitsanalyse** brechen: Man zählt die Häufigkeit von Symbolen im Geheimtext und vergleicht sie mit der bekannten Buchstabenhäufigkeit der Sprache. + +- Im Englischen ist **E** der häufigste Buchstabe (~11,16 %), gefolgt von A, R, I, O +- Samuel Morse nutzte dasselbe Prinzip für sein Morsealphabet + +### 2.2 Caesar-Chiffre + +**Definition:** Jeder Buchstabe wird um eine feste Zahl *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 → D, B → E, Z → C + +**Schwäche:** Nur 25 mögliche Schlüssel → trivial per Brute-Force brechbar. + +### 2.3 Vigenère-Chiffre + +**Definition:** Polyalphabetische Substitution. Ein Schlüsselwort wird wiederholt über den Klartext gelegt. Jeder Buchstabe bekommt einen anderen Caesar-Shift. + +- **Verschlüsselung:** `C_i = (M_i + K_i) mod 26` +- **Entschlüsselung:** `M_i = (C_i - K_i) mod 26` + +**Beispiel:** Klartext „attackatdawn" + Schlüssel „LEMON" (wiederholt: „LEMONLEMONLE") → Geheimtext „LXFOPVEFRNHR" + +**Schwäche:** Der **Kasiski-Test** ermittelt die Schlüssellänge. Wiederholen sich Muster im Klartext an Positionen, die ein Vielfaches der Schlüssellänge auseinanderliegen, entstehen identische Muster im Geheimtext. Der ggT der Abstände dieser Muster ist oft die Schlüssellänge. + +### 2.4 Homophone Chiffren + +Jedem Buchstaben werden mehrere Symbole zugeordnet (proportional zur Häufigkeit), um die Häufigkeitsverteilung zu glätten. Bieten keinen vollständigen Schutz. + +--- + +## 3. Informationstheoretische Sicherheit + +### 3.1 Informationsgehalt und Entropie + +**Informationsgehalt** eines Zeichens x mit Wahrscheinlichkeit p_x: +``` +I(x) = -log₂(p_x) = log₂(1/p_x) +``` +Je seltener ein Zeichen, desto größer sein Informationsgehalt (in Bit). + +**Entropie H(X)** – mittlerer Informationsgehalt einer Zufallsvariable: +``` +H(X) = -∑_x p_x · log₂(p_x) +``` +Die Entropie ist maximal, wenn alle Zeichen gleich wahrscheinlich sind. + +**Bedingte Entropie:** `H(X|Y) = H(X,Y) - H(Y)` + +### 3.2 Perfekte Sicherheit (Shannon Perfect Secrecy) + +**Definition (Claude Shannon, 1949):** Ein Verschlüsselungssystem hat **perfekte Sicherheit**, wenn gilt: +``` +H(M|E) = H(M) +``` +Das bedeutet: Die bedingte Entropie der Nachricht M gegeben den Geheimtext E ist gleich der Entropie von M. Der Geheimtext verrät **keinerlei Information** über den Klartext. M und E sind stochastisch unabhängig. + +**Äquivalente Formulierung:** Jeder Geheimtext ist unabhängig vom Klartext gleich wahrscheinlich. + +**Konsequenz:** Für perfekte Sicherheit muss der Schlüssel **mindestens so lang wie die Nachricht** sein. + +### 3.3 One-Time Pad (OTP) + +**Definition:** Das einzige Verfahren, das perfekte Sicherheit erreicht. + +- **Verschlüsselung:** `E = P ⊕ K` (bitweise XOR von Klartext und Schlüssel) +- **Entschlüsselung:** `P = E ⊕ K` + +**Bedingungen für perfekte Sicherheit:** +1. Der Schlüssel muss **echt zufällig** erzeugt werden +2. Der Schlüssel muss **mindestens so lang** sein wie die Nachricht +3. Der Schlüssel darf **nur einmal** verwendet werden (daher „One-Time") + +**Problem in der Praxis:** Der Schlüssel muss genauso lang sein wie die Nachricht und über einen sicheren Kanal übertragen werden – unpraktisch. + +**Was passiert bei zweifacher Verwendung desselben OTP-Schlüssels?** +``` +C₁ = M₁ ⊕ K und C₂ = M₂ ⊕ K +→ C₁ ⊕ C₂ = M₁ ⊕ M₂ +``` +Ein Angreifer erhält XOR der beiden Klartexte – mit Häufigkeitsanalyse oft lösbar. + +--- + +## 4. Kryptographische Primitive + +### 4.1 Einwegfunktionen (One-Way Functions, OWF) + +**Definition:** Eine Funktion `f: {0,1}* → {0,1}*` ist eine Einwegfunktion, wenn: +1. **Leicht zu berechnen:** Es gibt einen Polynomialzeit-Algorithmus, der f(x) berechnet. +2. **Schwer umzukehren:** Für jeden effizienten Algorithmus A' und alle hinreichend großen n gilt: + ``` + Pr[A'(f(x)) = x'] < 1/p(n) + ``` + mit beliebigem Polynom p(n). Das heißt, die Umkehrung gelingt nur mit vernachlässigbarer Wahrscheinlichkeit. + +**Anschaulich:** x → f(x) ist schnell und einfach. f(x) → x ist praktisch unmöglich. + +**Beispiele:** Multiplikation zweier Primzahlen (leicht), Faktorisierung des Produkts (schwer). + +### 4.2 Pseudo-Zufallszahlengeneratoren (PRG/PRNG) + +**Definition:** Eine Funktion `G: {0,1}^n → {0,1}^{l(n)}` ist ein PRG, wenn: +1. G ist in Polynomialzeit berechenbar. +2. Die Ausgabe ist **länger** als die Eingabe: `l(n) > n` (Streckung). +3. Die Verteilungen `{G(U_n)}` (Ausgabe auf zufälligem Seed) und `{U_{l(n)}}` (echte Zufallsbits) sind **berechnungsmäßig ununterscheidbar**. + +**Amplifikation:** Hat man einen PRG mit Streckung n+1, kann man für jedes Polynom l(n) einen PRG mit Streckung l(n) konstruieren, indem man G iteriert anwendet. + +### 4.3 Berechnungsmäßige Ununterscheidbarkeit (Computational Indistinguishability) + +**Definition:** Zwei Wahrscheinlichkeitsensembles {X_n} und {Y_n} sind **berechnungsmäßig ununterscheidbar**, wenn für jeden probabilistischen Polynomialzeit-Algorithmus D (Distinguisher) und jedes Polynom p(·) ab einem N gilt: +``` +|Pr[D(X_n) = 1] - Pr[D(Y_n) = 1]| < 1/p(n) +``` + +**Umgangssprachlich:** Kein effizienter Algorithmus kann mit nicht-vernachlässigbarem Vorteil entscheiden, ob er eine Ausgabe von G oder echte Zufallsbits sieht. + +### 4.4 Zusammenhang OWF ↔ PRG + +> **Theorem:** Pseudo-Zufallszahlengeneratoren existieren **genau dann**, wenn Einwegfunktionen existieren. + +- **PRG → OWF:** Aus einem PRG `G: {0,1}^n → {0,1}^{2n}` konstruiert man eine OWF: `f(x||y) = G(x)` wobei |x| = |y| = n. Die Funktion „vergisst" die Hälfte der Eingabe. +- **OWF → PRG:** Über ein **Hardcore-Prädikat (HCP)**. Ein HCP ist leicht zu berechnen, aber aus f(x) allein nicht vorhersagbar. + +--- + +## 5. Bit Commitment + +**Definition:** Ein Zwei-Phasen-Protokoll, bei dem sich Alice auf einen Wert (z.B. ein Bit b) festlegt (**Commit**), ohne dass Bob ihn kennt. Später enthüllt Alice den Wert (**Reveal**). + +**Eigenschaften:** +- **Hiding:** Bob kann b vor der Reveal-Phase nicht bestimmen. +- **Binding:** Alice kann b nach dem Commit nicht mehr ändern. + +**Naiver Ansatz (mit PRG) – funktioniert NICHT:** +- Alice wählt Seed s, sendet `G_m(s)` und `B_{m+1}(s) ⊕ b` +- **Problem:** Alice könnte zwei Seeds s, s' finden, die in den ersten m Bits übereinstimmen, aber im (m+1)-ten Bit differieren → Betrug möglich. + +**Verbessertes Protokoll – funktioniert:** +1. Bob sendet zufälligen Vektor `R = (r₁, ..., r_{3n})` +2. Alice wählt Seed s und sendet: + - `d_i = B_i(s)` falls `r_i = 0` + - `d_i = B_i(s) ⊕ b` falls `r_i = 1` +3. Reveal: Alice sendet s und b, Bob verifiziert. + +**Warum sicher?** Die Wahrscheinlichkeit, dass Alice betrügen kann (zwei Seeds finden, die dieselben d_i erzeugen, aber verschiedenes b liefern), ist höchstens `2^{-n}`. + +--- + +## 6. Symmetrische Verschlüsselung + +**Definition:** Sender und Empfänger verwenden **denselben geheimen Schlüssel** zum Ver- und Entschlüsseln. + +### 6.1 Stromchiffren + +**Prinzip:** Ein kurzer Schlüssel (Seed) wird durch einen PRNG zu einem langen Schlüsselstrom gestreckt. Dieser wird per XOR mit dem Klartext verknüpft. + +``` +Schlüsselstrom = PRNG(Seed) +Geheimtext = Klartext ⊕ Schlüsselstrom +``` + +### 6.2 ChaCha20 – Parameter und Funktionsweise + +**ChaCha20** ist eine moderne, weit verbreitete Stromchiffre (z.B. in TLS 1.3, WireGuard). + +**Parameter:** +| Parameter | Größe | Bedeutung | +|---|---|---| +| **Schlüssel** | 256 Bit | Geheimer Schlüssel | +| **Zähler** | 32 Bit | Block-Zähler (verhindert Wiederholung) | +| **Nonce** | 96 Bit | Number-used-once (verhindert IV-Wiederverwendung) | +| **Klartext** | beliebig | Zu verschlüsselnde Daten | + +**Kernoperation – Quarter Round** (arbeitet auf 4 Wörtern a, b, c, d je 32 Bit): +``` +a += b; d ^= a; d <<<= 16 +c += d; b ^= c; b <<<= 12 +a += b; d ^= a; d <<<= 8 +c += d; b ^= c; b <<<= 7 +``` + +**Inner Block:** 8 Quarter Rounds (4 Spalten + 4 Diagonalen) + +**Block-Erzeugung:** 4×4-Matrix aus [Konstanten | Key | Zähler | Nonce] wird 10× durch inner_block gejagt, dann zum Ausgangszustand addiert. + +### 6.3 Blockchiffren + +**Definition:** Verschlüsselt einen Klartextblock **fester Größe** (z.B. 128 Bit) in einen Geheimtextblock gleicher Größe. Für längere Nachrichten werden **Betriebsmodi** benötigt. + +### 6.4 Feistel-Netzwerk (Feistel Cipher) + +**Grundprinzip:** Der Block wird in zwei gleiche Hälften L, R aufgeteilt. Pro Runde gilt: +``` +L_{i+1} = R_i +R_{i+1} = L_i ⊕ F(R_i, K_i) +``` +Die Funktion F muss **nicht invertierbar** sein, weil die Entschlüsselung durch Anwenden der Rundenschlüssel in umgekehrter Reihenfolge funktioniert. + +**Beispiel:** DES (Data Encryption Standard, 1977) ist ein 16-Runden-Feistel-Netzwerk. +- Blockgröße: 64 Bit, Schlüssellänge: 56 Bit (effektiv) → **heute unsicher** + +--- + +## 7. AES – Advanced Encryption Standard + +**Definition:** Symmetrische Blockchiffre, seit 2001 Standard (NIST). +- **Blockgröße:** 128 Bit +- **Schlüssellängen:** 128 Bit (10 Runden), 192 Bit (12 Runden), 256 Bit (14 Runden) +- **Gilt als sicher** + +### 7.1 Die 4 Phasen von AES-128 + +Der Zustand ist eine 4×4-Matrix von Bytes (128 Bit). + +**Algorithmus:** +1. Schlüsselexpansion: Aus dem Hauptschlüssel werden 11 Rundenschlüssel K₀, ..., K₁₀ abgeleitet. +2. Initiales XOR: `s ← M ⊕ K₀` +3. Für jede Runde r = 1 bis 10: + 1. **SubBytes** – nichtlineare Byte-Substitution (S-Box) + 2. **ShiftRows** – zeilenweises Verschieben + 3. **MixColumns** – spaltenweise Mischung (nicht in Runde 10) + 4. **AddRoundKey** – XOR mit Rundenschlüssel K_r + +**Die vier Transformationen im Detail:** + +| Phase | Beschreibung | Zweck | +|---|---|---| +| **SubBytes** | Jedes Byte wird durch sein mult. Inverses in GF(2⁸) ersetzt + affine Transformation | Konfusion (non-linearity) | +| **ShiftRows** | Zeile 0: kein Shift; Zeile 1: 1 Byte; Zeile 2: 2 Bytes; Zeile 3: 3 Bytes zyklisch links | Diffusion (Bytes werden „gemischt") | +| **MixColumns** | Jede Spalte wird als Polynom über GF(2⁸) mit einem festen Polynom multipliziert | Diffusion (algebraische Mischung) | +| **AddRoundKey** | XOR des aktuellen Zustands mit dem Rundenschlüssel | Schlüsseleinbindung | + +### 7.2 AES S-Box – Mathematik in GF(2⁸) + +AES arbeitet im endlichen Körper **GF(2⁸)** (Galois-Körper mit 256 Elementen) mit dem **irreduziblen Polynom:** +``` +m(x) = x⁸ + x⁴ + x³ + x + 1 +``` + +**Operationen in GF(2⁸):** +- **Addition:** XOR der Koeffizienten (entspricht XOR der Byte-Werte) +- **Multiplikation:** Polynommultiplikation **modulo m(x)** +- **Multiplikatives Inverses:** Berechnung mit dem **erweiterten euklidischen Algorithmus**: Finde `a(x)`, `c(x)` sodass `b(x)·a(x) + m(x)·c(x) = 1` + +**S-Box-Konstruktion (zweistufig):** +1. Berechne das multiplikative Inverse von b in GF(2⁸): `b⁻¹` +2. Affine Transformation: `s = A · b⁻¹ + c` (Matrixmultiplikation über GF(2) + Konstantenvektor) + +**Beispiel:** Um zwei Bytes zu multiplizieren, werden sie als Polynome behandelt (Bit 0 = Koeffizient von x⁰, Bit 7 = Koeffizient von x⁷), multipliziert und modulo m(x) reduziert. + +--- + +## 8. Betriebsmodi (Modes of Operation) + +Betriebsmodi bestimmen, wie eine Blockchiffre auf lange Nachrichten angewendet wird. + +### 8.1 ECB (Electronic Codebook Mode) + +**Funktionsweise:** Jeder Block wird **unabhängig** mit demselben Schlüssel verschlüsselt. + +``` +C_i = Enc(K, M_i) +``` + +**Problem:** Identische Klartextblöcke → identische Geheimtextblöcke. Muster bleiben sichtbar (bekanntes „ECB-Pinguin-Bild"). **ECB ist NICHT IND-CPA-sicher.** + +### 8.2 CBC (Cipher Block Chaining) + +**Funktionsweise:** 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. + +``` +C_0 = IV +C_i = Enc(K, M_i ⊕ C_{i-1}) +Entschlüsselung: M_i = Dec(K, C_i) ⊕ C_{i-1} +``` + +**Vorteil:** Gleiche Klartextblöcke ergeben unterschiedliche Geheimtextblöcke (bei verschiedenem IV). +**Nachteil:** Sequenziell (nicht parallelisierbar). Anfällig für **Padding Oracle Attack**. + +### 8.3 CTR (Counter Mode) + +**Funktionsweise:** Wandelt eine Blockchiffre in eine Stromchiffre um. Nonce + fortlaufender Zähler werden verschlüsselt und per XOR mit dem Klartext verknüpft. + +``` +C_i = M_i ⊕ Enc(K, Nonce || Counter_i) +``` + +**Vorteile:** Parallelisierbar, kein Padding nötig, wahlfreier Zugriff möglich. + +### 8.4 OFB (Output Feedback) + +``` +O_0 = IV, O_i = Enc(K, O_{i-1}) +C_i = M_i ⊕ O_i +``` +Der Schlüsselstrom ist **unabhängig vom Klartext**. + +### 8.5 CFB (Cipher Feedback) + +``` +C_i = M_i ⊕ Enc(K, C_{i-1}) +``` +Ähnlich wie OFB, aber der **Geheimtext** (statt des Verschlüsselungsoutputs) wird als nächster Eingabeblock verwendet. + +### 8.6 Cipher Text Stealing (CTS) + +**Problem:** Blockchiffren benötigen Padding, wenn die Nachricht kein Vielfaches der Blockgröße ist. + +**CTS-Lösung:** Kein Padding nötig. Die letzten beiden Blöcke werden geschickt kombiniert: +- Der vorletzte (vollständige) und der letzte (unvollständige) Block werden vertauscht und kombiniert. +- Die Gesamtlänge des Geheimtexts entspricht exakt der Klartextlänge. + +### 8.7 Padding Oracle Attack + +**Kontext:** CBC-Modus mit PKCS#7-Padding. + +**PKCS#7-Padding:** Fehlen zum letzten Block n Bytes, werden n Bytes mit dem Wert n angehängt (z.B. 3 fehlende Bytes → `03 03 03`). + +**Angriff:** Ein Angreifer kann den Klartext rekonstruieren, **ohne den Schlüssel zu kennen**, wenn: +1. Er beliebige Geheimtexte zur Entschlüsselung einreichen kann +2. Das System **unterschiedliche Fehlermeldungen** für Padding-Fehler vs. andere Fehler zurückgibt (das „Oracle") + +**Ablauf (vereinfacht für einen Block):** +- Der Angreifer modifiziert Bytes des vorherigen Geheimtextblocks und beobachtet, ob das Padding korrekt ist. +- Durch systematisches Ausprobieren kann er Byte für Byte den Klartext ermitteln. + +**Gegenmaßnahmen:** Einheitliche Fehlermeldungen, Encrypt-then-MAC (AEAD), TLS 1.3 (verwendet kein CBC mehr). + +--- + +## 9. Angriffsmodelle & IND-CPA + +### 9.1 Angriffstypen (aufsteigend nach Stärke) + +| Angriffstyp | Fähigkeit des Angreifers | +|---|---| +| **Ciphertext-only** | Kennt nur den Geheimtext | +| **Known Plaintext (KPA)** | Kennt Paare von Klartext und Geheimtext | +| **Chosen Plaintext (CPA)** | Kann beliebige Klartexte verschlüsseln lassen | +| **Adaptive Chosen Plaintext** | Wie CPA, aber Anfragen können adaptiv gestellt werden | +| **Chosen Ciphertext (CCA)** | Kann beliebige Geheimtexte entschlüsseln lassen | +| **Adaptive Chosen Ciphertext (CCA2)** | Wie CCA, adaptiv (stärkstes Modell) | + +### 9.2 IND-CPA-Sicherheit + +**Definition:** Ein Verschlüsselungsschema ist **IND-CPA-sicher** (Indistinguishability under Chosen Plaintext Attack), wenn kein effizienter Angreifer mit nicht-vernachlässigbarem Vorteil entscheiden kann, welche von zwei Nachrichten verschlüsselt wurde. + +**Das „Find-then-Guess"-Spiel:** +1. Challenger erzeugt Schlüssel k und Bit b ∈ {0,1} +2. Angreifer A darf beliebig viele Klartexte verschlüsseln lassen (Orakelzugriff) +3. A wählt zwei Nachrichten M₀, M₁ gleicher Länge +4. Challenger verschlüsselt M_b und gibt Geheimtext c zurück +5. A muss b erraten + +**Sicher, wenn:** `Adv(A) = |Pr[b = b'] - 1/2| ≤ negl(n)` (vernachlässigbar) + +**Warum ECB nicht IND-CPA-sicher ist:** A wählt M₀ = „AA...A" und M₁ = „AA...AB". Im ECB-Modus sind gleiche Blöcke im Klartext auch gleiche Blöcke im Geheimtext → A kann erkennen, welche Nachricht verschlüsselt wurde. + +**Warum Determinismus IND-CPA bricht:** Bei deterministischer Verschlüsselung kann A M₀ selbst verschlüsseln und mit c vergleichen → sofort erkennbar, ob b=0. + +--- + +## 10. MAC, HMAC & AEAD + +### 10.1 Message Authentication Code (MAC) + +**Definition:** 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) +``` + +**Bietet:** Integrität und Authentizität – aber **keine Vertraulichkeit**. + +### 10.2 Angriffsvektoren auf MACs + +| Stärke | Angriff | Beschreibung | +|---|---|---| +| Stärkster | **Total Break** | Angreifer rekonstruiert den Schlüssel oder kann beliebige MACs erzeugen | +| Mittel | **Selective Forgery** | MAC für eine Nachricht, die **vor** dem Angriff gewählt wurde | +| Schwächster | **Existential Forgery** | MAC für **irgendeine** Nachricht erzeugbar (auch sinnlos) | + +### 10.3 Warum naive MAC-Konstruktionen unsicher sind + +1. **Kein Schlüssel:** Angreifer kann eigene Blöcke einfügen +2. **Jeder Block unabhängig MACen** `t_i = MAC(k, m_i)`: Reihenfolge der Blöcke vertauschbar +3. **Mit Blocknummer** `t_i = MAC(k, i || m_i)`: Blöcke aus verschiedenen Nachrichten mischbar +4. **Mit Nachrichten-ID** `t_i = MAC(k, id || i || m_i)`: Letzter Block weglassbar (Truncation) +5. **Länge im letzten Block kodiert:** Dann erst sicher (CBC-MAC-Variante) + +### 10.4 Eigenschaften kryptographischer Hashfunktionen + +1. **Effizienz:** Schnell berechenbar +2. **Einwegfunktion:** Schwer zu invertieren +3. **Kollisionsresistenz:** Schwer, zwei verschiedene Eingaben mit gleichem Hash zu finden +4. **Lawineneffekt:** Kleine Eingabeänderung → große Ausgabeänderung + +### 10.5 HMAC (Hash-MAC) + +**Definition:** HMAC kombiniert eine Hashfunktion mit einem Schlüssel in einer doppelt-genesteten Konstruktion. + +``` +HMAC(k, m) = H( (k ⊕ opad) || H( (k ⊕ ipad) || m ) ) +``` + +- `H` = kryptographische Hashfunktion (z.B. SHA-256) +- `opad` = Outer Padding (0x5c 5c 5c ...) +- `ipad` = Inner Padding (0x36 36 36 ...) + +**Sicherheit:** Durch die Verschachtelung ist HMAC widerstandsfähig gegen Length-Extension-Angriffe. + +### 10.6 Kombination Verschlüsselung + MAC + +| Variante | Schema | Empfehlung | +|---|---|---| +| **Encrypt-then-MAC** | c = Enc(k₁, m); t = MAC(k₂, c) | ✅ Empfohlen (TLS 1.3) | +| **MAC-then-Encrypt** | t = MAC(k₂, m); c = Enc(k₁, m\|t) | ⚠️ Problematisch (Padding Oracle in altem TLS) | +| **Encrypt-and-MAC** | c = Enc(k₁, m); t = MAC(k₂, m) | ⚠️ MAC kann Klartextinfo leaken | + +**Warum Encrypt-then-MAC sicher ist:** Der MAC schützt den Geheimtext – manipulierte Ciphertexte werden **vor** der Entschlüsselung erkannt. + +### 10.7 AEAD (Authenticated Encryption with Associated Data) + +**Definition:** 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) (gibt ⊥ bei Authentifizierungsfehler) +``` + +- `m` = Plaintext (wird verschlüsselt **und** authentifiziert) +- `aad` = Associated Authenticated Data (z.B. IP-/MAC-Adressen, Header – wird **nur authentifiziert**, nicht verschlüsselt) + +**Beispiele:** +- **ChaCha20-Poly1305:** ChaCha20 (Stromchiffre) + Poly1305 (MAC) – Standard in TLS 1.3, WireGuard +- **AES-GCM:** AES im CTR-Mode + GHASH (MAC über GF(2¹²⁸)) – Standard für AES in TLS 1.3 + +**AEAD ist in TLS 1.3 der einzige Standard für Datenintegrität.** + +--- + +## 11. Public-Key-Kryptographie + +### 11.1 Das Schlüsselaustauschproblem + +Bei symmetrischer Kryptographie brauchen beide Parteien denselben geheimen Schlüssel. Das Problem: Wie überträgt man diesen sicher über einen unsicheren Kanal? + +**Merkle Puzzle (1974):** Alice erzeugt n verschlüsselte Rätsel; Bob löst zufällig eines (O(n) Aufwand). Angreifer muss alle n/2 lösen (O(n)). Praktisch ineffizient. + +### 11.2 Diffie-Hellman-Schlüsselaustausch + +**Definition:** Ermöglicht zwei Parteien, über einen **öffentlichen Kanal** ein gemeinsames Geheimnis zu vereinbaren, ohne dieses direkt zu übertragen. + +**Protokoll:** +``` +Öffentlich: Primzahl p, Generator g (Basis) + +Alice wählt a (geheim) → sendet A = g^a mod p +Bob wählt b (geheim) → sendet B = g^b mod p + +Gemeinsames Geheimnis: K = g^(ab) mod p + Alice berechnet: K = B^a mod p = (g^b)^a mod p = g^(ab) mod p + Bob berechnet: K = A^b mod p = (g^a)^b mod p = g^(ab) mod p +``` + +**Sicherheit:** Basiert auf dem **Diskreten-Logarithmus-Problem (DLP)**: Aus g^a mod p ist es schwer, a zu berechnen. + +### 11.3 Diskretes-Logarithmus-Problem (DLP) + +**Definition:** Gegeben Gruppe G, Generator g, Element y = g^x: Bestimme x = log_g(y). + +- **Berechnung von g^x:** effizient – O(log x) Multiplikationen (schnelle Exponentiation) +- **Umkehrung (diskreter Logarithmus):** für große Gruppen **schwer** (kein effizienter klassischer Algorithmus bekannt) + +### 11.4 ModP-Gruppe (Einheitengruppe) + +**Definition:** 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⁰, g¹, ..., g^(p-2)} = ℤ_p*` +- **Fermat'scher kleiner Satz:** `a^(p-1) ≡ 1 (mod p)` für alle a mit ggT(a,p) = 1 +- Für Diffie-Hellman braucht man p mit mindestens **2048 Bit** (heutige Empfehlung) + +### 11.5 Elliptische Kurven (EC) + +Elliptische Kurven bieten dieselbe Sicherheit wie ModP-Gruppen, aber mit **viel kleineren Schlüsseln** (256 Bit ECDH ≈ 3072 Bit DH in klassischer Sicherheit). + +**Kurvendefinition (Weierstraß-Form):** +``` +y² = x³ + ax + b mit 4a³ + 27b² ≠ 0 (keine Singularitäten) +``` + +**Gruppengesetz:** Punkte auf der Kurve bilden eine abelsche Gruppe: +- **Neutrales Element:** Punkt im Unendlichen O +- **Addition P + Q:** Schneide Gerade durch P, Q mit der Kurve; reflektiere dritten Schnittpunkt +- **Verdoppelung 2P:** Tangente an P; reflektiere zweiten Schnittpunkt + +**ECDLP:** Gegeben P und Q = k·P, finde k. Gilt als schwerer als DLP in ModP → kleinere Schlüssel. + +**ECDH:** Wie DH, aber mit Punktmultiplikation statt Exponentiation. + +--- + +## 12. RSA-Kryptosystem + +### 12.1 Schlüsselgenerierung + +``` +1. Wähle zwei große Primzahlen p, q (je 1024–2048 Bit) +2. n = p · q (öffentlicher 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) +``` + +### 12.2 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^(1 mod φ(n)) ≡ m (mod n)`. + +### 12.3 Beispielrechnung + +**Gegeben:** p = 11, q = 13 + +``` +n = 11 · 13 = 143 +φ(n) = 10 · 12 = 120 +Wähle e = 7 (ggT(7, 120) = 1 ✓) +d = 7⁻¹ mod 120 = 103 (denn 7 · 103 = 721 = 6·120 + 1 ✓) + +Öffentlicher Schlüssel: (143, 7) +Privater Schlüssel: (143, 103) + +Verschlüsseln von m = 5: +c = 5^7 mod 143 = 78125 mod 143 = 47 + +Entschlüsseln von c = 47: +m = 47^103 mod 143 = 5 ✓ +``` + +### 12.4 Faktorisierungsproblem + +**Definition:** Gegeben n = p · q (p, q prim), finde p und q. + +- **Multiplikation** p · q → n: effizient, O(log²n) +- **Faktorisierung** n → p, q: schwer (bester klassischer Algorithmus: **Zahlkörpersieb**, subexponentiell, aber nicht polynomial) + +**Wichtig:** Die Sicherheit von RSA basiert auf der Annahme, dass Faktorisierung schwer ist. Es ist jedoch **nicht bewiesen**, dass RSA-Brechen äquivalent zur Faktorisierung ist. + +--- + +## 13. ElGamal-Verschlüsselung + +**Definition:** Auf Diffie-Hellman basierendes Public-Key-Verfahren (Taher Elgamal, 1985). Der Sender macht einen einmaligen DH-Austausch mit dem öffentlichen Schlüssel des Empfängers. + +### Schlüsselgenerierung + +``` +Öffentliche Parameter: zyklische Gruppe G der Ordnung n, Generator α +Privater Schlüssel: a (zufällig, 1 ≤ a ≤ n-1) +Öffentlicher Schlüssel: (α, α^a) +``` + +### Verschlüsselung (probabilistisch) + +``` +Wähle zufälliges k (1 ≤ k ≤ n-1) ← jedes Mal neu! +γ = α^k ← "einmaliger DH-Anteil" des Senders +δ = m · (α^a)^k ← Nachricht maskiert mit DH-Geheimnis +Ciphertext: (γ, δ) +``` + +### Entschlüsselung + +``` +Berechne γ^a = (α^k)^a = α^(ka) ← gemeinsames DH-Geheimnis +m = δ · (γ^a)^(-1) = δ · γ^(-a) +``` + +**Korrektheit:** `δ · γ^(-a) = m · α^(ak) · α^(-ak) = m ✓` + +**Sicherheit:** Basiert auf der **DDH-Annahme** (Decisional Diffie-Hellman). ElGamal ist IND-CPA-sicher, aber **NICHT IND-CCA-sicher** (Malleability: Aus (γ, δ) kann man (γ, δ·m') erzeugen, das m·m' verschlüsselt). + +**Nachteil:** Ciphertext (γ, δ) ist **doppelt so lang** wie die Nachricht. + +--- + +## 14. IND-CCA, IND-CCA2 & Padding + +### 14.1 IND-CCA-Sicherheit + +**Definition:** **Indistinguishability under Chosen Ciphertext Attack** – das stärkste gängige Sicherheitsmodell für Public-Key-Verschlüsselung. + +Erweiterung des IND-CPA-Spiels: Der Angreifer erhält zusätzlich ein **Entschlüsselungsorakel**. + +``` +Phase 1: Angreifer sendet beliebige Ciphertexte und bekommt Klartexte zurück +Challenge: Challenger verschlüsselt M_b → Angreifer bekommt c +Phase 2: Angreifer darf weiter entschlüsseln – ABER nicht c selbst! +``` + +**IND-CCA** (nicht-adaptiv): Entschlüsselungsanfragen nur in Phase 1. +**IND-CCA2** (adaptiv): Entschlüsselungsanfragen in Phase 1 **und** Phase 2 (außer c selbst). + +**Textbook RSA ist NICHT IND-CPA-sicher** (deterministisch!). Mit Padding-Schemata wird IND-CCA2 erreicht. + +### 14.2 OAEP (Optimal Asymmetric Encryption Padding) + +**Definition:** OAEP macht RSA probabilistisch und erreicht IND-CCA2-Sicherheit im Random-Oracle-Modell. + +``` +Eingabe: Nachricht m, zufälliger Seed r + +X = (m || 0...0) ⊕ G(r) (G = Pseudozufallsfunktion / Mask Generation Function) +Y = r ⊕ H(X) (H = Hashfunktion) + +RSA-Input: (X || Y) +Verschlüsselung: c = (X||Y)^e mod n +``` + +In der Praxis: **RSA-OAEP** aus PKCS#1 v2.x. + +### 14.3 RSA-PSS (Probabilistic Signature Scheme) + +**Warum RSA-PSS nötig ist:** Rohes RSA ohne Padding ist anfällig für **Existential Forgery**: Ein Angreifer wählt eine beliebige Signatur s und berechnet „die Nachricht" x = s^e mod n. Das Paar (x, s) ist eine gültige Signatur! + +**RSA-PSS verhindert das durch Padding vor der Signatur:** +1. `mHash = H(M)` +2. `M' = [8×0x00 | mHash | salt]` → nochmals gehasht → `H` +3. `DB = [PS | 0x01 | salt]` +4. `maskedDB = DB ⊕ MGF(H)` (Mask Generation Function) +5. `EM = [maskedDB | H | 0xbc]` +6. Signatur: `s = EM^d mod n` + +--- + +## 15. Digitale Signaturen + +### 15.1 Grundprinzip + +**Definition:** Eine digitale Signatur ermöglicht **Integrität**, **Authentizität** und **Non-Repudiation** (Nicht-Abstreitbarkeit). + +**Ablauf:** +- **Signieren:** `σ = sign(m, sk)` – mit privatem Schlüssel signieren +- **Verifizieren:** `verify(σ, m, pk) → {true, false}` – mit öffentlichem Schlüssel prüfen + +**Formale Algorithmen:** +``` +keygen(1^k) → (sk, pk) Schlüsselpaar erzeugen +sign(m, sk) → σ Signatur erzeugen +verify(σ, m, pk) → d Signatur verifizieren +``` + +**Wichtig:** Private Key ≠ Public Key! Der Sender signiert mit dem **privaten Schlüssel**, der Empfänger verifiziert mit dem **öffentlichen Schlüssel**. (Umgekehrt zur Verschlüsselung!) + +### 15.2 Angriffsvektoren auf Signaturen + +| Angriff | Beschreibung | +|---|---| +| **Total Break** | Angreifer leitet den privaten Schlüssel ab → kann beliebige Signaturen erzeugen | +| **Selective Forgery** | Gültige Signatur für eine Nachricht, die **vor** dem Angriff gewählt wurde | +| **Existential Forgery** | Gültige Signatur für **irgendeine** Nachricht (auch sinnlose) | + +### 15.3 RSA-Signatur + +``` +Signatur: s = m^d mod n (mit privatem Schlüssel d) +Verifikation: m' = s^e mod n (mit öffentlichem Schlüssel e) +Gültig wenn: m' = m +``` + +**Existential Forgery gegen Textbook RSA:** +Oscar wählt s → berechnet x = s^e mod n → präsentiert (x, s) als gültige Signatur. Alice verifiziert: s^e ≡ x ✓. **Deshalb ist RSA-PSS notwendig.** + +### 15.4 ECDSA (Elliptic Curve Digital Signature Algorithm) + +**Signieren** (Nachricht m, privater Schlüssel d_A, Basispunkt G, Gruppenordnung n): +``` +1. e = H(m) (Hash der Nachricht) +2. z = linkste L_n Bits von e +3. Wähle zufälliges k ∈ [1, n-1] +4. (x₁, y₁) = k × G (Skalarmultiplikation auf EC) +5. r = x₁ mod n +6. s = k⁻¹ · (z + r · d_A) mod n +Signatur: (r, s) +``` + +**Verifizieren** (mit öffentlichem Schlüssel Q_A = d_A · G): +``` +1. e = H(m), z = linkste L_n Bits +2. u₁ = z · s⁻¹ mod n +3. u₂ = r · s⁻¹ mod n +4. (x₁, y₁) = u₁ × G + u₂ × Q_A +5. Gültig wenn r ≡ x₁ (mod n) +``` + +### 15.5 Fiat-Shamir Transformation + +**Definition:** Die Fiat-Shamir-Transformation (Fiat & Shamir, 1986) wandelt ein **interaktives Zero-Knowledge-Protokoll** in einen **nicht-interaktiven Beweis** (oder eine digitale Signatur) um. + +**Grundidee:** Die zufällige Challenge des Verifiers wird durch den Output einer **kryptographischen Hashfunktion** ersetzt: +``` +Challenge = H(Commitment, public_data) [bei ZK-Proof] +Challenge = H(Commitment, Nachricht) [bei Signatur] +``` + +**Interaktives Protokoll → Nicht-interaktiv:** + +*Original (interaktiv, 3 Schritte):* +1. Prover sendet Commitment C +2. Verifier sendet zufällige Challenge ch +3. Prover sendet Response r + +*Fiat-Shamir (nicht-interaktiv):* +1. Prover berechnet Commitment C +2. Prover berechnet: `ch = H(C, öffentliche_Parameter)` +3. Prover berechnet Response r +4. Beweis: `(C, ch, r)` – kein Verifier nötig! + +**Signaturschema aus ZK-Proof:** +- Die Nachricht wird in den Hash eingebaut: `ch = H(C, m)` +- Die Signatur ist das Tripel `(C, r)` (ch kann rekonstruiert werden) +- Sicherheit hängt von der Random-Oracle-Annahme ab (H verhält sich wie eine ideale Zufallsfunktion) + +**Beispiel – Schnorr-Signatur (aus DLP-ZK-Proof):** +``` +Schlüsselpaar: sk = x, pk = g^x mod p +Signieren von m: + r = g^k mod p (zufälliges k) + e = H(r, m) + s = k - x·e mod (p-1) +Signatur: (s, e) + +Verifizieren: + r' = g^s · (g^x)^e mod p + Gültig wenn H(r', m) = e +``` + +--- + +## 16. Zertifikate & PKI + +### 16.1 Das Kernproblem + +> Wie kann Bob sicher sein, dass ein Public Key wirklich zu Alice gehört und nicht zu einem Angreifer? + +**Man-in-the-Middle-Angriff:** Oscar gibt sich sowohl gegenüber Alice als auch Bob als der jeweils andere aus und führt zwei separate DH-Austausche durch. Ohne Authentifizierung ist dies undetektierbar. + +### 16.2 Certificate Authority (CA) und Zertifikate + +**Lösung:** Eine **vertrauenswürdige Zertifizierungsstelle (CA)** bestätigt die Identität und signiert den Public Key. + +**Inhalt eines X.509-Zertifikats:** +- Name, Organisation, Land +- Gültigkeitszeitraum (von/bis) +- Public Key des Inhabers +- Algorithmus und Parameter +- **Digitale Signatur der CA** + +**Funktionsweise:** +1. Alice generiert Schlüsselpaar (sk, pk) +2. Alice gibt pk an die CA, beweist ihre Identität +3. CA erzeugt Zertifikat: `Cert = Sign(sk_CA, ID_Alice || pk_Alice || Gültigkeit)` +4. Jeder, der CA's Public Key kennt und ihr vertraut, kann das Zertifikat verifizieren + +### 16.3 Zertifikatskette (Chain of Trust) + +``` +Endnutzer-Zertifikat (z.B. google.com) + ↑ signiert von +Intermediate CA (z.B. Google Trust Services) + ↑ signiert von +Root CA (z.B. GlobalSign, DigiCert) + ↑ selbst-signiert (Vertrauensanker, im Browser vorinstalliert) +``` + +**Root CAs** sind die letzte Vertrauensbasis. Ihre öffentlichen Schlüssel sind in Betriebssystemen und Browsern vorinstalliert. + +### 16.4 Zertifikatswiderruf + +**CRL (Certificate Revocation List):** +- Liste aller zurückgezogenen Zertifikate, periodisch von der CA veröffentlicht +- Nachteil: Kein Echtzeit-Update, kann veraltet sein + +**OCSP (Online Certificate Status Protocol):** +- Echtzeitabfrage des Zertifikatstatus bei einem **OCSP-Responder** (Server der CA) +- Vorteil: Aktuell; Nachteil: Datenschutz (CA erfährt, welche Sites besucht werden) +- **OCSP Stapling:** Server fragt selbst den Status ab und hängt die Antwort an den TLS-Handshake + +--- + +## 17. TLS (Transport Layer Security) + +### 17.1 Einordnung im OSI-Modell + +TLS liegt zwischen **Anwendungsschicht** und **Transportschicht** (OSI Layer 4/5): +``` +Anwendung (Layer 7) → TLS → TCP (Layer 4) → IP (Layer 3) → ... +``` +TLS läuft **über TCP**, nicht im Kernel/Netzwerkstack. + +### 17.2 TLS-Ziele (RFC 8446, TLS 1.3) + +- **Authentifizierung:** Server wird immer authentifiziert, Client optional +- **Vertraulichkeit:** Daten nur für Endpunkte sichtbar +- **Integrität:** Manipulationen werden erkannt + +### 17.3 TLS-Komponenten + +| Komponente | Aufgabe | +|---|---| +| **Record Layer** | Fragmentierung, Authentifizierung, Verschlüsselung der Nutzdaten | +| **Handshake Protocol** | Aushandeln von Algorithmen, Zertifikatsaustausch, Key Exchange | +| **Alert Protocol** | Fehlermeldungen und Verbindungsabschluss | +| **Change Cipher Spec** | (nur Kompatibilität in TLS 1.3) | + +### 17.4 TLS 1.3 Handshake (vereinfacht) + +``` +Client Server + ClientHello (supported ciphers, + key_share, random) → + ← ServerHello (chosen cipher, key_share) + ← {EncryptedExtensions} + ← {Certificate} + ← {CertificateVerify} + ← {Finished} + {Finished} → + [Application Data] ↔ [Application Data] +``` + +Key Exchange erfolgt mit **(EC)DHE** – Forward Secrecy ist damit garantiert. + +### 17.5 TLS 1.3 Sicherheitsmerkmale + +- Nur **AEAD-Cipher** erlaubt: AES-GCM, AES-CCM, ChaCha20-Poly1305 +- Kein CBC, kein RC4, kein 3DES +- **Perfect Forward Secrecy (PFS)** durch ephemere DH-Schlüssel +- Reduzierte RTT (Round-Trip-Time) durch 0-RTT oder 1-RTT + +### 17.6 TLS-Versionshistorie + +| Version | Jahr | Status | +|---|---|---| +| SSL 2.0 | 1995 | Veraltet (2011) | +| SSL 3.0 | 1996 | Veraltet (2015) | +| TLS 1.0 | 1999 | Veraltet (2021) | +| TLS 1.1 | 2006 | Veraltet (2021) | +| TLS 1.2 | 2008 | Noch genutzt | +| **TLS 1.3** | **2018** | **Aktuell** | + +--- + +## 18. IPSec + +**Einordnung im OSI-Modell:** IPSec arbeitet auf **Layer 3 (Netzwerkschicht)** – direkt im IP-Stack. + +**Vergleich mit TLS:** TLS schützt Anwendungsdaten (Layer 7), IPSec schützt IP-Pakete (Layer 3). + +### Betriebsmodi + +| Modus | Beschreibung | +|---|---| +| **Transportmodus** | Nur der Payload des IP-Pakets wird geschützt; IP-Header bleibt sichtbar | +| **Tunnelmodus** | Das gesamte ursprüngliche IP-Paket wird verschlüsselt und in ein neues IP-Paket eingebettet (Gateway-zu-Gateway, VPN) | + +### Protokolle + +| Protokoll | Bietet | Schützt | +|---|---|---| +| **AH (Authentication Header)** | Integrität + Authentizität | Header + Daten (kein Payload-Encrypt) | +| **ESP (Encapsulating Security Payload)** | Verschlüsselung + Authentifizierung | Nur Payload-Daten | + +--- + +## 19. Quantencomputer & Kryptographie + +### 19.1 Quantenmechanische Grundlagen + +| Phänomen | Bedeutung für Krypto | +|---|---| +| **Superposition** | Qubit = gleichzeitig 0 und 1 → parallele Berechnungen | +| **Verschränkung (Entanglement)** | Qubits sind korreliert, unabhängig von Distanz | +| **Nondeterminismus** | Messung ergibt zufälliges Ergebnis → Echte Zufallszahlengeneratoren (QRNG) | +| **No-Cloning-Theorem** | Quantenzustände können nicht kopiert werden → Sicherheit von QKD | + +### 19.2 BB84-Protokoll (Quantum Key Distribution) + +**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. **Öffentlicher Abgleich:** Alice und Bob vergleichen ihre Basen (nicht die Bits!) +4. Bits mit **übereinstimmenden Basen** ergeben den **Sifted Key** (ca. 50% der Bits) +5. Stichproben prüfen Abhören: Eve-Messung stört den Quantenzustand + +**Sicherheit:** Jede Messung durch Eve verändert den Quantenzustand (Messprinzip). Bei ~25% der Bits führt Eves Abhören zu einem Fehler → Eve ist **nachweisbar**. + +**No-Cloning-Theorem:** Quantenzustände können nicht kopiert werden → klassische Repeater funktionieren nicht. + +### 19.3 Shors Algorithmus + +**Peter Shor (1994):** Löst **ganzzahlige Faktorisierung** und das **Diskrete-Logarithmus-Problem** in **polynomialer Zeit** auf einem Quantencomputer. + +**Konsequenz für klassische Kryptographie:** + +| Algorithmus | Klassische Sicherheit | Sicherheit mit Quantencomputer | +|---|---|---| +| RSA-3072 | 128 Bit | **gebrochen (0 Bit)** | +| DH-3072 | 128 Bit | **gebrochen (0 Bit)** | +| ECDH-256 | 128 Bit | **gebrochen (0 Bit)** | +| ECDSA-256 | 128 Bit | **gebrochen (0 Bit)** | + +**Alle auf DLP oder Faktorisierung basierenden Verfahren werden durch Shor wertlos.** + +### 19.4 Grovers Algorithmus + +**Lov Grover:** Findet ein Element in einer Datenbank der Größe N in **O(√N)** Schritten (statt O(N) klassisch). + +**Konsequenz für symmetrische Kryptographie:** Effektive Schlüssellänge wird **halbiert**. + +| Algorithmus | Klassische Sicherheit | Mit Grover | +|---|---|---| +| AES-128 | 128 Bit | **64 Bit** (unsicher!) | +| AES-256 | 256 Bit | 128 Bit ✓ (noch sicher) | +| SHA-256 | 256 Bit* | 128 Bit* ✓ | + +**Gegenmaßnahme:** Schlüssellängen **verdoppeln** (AES-256 statt AES-128). + +### 19.5 Simons Algorithmus + +**Simons Problem:** Gegeben eine Funktion f mit einer verborgenen Periode s, finde s. +- Klassisch: **Ω(2^(n/2))** Anfragen nötig +- Quantenalgorithmus: **O(n)** Anfragen (exponentiell schneller) + +**Konsequenz:** Viele klassische kryptographische Konstruktionen werden durch Simons Algorithmus gebrochen (selbst wenn Grover/Shor nicht anwendbar sind): + +Durch quantenbasierte Angriffe sind gebrochen: Even-Mansour, 3-Runden-Feistel, LRW, CBC-MAC, GMAC, PMAC, GCM, OCB und viele weitere symmetrische Konstruktionen. + +--- + +## 20. Post-Quantum Kryptographie (PQC) + +### 20.1 Warum PQC? – Moscas Theorem + +Drei Zeitparameter: +- **x** = Wie lange müssen heutige Daten sicher bleiben? +- **y** = Wie lange dauert die Migration auf quantensichere Lösungen? +- **z** = Wann gibt es kryptographisch relevante Quantencomputer? + +> **Moscas Theorem:** Falls **x + y > z**, muss **jetzt** gehandelt werden. + +**„Harvest now, decrypt later":** Angreifer sammeln heute verschlüsselte Daten und entschlüsseln sie, sobald Quantencomputer verfügbar sind. + +### 20.2 PQC-Strategien + +| Ansatz | Basis | Vorteil | Nachteil | +|---|---|---|---| +| **Hash-based** | Nur kryptographische Hashfunktionen | Sehr gut verstanden, konservative Sicherheit | Signaturen sind groß, Schlüsselpaare oft einmalig | +| **Lattice-based (Gitter)** | Schwere Gitterprobleme (LWE, SIS) | Beste Performanz, stärkstes theoretisches Fundament | Komplex | +| **Code-based** | Schweres Dekodierungsproblem | Bewährt seit 1978 (McEliece) | Große Schlüssel | +| **Multivariate** | Unlösbarkeit quadratischer Gleichungssysteme (MQ-Problem) | Sehr schnelle Signaturen | Große Schlüssel, mehrere gebrochen | +| **Isogenien** | Schwierigkeit von Isogenieberechnungen | Kleine Schlüssel | SIKE 2022 gebrochen! | +| **MPC in the Head** | Sicherheit von ZK-Proofs | Minimale Annahmen | Größere Signaturen | + +### 20.3 Hash-basierte Signaturen + +**Grundprinzip:** Öffentlicher Schlüssel = Hash-Werte h(x)||h(y); Privater Schlüssel = (x, y). + +**Lamport-OTS (One-Time Signature):** Einmalsignatur nur auf Basis von OWFs. Schlüssel darf nur **einmal** verwendet werden. + +**Merkle-Baum:** Viele OTS-Schlüssel werden in einem binären Hash-Baum organisiert. Die Wurzel ist der öffentliche Schlüssel. Ein **Authentifizierungspfad** ermöglicht die Verifikation einzelner Blätter. + +**XMSS/SPHINCS+:** Hierarchische Baumstrukturen für mehrfache Signaturen. **SPHINCS+** ist NIST-standardisiert. + +### 20.4 Gitter-basierte Kryptographie (Lattice-based) + +**Grundidee:** Gitter sind regelmäßige Punktgitter im n-dimensionalen Raum, aufgespannt durch Basisvektoren. + +**Schwere Gitterprobleme:** +- **SVP (Shortest Vector Problem):** Finde den kürzesten Nicht-Null-Vektor im Gitter +- **CVP (Closest Vector Problem):** Finde den nächsten Gitterpunkt zu einem gegebenen Punkt +- **GapSVP_γ:** Entscheidungsversion von SVP mit Approximationsfaktor γ + +**LWE (Learning With Errors):** Gegeben verrauschte Skalarprodukte `bᵢ ≈ ⟨aᵢ, s⟩ mod q`, finde s. Gilt als quantenresistentes schweres Problem. + +**Worst-Case-zu-Average-Case-Reduktion:** Der entscheidende Vorteil: Wenn LWE im Durchschnitt leicht wäre, wäre GapSVP im schlimmsten Fall leicht. Das LWE-Problem ist daher so schwer wie das schlimmste Gitterproblem. + +**Regev's Public-Key-Kryptosystem (LWE-Beispiel):** +``` +Privater Schlüssel: s ∈ ℤ_q^n (zufällig) +Öffentlicher Schlüssel: m Paare (aᵢ, bᵢ) mit bᵢ = ⟨aᵢ, s⟩/q + eᵢ + (eᵢ = kleiner Fehler aus Fehlerverteilung χ) + +Verschlüsselung von Bit x: + Wähle zufällige Teilmenge S ⊆ [m] + Enc(x) = (Σᵢ∈S aᵢ, x/2 + Σᵢ∈S bᵢ) + +Entschlüsselung: + Prüfe ob b - ⟨a, s⟩/q näher an 0 (→ x=0) oder an 1/2 (→ x=1) +``` + +### 20.5 Isogenien-basierte Kryptographie + +**Isogenie:** Ein Gruppenhomomorphismus `φ: E → E'` zwischen elliptischen Kurven, dargestellt durch rationale Funktionen. + +**SIDH-Schlüsselaustausch (analog zu DH):** +- Alice berechnet Isogenie Φ_A(E) und sendet sie an Bob +- Bob berechnet Isogenie Φ_B(E) und sendet sie an Alice +- Gemeinsames Geheimnis: j-Invariante von Φ'_A(Φ_B(E)) = Φ'_B(Φ_A(E)) + +⚠️ **SIKE (konkrete Instanz) wurde im Juli 2022 vollständig gebrochen** – alle Isogenien-basierten Verfahren müssen neu bewertet werden. + +### 20.6 Code-basierte Kryptographie + +**Grundidee:** Sicherheit beruht auf der Schwierigkeit des **Syndrome-Decoding-Problems** (allgemeine Fehlerkorrektur ist NP-hart). + +**McEliece-Kryptosystem (1978):** +- Öffentlicher Schlüssel: `H* = P · H · S` (permutierte und transformierte Prüfmatrix) +- Verschlüsselung: `c = m · H*` + absichtliche Fehler +- Entschlüsselung: Nur Besitzer von P, H, S kann effizient dekodieren + +### 20.7 NIST PQC-Standardisierung + +**Timeline:** +- 2017: Ausschreibung mit **69 Kandidaten** (1. Runde) +- 2022: Auswahl der ersten Standards + +**Ausgewählte Algorithmen:** +| Algorithmus | Typ | Basis | +|---|---|---| +| **CRYSTALS-Kyber** (ML-KEM) | Key Encapsulation Mechanism | Gitter (Module-LWE) | +| **CRYSTALS-Dilithium** (ML-DSA) | Digitale Signatur | Gitter (Module-LWE) | +| **Falcon** | Digitale Signatur | Gitter (NTRU) | +| **SPHINCS+** (SLH-DSA) | Digitale Signatur | Hash-basiert | + +--- + +## 21. Homomorphe Verschlüsselung + +### 21.1 Grundidee + +**Definition:** Homomorphe Verschlüsselung ermöglicht Berechnungen auf **verschlüsselten Daten**, ohne diese zu entschlüsseln. + +``` +Enc(m₁) ⋆ Enc(m₂) = Enc(m₁ ∘ m₂) +``` +(⋆ = Operation auf Chiffretexten; ∘ = entsprechende Operation auf Klartexten) + +**Kerngleichung:** Der Verarbeitende erhält `Enc(f(m))`, ohne m jemals zu sehen. + +**Anwendung:** Cloud Computing – Daten bleiben beim Cloud-Anbieter verschlüsselt, werden aber trotzdem verarbeitet. + +### 21.2 Klassifizierung + +| Typ | Abk. | Fähigkeit | Performance | +|---|---|---|---| +| **Partially Homomorphic Encryption** | PHE | Eine Operation unbeschränkt oft | Hoch | +| **Somewhat Homomorphic Encryption** | SWHE | Zwei Operationen, mindestens eine beschränkt | Mittel | +| **Fully Homomorphic Encryption** | FHE | Beliebige Berechnungen, unbeschränkt | Niedrig | + +### 21.3 RSA als Beispiel für PHE (multiplikativ homomorph) + +``` +E(M₁) · E(M₂) = M₁^e · M₂^e mod n = (M₁·M₂)^e mod n = E(M₁·M₂) +``` +RSA ist **multiplikativ homomorph** – beliebig viele Multiplikationen auf Chiffretexten möglich. + +### 21.4 Paillier-Kryptosystem (additiv homomorph, fast wie RSA) + +**Definition:** Paillier (1999) ist ähnlich wie RSA aufgebaut, aber **additiv homomorph** statt multiplikativ. + +**Schlüsselerzeugung:** +``` +n = p · q (zwei große Primzahlen) +g = n + 1 (öffentlicher Parameter) +λ = φ(n) = (p-1)(q-1) +μ = φ(n)⁻¹ mod n (privater Schlüssel) + +Öffentlicher Schlüssel: (n, g) +Privater Schlüssel: (n, λ, μ) +``` + +**Verschlüsselung:** +``` +c = g^m · r^n mod n² (r zufällig, ggT(r,n) = 1) +``` + +**Entschlüsselung:** +``` +m = L(c^λ mod n²) · μ mod n mit L(x) = (x-1)/n +``` + +**Homomorphe Addition:** +``` +D( E(m₁, r₁) · E(m₂, r₂) mod n² ) = m₁ + m₂ mod n +``` +Das **Produkt zweier Chiffretexte** entspricht der **Summe der Klartexte**. + +**Vergleich Paillier vs. RSA:** +- Beide basieren auf Faktorisierungsproblem +- Paillier: additiv homomorph; RSA: multiplikativ homomorph +- Paillier: probabilistisch; RSA (ohne Padding): deterministisch +- Paillier: Chiffretexte liegen in ℤ_{n²} statt ℤ_n + +--- + +## 22. Multi-Party Computation (MPC) + +### 22.1 Ziel und Motivation + +**Definition:** MPC ermöglicht mehreren Parteien, gemeinsam eine Funktion **f(x₁, x₂, ..., x_n)** zu berechnen, ohne dass irgendeine Partei die Eingaben der anderen erfährt. + +**Yao's Millionärsproblem (1982):** Zwei Millionäre wollen herausfinden, wer reicher ist, ohne ihr Vermögen preiszugeben. + +**Ideales Modell:** Alle Parteien senden ihre Eingaben an eine vertrauenswürdige dritte Partei (Trusted Third Party), die f berechnet und das Ergebnis zurückgibt. **Ziel von MPC:** Das gleiche Ergebnis ohne vertrauenswürdige dritte Partei erreichen. + +### 22.2 Oblivious Transfer (OT) + +**Definition:** Ein Protokoll, bei dem der **Sender nicht weiß, welche** seiner Nachrichten der Empfänger erhalten hat. + +**Drei Varianten:** + +| Variante | Beschreibung | +|---|---| +| **OT (Rabin, 1981)** | Alice hat Bit b. Bob erhält b mit Prob. 1/2. Alice weiß nicht, ob Bob b erhalten hat. | +| **1-out-of-2 OT** | Alice hat b₀, b₁. Bob erhält genau eines (b_k). Alice weiß nicht, welches. | +| **p-OT** | Wie OT, aber Empfang mit beliebiger Wahrscheinlichkeit p. | + +**Wofür ist OT gut?** +- Fundamentaler Baustein für MPC-Protokolle +- Ermöglicht es Parteien, Informationen auszutauschen, ohne vollständigen Einblick zu geben +- Garbled Circuits benötigen OT für Bobs Eingaben + +**DH-basiertes 1-out-of-2 OT-Protokoll:** +``` +Sender hat (M₀, M₁), Empfänger hat Auswahlbit c + +Sender wählt a, sendet A = g^a +Empfänger wählt b: + Falls c=0: sendet B = g^b + Falls c=1: sendet B = A · g^b = g^(a+b) + +Sender berechnet: + k₀ = H(B^a) k₁ = H((B/A)^a) + Sendet: E(k₀, M₀), E(k₁, M₁) + +Empfänger berechnet: + k_R = H(A^b) + Falls c=0: k_R = H(g^(ab)) = k₀ → entschlüsselt M₀ + Falls c=1: k_R = H(g^(ab)) = k₁ → entschlüsselt M₁ +``` + +### 22.3 Garbled Circuits + +**Definition:** Garbled Circuits (Yao, 1986) ermöglichen es, eine beliebige Boolesche Funktion als verschlüsselten Schaltkreis zwischen zwei Parteien sicher auszuwerten. + +**Ablauf:** + +1. **Alice (Garbler) erstellt den verschlüsselten Schaltkreis:** + - Für jeden Draht werden zwei zufällige Labels erzeugt: L^0_i (für Bit 0) und L^1_i (für Bit 1) + - Für jedes Gatter (AND, OR, XOR): Die Wahrheitstabelle wird mit den Input-Labels verschlüsselt + - Die Zeilen der Wahrheitstabelle werden **zufällig permutiert** (kein Bit-Leak) + +2. **Bob (Evaluator) wertet aus:** + - Empfängt den „garbled circuit" + - Kann pro Gatter genau **eine** Zeile entschlüsseln (die passende zu seinen Labels) + - Lernt nur das Endergebnis, nicht die Zwischenwerte + +3. **Eingaben:** + - **Alice** gibt ihre Labels direkt weiter + - **Bob** erhält seine Eingabe-Labels via **Oblivious Transfer** (Alice erfährt nicht, welche Bits Bob hat) + +**Sicherheit:** +- Alice lernt nichts über Bobs Eingabe (durch OT) +- Bob lernt nichts über Alices Eingabe (Labels verraten keine Bits) +- Beide lernen nur f(A, B) + +**Beispiel:** Boole'sche Funktion `f = AND(a, b)` als Garbled Circuit: +- Drähte erhalten Labels: Wire_a: (L^0_a, L^1_a); Wire_b: (L^0_b, L^1_b) +- Ausgabe-Labels: (L^0_out, L^1_out) +- Verschlüsselte Wahrheitstabelle (permutiert): + - `Enc(L^1_a, L^1_b, L^1_out)` (1 AND 1 = 1) + - `Enc(L^0_a, L^1_b, L^0_out)` (0 AND 1 = 0) + - usw. + +### 22.4 Additive Secret Sharing + +**Definition:** Ein Geheimnis x wird so in n Anteile (Shares) aufgeteilt, dass jede echte Teilmenge der Shares **keine Information** über x verrät. + +**Aufteilen (n Parteien):** +``` +Wähle x₁, x₂, ..., x_{n-1} zufällig +Setze x_n = x - (x₁ + ... + x_{n-1}) mod q +Verteile [x] = (x₁, ..., x_n) +``` + +**Rekonstruktion:** `x = x₁ + x₂ + ... + x_n mod q` + +**Sicherheit:** Informationstheoretisch – auch mit unbegrenzter Rechenleistung lässt sich aus n-1 Shares nichts ableiten. + +**Addition trivial möglich:** +``` +[x + y] = ([x] + [y]) = (x₁+y₁, ..., x_n+y_n) ← jede Partei addiert lokal +[x + c] = (x₁+c, x₂, ..., x_n) ← nur der erste Share wird angepasst +``` + +**Multiplikation NICHT trivial:** Das Produkt zweier Shares ergibt kein Share des Produkts. Lösung: **Beaver Triples**. + +### 22.5 Beaver Triples + +**Definition:** Ein Beaver Triple ist ein vorberechnetes Tripel `([a], [b], [c])` mit `c = a · b`, wobei a und b zufällig sind. + +**Multiplikationsprotokoll für [x · y]:** +1. Parteien öffnen (veröffentlichen): `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`: öffentliche Konstante + - `d·[b]` und `e·[a]`: Multiplikation mit öffentlicher Konstante (einfach) + - `[c]`: bereits als Share vorhanden + +**Vorteil:** Die aufwändige Erzeugung der Triples kann in einer **Offline-Phase** vor der eigentlichen Berechnung stattfinden (z.B. mit Homomorpher Verschlüsselung oder OT). + +**SPDZ-Protokoll (2012):** Kombiniert Additive Secret Sharing, Beaver Triples und MACs auf den Shares. Sicher gegen aktive Angreifer, die bis zu n-1 Parteien kontrollieren. + +--- + +## 23. Zero Knowledge Proofs (ZKP) + +### 23.1 Was ist Zero Knowledge? + +**Definition:** Ein Zero-Knowledge-Beweis ermöglicht es einem **Prover**, einem **Verifier** zu beweisen, dass eine Aussage wahr ist, ohne **irgendwelche weiteren Informationen** preiszugeben – insbesondere nicht das Geheimnis, das die Wahrheit belegt. + +**Motivationsbeispiele:** +- „Ich bin älter als 18" beweisen, ohne das Geburtsdatum preiszugeben +- „Ich kenne die Lösung dieses Rätsels" beweisen, ohne die Lösung zu zeigen +- „Ich habe die Signatur der Nachricht" beweisen, ohne den privaten Schlüssel zu zeigen + +### 23.2 Drei Eigenschaften + +| Eigenschaft | Bedeutung | Beschreibung | +|---|---|---| +| **Completeness (Vollständigkeit)** | Wenn die Aussage wahr ist, überzeugt der Prover den Verifier | Ein ehrlicher Prover mit dem Geheimnis wird immer akzeptiert | +| **Soundness (Korrektheit)** | Wenn die Aussage falsch ist, kann kein Prover den Verifier überzeugen | Ein betrügender Prover wird höchstens mit vernachlässigbarer Wahrscheinlichkeit akzeptiert | +| **Zero Knowledge** | Der Verifier lernt nichts außer der Tatsache, dass die Aussage wahr ist | Das Transkript des Protokolls kann vom Verifier selbst simuliert werden | + +### 23.3 Beispiel: Graph-Isomorphismus + +**Problem:** Prover kennt einen Isomorphismus π zwischen zwei Graphen G₀ und G₁ (d.h. G₁ = π(G₀)) und möchte das beweisen, ohne π preiszugeben. + +**Protokoll (eine Runde):** +1. **Prover** wählt zufällige Permutation σ; berechnet H = σ(G_b) für zufälliges b ∈ {0,1}; sendet H +2. **Verifier** sendet Challenge-Bit c ∈ {0,1} +3. **Prover** antwortet: + - Falls c = b: sendet σ (H = σ(G_b)) + - Falls c ≠ b: sendet σ ∘ π (bzw. σ ∘ π⁻¹) +4. **Verifier** prüft: Bildet die Antwort H korrekt auf G_c ab? + +**Zero Knowledge?** Ja – der Prover wählt b zufällig. Der Verifier sieht immer nur eine zufällige Permutation eines der Graphen, was er selbst hätte erzeugen können. + +**Soundness?** Ja – wenn G₀ und G₁ nicht isomorph sind, kann der Prover für genau eines von b=c und b≠c antworten. In 50% der Fälle wird er erwischt. Nach k Runden: Betrugswahrscheinlichkeit = (1/2)^k. + +### 23.4 Diskreter Logarithmus als ZK-Proof (Schnorr-Protokoll) + +**Problem:** Prover kennt x mit g^x = h mod p (diskreter Logarithmus). + +**Protokoll:** +``` +1. Prover wählt zufälliges r, berechnet Commitment: a = g^r mod p → sendet a +2. Verifier sendet zufällige Challenge c +3. Prover antwortet: z = r + c·x mod (p-1) +4. Verifier prüft: g^z ≡ a · h^c (mod p) +``` + +**Korrektheit:** `g^z = g^(r + cx) = g^r · (g^x)^c = a · h^c ✓` + +**Zero Knowledge:** Simulierbar ohne x (Simulator wählt z und c zufällig, berechnet a = g^z / h^c rückwärts). + +### 23.5 ZK-Proof für weitere Probleme + +| Problem | Öffentlich | Geheim | +|---|---|---| +| Graph-Isomorphismus | G₀, G₁ | Isomorphismus π | +| Diskreter Logarithmus | g, h = g^x | x | +| Quadratischer Rest | n, y | x mit x² ≡ y mod n | +| Signatur-Schema | Public Key | Secret Key | + +### 23.6 Fiat-Shamir Transformation (→ Signaturschema) + +*(Vollständig beschrieben in Abschnitt 15.5)* + +**Kernidee:** Challenge = H(Commitment, Nachricht). Macht interaktive ZK-Proofs nicht-interaktiv und ermöglicht digitale Signaturen aus ZK-Proofs. + +### 23.7 MPC in the Head + +**Definition:** Eine Technik, um Zero-Knowledge-Beweise aus MPC-Protokollen zu konstruieren. + +**Idee:** +1. Prover **simuliert** ein MPC-Protokoll im Kopf (spielt alle Parteien selbst) +2. Teilt sein Geheimnis in Shares auf und führt das Protokoll virtuell durch +3. **Committet** auf alle Transkripte der virtuellen Parteien +4. Verifier wählt eine Teilmenge der Parteien aus → Prover öffnet deren Transkripte +5. **Zero Knowledge:** Verifier sieht nur einen Teil → kann Geheimnis nicht rekonstruieren +6. **Soundness:** Prover hat sich durch Commitments festgelegt → kein Betrug möglich + +**Vorteil:** Jedes MPC-Protokoll kann automatisch in einen ZK-Proof umgewandelt werden. Grundlage für PICNIC (Post-Quantum-Signaturschema). + +--- + +## 24. Differential Privacy + +### 24.1 Motivation und Kernproblem + +**Problem:** Wie kann man statistische Analysen auf sensiblen Daten veröffentlichen, ohne Individuen zu identifizieren? + +**Naives Beispiel:** In einer Umfrage „Haben Sie schon einmal gestohlen?" lügen Befragte aus Angst vor Konsequenzen. + +### 24.2 Randomized Response + +**Lösung:** **Münzwurf-Technik** für plausible Abstreitbarkeit. + +**Protokoll:** +1. Befragter wirft eine Münze (privat) +2. **Kopf** → Wahrheit sagen +3. **Zahl** → Lügen (entgegengesetzte Antwort) + +**Analyse:** In 3/4 der Fälle steht die richtige Antwort (Kopf+Ja oder Zahl+Nein für einen Nein-Sager). + +**Rückrechnung** des echten „Ja"-Anteils: +``` +Echter "Ja"-Anteil = 2 × (Gemessener "Ja"-Anteil - 0,25) +``` + +**Beispiel:** 37,5% gemessene „Ja"-Antworten → echter Anteil = 2 × (0,375 - 0,25) = **25%** + +**Vorteil:** Jede individuelle Antwort ist **plausibel abstreitbar** – niemand kann beweisen, ob eine Person die Wahrheit sagte. + +### 24.3 Formale Definition (ε-Differential Privacy) + +**Definition:** Ein Mechanismus M erfüllt **ε-Differential Privacy**, wenn für alle benachbarten Datensätze D, D' (die sich in genau einem Eintrag unterscheiden) und alle möglichen Ausgaben S gilt: +``` +Pr[M(D) ∈ S] ≤ e^ε · Pr[M(D') ∈ S] +``` + +**Parameter ε (Privacy Budget):** +- **Kleines ε** → mehr Privatsphäre, weniger Genauigkeit +- **Großes ε** → weniger Privatsphäre, mehr Genauigkeit +- Typisch: ε ≤ 1 für starke Privacy + +**Sensitivität** einer Funktion f: Wie stark ändert sich f, wenn ein einzelner Datensatz entfernt wird? +``` +Δf = max_{D,D' benachbart} ||f(D) - f(D')|| +``` +Bestimmt die Stärke des Rauschens. + +### 24.4 Mechanismen + +| Mechanismus | Beschreibung | Anwendung | +|---|---|---| +| **Laplace-Mechanismus** | Addiert Rauschen ~ Laplace(0, Δf/ε) | Numerische Abfragen | +| **Gaußscher Mechanismus** | Addiert Gaußsches Rauschen; benötigt (ε, δ)-DP | Wenn etwas Lockerung akzeptabel | +| **Exponentieller Mechanismus** | Wählt Ergebnis mit exp-gewichteter Wahrscheinlichkeit | Nicht-numerische Ausgaben | + +--- + +## 25. Trusted Execution Environments (TEE) + +### 25.1 Motivation + +**Virtual Black Box Obfuscator (Ideallösung):** Ein Programm so verschleiern, dass man es ausführen, aber nicht verstehen kann. **Problem:** Unmöglich zu konstruieren (Barak et al., 2001). + +**TEE als praktischer Kompromiss:** Statt Software-Obfuskation nutzt man Hardware-Isolation. + +### 25.2 TEE-Architektur (Enklave) + +**Definition:** Ein **Trusted Execution Environment** ist ein hardware-geschützter Bereich (Enklave) auf einem Prozessor, in dem Code und Daten sicher verarbeitet werden. + +**Schlüsseleigenschaften:** +- **Hardware-Isolation:** Selbst ein kompromittiertes Betriebssystem hat keinen Zugriff auf Enklaven-Daten +- **Verschlüsselter Speicher:** Alle Daten werden beim Verlassen der Enklave verschlüsselt +- **Attestierung:** Die Hardware kann kryptographisch beweisen, welcher Code in der Enklave läuft + +**Ablauf:** +``` +Externe Partei → Verschlüsselte Daten → Enklave + ↓ (nur hier entschlüsselt) + Attestierter Code + ↓ + Verschlüsselte Ergebnisse → Externe Partei +``` + +**Beispiele:** Intel SGX, ARM TrustZone, AMD SEV + +**Attestierung:** Externe Parteien können prüfen, dass tatsächlich der korrekte Code in der Enklave läuft (kryptographische Signatur der Hardware). Verhindert, dass der Betreiber manipulierten Code einschleust. + +**Einschränkungen:** Side-Channel-Angriffe (z.B. SGX wurde mehrfach durch Spectre-ähnliche Angriffe kompromittiert), TEE vertraut der Hardware des Herstellers. + +--- + +## 26. Privacy-Schutzziele & Technologien + +### 26.1 Drei Dimensionen von Datenschutz + +| Zustand | Schutzziel | Beispiel | +|---|---|---| +| **Data at Rest** | Vertraulichkeit, Integrität | Verschlüsselte Festplatte | +| **Data in Transit** | Vertraulichkeit, Integrität, Authentizität | TLS | +| **Data in Use** | Vertraulichkeit während Verarbeitung | HE, MPC, TEE | + +### 26.2 Erweiterte Privacy-Ziele + +| Ziel | Bedeutung | +|---|---| +| **Input Privacy** | Eingabedaten der Datenlieferanten werden geschützt | +| **Output Privacy** | Ergebnisse schützen Informationen über Individuen | +| **Policy Enforcement** | Nutzungsregeln werden technisch/rechtlich durchgesetzt | + +### 26.3 Privacy Enhancing Technologies (PET) – Gesamtübersicht + +| Technologie | Input Privacy | Output Privacy | Policy Enforcement | +|---|---|---|---| +| **MPC** | ✅ | — | — | +| **TEE** | ✅ | — | — | +| **Homomorphe Verschlüsselung (HE/FHE)** | ✅ | — | — | +| **Zero Knowledge Proofs** | ✅ | — | — | +| **Differential Privacy** | — | ✅ | — | +| **Aggregation** | — | ✅ | — | +| **Non-Disclosure Agreements (NDA)** | — | — | ✅ | + +--- + +## Schnellreferenz: Wichtige Formeln + +| Konzept | Formel | +|---|---| +| Caesar | E(x) = (x+n) mod 26 | +| Vigenère | C_i = (M_i + K_i) mod 26 | +| OTP | E = P ⊕ K | +| Shannon Perfect Secrecy | H(M\|E) = H(M) | +| Entropie | H(X) = -Σ p_x · log₂(p_x) | +| RSA Verschlüsselung | c = m^e mod n | +| RSA Entschlüsselung | m = c^d mod n | +| RSA Signatur | s = m^d mod n | +| DH gemeinsames Geheimnis | K = g^(ab) mod p | +| HMAC | H((k⊕opad) \|\| H((k⊕ipad)\|\|m)) | +| Beaver Triple Multiplikation | xy = de + d[b] + e[a] + [c] | +| Fiat-Shamir Challenge | ch = H(Commitment, Nachricht) | +| DP Formel | Pr[M(D)∈S] ≤ e^ε · Pr[M(D')∈S] | +| DP Rückrechnung | Echter Anteil = 2×(gemessen - 0,25) | +| AES irreduzibles Polynom | m(x) = x⁸ + x⁴ + x³ + x + 1 | +| Paillier Verschlüsselung | c = g^m · r^n mod n² | +| Paillier Homomorphie | D(E(m₁)·E(m₂)) = m₁+m₂ mod n | + +--- + +## Schnellreferenz: Wichtige Definitionen + +| Begriff | Kurzdefinition | +|---|---| +| **Perfect Secrecy** | Geheimtext verrät keinerlei Information über Klartext (H(M\|E) = H(M)) | +| **OWF** | Leicht zu berechnen, praktisch unmöglich umzukehren | +| **PRG** | Streckt kurzen Seed zu ununterscheidbarem langen Pseudozufallsstring | +| **Comp. Indistinguishability** | Kein effizienter Algorithmus kann zwei Verteilungen mit messbarem Vorteil unterscheiden | +| **IND-CPA** | Angreifer kann bei Zugriff auf Verschlüsselungsorakel nicht unterscheiden, welche Nachricht verschlüsselt wurde | +| **IND-CCA2** | Wie IND-CPA + adaptiver Zugriff auf Entschlüsselungsorakel (außer Challenge-CT) | +| **MAC** | Kurzer Tag, der Integrität und Authentizität (nicht Vertraulichkeit) sichert | +| **AEAD** | Kombiniert Verschlüsselung + Authentifizierung in einem Algorithmus | +| **Feistel-Netzwerk** | Blockchiffre-Struktur: L_{i+1}=R_i, R_{i+1}=L_i⊕F(R_i,K_i); F muss nicht invertierbar sein | +| **Padding Oracle Attack** | Angriff auf CBC: nutzt Unterscheidung zwischen Padding-Fehlern aus | +| **Cipher Text Stealing** | Vermeidet Padding, indem letzter vollständiger + unvollständiger Block kombiniert werden | +| **Shors Algorithmus** | Löst Faktorisierung und DLP in polynomialer Zeit → bricht RSA, DH, ECDH | +| **Grovers Algorithmus** | Suche in O(√N) → halbiert effektive Schlüssellänge symmetrischer Verfahren | +| **LWE** | Learning With Errors: schweres Gitterproblem, Basis für PQC | +| **Oblivious Transfer** | Sender weiß nicht, welche seiner Nachrichten der Empfänger erhalten hat | +| **Garbled Circuit** | Verschlüsselter Boole'scher Schaltkreis; ermöglicht sichere Zweikparteienberechnung | +| **Beaver Triple** | Vorberechnetes (a, b, c=ab)-Tripel für effiziente MPC-Multiplikation | +| **ZK-Proof (Zero Knowledge)** | Beweis der Wahrheit einer Aussage ohne Preisgabe weiterer Informationen | +| **Fiat-Shamir** | Macht interaktive ZK-Proofs nicht-interaktiv durch H(Commitment, Nachricht) als Challenge | +| **Differential Privacy** | Statistischer Datenschutz: Pr[M(D)∈S] ≤ e^ε·Pr[M(D')∈S] für benachbarte D, D' | +| **TEE/Enklave** | Hardware-geschützter Ausführungsbereich; auch kompromittiertes OS hat keinen Zugriff | +| **Zertifikat (X.509)** | Digitale Bestätigung einer CA: bindet Public Key an Identität | +| **Chain of Trust** | Hierarchische Vertrauenskette: Endnutzer-Zertifikat ← CA ← Root CA | +| **CRL** | Liste widerrufener Zertifikate, periodisch veröffentlicht | +| **OCSP** | Echtzeitabfrage des Zertifikatstatus bei einem Responder-Server | +| **BB84** | Quantenschlüsselaustausch; sicher durch No-Cloning-Theorem; Eve-Abhören detektierbar | +| **MPC in the Head** | ZK-Proofs durch Simulation eines MPC-Protokolls im Kopf des Provers | + +--- + +*Tags: #Kryptographie #HWR #Klausur #Zusammenfassung #Kryptografische_Primitive #Symmetrisch #Asymmetrisch #AES #RSA #TLS #PostQuantum #MPC #ZeroKnowledge #DifferentialPrivacy #TEE* diff --git a/Kryptografie/klausur/klausurthemen.md b/Kryptografie/klausur/klausurthemen.md new file mode 100644 index 0000000..ab92fa3 --- /dev/null +++ b/Kryptografie/klausur/klausurthemen.md @@ -0,0 +1,76 @@ +# Klausurvorbereitung + +Erwartungen und Themen: +- Keine Hilfsmittel erlaubt in der Klausur +- Definitionen lernen, grundlegende Sachen +- Abkürzungen entziffern +- Grundlegende Verfahren erklären können +- Aufgabentypen: "**Beschreiben** Sie Verfahren X, **Definieren** Sie Konzept Y" +- 4 Sicherheitsbegriffe +- Symmetrische Verschlüsselung: + - Caesar + - Vigenere + - Shanon Perfect Secrecy + - OTP +- Pseudozufallszahlengenerator: Computational Indistinguishibility erklären können +- Formale Definition super, aber umgangssprachlich okay, kann aber falsch werden +- Umgangssprachliche Erklärungen von Formeln okay +- Bit Commitment, warum eine Variante funktioniert, warum die andere nicht +- Grobe Vorstellung von Parametern, z.B. bei ChaCha20 +- Blockmodi kennen, was ist ECB +- Was ist IND-CPA sicher? +- Chaining Modes +- Padding Orakel +- Cipher Text Stealing +- Kein DES Aufbau, wissen was eine Phaestel Ciffre ist +- Grundlegendes Prinzip von AES, 4 Phasen kennen +- AES S-Box Modulo Polynomrechnung +- MAC + - Angriffsvektoren + - HMAC + - Eigenschaften Kryptografischer Hashfunktion + - Varianten + - AEAD (in TLS 1.3 Standard genutzt) +- Public Key Kryto System +- Diffie Hellman Key Exchange +- ModP +- RSA Kryptosystem wissen und anwenden können (Beispielrechnung) +- Faktorisierungsproblem +- IND-CCA und IND-CCA2 erklären können +- Padding kennen, warum man RSA-PSS braucht +- Elgamal kennen +- Signaturen, Angriffsvektoren +- Publik Key Methode zur Signaturmethode +- ECDSA kennen nur +- Zertifikat, Aufgaben, PKI, Zertifikatskette, Root-CA, +- CRL, OCSP-Responder +- TLS einordnen können (OSI-Layer, Handshake, Record, Komponenten) +- IPSec kleine Wissenfrage auf welchem OSI-Layer +- BB84-Protocol +- Peter Shor, SHor-Algorithmen +- Grover-Algorithmus +- Simons Problem +- PQC-Strategien benennen können + - Hash-based Kryptografie kennen + - Isogenien und was man damit machen kann: Diffie Hellmann Key Exchange + - Code-base + - Lattice-based: Beispiel kennen und halbwegs erklären können Regev Beispiel +- PQC Standartisierung und Competition +- Privacy Definitionen Schutzziele +- Homomorphe Encryption: Grundlagen & Ansätze +- Pailler verstehen (fast wie RSA) +- MPC: Erkläurung, Ziel + - Oblivious Transfer: + - Definitionen, Arten, Unterschiede + - Wofür ist das gut? + - Garbled Circuits: erstellen können und auswerten + - Additive Secret Sharing + - Beaver Triples +- Zero Knowledge: Was ist das und was bedeutet es? Beispiele und Verständnis + - Graph-Isomorphie + - Diskreter Algorithmus + - Flat Shamir Transformation + - Signature Schema +- MPC in the Head +- Differential Privacy: Definition und Beispiel +- Trusted Execution Environment: Enklave und grundlegendes Prinzip \ No newline at end of file diff --git a/Kryptografie/klausur/themenliste.md b/Kryptografie/klausur/themenliste.md new file mode 100644 index 0000000..4bbf036 --- /dev/null +++ b/Kryptografie/klausur/themenliste.md @@ -0,0 +1,113 @@ +# Kryptographie - Themenliste + +## KR1 – Grundlagen +- Häufigkeitsanalyse +- Caesar-Chiffre +- Vigenère-Chiffre (inkl. Kasiski-Test) +- Homophone Chiffren +- Beale-Chiffren +- Informationsgehalt & Entropie +- Bemessbarkeit von Sicherheit (Claude Shannon) / Perfekte Sicherheit +- One Time Pad +- Einwegfunktionen (OWF) +- Pseudozufallsgeneratoren (PRG) & Zusammenhang OWF ↔ PRG +- Hardcore-Prädikat (HCP) +- Strom-Chiffre +- CHACHA20 (Stromchiffre) +- Block-Chiffre +- Betriebsmodi: + - ECB (Electronic Codebook) + - CBC (Cipher Block Chaining) inkl. Padding Oracle Attack + - CTR (Counter Mode) + - OFB (Output Feedback Mode) + - CFB (Cipher Feedback Mode) + - Cipher Text Stealing +- Kryptoanalyse & Angriffsmodelle (Ciphertext-only, Known Plaintext, CPA, CCA) +- IND-CPA Game +- DES (Data Encryption Standard) – Feistel-Netzwerk +- AES (Advanced Encryption Standard) – SubBytes, ShiftRows, MixColumns, AddRoundKey +- AES S-Box & Arithmetik in GF(2⁸) +- Lamport's One-Time-Signature +- Bit Commitment Protokoll + +## KR2 – MAC, AEAD & Public Key Cryptography +- MAC (Message Authentication Code) – Funktionsweise & Angriffsvektoren +- How to NOT MAC a Long Message (6 fehlerhafte Ansätze) +- HMAC (Hash-based MAC) +- MAC-Kompositionsmethoden (Encrypt-then-MAC, MAC-then-Encrypt, Encrypt-and-MAC) +- AEAD (Authenticated Encryption with Associated Data) + - ChaCha20-Poly1305 + - Galois Counter Mode (GCM) +- Symmetric Search over Encrypted Data +- Public Key Cryptography: + - Merkle Puzzle + - Virtual Black Box Obfuscator (existiert nicht) + - Diffie-Hellman Key Exchange + - Problem des diskreten Logarithmus + - MODP (Einheitengruppe eines endlichen Körpers) – RFC 3526 + - Gruppe auf einem Kreis + - Elliptische Kurven (Punktaddition, Formale Definition, Sicherheitsbewertung) + - RSA (Key Generation, Encryption, Decryption) + - Faktorisierungsproblem & General Number Field Sieve (GNFS) + - IND-CCA2 Game + - OAEP (Optimal Asymmetric Encryption Padding) + - ElGamal (inkl. Generalized ElGamal) + +## KR3 – Signaturen, Zertifikate, TLS & Quantenkryptographie +- Digitale Signaturen (Grundprinzip, Angriffsziele) +- RSA-Signatur (inkl. Existential Forgery Attack) +- RSA-PSS (Probabilistic Signature Scheme) +- ECDSA (Elliptic Curve Digital Signature Algorithm) +- Zertifikate (X.509, Chain of Trust, CRL, OCSP) +- Identity-Based Encryption (IBE) – Boneh & Franklin +- Babington Plot – Schichtenmodell der Kommunikationssicherheit +- TLS (Transport Layer Security) – TLS 1.3, Handshake, Key Exchange Modi +- SSL/TLS Versionshistorie & bekannte Angriffe +- QUIC +- IPSec (Tunnel Mode, AH, ESP) +- Quantenmechanik-Grundlagen (Superposition, Verschränkung, Unschärfe) +- BB84 Protokoll (Quantum Key Distribution) +- No-Cloning-Theorem +- Shors Algorithmus (bricht RSA, DH, ECDH, ECDSA) +- Grovers Algorithmus (halbiert symmetrische Schlüssellänge) +- Simons Algorithmus + +## KR4 – Post-Quantum Kryptographie & Homomorphe Verschlüsselung +- Komplexitätsklassen (P, NP, Co-NP, BQP, PSPACE) +- PQC-Strategien (Überblick) +- PQ-RSA („Trotziges Kind") +- Hash-basierte Kryptographie (Merkle-Baum, XMSS, SPHINCS) +- Isogenien-basierte Kryptographie (SIDH) +- Multivariate Polynome (MQ-Problem, Oil-and-Vinegar) +- Code-basierte Kryptographie (McEliece, Syndrome-Decoding) +- Gitter-basierte Kryptographie (CVP, SVP, GapSVP, LWE, SIS) +- Worst-Case zu Average-Case Reduktion +- Regev's Public-Key-Kryptosystem +- Moscas Theorem (x + y > z) +- NIST PQC-Standardisierung (Kyber, Dilithium, Falcon, SPHINCS+) +- Drei Dimensionen des Datenschutzes (at rest, in transit, in use) +- Input Privacy, Output Privacy, Policy Enforcement +- Homomorphe Verschlüsselung (PHE, SWHE, FHE) + - RSA als PHE (multiplikativ homomorph) + - Paillier als PHE (additiv homomorph) + - SWHE-Beispiel +- Multi-Party Computation (MPC) – Millionärsproblem, Ideales/Reales Modell +- Oblivious Transfer (OT) – Varianten, DH-basiertes Protokoll + +## KR5 – MPC-Protokolle, Zero Knowledge Proofs & Differential Privacy +- Yao's Millionärsproblem +- Garbled Circuits (Garbler/Evaluator, Eingaben via OT) +- Arithmetic Circuits +- Additive Secret Sharing (Addition, Multiplikationsproblem) +- Beaver Triples (Multiplikationsprotokoll) +- SPDZ-Protokoll +- Zero Knowledge Proofs (Completeness, Soundness, Zero Knowledge) + - Beispiel: Graph-Isomorphismus + - Quadratic Residues, Diskreter Logarithmus, Signatur-Schema +- MPC in the Head +- Differential Privacy + - Randomized Response + - Epsilon (Privacy Budget) & Sensitivität + - Laplace-, Gauß- und Exponentieller Mechanismus +- Trusted Execution Environments (TEE) – Intel SGX, ARM TrustZone, AMD SEV +- Privacy Enhancing Technologies – Gesamtübersicht \ No newline at end of file diff --git a/Kryptografie/zusammenfassungen/kr1 - zusammenfassung.md b/Kryptografie/zusammenfassungen/kr1 - zusammenfassung.md new file mode 100644 index 0000000..2b2b3cd --- /dev/null +++ b/Kryptografie/zusammenfassungen/kr1 - zusammenfassung.md @@ -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 | diff --git a/Kryptografie/zusammenfassungen/kr2 - additional notes.md b/Kryptografie/zusammenfassungen/kr2 - additional notes.md new file mode 100644 index 0000000..4af9dbc --- /dev/null +++ b/Kryptografie/zusammenfassungen/kr2 - additional notes.md @@ -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. \ No newline at end of file diff --git a/Kryptografie/zusammenfassungen/kr2 - zusammenfassung.md b/Kryptografie/zusammenfassungen/kr2 - zusammenfassung.md new file mode 100644 index 0000000..10dadb0 --- /dev/null +++ b/Kryptografie/zusammenfassungen/kr2 - zusammenfassung.md @@ -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). \ No newline at end of file diff --git a/Kryptografie/zusammenfassungen/kr3 - zusammenfassung.md b/Kryptografie/zusammenfassungen/kr3 - zusammenfassung.md new file mode 100644 index 0000000..3c6df0f --- /dev/null +++ b/Kryptografie/zusammenfassungen/kr3 - zusammenfassung.md @@ -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_ \ No newline at end of file diff --git a/Kryptografie/zusammenfassungen/kr4 - zusammenfassung.md b/Kryptografie/zusammenfassungen/kr4 - zusammenfassung.md new file mode 100644 index 0000000..7e01661 --- /dev/null +++ b/Kryptografie/zusammenfassungen/kr4 - zusammenfassung.md @@ -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| \ No newline at end of file diff --git a/Kryptografie/zusammenfassungen/kr5 - zusammenfassung.md b/Kryptografie/zusammenfassungen/kr5 - zusammenfassung.md new file mode 100644 index 0000000..a62a960 --- /dev/null +++ b/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) | diff --git a/Latex Projekte/Overleaf Projects (6 items).zip b/Latex Projekte/Overleaf Projects (6 items).zip new file mode 100644 index 0000000..c4898cb Binary files /dev/null and b/Latex Projekte/Overleaf Projects (6 items).zip differ diff --git a/Netzwerke/.DS_Store b/Netzwerke/.DS_Store new file mode 100644 index 0000000..3951004 Binary files /dev/null and b/Netzwerke/.DS_Store differ diff --git a/Netzwerke/_Overview.md b/Netzwerke/_Overview.md new file mode 100644 index 0000000..7406a3f --- /dev/null +++ b/Netzwerke/_Overview.md @@ -0,0 +1,41 @@ +# Netzwerke + +> [[Dashboard|← Zurück zum Dashboard]] + +**Dozentin:** Gabriele Schrenk + +--- + +## Vorlesungen + +| # | Thema | Folien | Zusammenfassung | NotebookLM | Lernkarten | Status | +| --- | -------------------------------- | ------ | --------------------------------- | ---------- | ---------- | ------ | +| 01 | Netzwerkgrundlagen & Komponenten | ✅ | ✅ [[nw1 - zusammenfassung\|Link]] | ✅ | ✅ | 🟢 | +| 02 | Topologien & OSI-Modell | ✅ | ✅ [[nw2 - zusammenfassung\|Link]] | ✅ | ✅ | 🟢 | +| 03 | Layer 2/3, IPv4 & Routing | ✅ | ✅ [[nw3 - zusammenfassung\|Link]] | ✅ | ✅ | 🟢 | +| 04 | IPv6, DHCP & WAN | ✅ | ✅ [[nw4 - zusammenfassung\|Link]] | ✅ | ✅ | 🟢 | +| 05 | — | ⬜ | ⬜ | ⬜ | ⬜ | 🔴 | +| 06 | — | ⬜ | ⬜ | ⬜ | ⬜ | 🔴 | +| 07 | — | ⬜ | ⬜ | ⬜ | ⬜ | 🔴 | +| 08 | — | ⬜ | ⬜ | ⬜ | ⬜ | 🔴 | +| 09 | — | ⬜ | ⬜ | ⬜ | ⬜ | 🔴 | +| 10 | — | ⬜ | ⬜ | ⬜ | ⬜ | 🔴 | +| 11 | Klausurvorbereitung | ⬜ | ⬜ | ⬜ | ⬜ | 🔴 | + +**Legende:** ⬜ Offen · ✅ Erledigt · 🔴 Nicht begonnen · 🟡 In Arbeit · 🟢 Fertig + +--- + +## Zusätzliche Materialien + +- [[nw3 - labor|NW3 – Laborübung]] +- [[nw4 - labor|NW4 – Laborübung]] + +--- + +## Modul-Infos + +- **Dozentin:** Gabriele Schrenk +- **Prüfungsform:** +- **Prüfungstermin:** +- **Besonderheiten:** diff --git a/Netzwerke/folien/nw1 - folien.pdf b/Netzwerke/folien/nw1 - folien.pdf new file mode 100644 index 0000000..3e3467c Binary files /dev/null and b/Netzwerke/folien/nw1 - folien.pdf differ diff --git a/Netzwerke/folien/nw2 - folien.pdf b/Netzwerke/folien/nw2 - folien.pdf new file mode 100644 index 0000000..c9ab42f Binary files /dev/null and b/Netzwerke/folien/nw2 - folien.pdf differ diff --git a/Netzwerke/folien/nw3 - folien.pdf b/Netzwerke/folien/nw3 - folien.pdf new file mode 100644 index 0000000..64e92a2 Binary files /dev/null and b/Netzwerke/folien/nw3 - folien.pdf differ diff --git a/Netzwerke/folien/nw4 - folien.pdf b/Netzwerke/folien/nw4 - folien.pdf new file mode 100644 index 0000000..042b91b Binary files /dev/null and b/Netzwerke/folien/nw4 - folien.pdf differ diff --git a/Netzwerke/folien/nw5 - folien.pdf b/Netzwerke/folien/nw5 - folien.pdf new file mode 100644 index 0000000..835678c Binary files /dev/null and b/Netzwerke/folien/nw5 - folien.pdf differ diff --git a/Netzwerke/folien/nw6 - folien.pdf b/Netzwerke/folien/nw6 - folien.pdf new file mode 100644 index 0000000..6155734 Binary files /dev/null and b/Netzwerke/folien/nw6 - folien.pdf differ diff --git a/Netzwerke/folien/nw7 - folien.pdf b/Netzwerke/folien/nw7 - folien.pdf new file mode 100644 index 0000000..699db67 Binary files /dev/null and b/Netzwerke/folien/nw7 - folien.pdf differ diff --git a/Netzwerke/klausur/ipv4-zusammenfassen.md b/Netzwerke/klausur/ipv4-zusammenfassen.md new file mode 100644 index 0000000..7426218 --- /dev/null +++ b/Netzwerke/klausur/ipv4-zusammenfassen.md @@ -0,0 +1,265 @@ +# IPv4-Netzadressen zusammenfassen (Route Summarization) +> **Kommt sicher in der Klausur!** Verschiedene IPv4-Netze in CIDR-Schreibweise → zusammenfassen + begründen. + +--- + +## Das Prinzip + +Mehrere spezifische Routen werden zu **einer einzigen summarischen Route** zusammengefasst. +Das reduziert Routing-Tabellen und macht das Netz effizienter. + +**Bedingung:** Alle zusammenzufassenden Netze müssen zum **gleichen Next Hop / gleichen Interface** führen – sonst ergibt die Zusammenfassung keinen Sinn (man würde Datenverkehr falsch weiterleiten). + +--- + +## Algorithmus (Schritt für Schritt) + +1. Alle Netzadressen in **Binär** umschreiben (nur die relevanten Oktette) +2. Von links nach rechts die **identischen Bits zählen** → das wird die neue Präfixlänge +3. Die ersten n identischen Bits nehmen, Rest auf **0 setzen** → neue Netzadresse +4. **Prüfen**: Deckt die Zusammenfassung nur die gewünschten Netze ab, oder fallen unerwünschte Netze mit rein? +5. Falls unerwünschte Netze dabei sind: **Präfix vergrößern** (mehr Bits = kleineres Netz) und Restnetze separat behandeln + +--- + +## Wann kann man NICHT zusammenfassen? + +- Die Netze liegen **nicht lückenlos beieinander** im Adressraum → unerwünschte Netze würden mit eingeschlossen +- Die Netze führen zu **unterschiedlichen Next Hops** → falsche Weiterleitung +- Ein Netz liegt **außerhalb** der möglichen Zusammenfassung → dann zwei getrennte Zusammenfassungen + +**Argumentation in der Klausur:** +„Netz X kann nicht mit Netz Y zusammengefasst werden, weil eine gemeinsame Zusammenfassung auch die Netze A, B, C einschließen würde, die einen anderen Next Hop haben / nicht existieren." + +--- + +## Hilfstabelle: Bit-Wertigkeiten + +| 2⁷ | 2⁶ | 2⁵ | 2⁴ | 2³ | 2² | 2¹ | 2⁰ | +|----|----|----|----|----|----|----|-----| +| 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 | + +--- + +## Beispiel 1 – Einfache Zusammenfassung (aus VL4) + +**Gegeben:** 172.16.0.0/24, 172.16.1.0/24, 172.16.2.0/24, 172.16.3.0/24 + +**Schritt 1 – Binär (3. Oktett entscheidend):** +``` +172.16.0.0 → 0000 00|00 +172.16.1.0 → 0000 00|01 +172.16.2.0 → 0000 00|10 +172.16.3.0 → 0000 00|11 + ↑ + 22 Bits identisch +``` + +**Schritt 2 – Neue Präfixlänge:** /22 (22 identische Bits von links) + +**Schritt 3 – Neue Netzadresse:** 172.16.0.0 (Bits ab Position 23 auf 0) + +**Ergebnis:** `172.16.0.0/22` + +**Prüfung:** /22 deckt 172.16.0.0 bis 172.16.3.255 → genau die 4 Netze, keine unerwünschten ✓ + +--- + +## Beispiel 2 – Nicht-triviale Zusammenfassung (aus VL4) + +**Gegeben:** 192.168.0.0/24 bis 192.168.9.0/24 + +**Problem:** Eine einzige Zusammenfassung würde auch 192.168.10.0 bis 192.168.15.0 einschließen. + +**Binär (3. Oktett):** +``` +192.168.0.0: 0000 0|000 ─┐ +192.168.1.0: 0000 0|001 │ +192.168.2.0: 0000 0|010 ├─ 21 Bits identisch → /21 +192.168.3.0: 0000 0|011 │ deckt .0 bis .7 +192.168.4.0: 0000 0|100 │ +192.168.5.0: 0000 0|101 │ +192.168.6.0: 0000 0|110 │ +192.168.7.0: 0000 0|111 ─┘ + +192.168.8.0: 0000 100|0 ─┐ 23 Bits identisch → /23 +192.168.9.0: 0000 100|1 ─┘ deckt .8 und .9 +``` + +**Ergebnis:** Zwei Zusammenfassungen nötig: +- `192.168.0.0/21` (deckt .0 bis .7) +- `192.168.8.0/23` (deckt .8 und .9) + +**Argumentation:** Eine einzige /21 ab .8 würde .8 bis .15 abdecken – aber .10 bis .15 existieren nicht / haben anderen Next Hop → nicht erlaubt. + +--- + +## Beispiel 3 – Aus VL4 Vorlesungsaufgabe + +**Gegeben:** +- 192.168.160.0/24 +- 192.168.161.0/24 +- 192.168.162.0/23 +- 192.168.164.0/22 + +**Binär (3. Oktett):** +``` +192.168.160.0: 1010 0|000 +192.168.161.0: 1010 0|001 +192.168.162.0: 1010 0|010 (→ deckt .162 und .163 wegen /23) +192.168.164.0: 1010 0|100 (→ deckt .164 bis .167 wegen /22) + ↑ + 21 Bits identisch +``` + +**Ergebnis:** `192.168.160.0/21` +(deckt 160–167, alle 4 Netze liegen darin, keine unerwünschten Netze dabei ✓) + +--- + +## Beispiel 4 – Gruppenaufgabe VL4 (ein Netz passt nicht rein) + +**Gegeben:** +- 172.30.31.0/24 +- 172.30.32.0/24 +- 172.30.33.0/24 +- 172.30.34.0/23 +- 172.30.36.0/23 +- 172.30.38.0/24 + +**Binär (3. Oktett):** +``` +172.30.31.0: 0001 1111 ← passt NICHT zu den anderen (andere Bitfolge) +172.30.32.0: 0010 00|00 ─┐ +172.30.33.0: 0010 00|01 ├─ 22 Bits → /22 (deckt .32–.35) +172.30.34.0: 0010 00|10 ─┘ +172.30.36.0: 0010 01|00 → /23 (deckt .36–.37) +172.30.38.0: 0010 01|10 → /24 (einzeln) +``` + +**Warum .31 nicht zusammenfassen?** +Würde man .31 mit .32–.38 zusammenfassen, bräuchte man /21, das würde .24–.31 UND .32–.39 abdecken. Damit kämen .24–.30 dazu – die existieren nicht / haben anderen Next Hop. → Nicht erlaubt. + +**Ergebnis:** 4 Einträge: +- `172.30.31.0/24` (allein, passt nicht in Gruppe) +- `172.30.32.0/22` (deckt .32–.35) +- `172.30.36.0/23` (deckt .36–.37) +- `172.30.38.0/24` (allein) + +--- + +## Schnell-Lookup: Welche CIDR-Größen gibt es? + +| Präfix | Maske | Adressen | 3. Oktett Schrittweite | +|--------|-------|----------|------------------------| +| /24 | 255.255.255.0 | 256 | 1 | +| /23 | 255.255.254.0 | 512 | 2 | +| /22 | 255.255.252.0 | 1024 | 4 | +| /21 | 255.255.248.0 | 2048 | 8 | +| /20 | 255.255.240.0 | 4096 | 16 | +| /19 | 255.255.224.0 | 8192 | 32 | +| /18 | 255.255.192.0 | 16384 | 64 | +| /17 | 255.255.128.0 | 32768 | 128 | +| /16 | 255.255.0.0 | 65536 | — (ganzes 2. Oktett) | + +**Schrittweite** = wie weit auseinander die Netzadressen liegen dürfen (z.B. bei /22 immer Vielfache von 4 im 3. Oktett: .0, .4, .8, .12, ...) + +--- + +## Übungsaufgaben (selbst lösen) + +### Aufgabe 1 +Gegeben (alle /24, gleicher Next Hop): +- 10.0.0.0/24 +- 10.0.1.0/24 +- 10.0.2.0/24 +- 10.0.3.0/24 + +
+
+
+---
+
+### Aufgabe 2
+Gegeben (alle /24, gleicher Next Hop):
+- 192.168.4.0/24
+- 192.168.5.0/24
+- 192.168.6.0/24
+- 192.168.7.0/24
+
+Lösung
+ +3. Oktett: 0, 1, 2, 3 → binär: 0000 00|00 bis 0000 00|11 → 22 identische Bits +**Ergebnis: 10.0.0.0/22** + +
+
+
+---
+
+### Aufgabe 3
+Gegeben (alle /24, gleicher Next Hop):
+- 172.16.8.0/24
+- 172.16.9.0/24
+- 172.16.10.0/24
+- 172.16.11.0/24
+- 172.16.12.0/24
+- 172.16.13.0/24
+
+Lösung
+ +3. Oktett: 4, 5, 6, 7 → binär: 0000 01|00 bis 0000 01|11 → 22 identische Bits +**Ergebnis: 192.168.4.0/22** + +
+
+
+---
+
+### Aufgabe 4 – Mit unterschiedlichen Präfixen
+Gegeben (gleicher Next Hop):
+- 10.1.0.0/24
+- 10.1.1.0/24
+- 10.1.2.0/23
+
+Lösung
+ +3. Oktett binär: +- 8 = 0000 1000 +- 9 = 0000 1001 +- 10 = 0000 1010 +- 11 = 0000 1011 +- 12 = 0000 1100 ← hier weicht Bit 5 ab! +- 13 = 0000 1101 + +Eine einzige Zusammenfassung würde 8–15 umfassen (/21), aber .14 und .15 sind nicht dabei → prüfen ob das ok ist (fehlen die im Next Hop?). +Falls .14 und .15 nicht existieren / anderen Next Hop haben → zwei Zusammenfassungen: +- `172.16.8.0/22` (deckt .8–.11) +- `172.16.12.0/23` (deckt .12–.13) + +Falls .14 und .15 denselben Next Hop haben → **172.16.8.0/21** (deckt .8–.15) + +**Argumentation zählt hier!** + +
+
+
+---
+
+## Argumentation-Template für die Klausur
+
+**Wenn zusammenfassbar:**
+> „Die Netze X, Y, Z können zu [Zusammenfassung]/[Präfix] zusammengefasst werden, da die ersten [n] Bits der Netzadressen identisch sind. Die Zusammenfassung deckt genau diese Netze ab und schließt keine unerwünschten Netze ein."
+
+**Wenn NICHT zusammenfassbar (als eine Zusammenfassung):**
+> „Eine gemeinsame Zusammenfassung von X und Y würde das Netz [unerwünschtes Netz] einschließen, das einen anderen Next Hop hat / nicht existiert. Daher sind zwei separate Zusammenfassungen nötig: [A]/[n] und [B]/[m]."
+
+**Wenn ein Netz einzeln bleiben muss:**
+> „Netz X kann nicht mit den übrigen Netzen zusammengefasst werden, da eine gemeinsame Zusammenfassung die Netze [A bis B] einschließen würde, die nicht zum selben Next Hop gehören."
diff --git a/Netzwerke/klausur/nw6 - klausurstuff.md b/Netzwerke/klausur/nw6 - klausurstuff.md
new file mode 100644
index 0000000..fd296a4
--- /dev/null
+++ b/Netzwerke/klausur/nw6 - klausurstuff.md
@@ -0,0 +1,496 @@
+# IT2221 – Prüfungsvorbereitung: Kernthemen mit Erklärungen & Beispielen
+
+---
+
+## 1. Troubleshooting
+
+### Die 7-Schritte-Methodik
+
+| Schritt | Was tun? |
+|---------|----------|
+| 1 | **Problem definieren** – Was genau geht nicht? Seit wann? Wer ist betroffen? |
+| 2 | **Informationen sammeln** – Show-Befehle, Logs, Topology prüfen |
+| 3 | **Daten analysieren** – Routingtabellen, Nachbarzustände vergleichen |
+| 4 | **Hypothese formulieren** – Welche OSI-Schicht ist schuld? |
+| 5 | **Hypothese testen** – PCAPs, Ping, Traceroute |
+| 6 | **Korrektur implementieren** |
+| 7 | **Verifizieren & dokumentieren** |
+
+---
+
+### Vorgehensstrategien
+
+**Bottom-Up** – Fange bei Layer 1 an, arbeite dich hoch:
+> Kabel ok? → Link up? → IP ok? → Routing ok? → App ok?
+> Gut wenn: Das Problem unbekannt ist und man systematisch vorgehen will.
+
+**Top-Down** – Fange bei Layer 7 an, arbeite dich runter:
+> App geht nicht? → DNS ok? → TCP-Verbindung ok? → Route ok? → Link ok?
+> Gut wenn: Der User ein konkretes App-Problem meldet.
+
+**Divide & Conquer** – Fang in der Mitte an (z.B. Layer 3) und entscheide dann ob du rauf oder runter gehst:
+> Ping zum nächsten Router ok? → Problem ist oben (L4–L7). Ping nicht ok? → Problem ist unten (L1–L2).
+> Gut wenn: Das Netz groß ist und du Zeit sparen willst.
+
+---
+
+### Wichtigste Show-Befehle je Schicht
+
+| OSI-Schicht | Befehl | Was zeigt er? |
+|-------------|--------|---------------|
+| L1 (Physical) | `show interfaces` | Link up/down, Fehler, Kabelfehler |
+| L2 (Data Link) | `show mac address-table` | MAC-Tabelle des Switches |
+| L2 (Data Link) | `show spanning-tree` | STP-Zustand |
+| L3 (Network) | `show ip route` | Routingtabelle |
+| L3 (Network) | `show ip ospf neighbor` | OSPF-Nachbarn und deren Zustand |
+| L3 (Network) | `show bgp summary` | BGP-Nachbarn, Status, Routen |
+| L3 MPLS | `show mpls forwarding-table` | MPLS Label-Tabelle (FIB) |
+| L3 MPLS | `show mpls ldp neighbor` | LDP-Nachbarn |
+| L4 (Transport) | `show ip sockets` | Offene TCP/UDP-Verbindungen |
+
+**Beispiel-Szenario:** PC bekommt keine IP-Adresse.
+
+```
+Schritt 1: Problem klar → DHCP funktioniert nicht
+Schritt 2: show ip interface brief → Interface up?
+ show ip dhcp pool → DHCP-Pool konfiguriert?
+ show ip dhcp binding → Gibt es Zuweisungen?
+Schritt 3: Kein Pool vorhanden → Hypothese: DHCP falsch konfiguriert
+Schritt 4: ip dhcp pool MEIN_POOL konfiguriert? Nein!
+Schritt 5: Pool anlegen, PC neu verbinden → IP erhalten ✓
+Schritt 7: Dokumentieren
+```
+
+---
+
+## 2. BGP – Border Gateway Protocol
+
+### Grundidee: Path-Vector
+
+BGP ist ein **Path-Vector-Protokoll**. Das bedeutet: BGP teilt nicht nur mit „ich kann Netz X erreichen", sondern auch **über welchen Weg** (AS-Pfad). So können Schleifen erkannt werden – wenn meine eigene AS-Nummer im Pfad steht, nehme ich die Route nicht an.
+
+**Verbindung:** BGP läuft über **TCP Port 179** (zuverlässige Übertragung, kein eigenes Reliability-Protokoll nötig).
+
+---
+
+### Die 4 Nachrichtentypen
+
+| Typ | Wann? | Was macht er? |
+|-----|-------|---------------|
+| **OPEN** | Beim Verbindungsaufbau | Stellt sich vor: AS-Nummer, BGP-Version, Router-ID, Hold-Time |
+| **UPDATE** | Wenn sich Routen ändern | Teilt neue Routen mit oder zieht alte zurück |
+| **KEEPALIVE** | Alle ~60 Sekunden | „Ich lebe noch" – verhindert Timeout |
+| **NOTIFICATION** | Bei Fehlern | Meldet Fehler und bricht die Session ab |
+
+**Beispiel OPEN:**
+```
+Router A öffnet TCP-Verbindung zu Router B auf Port 179.
+Schickt OPEN: „Ich bin AS 65000, meine Router-ID ist 1.1.1.1, Hold-Time 90s"
+Router B antwortet mit eigenem OPEN + KEEPALIVE → Session steht.
+```
+
+---
+
+### 9-stufige Wegewahl (vereinfacht auf die wichtigsten)
+
+Wenn BGP mehrere Routen zum gleichen Ziel kennt, wählt er nach dieser Reihenfolge:
+
+| Priorität | Attribut | Merkhilfe |
+|-----------|----------|-----------|
+| 1 | **LOCAL_PREF** (höher = besser) | „Welchen Ausgang bevorzuge ich?" |
+| 2 | **AS_PATH** (kürzer = besser) | „Welcher Weg hat weniger Hops?" |
+| 3 | **MED** (niedriger = besser) | „Welchen Eingang bevorzugt mein Nachbar?" |
+| ... | weitere Kriterien | Router-ID, Neighbor-IP, etc. |
+
+**Beispiel:**
+```
+Router A kennt zwei Wege zu 8.8.8.0/24:
+
+Weg 1: LOCAL_PREF=200, AS_PATH: 65001 65002
+Weg 2: LOCAL_PREF=100, AS_PATH: 65003
+
+→ Weg 1 gewinnt, weil LOCAL_PREF höher (200 > 100).
+ AS_PATH wird gar nicht mehr verglichen.
+```
+
+---
+
+### Transit vs. Peering
+
+**Peering:** Zwei Provider tauschen gegenseitig ihre eigenen Routen aus – kostenlos, aber nur das eigene Netz, keine Weiterleitung fremder Pakete.
+
+```
+Telekom ←→ Vodafone: „Ich leite deine Kunden-Pakete weiter, du meine."
+Aber: Telekom leitet keine Pakete von Vodafone an einen dritten Provider weiter.
+```
+
+**Transit:** Ein Provider kauft beim anderen die Weiterleitung aller Pakete – auch zu Dritten. Kostet Geld.
+
+```
+Kleiner ISP → bezahlt Telekom → Telekom leitet Pakete ans gesamte Internet weiter.
+```
+
+---
+
+### Tier 1 / Tier 2 / Tier 3
+
+| Tier | Wer? | Beispiel |
+|------|------|---------|
+| **Tier 1** | Große Provider, die das Internet-Backbone bilden. Haben Peering mit allen anderen Tier-1. Kaufen keinen Transit. | Deutsche Telekom, AT&T, Level3 |
+| **Tier 2** | Mittelgroße Provider. Haben Peering mit manchen, kaufen Transit von Tier-1. | Regionaler ISP |
+| **Tier 3** | Kleine Provider, kaufen Transit von Tier-2. Kein eigenes Peering. | Dein lokaler Kabel-Anbieter |
+
+---
+
+### iBGP vs. eBGP
+
+| | iBGP | eBGP |
+|--|------|------|
+| **Wo?** | Innerhalb eines AS | Zwischen verschiedenen AS |
+| **TTL** | 255 (muss nicht direkt verbunden sein) | 1 (muss direkt verbunden sein) |
+| **Routen weitergeben?** | iBGP-Routen werden **nicht** an andere iBGP-Nachbarn weitergegeben | eBGP-Routen werden weitergegeben |
+| **Problem iBGP** | Alle iBGP-Router müssen sich kennen (Full Mesh) → bei n Routern: n*(n-1)/2 Sessions |
+
+**Warum darf iBGP keine Routen an iBGP-Nachbarn weitergeben?**
+→ Schleifenvermeidung! iBGP hat kein AS_PATH innerhalb eines AS, daher könnte eine Route endlos weitergegeben werden.
+
+---
+
+### Route Reflector
+
+**Problem:** Bei 10 iBGP-Routern braucht man 45 Sessions. Bei 100 Routern: 4950. Nicht skalierbar.
+
+**Lösung:** Ein Router wird zum **Route Reflector (RR)**. Er darf iBGP-Routen an andere iBGP-Nachbarn weitergeben – aber nur, wenn er als RR konfiguriert ist.
+
+```
+Ohne RR (Full Mesh, 4 Router):
+A ←→ B, A ←→ C, A ←→ D, B ←→ C, B ←→ D, C ←→ D → 6 Sessions
+
+Mit RR (A ist Route Reflector):
+B → A → C
+B → A → D
+C → A → D → nur 3 Sessions nötig
+```
+
+---
+
+### Administrative Distanz (AD)
+
+Wenn eine Route sowohl von BGP als auch von z.B. OSPF gelernt wird, entscheidet die AD welche genommen wird (niedrigere AD = bevorzugt):
+
+| Protokoll | AD |
+|-----------|----|
+| Connected | 0 |
+| Static | 1 |
+| OSPF | 110 |
+| iBGP | 200 |
+| eBGP | 20 |
+
+> eBGP (AD 20) wird fast immer gegenüber anderen Protokollen bevorzugt. iBGP (AD 200) fast nie.
+
+---
+
+## 3. MPLS – Label-Format und Forwarding
+
+### Das Label-Format (32 Bit)
+
+```
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Label (20 Bit) | TC |S| TTL |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+```
+
+| Feld | Bits | Bedeutung |
+|------|------|-----------|
+| **Label** | 20 | Der eigentliche Label-Wert (0 – 1.048.575) |
+| **TC** | 3 | Traffic Class – früher „EXP", für QoS/Priorisierung |
+| **S** | 1 | Bottom-of-Stack – ist dies das unterste Label im Stack? |
+| **TTL** | 8 | Time to Live – verhindert Schleifen |
+
+---
+
+### Reservierte Labels (0–15)
+
+| Label | Name | Bedeutung |
+|-------|------|-----------|
+| **0** | IPv4 Explicit Null | Pop Label, dann normales IPv4-Forwarding |
+| **1** | Router Alert | Paket soll speziell behandelt werden |
+| **2** | IPv6 Explicit Null | Pop Label, dann normales IPv6-Forwarding |
+| **3** | Implicit Null | PHP – vorletzter Router soll Label entfernen |
+| 4–15 | Reserviert | Noch nicht vergeben |
+
+---
+
+### Push / Swap / Pop
+
+| Operation | Wer macht es? | Was passiert? |
+|-----------|--------------|---------------|
+| **PUSH** | Ingress-Router (erster LER) | Label wird auf das Paket gedrückt |
+| **SWAP** | Transit-Router (LSR) | Altes Label wird durch neues ersetzt |
+| **POP** | Egress-Router (letzter LER) oder vorletzter (PHP) | Label wird entfernt |
+
+**Beispiel:**
+
+```
+Paket kommt an Router A (IP: 10.2.0.1):
+
+Router A (PUSH): [IP-Paket] → [Label 200][IP-Paket]
+Router B (SWAP): [Label 200] → [Label 350] (tauscht aus, leitet weiter)
+Router C (POP): [Label 350] → [IP-Paket] (entfernt, liefert aus)
+```
+
+---
+
+### FEC – Forwarding Equivalence Class
+
+Eine FEC ist eine **Gruppe von Paketen, die gleich behandelt werden** – gleicher Label, gleicher Weg, gleiche Behandlung.
+
+**Beispiel:**
+```
+Alle Pakete mit Ziel 192.168.10.0/24 → FEC „Richtung Standort Berlin"
+→ alle bekommen Label 200, alle gehen über den gleichen Pfad
+```
+
+Pakete werden am Ingress-Router in FECs eingeteilt – danach nur noch Label-Switching, keine IP-Entscheidungen mehr.
+
+---
+
+### LSP – Label Switched Path
+
+Der vorher festgelegte **Pfad durch das MPLS-Netz** von Ingress bis Egress. Wie eine Schiene.
+
+```
+CE1 → [PE1: Label 200 PUSH] → [P1: Label SWAP] → [P2: Label SWAP] → [PE2: POP] → CE2
+ ←————————————————— LSP ————————————————————→
+```
+
+---
+
+### Label Stack und S-Bit
+
+Labels können gestapelt werden (z.B. VPN-Label + Transport-Label). Das **S-Bit** zeigt an, ob ein Label das unterste im Stack ist:
+
+```
+[ Transport-Label S=0 ] ← nicht unterstes Label
+[ VPN-Label S=1 ] ← unterstes Label (Bottom of Stack)
+[ IP-Paket ]
+```
+
+Router schauen immer nur auf das **oberste Label**. Erst wenn S=1 ist wissen sie: nach dem Pop kommt direkt das IP-Paket.
+
+---
+
+### Forwarding Matrix (LFIB)
+
+Die Tabelle, die jeder MPLS-Router führt:
+
+```
+Eingehendes Label | Operation | Ausgehendes Label | Next Hop
+------------------|-----------|--------------------|----------
+200 | SWAP | 350 | 10.0.0.2
+350 | POP | - | 10.0.0.5
+- | PUSH 200 | 200 | 10.0.0.1 (für FEC 192.168.10.0/24)
+```
+
+---
+
+## 4. MPLS-Signalisierung
+
+Drei Protokolle verteilen die Labels – je nach Anwendungsfall:
+
+### LDP – Label Distribution Protocol
+
+- **Port:** TCP 646
+- **Schicht:** L7 (Application)
+- **Zweck:** Automatische Label-Verteilung für normales MPLS-Forwarding
+
+**Wie funktioniert es?**
+
+```
+Router C sagt zu B (via LDP): „Für FEC 10.2.0.0/24 → gib mir Label 42"
+Router B sagt zu A (via LDP): „Für FEC 10.2.0.0/24 → gib mir Label 17"
+→ LSP ist aufgebaut, Pakete können fließen.
+```
+
+**Link-LDP vs. Targeted-LDP:**
+
+| | Link-LDP | Targeted-LDP |
+|--|---------|--------------|
+| **Nachbarn** | Nur direkt verbundene Router | Auch nicht-direkt verbundene Router |
+| **Einsatz** | Normales MPLS | Pseudowires (VPWS, VPLS) |
+| **Discovery** | Multicast Hello | Unicast Hello |
+
+---
+
+### RSVP-TE – Resource Reservation Protocol – Traffic Engineering
+
+- **Protokoll:** IP Protokoll 46
+- **Schicht:** L3 (Network)
+- **Zweck:** LSPs mit Bandbreitenreservierung und expliziten Pfaden (Traffic Engineering)
+
+**Zwei Nachrichten:**
+
+| Nachricht | Richtung | Zweck |
+|-----------|----------|-------|
+| **PATH** | Ingress → Egress | „Ich will einen LSP aufbauen, reserviere Ressourcen" |
+| **RESV** | Egress → Ingress | „Ok, Ressourcen reserviert, hier ist dein Label" |
+
+**Beispiel:**
+
+```
+PE1 schickt PATH-Nachricht: „Ich will 100 Mbit/s von PE1 nach PE2, über P1 und P2"
+PATH wandert: PE1 → P1 → P2 → PE2
+PE2 antwortet mit RESV: „Ok, Label 500 zugeteilt"
+RESV wandert zurück: PE2 → P2 → P1 → PE1
+→ LSP steht, Bandbreite ist reserviert.
+```
+
+> **Unterschied zu LDP:** LDP nimmt den kürzesten IGP-Pfad. RSVP-TE kann **explizite Pfade** erzwingen und **Bandbreite reservieren** – daher für Traffic Engineering geeignet.
+
+---
+
+### MP-BGP – Multiprotocol BGP
+
+- **Port:** TCP 179
+- **Schicht:** L7 (Application)
+- **Zweck:** Labels und VPN-Routen verteilen (für L3 VPNs, VPLS Auto-Discovery)
+
+**Erweiterungen gegenüber normalem BGP:**
+
+| Feld | Bedeutung |
+|------|-----------|
+| **AFI** (Address Family Identifier) | Welche Adressfamilie? (IPv4=1, IPv6=2, L2VPN=25) |
+| **SAFI** (Subsequent AFI) | Welcher Subtyp? (Unicast=1, VPN=128, EVPN=70) |
+| **RD** (Route Distinguisher) | Macht VPN-Routen global eindeutig (8 Byte Präfix) |
+
+**Beispiel:**
+
+```
+Normale BGP-Route: 192.168.1.0/24
+MP-BGP VPNv4-Route: 65000:1:192.168.1.0/24
+ ←RD→ ←————IP————→
+```
+
+→ Gleiche IP-Adresse kann bei verschiedenen Kunden existieren, weil der RD sie unterscheidbar macht.
+
+---
+
+## 5. Ausfallsicherheit: BFD und FRR
+
+### BFD – Bidirectional Forwarding Detection
+
+- **Port:** UDP 3784
+- **Zweck:** Sehr schnelle Erkennung von Link-/Nachbar-Ausfällen (viel schneller als BGP/OSPF-Timer)
+
+**Die 3 Zustände:**
+
+```
+DOWN ──────→ INIT ──────→ UP
+ (Hello (Antwort
+ gesendet) erhalten)
+```
+
+| Zustand | Bedeutung |
+|---------|-----------|
+| **Down** | Keine Verbindung, oder gerade gestartet |
+| **Init** | Ich sende Hellos, habe aber noch keine Antwort |
+| **Up** | Beidseitige Verbindung bestätigt, alles ok |
+
+**Heartbeat:** BFD schickt alle **50ms** ein Hello-Paket. Kommen 3 aus, gilt der Nachbar als ausgefallen → **150ms** bis zur Fehlererkennung.
+
+> **Zum Vergleich:** OSPF-Dead-Interval ist standardmäßig 40 Sekunden. BFD ist also ~267x schneller.
+
+**Beispiel:**
+
+```
+Router A und B laufen, BFD-Session ist im Zustand UP.
+Link zwischen A und B fällt aus.
+Nach 150ms: Kein BFD-Hello mehr empfangen → BFD meldet „Nachbar down"
+→ OSPF/BGP bekommt sofort Bescheid → Router wechselt auf Backup-Route.
+Ohne BFD: OSPF würde erst nach 40 Sekunden reagieren.
+```
+
+---
+
+### FRR – Fast ReRoute
+
+- **Ziel:** Umschaltung auf Backup-Pfad in **unter 50ms** (nicht wahrnehmbar für Telefonie/Video)
+- **Funktioniert mit:** RSVP-TE, Segment Routing
+
+**Zwei Backup-Strategien:**
+
+#### One-to-One Backup
+
+Für jeden primären LSP wird ein **eigener Backup-LSP** vorbereitet.
+
+```
+Primär-LSP: PE1 → P1 → P2 → PE2
+Backup-LSP: PE1 → P3 → P4 → PE2 (vorbereitet, aber inaktiv)
+
+P1 fällt aus → sofort auf Backup-LSP umschalten
+```
+
+- **Vorteil:** Sehr schnell, dedizierter Pfad
+- **Nachteil:** Viele Ressourcen (für jeden LSP ein Backup)
+
+#### Facility Backup (auch: Bypass Tunnel)
+
+Ein einziger Bypass-Tunnel schützt **viele LSPs gleichzeitig**.
+
+```
+Primär-LSPs: LSP1, LSP2, LSP3 laufen alle über Link P1→P2
+Bypass: Ein Tunnel P1 → P3 → P2 schützt alle drei auf einmal
+
+P1→P2 fällt aus → alle drei LSPs werden automatisch in den Bypass umgeleitet
+```
+
+- **Vorteil:** Effizient, ein Bypass für viele LSPs
+- **Nachteil:** Weniger präzise Kontrolle
+
+---
+
+### Link Protection vs. Node Protection
+
+| | Link Protection | Node Protection |
+|--|-----------------|-----------------|
+| **Schützt gegen** | Ausfall eines Links | Ausfall eines ganzen Routers |
+| **Bypass geht** | Um den ausgefallenen Link herum | Um den ausgefallenen Knoten herum |
+| **Beispiel** | P1 → P2 fällt aus → Bypass P1 → P3 → P2 | P2 fällt komplett aus → Bypass P1 → P3 → PE2 |
+
+```
+Link Protection:
+PE1 → P1 → [X] → P2 → PE2
+ ↓
+PE1 → P1 → P3 → P2 → PE2 (umgeht nur den ausgefallenen Link)
+
+Node Protection:
+PE1 → P1 → [P2 komplett ausgefallen] → PE2
+ ↓
+PE1 → P1 → P3 → PE2 (umgeht den ganzen Router P2)
+```
+
+---
+
+### Local Repair vs. Global Repair
+
+| | Local Repair | Global Repair |
+|--|-------------|---------------|
+| **Wer handelt?** | Der Router direkt am Ausfall | Der Ingress-Router (PE1) |
+| **Wie schnell?** | Sofort (< 50ms) – Bypass bereits vorbereitet | Langsamer – neuer LSP muss erst berechnet werden |
+| **Qualität** | Suboptimaler Pfad möglich | Optimaler neuer Pfad |
+| **Typischer Ablauf** | Zuerst Local Repair → Verkehr fließt wieder | Dann Global Repair → Pfad wird optimiert |
+
+**Beispiel:**
+
+```
+1. Link P1→P2 fällt aus.
+2. P1 erkennt Ausfall sofort (via BFD, 150ms).
+3. LOCAL REPAIR: P1 leitet Pakete sofort über vorbereiteten Bypass (< 50ms).
+ → Verkehr fließt wieder, User merkt (fast) nichts.
+4. GLOBAL REPAIR: PE1 berechnet neuen optimalen LSP via RSVP-TE.
+ → Neuer LSP wird aufgebaut, Bypass wird freigegeben.
+```
+
+> **Zusammenspiel BFD + FRR:** BFD erkennt den Ausfall in ~150ms. FRR schaltet in <50ms um (Bypass war bereits vorbereitet). Zusammen ist die Unterbrechung für den Nutzer minimal.
\ No newline at end of file
diff --git a/Netzwerke/klausur/themenliste.md b/Netzwerke/klausur/themenliste.md
new file mode 100644
index 0000000..bd611bc
--- /dev/null
+++ b/Netzwerke/klausur/themenliste.md
@@ -0,0 +1,271 @@
+# Themenliste – Klausurvorbereitung Netzwerktechnik IT2221
+**Klausur:** Mo., 4. Mai 2026 | 14:00–16:00 Uhr | Räume 6B.369 / 6B.371
+
+> Fokus auf NW1–NW4. Themen ab NW5 sind ergänzend aufgeführt.
+
+---
+
+## NW1 – Grundlagen, Layer 2 & 3 Basics
+
+### Netzwerkgrundlagen
+- [ ] Definition Netzwerk & Netzwerkknoten
+- [ ] Netzwerk-Komponenten: Repeater, Hub, Bridge, Switch, Router, Gateway – Funktion & Unterschied
+- [ ] Adressierungsarten: **Unicast, Broadcast, Multicast, Anycast** (Merkmale, Richtung, Punkt-zu-Punkt vs. Mehrpunkt)
+
+### Netzwerk-Topologien
+- [ ] Physikalische vs. logische Topologie
+- [ ] **Bus-Topologie** – Vor-/Nachteile, Abschlusswiderstand
+- [ ] **Stern-Topologie** – Vor-/Nachteile, zentraler Switch
+- [ ] **Baum-Topologie** – Hierarchie, Engpass an Wurzel
+- [ ] **Maschen-Topologie (Mesh)** – Vollvermascht vs. teilvermascht, Redundanz
+- [ ] **Zell-Topologie (WLAN)** – Funkverbindung, Sicherheitsrisiken
+- [ ] **Leaf-Spine-Architektur** – Rechenzentrum, zwei Ebenen, Skalierbarkeit
+
+### Layer 2 – Sicherungsschicht (Data Link Layer)
+- [ ] **Switch-Funktionsweise**: Lernen, Unicast, Broadcast, Flooding
+- [ ] **CAM-Tabelle / MAC-Adresstabelle** – wie ein Switch MAC-Adressen lernt
+- [ ] **Ethernet-Rahmenformat**: Preamble, Dst/Src MAC, Type/Length, Data, CRC – Feldgrößen
+- [ ] **MAC-Adresse**: 48 Bit, OUI + Gerätenummer, Broadcast FF:FF:FF:FF:FF:FF
+
+### Layer 3 – Grundlagen IP
+- [ ] **IPv4-Adresse**: 32 Bit, 4 Oktette, Netzanteil + Hostanteil
+- [ ] Darstellung: punktgetrennte Dezimalzahlen, Binärdarstellung
+
+### ARP – Address Resolution Protocol
+- [ ] Funktion: IP → MAC Auflösung (Layer 2 ↔ Layer 3)
+- [ ] Lokales Subnetz: ARP-Broadcast; fremdes Subnetz: MAC des Gateways
+- [ ] **ARP-Ablauf**: Request (Broadcast) → Reply (Unicast) → Eintrag in ARP-Tabelle
+- [ ] Vollständiges Paket: 4 Adressen (Quell-/Ziel-MAC + Quell-/Ziel-IP)
+- [ ] **ARP-Spoofing** – Sicherheitsrisiko: Antworten nicht authentifiziert
+
+### ICMP – Internet Control Message Protocol
+- [ ] Zweck: Fehlermeldungen & Statusinformationen (kein Datentransport!)
+- [ ] Verbindungslos, kein automatischer Neuversand
+- [ ] **ICMP-Header**: Typ (8 Bit), Code (8 Bit), Checksumme (16 Bit)
+- [ ] **Ping** (Echo Request Typ 8 / Echo Reply Typ 0)
+- [ ] **ICMP Timestamp** – Laufzeitprüfung zwischen zwei Systemen
+
+---
+
+## NW2 – OSI-Modell, Layer 1 & 2, IPv4-Klassen
+
+### Entfernungsklassen
+- [ ] **PAN** (~1–10 m, Bluetooth), **LAN** (bis ~1 km), **MAN** (bis 100 km), **WAN** (Länder), **GAN** (weltweit)
+
+### OSI-Referenzmodell
+- [ ] **7 Schichten**: Physikalisch → Sicherung → Vermittlung → Transport → Sitzung → Darstellung → Anwendung
+- [ ] Zugehörige **PDUs**: Bits, Frames, Pakete, Segmente, Daten
+- [ ] Hardware-Zuordnung: Hub/Repeater (L1), Switch/Ethernet (L2), Router/IP (L3), TCP/UDP (L4)
+- [ ] **Datenkapselung**: SDU + Header = PDU beim Senden; Dekapsulation beim Empfang
+- [ ] **TCP/IP-Modell**: 4 Schichten (Network Access, Internet, Transport, Application)
+
+### Layer 1 – Übertragungsmedien
+- [ ] **Kupferkabel (Twisted-Pair)**: Differenzsignale, Wellenwiderstand 50 Ohm, EMV-Unterdrückung
+- [ ] **Glasfaser – Singlemode (OS1/OS2)**: Kern ~9 µm, Laser, bis 10 km+, hohe Bandbreite
+- [ ] **Glasfaser – Multimode (OM1–OM5)**: Kern 50/62,5 µm, LED/VCSEL, bis ~550 m
+
+### Layer 2 – Switching & Protokolle
+- [ ] **Switching-Methoden**: Store-and-Forward (vollständig prüfen) vs. Cut-Through (schnell, kein CRC)
+- [ ] **STP – Spanning Tree Protocol (802.1D)**: Verhindert Broadcast-Stürme, Root-Bridge-Wahl (Bridge ID = Priorität + MAC), Blocking-Zustand
+- [ ] **VLANs (802.1Q)**: Logische Netztrennung, statisch (Port) vs. dynamisch (MAC), max. 4095 VLANs
+
+### WLAN (802.11)
+- [ ] Shared Medium, Frequenzen 2,4 GHz vs. 5 GHz (Reichweite vs. Datenrate)
+- [ ] Verbindungsaufbau: **Scanning/Probing → Authentifizierung → Assoziation**
+
+### IPv4-Adressklassen
+- [ ] **Klasse A**: 1–126, /8, bis 16,7 Mio. Hosts
+- [ ] **Klasse B**: 128–191, /16, bis 65.534 Hosts
+- [ ] **Klasse C**: 192–223, /24, bis 254 Hosts
+- [ ] **Klasse D**: 224–239 (Multicast), **Klasse E**: 240–255 (Reserviert)
+- [ ] **Loopback**: 127.0.0.1
+- [ ] **Binärumrechnung**: Bit-Wertigkeiten 128|64|32|16|8|4|2|1, Umrechnung Dezimal ↔ Binär
+
+### MAC vs. IP
+- [ ] MAC = Hardware-Identität (fest, 48 Bit, L2), IP = logische Anschrift (veränderlich, L3)
+
+---
+
+## NW3 – VLAN, IPv4-Header, Subnetting, ICMP-Details, Routing
+
+### Layer 2 – VLAN & QoS
+- [ ] **IEEE 802.1Q** – Frame-Struktur mit VLAN-Tag: TPID (0x8100) + TCI (PCP 3 Bit + DEI 1 Bit + VID 12 Bit)
+- [ ] Trunk-Port (getaggt zwischen Switches) vs. Access-Port (ungetaggt zum Endgerät)
+- [ ] Inter-VLAN-Routing nur über Router möglich
+- [ ] **IEEE 802.1p** – QoS Layer 2: 8 PCP-Prioritätsstufen (0 = Best Effort, 7 = Network Control)
+
+### IPv4-Header (alle Felder kennen!)
+- [ ] Version, HLEN, TOS, Total Length
+- [ ] Datagram ID, Flags (Don't Fragment), Fragment Offset → Fragmentierung
+- [ ] **TTL** (Time to Live) – Hop-Counter, wird bei jedem Router um 1 dekrementiert
+- [ ] Protocol (1=ICMP, 6=TCP, 17=UDP), Header Checksum
+- [ ] Source/Destination IP (je 32 Bit)
+
+### Subnetting & CIDR
+- [ ] Netzadresse (alle Host-Bits = 0) & Broadcastadresse (alle Host-Bits = 1)
+- [ ] **Nutzbare Hosts = 2^n − 2** (n = Anzahl Host-Bits)
+- [ ] **AND-Funktion**: IP AND Subnetzmaske = Netzadresse
+- [ ] **Dezimaldarstellung der Masken**: 128, 192, 224, 240, 248, 252, 254, 255
+- [ ] **CIDR-Notation** (/0 bis /32): Bedeutung und Umrechnung
+- [ ] Wichtige CIDR-Werte: /30 = 4 Adr. (2 nutzb.), /28 = 16 Adr., /24 = 256 Adr.
+- [ ] Subnetting-Merkregeln: Netzadressen gerade, Broadcastadressen ungerade
+- [ ] **Subnetting-Berechnungsaufgaben** üben! (Gegeben IP+Maske → Netz, Broadcast, erste/letzte IP, Anzahl Hosts)
+- [ ] **Private Adressbereiche (RFC 1918)**: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
+
+### ICMP – Details (NW3-Vertiefung)
+- [ ] **Destination Unreachable (Typ 3)**: Code 0 = Network, 1 = Host, 2 = Protocol, 3 = Port Unreachable
+- [ ] **Time Exceeded (Typ 11)**: TTL auf 0 → Paket wird verworfen
+- [ ] **Traceroute**: TTL=1,2,3,... → Time-Exceeded-Antworten → Weg zum Ziel verfolgen
+
+### Routing-Grundlagen
+- [ ] **Statisches Routing** (manuell) vs. **Dynamisches Routing** (automatisch)
+- [ ] **Metrik**: Hop Count, Kosten, Bandbreite, Latenz, Fehlerrate, Auslastung
+- [ ] **Distance Vector** (Straßenschild – nur Richtung & Entfernung) vs. **Link State** (Straßenkarte – gesamte Topologie)
+- [ ] **IGP** (innerhalb AS: RIP, OSPF) vs. **EGP** (zwischen AS: BGP)
+- [ ] **Autonomes System (AS)** – AS-Nummern von IANA, private AS: 64512–65534
+- [ ] Routing-Protokoll-Übersicht: RIP, IGRP/EIGRP, OSPF, IS-IS, BGP – Typ & Metrik
+
+### OSPF – Open Shortest Path First
+- [ ] **SPF-Algorithmus (Dijkstra)**: LSDB → SPF-Baum → Routing-Tabelle
+- [ ] Metrik = Kosten (= Bandbreite, höhere BW = kleinere Kosten)
+- [ ] **LSDB**: alle Router in einer Area haben identische Datenbank
+- [ ] **DR / BDR** (Designated Router / Backup): Wahl über Priorität + Router-ID; DROther nur mit DR/BDR
+- [ ] **OSPF-Nachbarschaftszustände**: Init/Two-Way → Exstart → Exchange → Loading → **Full**
+- [ ] Hello-Pakete alle 10–30 s; Multicast 224.0.0.5 (alle OSPF) / 224.0.0.6 (DR); Protokoll 89
+- [ ] **OSPF Areas**: Area 0 = Backbone, ABR (Area Border Router), ASBR (AS Border Router)
+- [ ] **LSA-Typen**: Router-LSA (alle Router), Network-LSA (DR), Summary-LSA (ABR)
+- [ ] Virtual Links: Area 0 kann indirekt verbunden werden
+
+---
+
+## NW4 – Route Summarization, IPv6, DHCP, WAN
+
+### Route Summarization (IPv4)
+- [ ] **Algorithmus**: Binärdarstellung → identische Bits zählen → neues Präfix
+- [ ] Nur möglich, wenn Netze zum gleichen Next Hop führen
+- [ ] Beispiel: 172.16.0.0/24 bis 172.16.3.0/24 → 172.16.0.0/22
+- [ ] Ggf. mehrere Zusammenfassungen nötig (nicht-triviale Fälle)
+
+### IPv6 – Grundlagen & Motivation
+- [ ] IPv4-Adressknappheit: 2³² ≈ 4,3 Mrd. Adressen; IPv6: 2¹²⁸ ≈ 3,4×10³⁸
+- [ ] RFC 1883 / RFC 8200, IETF 1995
+- [ ] Verbesserungen: vereinfachter Header, kein Broadcast mehr, IPSec, QoS (Flow Label), SLAAC
+
+### IPv6-Header
+- [ ] **Feste Headerlänge: 40 Byte** (vs. mind. 20 Byte IPv4)
+- [ ] Felder: Version (4 Bit), Traffic Class (8 Bit, DSCP+ECN), **Flow Label** (20 Bit), Payload Length, **Next Header**, **Hop Limit** (= TTL)
+- [ ] **Extension Headers**: Hop-by-Hop, Routing (43), Fragment (44), AH (51), ESP (50), Destination Options (60)
+- [ ] EtherType IPv6: **0x86DD**; IPv4: **0x0800**
+
+### IPv6-Adressierung
+- [ ] 128 Bit, 8 Blöcke à 16 Bit, hexadezimal, getrennt durch `:`
+- [ ] Führende Nullen weglassen, aufeinanderfolgende Nullblöcke → `::` (nur 1× pro Adresse!)
+- [ ] Struktur: **64 Bit Netz-Präfix + 64 Bit Interface ID**
+- [ ] CIDR-Notation wie IPv4 (z.B. `2001:db8::/32`)
+
+### IPv6-Adresstypen
+- [ ] **Loopback**: `::1` (= 127.0.0.1)
+- [ ] **Unspecified**: `::` (vor Adresszuweisung)
+- [ ] **Default Route**: `::/0`
+- [ ] **Global Unicast (2000::/3)**: weltweit routbar, vom ISP zugewiesen
+- [ ] **Link-Local Unicast (FE80::/10)**: nur lokales Segment, nicht geroutet, jedes Interface hat eine
+- [ ] **Multicast (FF00::/8)**: ersetzt Broadcast; Scope-Feld (Link, Site, Global, ...)
+- [ ] **Anycast**: syntaktisch Global Unicast, mehrfach vergeben, nächster Knoten antwortet
+- [ ] **Kein Broadcast in IPv6**
+
+### EUI-64 & Privacy Extension
+- [ ] **EUI-64**: MAC (48 Bit) → zwei 3-Byte-Blöcke + FFFE einsetzen + U/L-Bit invertieren → 64-Bit Interface ID
+- [ ] **Privacy Extension**: zufällige Interface ID statt EUI-64 (verhindert Tracking)
+
+### ICMPv6 & Neighbor Discovery Protocol (NDP)
+- [ ] ICMPv6 übernimmt mehr Aufgaben als ICMPv4 (ARP-Ersatz, Router Discovery, SLAAC)
+- [ ] **RS (133)**: Host → alle Router (ff02::2) – Router anfordern
+- [ ] **RA (134)**: Router → alle Hosts (ff02::1) – Präfix, Default-GW, Flags (A-Flag, M-Flag)
+- [ ] **NS (135)**: ARP-Ersatz – Solicited-Node-Multicast
+- [ ] **NA (136)**: Antwort auf NS mit eigener MAC
+- [ ] **Redirect (137)**
+
+### SLAAC & DAD
+- [ ] **SLAAC**: Host generiert Adresse aus Präfix (RA) + Interface ID (EUI-64/zufällig), ohne DHCP
+- [ ] **DAD (Duplicate Address Detection)**: NS an eigene Solicited-Node-Multicast-Adresse → kein NA → Adresse eindeutig
+
+### IPv4 → IPv6 Migration
+- [ ] **Dual Stack**: IPv4 und IPv6 parallel, bevorzugte Methode
+- [ ] **Tunneling**: 6in4 (manuell, empfohlen), 6-to-4, 6rd, Teredo (hinter NAT)
+
+### DHCP (Dynamic Host Configuration Protocol)
+- [ ] **DORA-Prozess**: Discover → Offer → Request → Acknowledge
+- [ ] DHCP arbeitet per Broadcast → Limited Broadcast 255.255.255.255
+- [ ] **DHCP Relay**: Router leitet DHCP-Broadcast in andere Subnetze (Option 82)
+- [ ] Lease-Erneuerung: nach 50% (Unicast), nach 7/8 (Broadcast), nach 100% (Discover)
+- [ ] Fehlernachrichten: DHCP-Decline, DHCP-NACK, DHCP-Release, DHCP-Inform
+
+### WAN & PPPoE
+- [ ] WAN verbindet LANs über große Entfernungen (Layer 1–3)
+- [ ] Verbindungsarten: Dediziert (Mietleitungen) vs. Switching (Leitungs- vs. Paketvermittelt)
+- [ ] Aktuelle Technologien: FTTH, DSL, DOCSIS, LTE/5G, Satellit
+- [ ] **PPPoE** (RFC 2516): IP über Modem/DSL, Authentifizierung via LCP
+- [ ] PPPoE-Discovery: PADI → PADO → PADR → PADS (Session-ID)
+
+---
+
+## NW5–NW7 – Ergänzende Themen
+
+### Layer 4 – Transport (NW5)
+- [ ] **TCP**: verbindungsorientiert, 3-Way-Handshake (SYN, SYN-ACK, ACK), 4-Way-Handshake (FIN)
+- [ ] TCP-Header-Felder: Ports, Sequenznummer, Acknowledgement-Nummer, Flags, Window-Größe
+- [ ] **Sliding Window**: Flusskontrolle, Window-Größe steuert Datenmenge ohne ACK
+- [ ] **Staukontrolle (CWND)**: Slow Start, Congestion Avoidance
+- [ ] **UDP**: verbindungslos, kein Handshake, kein Retransmit, minimal-Header (8 Byte)
+- [ ] Wichtige Ports: HTTP=80, HTTPS=443, DNS=53, DHCP=67/68, SSH=22
+
+### NAT – Network Address Translation (NW5)
+- [ ] Zweck: private IPs → öffentliche IP (RFC 1918)
+- [ ] **PAT / NAT Overload**: Port-basierte Unterscheidung (viele Clients → 1 öffentliche IP)
+- [ ] **NAT64**: IPv6-Clients → IPv4-Server
+
+### DNS – Domain Name Service (NW5)
+- [ ] Auflösung: Domainname → IP-Adresse
+- [ ] Hierarchie: Root → TLD → Second Level Domain
+- [ ] **Record-Typen**: A (IPv4), AAAA (IPv6), CNAME (Alias), MX (Mail), NS (Nameserver), PTR (Reverse), SOA
+- [ ] **Rekursive vs. iterative Anfrage**
+- [ ] DNS-Sicherheit: DNS Spoofing/Cache Poisoning, DDoS, DNS-Tunneling
+
+### BGP – Border Gateway Protocol (NW6)
+- [ ] **Path-Vector-Protokoll**, EGP, zwischen autonomen Systemen
+- [ ] BGP-Nachrichtentypen: OPEN, UPDATE, NOTIFICATION, KEEPALIVE
+- [ ] Pfadattribute: AS-Path, Next Hop, Local Pref, MED, Origin
+- [ ] **iBGP vs. eBGP** (intern vs. extern), Route Reflector
+- [ ] Transit vs. Peering (ISP-Hierarchie: Tier 1/2/3)
+
+### MPLS – Multiprotocol Label Switching (NW6/NW7)
+- [ ] Labels statt IP-Lookup → schnelleres Forwarding
+- [ ] Terminologie: LSR, LER, FEC, LSP
+- [ ] **Label-Operationen**: Push, Pop, Swap
+- [ ] Signalisierung: LDP, RSVP-TE, MP-BGP
+- [ ] **MPLS VPNs** (NW7): L2 (VPWS, VPLS, H-VPLS), L3 (BGP/MPLS IP VPN, VRF, RD, RT, PHP)
+
+### Ausfallsicherheit (NW6/NW7)
+- [ ] **BFD (Bidirectional Forwarding Detection)**: schnelle Link-Failure-Erkennung
+- [ ] **MPLS Fast Reroute (FRR)**: One-to-One Backup, Facility Backup
+
+### Segment Routing (NW7)
+- [ ] Ingress-Router legt gesamten Pfad als Segmentliste fest
+- [ ] **Node/Prefix SID** (global, kürzester Pfad) vs. **Adjacency SID** (lokal, expliziter Link)
+- [ ] SR-MPLS und SRv6; vereinfacht Control Plane gegenüber klassischem MPLS
+
+### Troubleshooting (NW6/NW7)
+- [ ] **7-Schritt-Methodik**: Problem definieren → Informationen sammeln → Analysieren → Hypothese → Testen → Korrigieren → Verifizieren
+- [ ] Typische Fehlerquellen: OSPF-Nachbarschaft, BGP-Redistribution, MTU/Adressen, DHCP
+
+---
+
+## Klausur-Checkliste: Rechenaufgaben üben
+
+- [ ] **Binärumrechnung** Dezimal ↔ Binär (einzelne Oktette)
+- [ ] **Subnetting**: Netzadresse, Broadcastadresse, erste/letzte nutzbare IP, Anzahl Hosts
+- [ ] **CIDR-Notation** lesen und umrechnen
+- [ ] **Route Summarization**: mehrere Netze binär aufschreiben, gemeinsame Bits finden
+- [ ] **IPv6-Adressen** kürzen und entfalten (`::` Notation)
+- [ ] **EUI-64**: MAC-Adresse → IPv6 Interface ID berechnen
+- [ ] **OSPF-Kosten** aus Bandbreite berechnen (Referenzbandbreite / Schnittstellenbandbreite)
diff --git a/Netzwerke/labor/Configuration commands.pdf b/Netzwerke/labor/Configuration commands.pdf
new file mode 100644
index 0000000..1e87dba
Binary files /dev/null and b/Netzwerke/labor/Configuration commands.pdf differ
diff --git a/Netzwerke/labor/Lab Support Document.md b/Netzwerke/labor/Lab Support Document.md
new file mode 100644
index 0000000..3708a5e
--- /dev/null
+++ b/Netzwerke/labor/Lab Support Document.md
@@ -0,0 +1,517 @@
+# OSPF-BGP Lab – Komplette Referenz
+
+## Inhaltsverzeichnis
+
+1. [Lab-Übersicht & Ziel](#1-lab-%C3%BCbersicht--ziel)
+2. [Netzwerktopologie](#2-netzwerktopologie)
+3. [Konfigurationen der Geräte](#3-konfigurationen-der-ger%C3%A4te)
+ - [München (Edge-Router, ABR)](#31-m%C3%BCnchen-edge-router-abr)
+ - [Nürnberg (ABR)](#32-n%C3%BCrnberg-abr)
+ - [Berlin (ASBR, NAT-Gateway, Core-Router)](#33-berlin-asbr-nat-gateway-core-router)
+ - [DHCP-Server](#34-dhcp-server)
+ - [ISP-Telekom (AS 65001)](#35-isp-telekom-as-65001)
+4. [NAT-Konfiguration – Erklärung](#4-nat-konfiguration--erkl%C3%A4rung)
+5. [Troubleshooting – Befehle & Methoden](#5-troubleshooting--befehle--methoden)
+ - [Endgeräte (Windows / Linux)](#51-endger%C3%A4te-windows--linux)
+ - [Interfaces & Layer 1/2](#52-interfaces--layer-12)
+ - [Switching & Layer 2](#53-switching--layer-2)
+ - [Routing, DHCP & NAT (Layer 3)](#54-routing-dhcp--nat-layer-3)
+ - [OSPF Troubleshooting](#55-ospf-troubleshooting)
+ - [BGP Troubleshooting](#56-bgp-troubleshooting)
+ - [Troubleshooting-Methoden](#57-troubleshooting-methoden)
+
+---
+
+## 1. Lab-Übersicht & Ziel
+
+Das Lab simuliert ein **großes Unternehmensnetzwerk (AS 65000)**, das über einen Internet Service Provider (**ISP-Telekom, AS 65001**) mit dem echten, physischen Internet (France-Orange / Google) verbunden ist.
+
+### Was passiert bei `ping google.com` vom PC in München?
+
+|Schritt|Layer|Was passiert|
+|---|---|---|
+|1|L7 (DNS/DHCP)|PC bekommt IP per DHCP (via `ip helper-address`). DNS löst `google.com` → 8.8.8.8 auf.|
+|2|L3 (OSPF)|München nutzt OSPF → Route über Nürnberg zum Core-Router Berlin. Area 0 (Backbone), Area 100/200 (Edge).|
+|3|L2|LLDP (`lldp run`) erkennt Nachbarn auf MAC-Ebene und verhindert Schleifen.|
+|4|L3 (NAT 1)|Berlin übersetzt private IP (`192.168.12.x`) → eigene externe IP (`88.1.1.1`).|
+|5|L3 (BGP)|Berlin schickt Paket per eBGP an ISP-Telekom.|
+|6|L3 (NAT 2)|ISP-Telekom übersetzt `88.1.1.1` → IP des Heimnetzwerks (France-Orange) → Double NAT.|
+|7|—|Paket erreicht Google. Rückweg läuft über NAT und OSPF/BGP wieder rückwärts.|
+
+**Schlüsselkombination für Internet-Erreichbarkeit:**
+
+- ISP sendet Default-Route via BGP: `neighbor 88.1.1.1 default-originate`
+- Berlin verteilt sie ins OSPF: `default-information originate`
+
+---
+
+## 2. Netzwerktopologie
+
+```
+ ┌─────────────────────────────┐
+ │ Area 0 (Backbone) │
+ Area 100 │ │ Area 200
+┌──────────────┐ │ Nürnberg ──── Berlin ──── Magdeburg ┌──────────────┐
+│ München │ │ (ABR) (ASBR) (ABR) │ Düsseldorf │
+│ 192.168.12 │ │ │ │ 192.168.1 │
+└──────────────┘ │ DHCP-Server └──────────────┘
+ └─────────────────────────────┘
+ │
+ ISP-Telekom
+ (AS 65001)
+ │
+ France-Orange
+ (echtes Internet)
+```
+
+**Wichtige Netze:**
+
+|Segment|Netz|Bereich|
+|---|---|---|
+|München–Nürnberg|`192.168.100.0/30`|Area 100|
+|Nürnberg–Berlin|`100.0.10.0/30`|Area 0|
+|Berlin–Magdeburg|`100.0.20.0/30`|Area 0|
+|Nürnberg–Magdeburg|`100.0.255.0/30`|Area 0|
+|Berlin–DHCP-Server|`192.168.10.0/30`|Area 0|
+|Berlin–ISP (BGP)|`88.1.1.0/30`|extern|
+|LAN München|`192.168.12.0/24`|Area 100|
+|LAN Düsseldorf|`192.168.1.0/24`|Area 200|
+
+---
+
+## 3. Konfigurationen der Geräte
+
+### 3.1 München (Edge-Router, ABR)
+
+> **Rolle:** Randrouter in Area 100. DHCP-Relay für das lokale LAN. Kein direkter Internet-Zugang – nutzt Default-Route via OSPF.
+
+```cisco
+ip name-server 8.8.8.8 8.8.4.4
+
+interface Loopback0
+ ip address 217.217.217.217 255.255.255.255
+
+interface Ethernet0/0
+ description ##to-Nuernberg##
+ ip address 192.168.100.2 255.255.255.252
+
+interface Ethernet0/1
+ description ##LAN-MUENCHEN##
+ ip address 192.168.12.254 255.255.255.0
+ ip helper-address 192.168.10.2 ! DHCP-Relay → zentraler DHCP-Server
+
+interface Ethernet0/2
+ no ip address
+ shutdown
+
+interface Ethernet0/3
+ no ip address
+ shutdown
+
+router ospf 217
+ passive-interface Ethernet0/1 ! Kein OSPF-Hello ins LAN (Sicherheit)
+ passive-interface Loopback0
+ network 192.168.12.0 0.0.0.255 area 100
+ network 192.168.100.0 0.0.0.3 area 100
+ network 217.217.217.217 0.0.0.0 area 100
+
+ip route 0.0.0.0 0.0.0.0 192.168.100.1 ! Statische Default-Route → Nürnberg
+```
+
+---
+
+### 3.2 Nürnberg (ABR)
+
+> **Rolle:** Area Border Router zwischen Area 100 (München) und Area 0 (Backbone). Verbindet auch Magdeburg (via `100.0.255.0/30`).
+
+```cisco
+ip name-server 8.8.8.8 8.8.4.4
+
+interface Loopback0
+ ip address 219.219.219.219 255.255.255.255
+
+interface Ethernet0/0
+ description ##to-Muenchen##
+ ip address 192.168.100.1 255.255.255.252
+
+interface Ethernet0/1
+ description ##to-Berlin##
+ ip address 100.0.10.2 255.255.255.252
+
+interface Ethernet0/2
+ description ##to-Magdeburg##
+ ip address 100.0.255.1 255.255.255.252
+
+interface Ethernet0/3
+ no ip address
+ shutdown
+
+router ospf 12
+ network 100.0.10.0 0.0.0.3 area 0
+ network 192.168.100.0 0.0.0.255 area 100 ! Inkludiert den /30-Link zu München
+ network 219.219.219.219 0.0.0.0 area 0
+
+ip route 0.0.0.0 0.0.0.0 100.0.10.1 ! Default-Route → Berlin
+```
+
+> ⚠️ **Hinweis:** `network 192.168.100.0 0.0.0.255 area 100` (Wildcard `/24`) deckt die `192.168.100.0/30`-Verbindung zu München ab. Das ABR-Verhalten macht Nürnberg zum Übergang zwischen Area 100 und Area 0.
+
+---
+
+### 3.3 Berlin (ASBR, NAT-Gateway, Core-Router)
+
+> **Rolle:** Herzstück des Netzes. Verbindet OSPF (intern) mit BGP (extern), macht NAT für das gesamte `192.168.0.0/16`- und `100.0.0.0/16`-Netz.
+
+```cisco
+ip name-server 8.8.8.8 8.8.4.4
+
+interface Loopback0
+ ip address 220.220.220.220 255.255.255.255
+
+interface Ethernet0/0
+ description ##to-Nuernberg##
+ ip address 100.0.10.1 255.255.255.252
+ ip nat inside
+
+interface Ethernet0/1
+ description ##to-Magdeburg##
+ ip address 100.0.20.1 255.255.255.252
+ ip nat inside
+
+interface Ethernet0/2
+ description ##Internet##
+ ip address dhcp ! Bekommt externe IP von ISP/France-Orange
+ ip nat outside
+
+interface Ethernet0/3
+ description ##to-DHCP-SERVER##
+ ip address 192.168.10.1 255.255.255.252
+ ip nat inside
+
+! --- OSPF ---
+router ospf 220
+ router-id 220.220.220.220
+ passive-interface Ethernet0/2 ! Kein OSPF ins Internet
+ network 100.0.10.0 0.0.0.3 area 0
+ network 100.0.20.0 0.0.0.3 area 0
+ network 192.168.10.0 0.0.0.3 area 0
+ network 220.220.220.220 0.0.0.0 area 0
+ redistribute bgp 65000 metric 10 metric-type 1 ! BGP-Routen ins OSPF einbringen
+ default-information originate ! Default-Route (0.0.0.0) ins OSPF verteilen
+
+! --- BGP ---
+router bgp 65000
+ network 192.168.0.0 mask 255.255.0.0 ! Eigenes Netz dem ISP ankündigen
+ neighbor 88.1.1.2 remote-as 65001 ! eBGP-Nachbarschaft zum ISP
+
+! --- NAT ---
+ip access-list standard 1
+ 10 permit 192.168.0.0 0.0.255.255 ! Alle privaten 192.168.x.x-Netze
+ 20 permit 100.0.0.0 0.0.255.255 ! Interne 100.0.x.x-Netze
+
+ip nat inside source list 1 interface Ethernet0/2 overload ! PAT auf externe IP
+
+ip route 0.0.0.0 0.0.0.0 dhcp ! Default-Route von DHCP (ISP)
+```
+
+---
+
+### 3.4 DHCP-Server
+
+> **Rolle:** Zentraler DHCP-Dienst für München und Düsseldorf. Erreichbar über `ip helper-address` auf den jeweiligen Edge-Routern.
+
+```cisco
+hostname DHCP-SERVER
+
+! --- Ausschluss statischer IPs (werden nicht per DHCP vergeben) ---
+ip dhcp excluded-address 192.168.12.254 ! Gateway München
+ip dhcp excluded-address 192.168.12.1 192.168.12.10
+ip dhcp excluded-address 192.168.1.1 192.168.1.10
+ip dhcp excluded-address 192.168.1.254 ! Gateway Düsseldorf
+
+! --- DHCP-Pool München ---
+ip dhcp pool Muenchen
+ network 192.168.12.0 255.255.255.0
+ default-router 192.168.12.254
+ dns-server 8.8.8.8 8.8.4.4
+ lease 7 ! Lease-Zeit: 7 Tage
+
+! --- DHCP-Pool Düsseldorf ---
+ip dhcp pool Duesseldorf
+ network 192.168.1.0 255.255.255.0
+ default-router 192.168.1.254
+ dns-server 8.8.8.8 8.8.4.4
+ lease 7
+
+! --- Interface & Default-Route ---
+interface Ethernet0/0
+ description ##to-BERLIN##
+ ip address 192.168.10.2 255.255.255.252
+
+ip route 0.0.0.0 0.0.0.0 192.168.10.1 ! Default-Route → Berlin
+```
+
+---
+
+### 3.5 ISP-Telekom (AS 65001)
+
+> **Rolle:** Simuliert den Internet Service Provider. Baut eBGP-Nachbarschaft zu Berlin auf, verteilt Default-Route und macht Double NAT zum echten Heimnetzwerk (France-Orange).
+
+```cisco
+! --- Interface zum echten Internet (France-Orange) ---
+interface Ethernet0/1
+ ip address dhcp ! Echte IP vom Heimrouter
+ ip nat outside
+
+interface Ethernet0/0
+ ip nat inside
+
+! --- NAT (Double NAT für das Lab) ---
+ip access-list standard 10
+ 10 permit 88.1.1.0 0.0.0.3 ! Transfernetz Berlin↔ISP
+
+ip nat inside source list 10 interface Ethernet0/1 overload
+
+! --- BGP ---
+router bgp 65001
+ neighbor 88.1.1.1 remote-as 65000 ! eBGP-Nachbarschaft zu Berlin
+ neighbor 88.1.1.1 default-originate ! Gibt Berlin eine Default-Route (→ Internet)
+
+! --- Default-Route ins echte Internet ---
+ip route 0.0.0.0 0.0.0.0 dhcp
+```
+
+---
+
+## 4. NAT-Konfiguration – Erklärung
+
+### Schritt 1: Access-List definieren – wer darf NAT nutzen?
+
+```cisco
+ip access-list standard 1
+ 10 permit 192.168.0.0 0.0.255.255
+```
+
+> Die Wildcard `0.0.255.255` bedeutet: Erste zwei Oktette (`192.168`) müssen exakt passen, die letzten zwei sind beliebig → alle IPs von `192.168.0.0` bis `192.168.255.255` sind erlaubt.
+
+---
+
+### Schritt 2: NAT Overload (PAT) aktivieren
+
+```cisco
+ip nat inside source list 1 interface Ethernet0/2 overload
+```
+
+> `overload` = **PAT (Port Address Translation)**. Mehrere interne Hosts teilen sich eine öffentliche IP – die Unterscheidung erfolgt über unterschiedliche Portnummern. Ohne `overload` könnte nur ein Host gleichzeitig die externe IP nutzen.
+
+---
+
+### Schritt 3: NAT-Rollen der Interfaces festlegen
+
+```cisco
+interface Ethernet0/0
+ ip nat inside ! Interne Seite (Richtung Nürnberg / LAN)
+
+interface Ethernet0/2
+ ip nat outside ! Externe Seite (Richtung ISP / Internet)
+```
+
+---
+
+## 5. Troubleshooting – Befehle & Methoden
+
+> 💡 **Goldene Regel:** Immer nach dem **OSI-Modell von unten nach oben** arbeiten (Bottom-Up): Kabel → Interfaces → Nachbarschaften → Routing-Tabelle → Anwendung.
+
+---
+
+### 5.1 Endgeräte (Windows / Linux)
+
+#### Windows
+
+```cmd
+ipconfig /all # IP, Subnetzmaske, Gateway, DNS – prüft ob DHCP funktioniert hat
+ping Lösung
+ +10.1.2.0/23 deckt bereits .2 und .3. +Also sind insgesamt .0, .1, .2, .3 abgedeckt → 4 aufeinanderfolgende /24-Äquivalente. +3. Oktett: 0–3 → 22 identische Bits +**Ergebnis: 10.1.0.0/22** + +
+
+## 1. Troubleshooting Methodology
+
+Strukturiertes Vorgehen bei Netzwerkproblemen (z.B. PC bekommt keine IP, PC erreicht anderes Gerät nicht):
+
+1. **Problem definieren** – Was genau funktioniert nicht?
+2. **Informationen sammeln** – `show`-Befehle ausführen
+3. **Daten analysieren** – Routingtabellen, Nachbarzustände prüfen
+4. **Hypothese formulieren** – Welche OSI-Schicht ist betroffen?
+5. **Hypothese testen** – Paketmitschnitte (PCAPs) auswerten
+6. **Korrektur implementieren**
+7. **Überprüfen & dokumentieren**
+
+Typische Fehlerquellen im Labor: OSPF-Nachbarschaft, BGP-Redistribution, falsche MTU/Adressen an Interfaces.
+
+---
+
+## 2. VPNs über MPLS – Grundidee
+
+**Ziel:** Mehrere Unternehmensstandorte über einen gemeinsamen Provider-Backbone verbinden, dabei aber voneinander isoliert halten.
+
+**Anforderungen (Wunschliste):**
+- Nutzung des bestehenden SP-Backbones
+- Überlappende Adressräume erlaubt (verschiedene Kunden dürfen gleiche IPs nutzen)
+- Datentrennung zwischen VPNs
+- Skalierung, QoS, einfache Verwaltung
+
+---
+
+## 3. VPN-Klassifizierung (RFC 4026 – PPVPN)
+
+```
+PPVPN
+├── Layer 2
+│ ├── P2P → VPWS (Virtual Private Wire Service)
+│ └── M2M → VPLS (Virtual Private LAN Service)
+└── Layer 3
+ ├── PE-based
+ │ ├── BGP/MPLS IP VPNs
+ │ └── Virtual Router
+ └── CE-based
+ └── IPsec
+```
+
+---
+
+## 4. Grundbegriffe: AC, Pseudowire, Tunnel LSP
+
+### Attachment Circuit (AC)
+
+Physischer oder logischer Anschluss zwischen Kundengerät (**CE**) und Provider-Edge-Router (**PE**). Kann sein: Ethernet-Port, VLAN, PPP, MPLS LSP, etc.
+
+```
+[CE-Gerät] ---AC--- [PE-Gerät] --- Service Provider Network
+```
+
+### Pseudowire (PW)
+
+Ein virtueller „Draht" durch das Provider-Netz, der L2-Daten von einem AC zu einem anderen transportiert.
+
+- Nur den beiden **Endpunkt-PEs** bekannt
+- Wird über einen **Tunnel (LSP)** transportiert, der allen Routern (LSRs) dazwischen bekannt ist
+- Pro Richtung ein unidirektionaler Tunnel → ein PW = 2 LSPs
+
+### Tunnel LSP – Label Stacking
+
+Mehrere Pseudowires zwischen zwei PEs werden in einem Tunnel aggregiert:
+
+- **Äußeres Label** = Tunnel LSP (für P-Router sichtbar, sorgt für Transport)
+- **Inneres Label** = Pseudowire LSP (nur PEs kennen es)
+
+> P-Router schauen **nur auf das äußere Label** und leiten entsprechend weiter – sie kennen die VPN-Details nicht.
+
+---
+
+## 5. Layer-2-Dienste: VPWS und VPLS
+
+### VPWS – Virtual Private Wire Service
+
+- **Point-to-Point**: genau ein AC ↔ genau ein PW
+- Transparente L2-Verbindung zwischen zwei Standorten
+- MPLS definiert Labelverteilung und Kapselung
+- Einsatz von **LDP (Targeted Mode)** oder **MP-BGP** zur Signalisierung
+
+**Forwarding-Beispiel (VPWS):**
+
+Ein PE empfängt einen VLAN1-Frame vom Kunden. Er schlägt in seiner FEC-Tabelle nach und findet: `VLAN1 → Out-Label 24, Next-Hop 1.1.1.1`. Zusätzlich drückt er ein Transport-Label (z.B. 16) obendrauf. Der Transit-Router (LSR) sieht nur das Transport-Label und leitet weiter. Der Egress-PE entfernt das äußere Label, erkennt anhand des inneren Labels (24) die Ziel-Schnittstelle und sendet den Frame an den Kunden.
+
+**VPWS Protection – Auslöser für Umschaltung auf Standby-PW:**
+
+- Manueller Eingriff (Precedence-Wert ändern)
+- Statusänderung des PW
+- Ausfall des aktiven PW
+- Benachrichtigung vom Remote-Peer (via T-LDP Notification Message)
+
+---
+
+### VPLS – Virtual Private LAN Service
+
+- **Multipoint-to-Multipoint**: mehrere Standorte agieren wie in einem gemeinsamen Ethernet-LAN
+- Jeder PE enthält ein **Switch-Modul** mit einem emulierten LAN (MAC-Learning, Flooding)
+- Standorte tauschen Ethernet-Frames direkt aus, als wären sie physisch im selben LAN
+
+**Architektur:**
+
+```
+[Kunde CE] --AC--> [PE: VPLS Forwarder + Emulated LAN Interface]
+ <------ VPLS PW ------>
+ [PE] --AC--> [Kunde CE]
+```
+
+**Skalierungsproblem:** Bei N Standorten braucht man **N*(N-1)/2 Pseudowires** (Vollvermaschung). Bei vielen Standorten entstehen viele States und viel Broadcast-Traffic.
+
+**Lösung: Hierarchisches VPLS (H-VPLS)**
+
+PE-Router werden in zwei Ebenen aufgeteilt:
+
+| Ebene | Gerät | Aufgabe |
+|-------|-------|---------|
+| Kern | **Hub-PE** | Vollvermaschung zwischen Hubs |
+| Rand | **Spoke-PE / MTU-s** | Aggregiert Kundenports zu einer einzigen Spoke-PW zum Hub |
+
+- Neue Verbindung nur zwischen Spoke und Hub, kein direktes Mesh zwischen allen Spokes
+- **Vorteile:** Weniger PWs, weniger Broadcast-Replikation, bessere Skalierbarkeit
+
+**Multi-Tenant Unit (MTU-s):** Gerät (Router, Switch oder Gateway), das viele Kundenports aggregiert und eine einzige Spoke-PW zum nächsten PE aufbaut.
+
+**Dual Homed MTUs:** MTU ist an zwei PEs angebunden → Redundanz bei Ausfall einer Verbindung.
+
+**VPLS Auto-Discovery (RFC 4761):** PE-Router erkennen automatisch andere PEs derselben VPLS-Domäne via MP-BGP, ohne manuelle Konfiguration jedes einzelnen Pseudowires.
+
+**VPLS Protection:** Backup-LSPs werden über T-LDP aufgebaut; Überwachung via BFD (Bidirectional Forwarding Detection).
+
+**VPLS und MTU-Größen:**
+
+| Pakettyp | L2 MTU |
+|----------|--------|
+| Normales MPLS-Paket | 1504 |
+| Ethernet over VPLS | 1508 |
+| VLAN over VPLS | 1526 |
+
+> VPLS fügt zusätzliche Header ein (MPLS-Label + VPLS-Label), was die MTU erhöht. Alle Geräte im Pfad müssen diese größeren Frames unterstützen.
+
+---
+
+## 6. Layer-3-VPNs: BGP/MPLS IP VPNs (RFC 4364)
+
+### Motivation
+
+- Kunden nutzen **private IP-Adressen** (RFC 1918) → können sich überschneiden
+- Provider übernimmt das Routing → Kunde muss sich nicht darum kümmern
+- MPLS-Backbone ist für den Kunden **transparent**
+
+### Beteiligte Geräte
+
+| Gerät | Aufgabe |
+|-------|---------|
+| **CE** (Customer Edge) | Kundenrouter, kennt nur seine eigene Seite |
+| **PE** (Provider Edge) | Kennt VPN-Routen; verwaltet VRFs; stellt MPLS-Pfade auf |
+| **P** (Provider Core) | Reine Transitknoten; kennen keine VPNs, nur MPLS-Labels |
+
+### VRF – VPN Routing and Forwarding Table
+
+Jeder PE führt **separate Routing-Tabellen pro Kunde** (VRF). Diese werden via **MP-BGP** zwischen den PEs ausgetauscht.
+
+**Problem:** BGP kann normalerweise nur eine Route pro IP-Präfix installieren – aber verschiedene Kunden können dieselben Adressen haben.
+
+**Lösung: Route Distinguisher (RD)**
+
+---
+
+### Route Distinguisher (RD)
+
+Ein **8-Byte-Präfix**, der jeder VPN-Route vorangestellt wird, um sie global eindeutig zu machen:
+
+```
+[Type 2B] [Administrator 2-4B] [Assigned Number 2-4B] + [IPv4-Adresse 8B] = 12 Bytes
+```
+
+**Beispiele:**
+
+```
+RD: 65000:101 (AS-Nummer : zugewiesene Nummer)
+RD: 10.0.0.1:1001 (IP-Adresse : zugewiesene Nummer)
+RD: 1000000:10
+```
+
+**Ergebnis:** Aus `192.168.1.10` wird die **VPNv4-Adresse** `65000:1:192.168.1.10` → global eindeutig, kein Konflikt trotz Adressüberlappung.
+
+> **Wichtig:** Der RD macht Adressen nur **eindeutig**. Er steuert *nicht*, welche Routen wohin verteilt werden – das macht der Route Target.
+
+---
+
+### Route Target (RT)
+
+Ein **BGP Extended Community Attribut** (RFC 4360), das steuert, welche Routen in welches VRF importiert/exportiert werden.
+
+Jede VRF hat:
+- **Export Target**: welcher RT wird angefügt, wenn eine Route exportiert wird
+- **Import Target**: welche eingehenden Routen werden in diese VRF installiert
+
+**Ablauf – 3-Schritt-Beispiel:**
+
+**Schritt 1 – Export:**
+
+PE an VPN1-Site1 empfängt eine IPv4-Route vom CE. Er konvertiert sie zu VPN-IPv4 und hängt RT1 und RT4 an (laut Export-Policy: `VRF VPN1 Export = RT1, RT4`). Die Route wird an alle PEs verteilt.
+
+**Schritt 2 – Import rechts:**
+
+Der rechte PE empfängt die Route mit RT1 und RT4 und vergleicht sie mit seinen VRF-Import-Listen:
+
+| VRF | Import-Liste | RT1 Match? | RT4 Match? | Ergebnis |
+|-----|-------------|------------|------------|----------|
+| VPN1 | RT1, RT4 | ✓ | ✓ | Route installiert → weiter zu Sites 4, 5 |
+| VPN2 | RT1, RT2 | ✓ | – | Route installiert → weiter zu Site 3 |
+
+**Schritt 3 – Import links:**
+
+Der linke PE vergleicht ebenfalls:
+
+| VRF | Import-Liste | Ergebnis |
+|-----|-------------|----------|
+| VPN2 | RT1, RT2 | RT1 matcht → Route zu Site 2 |
+| VPN3 | RT3 | kein Match → Route ignoriert |
+
+> **Merkhilfe:** RD = macht Adressen **eindeutig**. RT = steuert **Routenverteilung** (wer darf was sehen).
+
+---
+
+### Site of Origin (SoO)
+
+Optionales Attribut, das die CE-PE-Verbindung identifiziert. Verhindert **Routing-Schleifen** bei Multi-Homed CEs (CE an mehrere PEs angebunden).
+
+---
+
+### Datenweiterleitnung: Label Stacking
+
+```
+CE1 ---> PE1 ---> P1 ---> P2 ---> PE2 ---> CE2
+```
+
+**Schritt 1 – PE1 (Ingress):**
+Empfängt normales IP-Paket von CE1, sucht in der VRF (Longest Prefix Match), findet iBGP-Next-Hop PE2 und drückt **zwei Labels** auf das Paket:
+
+```
+[ Transport-Label | VPN-Label | IP-Paket ]
+```
+
+- **VPN-Label** (innen): identifiziert die Ziel-VRF bei PE2
+- **Transport-Label** (außen): für den Weg durch den Core zu PE2
+
+**Schritt 2 – P-Router:**
+Leiten nur anhand des **Transport-Labels** weiter – kein VPN-Wissen nötig.
+
+**Schritt 3 – PE2 (Egress):**
+Entfernt das Transport-Label, liest das VPN-Label, findet die richtige VRF, leitet das IP-Paket an CE2 weiter.
+
+### Penultimate Hop Popping (PHP)
+
+**Optimierung:** Der **vorletzte Router (P2)** entfernt bereits das Transport-Label, sodass PE2 nur noch das VPN-Label sieht und nur **einen einzigen Lookup** machen muss statt zwei. PE2 hat dies vorher via LDP beim vorherigen Hop angefordert.
+
+```
+PE1 P1 P2 PE2
+[TL|VL|IP] --> [TL|VL|IP] --> [VL|IP] --> [IP]
+ ^ PHP: TL wird hier entfernt
+```
+
+---
+
+### Inter-AS VPN
+
+Wenn VPN-Standorte über mehrere Autonomous Systems (verschiedene Provider) verbunden sind:
+
+| Option | Beschreibung | Label-Austausch |
+|--------|-------------|-----------------|
+| **A** | ASBRs führen VRFs; behandeln sich gegenseitig als CE | Kein Label-Austausch zwischen ASBRs |
+| **B** | ASBRs tauschen VPN-Routen via MP-eBGP aus | MP-eBGP + Label zwischen ASBRs |
+| **C** | Nur PE-Loopback-Adressen und Label-Bindings via eBGP; PEs kommunizieren direkt | eBGP + Label für Transport; MP-iBGP PE ↔ ASBR |
+
+---
+
+### BGP/MPLS L3 VPN – Vor- und Nachteile
+
+| Vorteile | Nachteile |
+|----------|-----------|
+| Skalierbare VPN-Architektur | Komplex für Provider zu betreiben |
+| SP oder Kunde kann VPN verwalten | Kunde hat keine vollständige WAN-Routing-Kontrolle |
+| Vereinfachtes WAN-Routing für Kunden | Nur IP-Verkehr unterstützt |
+| QoS/SLA pro VPN möglich (mit MPLS TE) | BGP konvergiert langsam (Abhilfe: BFD) |
+| Hohe Verfügbarkeit via MPLS FRR | |
+
+---
+
+## 7. Segment Routing (SR)
+
+### Grundprinzip: Source Routing
+
+Beim klassischen MPLS berechnet jeder Router Hop-by-Hop den Weg. Bei **Segment Routing** legt der **Ingress-Router** (erster Router) den gesamten Pfad fest und codiert ihn als **geordnete Liste von Segmenten** im Paket.
+
+**Segment:** Eine Anweisung für den Router, z.B. „Sende zu Knoten X über den kürzesten Pfad". Segmente werden als **SIDs (Segment Identifiers)** dargestellt.
+
+SR ist **Data Plane Agnostic**: funktioniert über MPLS oder IPv6, kombiniert mit IGP (IS-IS, OSPF) oder BGP.
+
+---
+
+### Vergleich Classic MPLS vs. Segment Routing
+
+| | Classic MPLS | Segment Routing |
+|--|--|--|
+| **Pfadaufbau** | LDP / RSVP-TE (separates Protokoll) | IGP/BGP (integriert) |
+| **Control Plane** | Komplex (IGP + LDP + RSVP-TE) | Vereinfacht (nur IGP/BGP) |
+| **State im Core** | Pro LSP/Flow | Nur am Ingress |
+| **Traffic Engineering** | Manuelle TE-LSPs via RSVP-TE | Automatisch über Segmentlisten |
+
+---
+
+### IGP Segment-Typen
+
+#### Node/Prefix SID (global)
+
+- **Global gültig** in der gesamten SR-Domäne – jeder Router versteht dieselbe SID gleich
+- Pakete werden zum Zielknoten über den **kürzesten IGP-Pfad** weitergeleitet (normales SPF-Routing)
+- Wird als **Index** angekündigt → tatsächliches Label = SRGB-Basiswert + Index
+
+```
+Beispiel:
+ SRGB = 16000–23999
+ Node-SID Index = 41
+ → Verwendetes MPLS-Label = 16041
+```
+
+#### Adjacency SID (lokal)
+
+- Nur auf dem **vergebenden Knoten lokal gültig** – andere Router verwenden diese SID nicht
+- Leitet das Paket **explizit über eine bestimmte Nachbarverbindung** weiter (echtes Source Routing)
+- Wird als **absoluter Wert** angekündigt (kein Index, direkt das Label)
+
+```
+Beispiel:
+ Adjacency SID = 9107
+ → Paket wird zwingend über genau diesen Link weitergeleitet
+```
+
+---
+
+### SR Vorteile
+
+**Control Plane Vereinfachung:**
+- Weniger Protokolle, weniger Abhängigkeiten
+- Automatischer Traffic-Schutz ohne per-Flow-Signalisierung
+
+**Traffic Engineering:**
+- Kein manuelles Konfigurieren von TE-LSPs nötig
+- Pfade werden automatisch berechnet oder von einem Controller (z.B. via PCEP) vorgegeben
+- Kein State pro Flow im Kernnetz
+
+**Software-Defined Networking:**
+- Hybrider Ansatz zwischen zentralisierter und verteilter Control Plane
+- Controller kann Pfade/Policies über Southbound-Schnittstellen (z.B. PCEP) vorgeben
+- Keine komplette Neukonstruktion des Netzes nötig
+
+---
+
+### IETF Standards für Segment Routing
+
+| Standard | Beschreibung |
+|----------|-------------|
+| RFC 8402 | SR Architektur |
+| RFC 9256 | SR Use Cases |
+| RFC 8660 | SR über MPLS (SR-MPLS) |
+| RFC 9886 | SR über IPv6 (SRv6) |
+
+Relevante IETF Working Groups: SPRING, PCE, IDR, 6MAN
+
+---
+
+## Prüfungsinfo
+
+| | |
+|--|--|
+| **Termin** | Mo., 4. Mai 2026, 14:00–16:00 Uhr |
+| **Räume** | 6B.369 (inkl. Nachteilsausgleich) und 6B.371 |
+| **Betreuer** | Schrenk und Albaradie |
+| **Format** | Klausur (keine praktische Prüfung, außer IT25-Jahrgang) |
+| **IT25** | Kombinierte Prüfung: Klausur (K) + Laborausarbeitung (L) |
\ No newline at end of file
diff --git "a/Projektmanagement/Referat \"Kanban\".md" "b/Projektmanagement/Referat \"Kanban\".md"
new file mode 100644
index 0000000..31dde15
--- /dev/null
+++ "b/Projektmanagement/Referat \"Kanban\".md"
@@ -0,0 +1,7 @@
+# Referat Notes "Kanban"
+
+- Freies Sprechen: Point and Speak
+- Nicht zur Präsi drehen
+- Offene Handflächen zur Zuhörerschaft
+- Am besten ohne Notizen
+- Anwendungsbeispiele zu Kanban
\ No newline at end of file
diff --git a/Skriptsprachen/.DS_Store b/Skriptsprachen/.DS_Store
new file mode 100644
index 0000000..05e1414
Binary files /dev/null and b/Skriptsprachen/.DS_Store differ
diff --git a/Skriptsprachen/test_exam.pdf b/Skriptsprachen/test_exam.pdf
new file mode 100644
index 0000000..4d76e21
Binary files /dev/null and b/Skriptsprachen/test_exam.pdf differ
diff --git a/Skriptsprachen/Übung.pdf b/Skriptsprachen/Übung.pdf
new file mode 100644
index 0000000..7d6d009
Binary files /dev/null and b/Skriptsprachen/Übung.pdf differ
diff --git a/Skriptsprachen/Übung2.pdf b/Skriptsprachen/Übung2.pdf
new file mode 100644
index 0000000..e4b6dfa
Binary files /dev/null and b/Skriptsprachen/Übung2.pdf differ
diff --git a/Software Engineering II/Entwurf von UI.md b/Software Engineering II/Entwurf von UI.md
new file mode 100644
index 0000000..6e1f0a2
--- /dev/null
+++ b/Software Engineering II/Entwurf von UI.md
@@ -0,0 +1,29 @@
+### Bewertung von Oberflächen
+
+##### Faktoren beim Entwurf menübasierter Oberfläche:
+(Beispiel: Geldautomaten einer Bank)
+
+| Faktor | Eingabebestätigung |
+| -------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| **Beschreibung** | Beim Ausführen einer Tätigkeit soll nochmal ein Fenster für das Bestätigen der Aktion durch den Benutzer stattfinden. |
+| **Geschätzte Wichtigkeit** | Hoch (ungewollte Aktionen sollen nicht passieren) |
+
+| Faktor | Minimalismus |
+| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Beschreibung** | Die Oberfläche soll so minimalistisch wie möglich sein, damit der Benutzer alle Aktionen, die er ausführen will auch schnellstmöglich ausführen will. Überladung würde nur überfordern. |
+| **Geschätzte Wichtigkeit** | Mittel |
+
+| Faktor | Audio-Visuelles Feedback |
+| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Beschreibung** | Sowohl audiotechnisch als auch visuell soll bei Eingaben ein Feedback in entsprechender Form ausgegeben werden. Zum Beispiel: Ton bei Tastendruck |
+| **Geschätzte Wichtigkeit** | Hoch |
+
+| Faktor | Barrierefreiheit |
+| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| **Beschreibung** | Behinderte Personen sollen beim Abheben ihres Geldes keine Einschränkungen haben, z.B. eine Sprachausgabe für blinde Personen. |
+| **Geschätzte Wichtigkeit** | Hoch |
+
+| Faktor | Hilfe-Button für Notfälle |
+| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Beschreibung** | Bei schwierigen Situationen sollen Kunden die Möglichkeit haben durch einen Button den Kundensupport zu erreichen und erste Hilfe zu erhalten. |
+| **Geschätzte Wichtigkeit** | Hoch |
diff --git a/Software-Engineering/.DS_Store b/Software-Engineering/.DS_Store
new file mode 100644
index 0000000..140368c
Binary files /dev/null and b/Software-Engineering/.DS_Store differ
diff --git a/Software-Engineering/GrowGreen_2_Paper.pdf b/Software-Engineering/GrowGreen_2_Paper.pdf
new file mode 100644
index 0000000..dcd320c
Binary files /dev/null and b/Software-Engineering/GrowGreen_2_Paper.pdf differ
diff --git a/Software-Engineering/Main_Screen_Maja_Vorgaben.pdf b/Software-Engineering/Main_Screen_Maja_Vorgaben.pdf
new file mode 100644
index 0000000..e3ede2f
Binary files /dev/null and b/Software-Engineering/Main_Screen_Maja_Vorgaben.pdf differ
diff --git a/Software-Engineering/Projektstruktur.excalidraw b/Software-Engineering/Projektstruktur.excalidraw
new file mode 100644
index 0000000..1be2526
--- /dev/null
+++ b/Software-Engineering/Projektstruktur.excalidraw
@@ -0,0 +1,5748 @@
+{
+ "type": "excalidraw",
+ "version": 2,
+ "source": "https://excalidraw.com",
+ "elements": [
+ {
+ "type": "text",
+ "version": 447,
+ "versionNonce": 2110348906,
+ "index": "aw",
+ "isDeleted": false,
+ "id": "-o28VB1RnsWwmUsGWPv4n",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 675.4369271401316,
+ "y": -369.9275529415858,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 145.87991333007812,
+ "height": 37.800000000000004,
+ "seed": 1092809015,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763516598,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "GrowGreen",
+ "textAlign": "left",
+ "verticalAlign": "top",
+ "containerId": null,
+ "originalText": "GrowGreen",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 288,
+ "versionNonce": 2057699626,
+ "index": "ax",
+ "isDeleted": false,
+ "id": "GOgYWsJqMKWtfglBG0S-2",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 649.4842332664231,
+ "y": -391.58532666004373,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 202.45778200566315,
+ "height": 83.20182822150537,
+ "seed": 943567447,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "8qNOjR_d8cIxQJkkiwynu",
+ "type": "arrow"
+ },
+ {
+ "id": "aLf88Vg0L04HQji3WaEWA",
+ "type": "arrow"
+ },
+ {
+ "id": "OFMDSVaLmTHtl24hz2UK0",
+ "type": "arrow"
+ },
+ {
+ "id": "XihGYRdbd3cGqBv8_w60f",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763516598,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 145,
+ "versionNonce": 1956846006,
+ "index": "b00",
+ "isDeleted": false,
+ "id": "xCFexJmC7efY1OrpBXpwQ",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -27.96562464220574,
+ "y": -139.14851046672726,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 141.8599395751953,
+ "height": 37.800000000000004,
+ "seed": 1017335671,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762422645,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Oberfläche",
+ "textAlign": "left",
+ "verticalAlign": "top",
+ "containerId": null,
+ "originalText": "Oberfläche",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 132,
+ "versionNonce": 1169730614,
+ "index": "b01",
+ "isDeleted": false,
+ "id": "QU8m0vfqf2iHrdz5Y-Ljd",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -56.45249622917129,
+ "y": -164.1090589331788,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 202.45778200566315,
+ "height": 83.20182822150537,
+ "seed": 412633239,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "R1lIC4Uvj4_Bwulm3n47R",
+ "type": "arrow"
+ },
+ {
+ "id": "U7CHLr5htyht_vIqQC0Fx",
+ "type": "arrow"
+ },
+ {
+ "id": "8qNOjR_d8cIxQJkkiwynu",
+ "type": "arrow"
+ },
+ {
+ "id": "aLf88Vg0L04HQji3WaEWA",
+ "type": "arrow"
+ },
+ {
+ "id": "X2L4XyZYj8TYmKXHQZM2C",
+ "type": "arrow"
+ },
+ {
+ "id": "O-26v593yK9ptNyhHwOn4",
+ "type": "arrow"
+ },
+ {
+ "id": "nqO-ZPm4PDDGfNYayE1uv",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762825644,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "rectangle",
+ "version": 80,
+ "versionNonce": 1481338422,
+ "index": "b08",
+ "isDeleted": false,
+ "id": "1LYkPkXQNUuOJ0dvpvBfP",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 470.6021716191249,
+ "y": -171.00463697188246,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 239.5252511756291,
+ "height": 96.13598516572871,
+ "seed": 790710583,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "rVPaBICRWTn1ZtiiPsc9-",
+ "type": "text"
+ },
+ {
+ "id": "aLf88Vg0L04HQji3WaEWA",
+ "type": "arrow"
+ },
+ {
+ "id": "OFMDSVaLmTHtl24hz2UK0",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762402329,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 23,
+ "versionNonce": 2053525314,
+ "index": "b08V",
+ "isDeleted": false,
+ "id": "rVPaBICRWTn1ZtiiPsc9-",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 495.4308320007932,
+ "y": -141.83664438901812,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 189.86793041229248,
+ "height": 37.800000000000004,
+ "seed": 156308857,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762238876,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Pflanzenfakten",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "1LYkPkXQNUuOJ0dvpvBfP",
+ "originalText": "Pflanzenfakten",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 333,
+ "versionNonce": 2123864670,
+ "index": "b0B",
+ "isDeleted": false,
+ "id": "mEWRp6pl8-yUcBuxED-kI",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 531.720138949023,
+ "y": -28.806721358341235,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 78.2123269144911,
+ "seed": 385914169,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "lSy_Blm8Ksi6VWm9IJVIk",
+ "type": "text"
+ }
+ ],
+ "updated": 1724762288355,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 283,
+ "versionNonce": 1001430686,
+ "index": "b0C",
+ "isDeleted": false,
+ "id": "lSy_Blm8Ksi6VWm9IJVIk",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 606.9690860730058,
+ "y": -8.600557901095687,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 75.99196910858154,
+ "height": 37.800000000000004,
+ "seed": 1619756569,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762288355,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Name",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "mEWRp6pl8-yUcBuxED-kI",
+ "originalText": "Name",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 258,
+ "versionNonce": 1106458462,
+ "index": "b0F",
+ "isDeleted": false,
+ "id": "rQrgA7FmY01fmzWdyk9BE",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 532.7508703330409,
+ "y": 96.28753875900998,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 78.2123269144911,
+ "seed": 1350642615,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "JvpVkUKioerB9k8YKRelJ",
+ "type": "text"
+ }
+ ],
+ "updated": 1724762364861,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 222,
+ "versionNonce": 730897310,
+ "index": "b0G",
+ "isDeleted": false,
+ "id": "JvpVkUKioerB9k8YKRelJ",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 560.4418509863053,
+ "y": 116.49370221625553,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 171.1079020500183,
+ "height": 37.800000000000004,
+ "seed": 1693490391,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762364861,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Gießfrequenz",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "rQrgA7FmY01fmzWdyk9BE",
+ "originalText": "Gießfrequenz",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 378,
+ "versionNonce": 1236035806,
+ "index": "b0H",
+ "isDeleted": false,
+ "id": "dvHLUvzWzb7Pwz6052D8-",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 531.7002718443,
+ "y": 218.69451733446283,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 78.2123269144911,
+ "seed": 58948503,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "QBYTglCTxSjc_Y1kiB5R8",
+ "type": "text"
+ }
+ ],
+ "updated": 1724762385889,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 351,
+ "versionNonce": 405249310,
+ "index": "b0I",
+ "isDeleted": false,
+ "id": "QBYTglCTxSjc_Y1kiB5R8",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 588.5252329505788,
+ "y": 238.90068079170837,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 112.83994114398956,
+ "height": 37.800000000000004,
+ "seed": 1188950199,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762385889,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Standort",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "dvHLUvzWzb7Pwz6052D8-",
+ "originalText": "Standort",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 528,
+ "versionNonce": 46285314,
+ "index": "b0L",
+ "isDeleted": false,
+ "id": "xTGwiFEI4fg_O57rU9jmx",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 531.8218037157158,
+ "y": 352.6575319003688,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 78.2123269144911,
+ "seed": 1543617527,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "ro4W3leIkuFwGC93AZaxb",
+ "type": "text"
+ }
+ ],
+ "updated": 1724762399131,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 508,
+ "versionNonce": 1257157058,
+ "index": "b0M",
+ "isDeleted": false,
+ "id": "ro4W3leIkuFwGC93AZaxb",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 605.5307515931013,
+ "y": 372.86369535761435,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 79.07196760177612,
+ "height": 37.800000000000004,
+ "seed": 175449367,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762399131,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Größe",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "xTGwiFEI4fg_O57rU9jmx",
+ "originalText": "Größe",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 342,
+ "versionNonce": 1560248682,
+ "index": "b0N",
+ "isDeleted": false,
+ "id": "vndsq92e1A0Xmt6CNtJg8",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 943.5745758306698,
+ "y": -169.4810954806611,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 239.5252511756291,
+ "height": 96.13598516572871,
+ "seed": 1374019057,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "ZkQE1V89oLZw4tgau8HPC",
+ "type": "text"
+ },
+ {
+ "id": "OFMDSVaLmTHtl24hz2UK0",
+ "type": "arrow"
+ },
+ {
+ "id": "p-hyLwp5-n4_0tPX7Gzhk",
+ "type": "arrow"
+ },
+ {
+ "id": "JufNoZKtlpp6eNK8lDSzy",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762645935,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 327,
+ "versionNonce": 1923742897,
+ "index": "b0O",
+ "isDeleted": false,
+ "id": "ZkQE1V89oLZw4tgau8HPC",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 998.263249697293,
+ "y": -140.31310289779677,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 130.1479034423828,
+ "height": 37.800000000000004,
+ "seed": 1916205009,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762536286,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Minispiele",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "vndsq92e1A0Xmt6CNtJg8",
+ "originalText": "Minispiele",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 403,
+ "versionNonce": 779107126,
+ "index": "b0P",
+ "isDeleted": false,
+ "id": "r1r9aznra1GSBA8F4mXFR",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 31.03229511239863,
+ "y": 882.1161382954857,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 239.5252511756291,
+ "height": 96.13598516572871,
+ "seed": 1942397879,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "IgVodJJKYvdmb_6feLuc_",
+ "type": "text"
+ },
+ {
+ "id": "X2L4XyZYj8TYmKXHQZM2C",
+ "type": "arrow"
+ },
+ {
+ "id": "WLq27kvz0Ste3OiswDPxn",
+ "type": "arrow"
+ },
+ {
+ "id": "bw3SEvlt9MV0QAgHmZ1Jp",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763321662,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 363,
+ "versionNonce": 1450140790,
+ "index": "b0Q",
+ "isDeleted": false,
+ "id": "IgVodJJKYvdmb_6feLuc_",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 52.10558729312902,
+ "y": 911.2841308783501,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 197.3786668141683,
+ "height": 37.800000000000004,
+ "seed": 1892095191,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763321662,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Laden Interface",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "r1r9aznra1GSBA8F4mXFR",
+ "originalText": "Laden Interface",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 431,
+ "versionNonce": 2123790710,
+ "index": "b0R",
+ "isDeleted": false,
+ "id": "FzK1iPVLQMYwpk-Z1U5WU",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 35.45720918897871,
+ "y": 1128.0649689789907,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 239.5252511756291,
+ "height": 96.13598516572871,
+ "seed": 2124908217,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "yxyOhGoTBTu8rsGA1GueG",
+ "type": "text"
+ },
+ {
+ "id": "nqO-ZPm4PDDGfNYayE1uv",
+ "type": "arrow"
+ },
+ {
+ "id": "WLq27kvz0Ste3OiswDPxn",
+ "type": "arrow"
+ },
+ {
+ "id": "pS0Xl7-95fzix_i3hJG6j",
+ "type": "arrow"
+ },
+ {
+ "id": "p_u7rslMJcPHw6ujq3Rgz",
+ "type": "arrow"
+ },
+ {
+ "id": "D5QpHUHE52PuCwObIQ9SE",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763321662,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 404,
+ "versionNonce": 1001642678,
+ "index": "b0S",
+ "isDeleted": false,
+ "id": "yxyOhGoTBTu8rsGA1GueG",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 57.289882632170475,
+ "y": 1157.232961561855,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 195.8599042892456,
+ "height": 37.800000000000004,
+ "seed": 1767393177,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763321662,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Home Interface",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "FzK1iPVLQMYwpk-Z1U5WU",
+ "originalText": "Home Interface",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 547,
+ "versionNonce": 389420313,
+ "index": "b0U",
+ "isDeleted": false,
+ "id": "PV-Xj0t4em5NNSLw6785Y",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 91.3942810061094,
+ "y": 419.01663076093485,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 181.6767931381222,
+ "height": 47.800000000000004,
+ "seed": 2101131825,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "QGVqWVYjYpVBks8nasRU0",
+ "type": "text"
+ },
+ {
+ "id": "vu7R7gFncL4Z1NPhZ2-R3",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763134656,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 569,
+ "versionNonce": 1640368633,
+ "index": "b0V",
+ "isDeleted": false,
+ "id": "QGVqWVYjYpVBks8nasRU0",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 143.84269344431112,
+ "y": 424.01663076093485,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 76.77996826171875,
+ "height": 37.800000000000004,
+ "seed": 2129153041,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763134656,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Name",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "PV-Xj0t4em5NNSLw6785Y",
+ "originalText": "Name",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 344,
+ "versionNonce": 514378038,
+ "index": "b0W",
+ "isDeleted": false,
+ "id": "R1lIC4Uvj4_Bwulm3n47R",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": -31.07004607890616,
+ "y": -75.90723071167344,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 56.42838707013607,
+ "height": 74.25097017992583,
+ "seed": 575120374,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172722,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "QU8m0vfqf2iHrdz5Y-Ljd",
+ "focus": 0.7492568584046314,
+ "gap": 5,
+ "fixedPoint": [
+ 0.1253715707976843,
+ 1.0600948333333333
+ ]
+ },
+ "endBinding": {
+ "elementId": "JDu2mm0pDBrx2XMjjHZ9J",
+ "focus": 0.00418410041841025,
+ "gap": 5,
+ "fixedPoint": [
+ -0.024310300081616273,
+ 0.4979079497907949
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 74.25097017992583
+ ],
+ [
+ 56.42838707013607,
+ 74.25097017992583
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 457,
+ "versionNonce": 1227125686,
+ "index": "b0WV",
+ "isDeleted": false,
+ "id": "U7CHLr5htyht_vIqQC0Fx",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": -31.505106955891904,
+ "y": -75.90723071167344,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 58.19663374122712,
+ "height": 146.28742166627126,
+ "seed": 94175210,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172722,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "QU8m0vfqf2iHrdz5Y-Ljd",
+ "focus": 0.7535546519759704,
+ "gap": 5,
+ "fixedPoint": [
+ 0.1232226740120148,
+ 1.0600948333333333
+ ]
+ },
+ "endBinding": {
+ "elementId": "V5CwbNIZRQWtiItk3POYw",
+ "focus": 0.0023255813953488797,
+ "gap": 4.999999999999943,
+ "fixedPoint": [
+ -0.01950570989336299,
+ 0.4988372093023256
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 146.28742166627126
+ ],
+ [
+ 58.19663374122712,
+ 146.28742166627126
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 403,
+ "versionNonce": 1899644022,
+ "index": "b0X",
+ "isDeleted": false,
+ "id": "j9DRT4gJDcPgHEgkOw4ku",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 19.27124327575268,
+ "y": 149.91105890465815,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 239.5252511756291,
+ "height": 96.13598516572871,
+ "seed": 1132898745,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "Vrk0zbeVzkFrNzLdUyatO",
+ "type": "text"
+ },
+ {
+ "id": "O-26v593yK9ptNyhHwOn4",
+ "type": "arrow"
+ },
+ {
+ "id": "7LCpeDFW-LG4Co_DgwTtX",
+ "type": "arrow"
+ },
+ {
+ "id": "xZIoeTIiVt-q115-AUU6s",
+ "type": "arrow"
+ },
+ {
+ "id": "vu7R7gFncL4Z1NPhZ2-R3",
+ "type": "arrow"
+ },
+ {
+ "id": "ND7FDvFD5hupkN4N5oiIZ",
+ "type": "arrow"
+ },
+ {
+ "id": "APQ-F3sprAL_APPnWh3U3",
+ "type": "arrow"
+ },
+ {
+ "id": "I5FdNyVMe-IKYrclnhpd8",
+ "type": "arrow"
+ },
+ {
+ "id": "NHMK4wYchJBlg4gwdFshB",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763295846,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 372,
+ "versionNonce": 1404923609,
+ "index": "b0Y",
+ "isDeleted": false,
+ "id": "Vrk0zbeVzkFrNzLdUyatO",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 78.73386962650669,
+ "y": 160.17905148752249,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 120.5999984741211,
+ "height": 75.60000000000001,
+ "seed": 744163993,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763121718,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Minispiel \nInterface",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "j9DRT4gJDcPgHEgkOw4ku",
+ "originalText": "Minispiel Interface",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 353,
+ "versionNonce": 1537792566,
+ "index": "b0c",
+ "isDeleted": false,
+ "id": "_sQGig8PgZlsxrdDUS_SQ",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1006.9068688793316,
+ "y": -26.248723314029917,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 78.2123269144911,
+ "seed": 37949311,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "yAIXlj-0tr-WvZZuR42eS",
+ "type": "text"
+ },
+ {
+ "id": "kzvCCfK5pTTx8hqLuQsQB",
+ "type": "arrow"
+ },
+ {
+ "id": "dk-gwuoZAhDx948kjwAyT",
+ "type": "arrow"
+ },
+ {
+ "id": "eY32GnMPpbihAIe8G4oE_",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762630284,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 311,
+ "versionNonce": 885539422,
+ "index": "b0d",
+ "isDeleted": false,
+ "id": "yAIXlj-0tr-WvZZuR42eS",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1074.1758202757753,
+ "y": -6.042559856784365,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 91.95196056365967,
+ "height": 37.800000000000004,
+ "seed": 1800587167,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762472362,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Plantle",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "_sQGig8PgZlsxrdDUS_SQ",
+ "originalText": "Plantle",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 590,
+ "versionNonce": 2068094905,
+ "index": "b0h",
+ "isDeleted": false,
+ "id": "MrNRtEQ3tXSkps04U2JVk",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 85.85802567014548,
+ "y": 293.6761008784393,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 181.6767931381222,
+ "height": 47.800000000000004,
+ "seed": 1222305207,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "191gyEccRRBOxZXaT4ta5",
+ "type": "text"
+ },
+ {
+ "id": "7LCpeDFW-LG4Co_DgwTtX",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763134656,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 625,
+ "versionNonce": 1693073561,
+ "index": "b0i",
+ "isDeleted": false,
+ "id": "191gyEccRRBOxZXaT4ta5",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 120.13644941654042,
+ "y": 298.6761008784393,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 113.11994564533234,
+ "height": 37.800000000000004,
+ "seed": 1577260759,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763134656,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Auswahl",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "MrNRtEQ3tXSkps04U2JVk",
+ "originalText": "Auswahl",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 396,
+ "versionNonce": 477592170,
+ "index": "b0n",
+ "isDeleted": false,
+ "id": "DlcSpY0t-bEfMNzCUU7rz",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1019.4371307417966,
+ "y": 337.73729816528214,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 78.2123269144911,
+ "seed": 476642463,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "type": "text",
+ "id": "5C3BOevlzx7niImdrJdVA"
+ },
+ {
+ "id": "JufNoZKtlpp6eNK8lDSzy",
+ "type": "arrow"
+ },
+ {
+ "id": "i5mJP0e_07DJ_uuzPYA6K",
+ "type": "arrow"
+ },
+ {
+ "id": "oUfoFMNFqLkawVeOykgcR",
+ "type": "arrow"
+ },
+ {
+ "id": "gxE41qroXCFrB5WJHD43W",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762949832,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 372,
+ "versionNonce": 955394858,
+ "index": "b0o",
+ "isDeleted": false,
+ "id": "5C3BOevlzx7niImdrJdVA",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1057.6821005670429,
+ "y": 357.9434616225277,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 149.9999237060547,
+ "height": 37.800000000000004,
+ "seed": 1618874559,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762655742,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Plant Crush",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "DlcSpY0t-bEfMNzCUU7rz",
+ "originalText": "Plant Crush",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 585,
+ "versionNonce": 1921223466,
+ "index": "b0p",
+ "isDeleted": false,
+ "id": "kWxf7N1o9tT0-UIRaDblb",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1025.406850567006,
+ "y": 724.8807615035482,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 78.2123269144911,
+ "seed": 170585553,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "type": "text",
+ "id": "mznfoHQi5vWqk9Hp97N63"
+ },
+ {
+ "id": "p-hyLwp5-n4_0tPX7Gzhk",
+ "type": "arrow"
+ },
+ {
+ "id": "PyRDa6nkpPGXFBJ22jOJN",
+ "type": "arrow"
+ },
+ {
+ "id": "Yhx6jySs54fA8bF3HePAK",
+ "type": "arrow"
+ },
+ {
+ "id": "_cd1tXsZTVVwrCrrvLxvb",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762972732,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 547,
+ "versionNonce": 115607377,
+ "index": "b0q",
+ "isDeleted": false,
+ "id": "mznfoHQi5vWqk9Hp97N63",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1085.239810199381,
+ "y": 745.0869249607938,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 106.82394409179688,
+ "height": 37.800000000000004,
+ "seed": 588188593,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762852920,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Memory",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "kWxf7N1o9tT0-UIRaDblb",
+ "originalText": "Memory",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 528,
+ "versionNonce": 194477622,
+ "index": "b0x",
+ "isDeleted": false,
+ "id": "O-26v593yK9ptNyhHwOn4",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": -29.946855633855535,
+ "y": -75.90723071167344,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 44.218098909608216,
+ "height": 273.7862821991959,
+ "seed": 1599986455,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172722,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "QU8m0vfqf2iHrdz5Y-Ljd",
+ "focus": 0.7381613061969202,
+ "gap": 5,
+ "fixedPoint": [
+ 0.1309193469015399,
+ 1.0600948333333333
+ ]
+ },
+ "endBinding": {
+ "elementId": "j9DRT4gJDcPgHEgkOw4ku",
+ "focus": 0.0020803864406784382,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02087462585034013,
+ 0.49895980677966073
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 273.7862821991959
+ ],
+ [
+ 44.218098909608216,
+ 273.7862821991959
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 174,
+ "versionNonce": 1731745054,
+ "index": "b0y",
+ "isDeleted": false,
+ "id": "zx0OcBo8YTY1g1_WUAcnd",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 491.53293869479353,
+ "y": -74.99840884064915,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 36.31118832885278,
+ "height": 88.95931656008625,
+ "seed": 1822727618,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762346568,
+ "link": null,
+ "locked": false,
+ "startBinding": null,
+ "endBinding": null,
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 88.95931656008625
+ ],
+ [
+ 36.31118832885278,
+ 88.95931656008625
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 368,
+ "versionNonce": 1346712170,
+ "index": "b0z",
+ "isDeleted": false,
+ "id": "wwEQe0g6ROPNV1DzskHx-",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1089.5713100533235,
+ "y": 165.2696882519101,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 1567972543,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "lkstIcrLz_nQnnNUhQMfc",
+ "type": "text"
+ },
+ {
+ "id": "dk-gwuoZAhDx948kjwAyT",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762617297,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 392,
+ "versionNonce": 345532127,
+ "index": "b10",
+ "isDeleted": false,
+ "id": "lkstIcrLz_nQnnNUhQMfc",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1119.9202837848197,
+ "y": 170.3696882519101,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 165.7919158935547,
+ "height": 37.800000000000004,
+ "seed": 1565093087,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762605237,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Pflanzenliste",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "wwEQe0g6ROPNV1DzskHx-",
+ "originalText": "Pflanzenliste",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 294,
+ "versionNonce": 1980086046,
+ "index": "b11",
+ "isDeleted": false,
+ "id": "hWxTjzcxS0SoECZtUE3N5",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 492.1994641570824,
+ "y": -73.69286828353346,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 36.38814366072114,
+ "height": 214.82520437294303,
+ "seed": 1497929054,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762473955,
+ "link": null,
+ "locked": false,
+ "startBinding": null,
+ "endBinding": null,
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 214.82520437294303
+ ],
+ [
+ 36.38814366072114,
+ 214.82520437294303
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 618,
+ "versionNonce": 75738713,
+ "index": "b12",
+ "isDeleted": false,
+ "id": "L-tmlkPyaY48XGWi90mJq",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 91.76067978516255,
+ "y": 483.60422647323503,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 181.6767931381222,
+ "height": 47.800000000000004,
+ "seed": 1064640089,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "y_qewsx4ZcTC9WfsJpQFB",
+ "type": "text"
+ },
+ {
+ "id": "ND7FDvFD5hupkN4N5oiIZ",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763134657,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 647,
+ "versionNonce": 479099705,
+ "index": "b13",
+ "isDeleted": false,
+ "id": "y_qewsx4ZcTC9WfsJpQFB",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 139.71709545822756,
+ "y": 488.60422647323503,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 85.76396179199219,
+ "height": 37.800000000000004,
+ "seed": 1473375033,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763134657,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "\"Logo\"",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "L-tmlkPyaY48XGWi90mJq",
+ "originalText": "\"Logo\"",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 623,
+ "versionNonce": 1561444601,
+ "index": "b14",
+ "isDeleted": false,
+ "id": "ZG97mLdZGt4tC1G4ZjST1",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 88.60178624236801,
+ "y": 357.4228337816849,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 253.9574787532801,
+ "height": 47.800000000000004,
+ "seed": 2081256215,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "keFdAVZlWsoeFlWKVPnUX",
+ "type": "text"
+ },
+ {
+ "id": "xZIoeTIiVt-q115-AUU6s",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763134657,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 685,
+ "versionNonce": 1795242457,
+ "index": "b15",
+ "isDeleted": false,
+ "id": "keFdAVZlWsoeFlWKVPnUX",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 101.8425953211565,
+ "y": 362.4228337816849,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 227.47586059570312,
+ "height": 37.800000000000004,
+ "seed": 440203319,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763134657,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Kurzbeschreibung",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "ZG97mLdZGt4tC1G4ZjST1",
+ "originalText": "Kurzbeschreibung",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 317,
+ "versionNonce": 1891135518,
+ "index": "b18",
+ "isDeleted": false,
+ "id": "sR1pParIS648fyB3RaiTe",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 491.9645328836713,
+ "y": -72.23301353566794,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 35.35474069273948,
+ "height": 329.66449089286135,
+ "seed": 2033871518,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762482625,
+ "link": null,
+ "locked": false,
+ "startBinding": null,
+ "endBinding": null,
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 329.66449089286135
+ ],
+ [
+ 35.35474069273948,
+ 329.66449089286135
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 447,
+ "versionNonce": 1673033194,
+ "index": "b19",
+ "isDeleted": false,
+ "id": "DsW7-aVAjpTDP-hB_kOkM",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1088.2160026696088,
+ "y": 92.28087176770498,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 1741576465,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "Po5ysnT2MmJDWrqvOxJfc",
+ "type": "text"
+ },
+ {
+ "id": "eY32GnMPpbihAIe8G4oE_",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762633219,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 495,
+ "versionNonce": 1840843825,
+ "index": "b1A",
+ "isDeleted": false,
+ "id": "Po5ysnT2MmJDWrqvOxJfc",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1132.2009703586245,
+ "y": 97.38087176770497,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 138.51992797851562,
+ "height": 37.800000000000004,
+ "seed": 664997617,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762608217,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Kategorien",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "DsW7-aVAjpTDP-hB_kOkM",
+ "originalText": "Kategorien",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 517,
+ "versionNonce": 247874026,
+ "index": "b1B",
+ "isDeleted": false,
+ "id": "8qNOjR_d8cIxQJkkiwynu",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 750.6131242692546,
+ "y": -303.38349843853837,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 721.2005360589714,
+ "height": 134.27443950535957,
+ "seed": 2003130026,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763516687,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "GOgYWsJqMKWtfglBG0S-2",
+ "focus": 0.000987860273972547,
+ "gap": 5,
+ "fixedPoint": [
+ 0.4995060698630137,
+ 1.0600948333333333
+ ]
+ },
+ "endBinding": {
+ "elementId": "QU8m0vfqf2iHrdz5Y-Ljd",
+ "focus": -0.15177294160959665,
+ "gap": 5,
+ "fixedPoint": [
+ 0.4241135291952017,
+ -0.060094833333333396
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 67.13721975267978
+ ],
+ [
+ -721.2005360589714,
+ 67.13721975267978
+ ],
+ [
+ -721.2005360589714,
+ 134.27443950535957
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 511,
+ "versionNonce": 825914538,
+ "index": "b1C",
+ "isDeleted": false,
+ "id": "aLf88Vg0L04HQji3WaEWA",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 750.6131242692546,
+ "y": -303.38349843853837,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 160.3483270623152,
+ "height": 127.3788614666559,
+ "seed": 108056042,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763516687,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "GOgYWsJqMKWtfglBG0S-2",
+ "focus": 0.0009878602739725472,
+ "gap": 5,
+ "fixedPoint": [
+ 0.4995060698630137,
+ 1.0600948333333333
+ ]
+ },
+ "endBinding": {
+ "elementId": "1LYkPkXQNUuOJ0dvpvBfP",
+ "focus": -0.0008349850340137951,
+ "gap": 4.999999999999993,
+ "fixedPoint": [
+ 0.49958250748299315,
+ -0.05200966101694913
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 63.68943073332795
+ ],
+ [
+ -160.3483270623152,
+ 63.68943073332795
+ ],
+ [
+ -160.3483270623152,
+ 127.3788614666559
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 309,
+ "versionNonce": 1486503710,
+ "index": "b1D",
+ "isDeleted": false,
+ "id": "C0LQ4m5GkvB_nD7SjEUkj",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 491.50410432284554,
+ "y": 67.31508275148838,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 35.35474069273948,
+ "height": 329.66449089286135,
+ "seed": 791236574,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762395193,
+ "link": null,
+ "locked": false,
+ "startBinding": null,
+ "endBinding": null,
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 329.66449089286135
+ ],
+ [
+ 35.35474069273948,
+ 329.66449089286135
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 734,
+ "versionNonce": 1142574954,
+ "index": "b1E",
+ "isDeleted": false,
+ "id": "OFMDSVaLmTHtl24hz2UK0",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 750.6131242692546,
+ "y": -303.38349843853837,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 312.6240771492297,
+ "height": 128.90240295787726,
+ "seed": 327861942,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763516687,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "GOgYWsJqMKWtfglBG0S-2",
+ "focus": 0.000987860273972828,
+ "gap": 5,
+ "fixedPoint": [
+ 0.4995060698630136,
+ 1.0600948333333333
+ ]
+ },
+ "endBinding": {
+ "elementId": "vndsq92e1A0Xmt6CNtJg8",
+ "focus": -0.0008349850340128459,
+ "gap": 4.999999999999993,
+ "fixedPoint": [
+ 0.49958250748299315,
+ -0.05200966101694913
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 64.45120147893863
+ ],
+ [
+ 312.6240771492297,
+ 64.45120147893863
+ ],
+ [
+ 312.6240771492297,
+ 128.90240295787726
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 254,
+ "versionNonce": 2139588446,
+ "index": "b1F",
+ "isDeleted": false,
+ "id": "i1S8ILvOf78x8y7LGT9C9",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 969.3831739413663,
+ "y": -71.7346013400821,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 36.31118832885278,
+ "height": 88.95931656008625,
+ "seed": 522290974,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762469374,
+ "link": null,
+ "locked": false,
+ "startBinding": null,
+ "endBinding": null,
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 88.95931656008625
+ ],
+ [
+ 36.31118832885278,
+ 88.95931656008625
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 433,
+ "versionNonce": 1613129974,
+ "index": "b1G",
+ "isDeleted": false,
+ "id": "1Pz_WZEPx4vPRyaeq-Xty",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 107.63070560178289,
+ "y": 1243.6699426587156,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 218.88521055456272,
+ "height": 47.800000000000004,
+ "seed": 1599323513,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "type": "text",
+ "id": "wmWW6ilgvWO9Vq9rB8CFJ"
+ },
+ {
+ "id": "pS0Xl7-95fzix_i3hJG6j",
+ "type": "arrow"
+ },
+ {
+ "id": "p_u7rslMJcPHw6ujq3Rgz",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763321663,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 288,
+ "versionNonce": 1419369014,
+ "index": "b1GV",
+ "isDeleted": false,
+ "id": "wmWW6ilgvWO9Vq9rB8CFJ",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 119.85735323746269,
+ "y": 1248.6699426587156,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 194.43191528320312,
+ "height": 37.800000000000004,
+ "seed": 918056665,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763321663,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "meine Pflanzen",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "1Pz_WZEPx4vPRyaeq-Xty",
+ "originalText": "meine Pflanzen",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 399,
+ "versionNonce": 2062260202,
+ "index": "b1H",
+ "isDeleted": false,
+ "id": "Qi53vDJGKj0pIyzNNxjyj",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1085.5053879021798,
+ "y": 241.3646839763138,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 879451665,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "fDXOr6G26UQ6qd1mAuT0L",
+ "type": "text"
+ },
+ {
+ "id": "kzvCCfK5pTTx8hqLuQsQB",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762604275,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 454,
+ "versionNonce": 949883601,
+ "index": "b1I",
+ "isDeleted": false,
+ "id": "fDXOr6G26UQ6qd1mAuT0L",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1146.7803488773284,
+ "y": 246.4646839763138,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 103.93994140625,
+ "height": 37.800000000000004,
+ "seed": 1146582001,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762577275,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Eingabe",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "Qi53vDJGKj0pIyzNNxjyj",
+ "originalText": "Eingabe",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 931,
+ "versionNonce": 271411254,
+ "index": "b1K",
+ "isDeleted": false,
+ "id": "p-hyLwp5-n4_0tPX7Gzhk",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 970.5009723539106,
+ "y": -68.34511031493241,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 49.90587821309532,
+ "height": 832.2320352757262,
+ "seed": 352845406,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172723,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "vndsq92e1A0Xmt6CNtJg8",
+ "focus": 0.7751686188317789,
+ "gap": 4.999999999999993,
+ "fixedPoint": [
+ 0.11241569058411013,
+ 1.052009661016949
+ ]
+ },
+ "endBinding": {
+ "elementId": "kWxf7N1o9tT0-UIRaDblb",
+ "focus": 0.002557141666667249,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4987214291666663
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 832.2320352757262
+ ],
+ [
+ 49.90587821309532,
+ 832.2320352757262
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 710,
+ "versionNonce": 1355105462,
+ "index": "b1N",
+ "isDeleted": false,
+ "id": "Kz-O25yDWT3MaThQtf93w",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 105.13952346149097,
+ "y": 997.4216730311916,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 181.6767931381222,
+ "height": 47.800000000000004,
+ "seed": 491911607,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "2QDeCgWI77bSiFol30Gqa",
+ "type": "text"
+ },
+ {
+ "id": "WLq27kvz0Ste3OiswDPxn",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763321663,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 752,
+ "versionNonce": 1281834486,
+ "index": "b1O",
+ "isDeleted": false,
+ "id": "2QDeCgWI77bSiFol30Gqa",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 151.18993327518103,
+ "y": 1002.4216730311916,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 89.57597351074219,
+ "height": 37.800000000000004,
+ "seed": 980921047,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763321663,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Kaufen",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "Kz-O25yDWT3MaThQtf93w",
+ "originalText": "Kaufen",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 739,
+ "versionNonce": 1541191798,
+ "index": "b1P",
+ "isDeleted": false,
+ "id": "lK0ZNxpOiGU3ZpEK5CdGL",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 106.25411369485539,
+ "y": 1063.7331206537492,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 181.67679313812232,
+ "height": 47.80000000000003,
+ "seed": 15951385,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "66HjrxdwuUghh2QQZs3r2",
+ "type": "text"
+ },
+ {
+ "id": "bw3SEvlt9MV0QAgHmZ1Jp",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763321663,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 799,
+ "versionNonce": 869939638,
+ "index": "b1Q",
+ "isDeleted": false,
+ "id": "66HjrxdwuUghh2QQZs3r2",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 133.16853718042046,
+ "y": 1068.7331206537492,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 127.84794616699219,
+ "height": 37.800000000000026,
+ "seed": 699480825,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763321663,
+ "link": null,
+ "locked": false,
+ "fontSize": 28.000000000000018,
+ "fontFamily": 6,
+ "text": "Verkaufen",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "lK0ZNxpOiGU3ZpEK5CdGL",
+ "originalText": "Verkaufen",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 731,
+ "versionNonce": 1542222250,
+ "index": "b1R",
+ "isDeleted": false,
+ "id": "JufNoZKtlpp6eNK8lDSzy",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 968.7372350778376,
+ "y": -68.34511031493241,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 45.69989566395907,
+ "height": 445.0885719374601,
+ "seed": 761367326,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763178143,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "vndsq92e1A0Xmt6CNtJg8",
+ "focus": 0.7898955611263078,
+ "gap": 4.999999999999993,
+ "fixedPoint": [
+ 0.10505221943684567,
+ 1.052009661016949
+ ]
+ },
+ "endBinding": {
+ "elementId": "DlcSpY0t-bEfMNzCUU7rz",
+ "focus": 0.0025571416666672494,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4987214291666663
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 445.0885719374601
+ ],
+ [
+ 45.69989566395907,
+ 445.0885719374601
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 605,
+ "versionNonce": 916016298,
+ "index": "b1S",
+ "isDeleted": false,
+ "id": "kzvCCfK5pTTx8hqLuQsQB",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1035.8668538870913,
+ "y": 56.963603600461184,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 44.63853401508845,
+ "height": 208.30108037585262,
+ "seed": 1890920255,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763178143,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "_sQGig8PgZlsxrdDUS_SQ",
+ "focus": 0.7442712483589602,
+ "gap": 5,
+ "fixedPoint": [
+ 0.12786437582052002,
+ 1.0639285416666666
+ ]
+ },
+ "endBinding": {
+ "elementId": "Qi53vDJGKj0pIyzNNxjyj",
+ "focus": 0.004166666666667614,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 208.30108037585262
+ ],
+ [
+ 44.63853401508845,
+ 208.30108037585262
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 635,
+ "versionNonce": 1525368758,
+ "index": "b1T",
+ "isDeleted": false,
+ "id": "dk-gwuoZAhDx948kjwAyT",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1036.419482131715,
+ "y": 56.963603600461184,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 48.1518279216084,
+ "height": 132.20608465144892,
+ "seed": 561863658,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172725,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "_sQGig8PgZlsxrdDUS_SQ",
+ "focus": 0.7393913103658518,
+ "gap": 5,
+ "fixedPoint": [
+ 0.13030434481707412,
+ 1.0639285416666666
+ ]
+ },
+ "endBinding": {
+ "elementId": "wwEQe0g6ROPNV1DzskHx-",
+ "focus": 0.0041666666666676155,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 132.20608465144892
+ ],
+ [
+ 48.1518279216084,
+ 132.20608465144892
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 713,
+ "versionNonce": 280580662,
+ "index": "b1U",
+ "isDeleted": false,
+ "id": "eY32GnMPpbihAIe8G4oE_",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1036.4095135209234,
+ "y": 56.96360360046117,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 46.80648914868539,
+ "height": 59.217268167243816,
+ "seed": 1904908790,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172725,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "_sQGig8PgZlsxrdDUS_SQ",
+ "focus": 0.7394793373587067,
+ "gap": 4.999999999999986,
+ "fixedPoint": [
+ 0.13026033132064663,
+ 1.0639285416666668
+ ]
+ },
+ "endBinding": {
+ "elementId": "DsW7-aVAjpTDP-hB_kOkM",
+ "focus": 0.004166666666666431,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4979166666666668
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 59.217268167243816
+ ],
+ [
+ 46.80648914868539,
+ 59.217268167243816
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 791,
+ "versionNonce": 1539293674,
+ "index": "b1V",
+ "isDeleted": false,
+ "id": "heHppwI4rOM8vklJBBTlf",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1088.1265816914906,
+ "y": 456.86849365117496,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 1787708767,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "gvET7fossfm12yldYATS4",
+ "type": "text"
+ },
+ {
+ "id": "i5mJP0e_07DJ_uuzPYA6K",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762935805,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 858,
+ "versionNonce": 587461802,
+ "index": "b1W",
+ "isDeleted": false,
+ "id": "gvET7fossfm12yldYATS4",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1157.171531680311,
+ "y": 461.968493651175,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 88.39996337890625,
+ "height": 37.800000000000004,
+ "seed": 1954300287,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762935805,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Farben",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "heHppwI4rOM8vklJBBTlf",
+ "originalText": "Farben",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 621,
+ "versionNonce": 1708982634,
+ "index": "b1Y",
+ "isDeleted": false,
+ "id": "JDu2mm0pDBrx2XMjjHZ9J",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 30.35834099122991,
+ "y": -25.456260531747603,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 205.6741374320203,
+ "height": 47.800000000000004,
+ "seed": 2124143161,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "qwrmKCTXlPQRmuKBeWBrP",
+ "type": "text"
+ },
+ {
+ "id": "R1lIC4Uvj4_Bwulm3n47R",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762726489,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 675,
+ "versionNonce": 1547486551,
+ "index": "b1Z",
+ "isDeleted": false,
+ "id": "qwrmKCTXlPQRmuKBeWBrP",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 40.50345414083381,
+ "y": -20.456260531747603,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 185.3839111328125,
+ "height": 37.800000000000004,
+ "seed": 511060761,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762719077,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Münzenanzahl",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "JDu2mm0pDBrx2XMjjHZ9J",
+ "originalText": "Münzenanzahl",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 660,
+ "versionNonce": 1935911031,
+ "index": "b1a",
+ "isDeleted": false,
+ "id": "V5CwbNIZRQWtiItk3POYw",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 31.691526785335157,
+ "y": 46.535772349946654,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 256.3351976080274,
+ "height": 47.800000000000004,
+ "seed": 340512089,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "4Ke9Wz39bCGmBxxlqhKcF",
+ "type": "text"
+ },
+ {
+ "id": "U7CHLr5htyht_vIqQC0Fx",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762747129,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 733,
+ "versionNonce": 669352343,
+ "index": "b1b",
+ "isDeleted": false,
+ "id": "4Ke9Wz39bCGmBxxlqhKcF",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 45.44919822118479,
+ "y": 51.535772349946654,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 228.81985473632812,
+ "height": 37.800000000000004,
+ "seed": 1543158329,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762747129,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Erfahrungspunkte",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "V5CwbNIZRQWtiItk3POYw",
+ "originalText": "Erfahrungspunkte",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 572,
+ "versionNonce": 895925430,
+ "index": "b1c",
+ "isDeleted": false,
+ "id": "7LCpeDFW-LG4Co_DgwTtX",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 47.22939119207315,
+ "y": 251.04704407038685,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 35,
+ "height": 66.4290568080524,
+ "seed": 937985014,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172725,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "j9DRT4gJDcPgHEgkOw4ku",
+ "focus": 0.7665536491113375,
+ "gap": 5,
+ "fixedPoint": [
+ 0.11672317544433126,
+ 1.0520096610169494
+ ]
+ },
+ "endBinding": {
+ "elementId": "MrNRtEQ3tXSkps04U2JVk",
+ "focus": 0.004184100418413371,
+ "gap": 5,
+ "fixedPoint": [
+ -0.027521401680613566,
+ 0.497907949790794
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 23.31452840402619
+ ],
+ [
+ -1.3713655219276717,
+ 23.31452840402619
+ ],
+ [
+ -1.3713655219276717,
+ 66.4290568080524
+ ],
+ [
+ 33.62863447807233,
+ 66.4290568080524
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 601,
+ "versionNonce": 1620805430,
+ "index": "b1f",
+ "isDeleted": false,
+ "id": "xZIoeTIiVt-q115-AUU6s",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 46.25406304092215,
+ "y": 251.04704407038685,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 37.34772320144586,
+ "height": 124.41023878723018,
+ "seed": 655300394,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172725,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "j9DRT4gJDcPgHEgkOw4ku",
+ "focus": 0.77469749320597,
+ "gap": 5,
+ "fixedPoint": [
+ 0.11265125339701502,
+ 1.0520096610169494
+ ]
+ },
+ "endBinding": {
+ "elementId": "ZG97mLdZGt4tC1G4ZjST1",
+ "focus": 0.24542054075597977,
+ "gap": 5,
+ "fixedPoint": [
+ -0.01968833532505457,
+ 0.37728972962201074
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 124.41023878723018
+ ],
+ [
+ 37.34772320144586,
+ 124.41023878723018
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 652,
+ "versionNonce": 1610592694,
+ "index": "b1g",
+ "isDeleted": false,
+ "id": "vu7R7gFncL4Z1NPhZ2-R3",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 46.1312569632299,
+ "y": 251.04704407038685,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 40.26302404287949,
+ "height": 191.76958669054795,
+ "seed": 759319466,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172726,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "j9DRT4gJDcPgHEgkOw4ku",
+ "focus": 0.7757229055755597,
+ "gap": 5,
+ "fixedPoint": [
+ 0.11213854721222034,
+ 1.0520096610169494
+ ]
+ },
+ "endBinding": {
+ "elementId": "PV-Xj0t4em5NNSLw6785Y",
+ "focus": 0.004184100418410993,
+ "gap": 5,
+ "fixedPoint": [
+ -0.027521401680613566,
+ 0.497907949790794
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 191.76958669054795
+ ],
+ [
+ 40.26302404287949,
+ 191.76958669054795
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 685,
+ "versionNonce": 926628918,
+ "index": "b1h",
+ "isDeleted": false,
+ "id": "ND7FDvFD5hupkN4N5oiIZ",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 47.618349974886115,
+ "y": 251.04704407038685,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 39.142329810276436,
+ "height": 256.35718240284814,
+ "seed": 1030018602,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172726,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "j9DRT4gJDcPgHEgkOw4ku",
+ "focus": 0.7633059014863679,
+ "gap": 5,
+ "fixedPoint": [
+ 0.11834704925681613,
+ 1.0520096610169494
+ ]
+ },
+ "endBinding": {
+ "elementId": "L-tmlkPyaY48XGWi90mJq",
+ "focus": 0.004184100418410994,
+ "gap": 5,
+ "fixedPoint": [
+ -0.027521401680613566,
+ 0.497907949790794
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 256.35718240284814
+ ],
+ [
+ 39.142329810276436,
+ 256.35718240284814
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 684,
+ "versionNonce": 1446252470,
+ "index": "b1i",
+ "isDeleted": false,
+ "id": "OTOyP0Z7HzkHx8g_xe8mf",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1088.1265816914893,
+ "y": 515.1467111509039,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 440911057,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "MvFQmI85xWRgRd4qq5dpq",
+ "type": "text"
+ },
+ {
+ "id": "oUfoFMNFqLkawVeOykgcR",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762946346,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 755,
+ "versionNonce": 1327660266,
+ "index": "b1j",
+ "isDeleted": false,
+ "id": "MvFQmI85xWRgRd4qq5dpq",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1138.027549746716,
+ "y": 520.2467111509039,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 126.68792724609375,
+ "height": 37.800000000000004,
+ "seed": 1735983793,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762935806,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Spielbrett",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "OTOyP0Z7HzkHx8g_xe8mf",
+ "originalText": "Spielbrett",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 667,
+ "versionNonce": 245883318,
+ "index": "b1k",
+ "isDeleted": false,
+ "id": "X2L4XyZYj8TYmKXHQZM2C",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": -30.403422750456613,
+ "y": -75.90723071167344,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 56.43571786285524,
+ "height": 1005.9913615900234,
+ "seed": 260104298,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763322228,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "QU8m0vfqf2iHrdz5Y-Ljd",
+ "focus": 0.7426715513658445,
+ "gap": 5,
+ "fixedPoint": [
+ 0.12866422431707777,
+ 1.0600948333333333
+ ]
+ },
+ "endBinding": {
+ "elementId": "r1r9aznra1GSBA8F4mXFR",
+ "focus": 0.0020803864406784382,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02087462585034013,
+ 0.49895980677966073
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 1005.9913615900234
+ ],
+ [
+ 56.43571786285524,
+ 1005.9913615900234
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 607,
+ "versionNonce": 764861098,
+ "index": "b1l",
+ "isDeleted": false,
+ "id": "b_y8WPu_eBGlnCjKhGtc5",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1089.481889075204,
+ "y": 574.7802360343471,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 2088423967,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "mmEjLSllZHjuCvgfJq6ly",
+ "type": "text"
+ },
+ {
+ "id": "gxE41qroXCFrB5WJHD43W",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762949836,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 687,
+ "versionNonce": 551799402,
+ "index": "b1m",
+ "isDeleted": false,
+ "id": "mmEjLSllZHjuCvgfJq6ly",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1103.578879164122,
+ "y": 579.8802360343471,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 198.29588317871094,
+ "height": 37.800000000000004,
+ "seed": 1522087487,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762935806,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Spielfunktionen",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "b_y8WPu_eBGlnCjKhGtc5",
+ "originalText": "Spielfunktionen",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 722,
+ "versionNonce": 461927798,
+ "index": "b1n",
+ "isDeleted": false,
+ "id": "nqO-ZPm4PDDGfNYayE1uv",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": -29.91678699255958,
+ "y": -75.90723071167344,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 60.37399618153829,
+ "height": 1251.9401922735285,
+ "seed": 226430902,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763322228,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "QU8m0vfqf2iHrdz5Y-Ljd",
+ "focus": 0.7378642700346342,
+ "gap": 5,
+ "fixedPoint": [
+ 0.1310678649826829,
+ 1.0600948333333333
+ ]
+ },
+ "endBinding": {
+ "elementId": "FzK1iPVLQMYwpk-Z1U5WU",
+ "focus": 0.0020803864406784374,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02087462585034013,
+ 0.49895980677966073
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 1251.9401922735285
+ ],
+ [
+ 60.37399618153829,
+ 1251.9401922735285
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 1040,
+ "versionNonce": 1950550122,
+ "index": "b1q",
+ "isDeleted": false,
+ "id": "WLq27kvz0Ste3OiswDPxn",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 61.78138852828536,
+ "y": 983.2521234612144,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 38.358134933205605,
+ "height": 37.96954956997706,
+ "seed": 809020726,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763322230,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "r1r9aznra1GSBA8F4mXFR",
+ "focus": 0.7432496718824831,
+ "gap": 5,
+ "fixedPoint": [
+ 0.12837516405875854,
+ 1.052009661016949
+ ]
+ },
+ "endBinding": {
+ "elementId": "Kz-O25yDWT3MaThQtf93w",
+ "focus": 0.004184100418415749,
+ "gap": 5,
+ "fixedPoint": [
+ -0.027521401680613566,
+ 0.4979079497907916
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 37.96954956997706
+ ],
+ [
+ 38.358134933205605,
+ 37.96954956997706
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 485,
+ "versionNonce": 739492918,
+ "index": "b1qV",
+ "isDeleted": false,
+ "id": "vVy5YeIyPL3R3oTFTd3i4",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 110.15221560968507,
+ "y": 1384.628568241851,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 218.88521055456272,
+ "height": 47.800000000000004,
+ "seed": 714736697,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "type": "text",
+ "id": "eZLtYYGbxpPx15dzuWEYI"
+ },
+ {
+ "id": "D5QpHUHE52PuCwObIQ9SE",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763321663,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 355,
+ "versionNonce": 1220136310,
+ "index": "b1r",
+ "isDeleted": false,
+ "id": "eZLtYYGbxpPx15dzuWEYI",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 119.5028714240758,
+ "y": 1389.628568241851,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 200.18389892578125,
+ "height": 37.800000000000004,
+ "seed": 1025447193,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763321663,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "locked Bereiche",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "vVy5YeIyPL3R3oTFTd3i4",
+ "originalText": "locked Bereiche",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 1070,
+ "versionNonce": 1358394858,
+ "index": "b1s",
+ "isDeleted": false,
+ "id": "bw3SEvlt9MV0QAgHmZ1Jp",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 61.34684167994324,
+ "y": 983.2521234612144,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 39.90727201491215,
+ "height": 104.28099719253476,
+ "seed": 1946875766,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763322230,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "r1r9aznra1GSBA8F4mXFR",
+ "focus": 0.7468780730319176,
+ "gap": 5,
+ "fixedPoint": [
+ 0.12656096348404128,
+ 1.052009661016949
+ ]
+ },
+ "endBinding": {
+ "elementId": "lK0ZNxpOiGU3ZpEK5CdGL",
+ "focus": 0.004184100418415746,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02752140168061355,
+ 0.49790794979079367
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 104.28099719253476
+ ],
+ [
+ 39.90727201491215,
+ 104.28099719253476
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 522,
+ "versionNonce": 2037475318,
+ "index": "b1u",
+ "isDeleted": false,
+ "id": "5XgEi3EZb7cklviGWDAWn",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 107.81815560566997,
+ "y": 1314.6067681214145,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 218.88521055456272,
+ "height": 47.800000000000004,
+ "seed": 1148549721,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "type": "text",
+ "id": "LKzvmzhpPlHzogs5UMve3"
+ },
+ {
+ "id": "p_u7rslMJcPHw6ujq3Rgz",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763321664,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 397,
+ "versionNonce": 707590454,
+ "index": "b1v",
+ "isDeleted": false,
+ "id": "LKzvmzhpPlHzogs5UMve3",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 119.96881447181852,
+ "y": 1319.6067681214145,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 194.58389282226562,
+ "height": 37.800000000000004,
+ "seed": 342279993,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763321664,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "meine Bereiche",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "5XgEi3EZb7cklviGWDAWn",
+ "originalText": "meine Bereiche",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 1123,
+ "versionNonce": 1787724650,
+ "index": "b1w",
+ "isDeleted": false,
+ "id": "pS0Xl7-95fzix_i3hJG6j",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 66.12984003335978,
+ "y": 1229.2009541447194,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 36.50086556842311,
+ "height": 38.26898851399619,
+ "seed": 1230442922,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763322230,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "FzK1iPVLQMYwpk-Z1U5WU",
+ "focus": 0.7438881229111772,
+ "gap": 4.999999999999886,
+ "fixedPoint": [
+ 0.12805593854441144,
+ 1.052009661016949
+ ]
+ },
+ "endBinding": {
+ "elementId": "1Pz_WZEPx4vPRyaeq-Xty",
+ "focus": 0.004184100418415749,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02284302346116538,
+ 0.497907949790794
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 38.26898851399619
+ ],
+ [
+ 36.50086556842311,
+ 38.26898851399619
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 1164,
+ "versionNonce": 551563498,
+ "index": "b1x",
+ "isDeleted": false,
+ "id": "p_u7rslMJcPHw6ujq3Rgz",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 67.1763196236246,
+ "y": 1229.2009541447194,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 35.64183598204538,
+ "height": 109.20581397669525,
+ "seed": 1041887722,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763322230,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "FzK1iPVLQMYwpk-Z1U5WU",
+ "focus": 0.7351501749484591,
+ "gap": 4.999999999999886,
+ "fixedPoint": [
+ 0.13242491252577046,
+ 1.052009661016949
+ ]
+ },
+ "endBinding": {
+ "elementId": "5XgEi3EZb7cklviGWDAWn",
+ "focus": 0.004184100418406236,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02284302346116538,
+ 0.4979079497907987
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 109.20581397669525
+ ],
+ [
+ 35.64183598204538,
+ 109.20581397669525
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 538,
+ "versionNonce": 982716982,
+ "index": "b1y",
+ "isDeleted": false,
+ "id": "DJc_KrjDV00Jxpc1llVQy",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1094.9925395881824,
+ "y": 829.5680885084615,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 26875839,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "PDc6V-NoEJ8mQ__k9lICg",
+ "type": "text"
+ },
+ {
+ "id": "PyRDa6nkpPGXFBJ22jOJN",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762961005,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 600,
+ "versionNonce": 237217297,
+ "index": "b1z",
+ "isDeleted": false,
+ "id": "PDc6V-NoEJ8mQ__k9lICg",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1171.2194811541513,
+ "y": 834.6680885084616,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 74.03598022460938,
+ "height": 37.800000000000004,
+ "seed": 857655263,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762913959,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Paare",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "DJc_KrjDV00Jxpc1llVQy",
+ "originalText": "Paare",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 1204,
+ "versionNonce": 1036287594,
+ "index": "b20",
+ "isDeleted": false,
+ "id": "D5QpHUHE52PuCwObIQ9SE",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 68.19771630570135,
+ "y": 1229.2009541447194,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 36.954499303983724,
+ "height": 179.2276140971319,
+ "seed": 116746410,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763322230,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "FzK1iPVLQMYwpk-Z1U5WU",
+ "focus": 0.7266216655152068,
+ "gap": 4.999999999999886,
+ "fixedPoint": [
+ 0.1366891672423967,
+ 1.052009661016949
+ ]
+ },
+ "endBinding": {
+ "elementId": "vVy5YeIyPL3R3oTFTd3i4",
+ "focus": 0.004184100418406236,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02284302346116538,
+ 0.4979079497907987
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 179.2276140971319
+ ],
+ [
+ 36.954499303983724,
+ 179.2276140971319
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 519,
+ "versionNonce": 691405686,
+ "index": "b21",
+ "isDeleted": false,
+ "id": "kfuq_E44DiHAAq69dF47E",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1094.9925395881824,
+ "y": 894.6228429267634,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 781060511,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "kr-QoFQkCw3xfeblCzV3J",
+ "type": "text"
+ },
+ {
+ "id": "Yhx6jySs54fA8bF3HePAK",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762966023,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 586,
+ "versionNonce": 2085361105,
+ "index": "b22",
+ "isDeleted": false,
+ "id": "kr-QoFQkCw3xfeblCzV3J",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1144.893507643409,
+ "y": 899.7228429267634,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 126.68792724609375,
+ "height": 37.800000000000004,
+ "seed": 1685683647,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762913959,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Spielbrett",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "kfuq_E44DiHAAq69dF47E",
+ "originalText": "Spielbrett",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 543,
+ "versionNonce": 1271636842,
+ "index": "b23",
+ "isDeleted": false,
+ "id": "1K7dAVCxa1ykZd5n0WWE9",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1094.992539588182,
+ "y": 967.8094416473533,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 919984095,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "khrFQBl4j0ZBApsXwrUal",
+ "type": "text"
+ },
+ {
+ "id": "_cd1tXsZTVVwrCrrvLxvb",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724762972732,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 616,
+ "versionNonce": 325817745,
+ "index": "b24",
+ "isDeleted": false,
+ "id": "khrFQBl4j0ZBApsXwrUal",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1109.0895296771,
+ "y": 972.9094416473533,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 198.29588317871094,
+ "height": 37.800000000000004,
+ "seed": 657294335,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762913959,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Spielfunktionen",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "1K7dAVCxa1ykZd5n0WWE9",
+ "originalText": "Spielfunktionen",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 675,
+ "versionNonce": 42806041,
+ "index": "b25",
+ "isDeleted": false,
+ "id": "6g0qLYIhCuM69Xf6T58no",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -458.7009895280118,
+ "y": -166.91517822634265,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 205.6741374320203,
+ "height": 47.800000000000004,
+ "seed": 1134171129,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "lWC7xBRHiD3f0dFcyR39e",
+ "type": "text"
+ }
+ ],
+ "updated": 1724762912408,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 733,
+ "versionNonce": 1036673017,
+ "index": "b26",
+ "isDeleted": false,
+ "id": "lWC7xBRHiD3f0dFcyR39e",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -386.3359056752829,
+ "y": -161.91517822634265,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 60.9439697265625,
+ "height": 37.800000000000004,
+ "seed": 587672793,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762912408,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "User",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "6g0qLYIhCuM69Xf6T58no",
+ "originalText": "User",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 699,
+ "versionNonce": 269450199,
+ "index": "b27",
+ "isDeleted": false,
+ "id": "eYsTRT-s2jmVbVm5Lly_T",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -440.02850949589515,
+ "y": -94.55931810189068,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 205.6741374320203,
+ "height": 48,
+ "seed": 572701559,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "pOPZIEJf9ZA9AYQFKyb78",
+ "type": "text"
+ }
+ ],
+ "updated": 1724762921159,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 762,
+ "versionNonce": 425156313,
+ "index": "b28",
+ "isDeleted": false,
+ "id": "pOPZIEJf9ZA9AYQFKyb78",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -375.5814249107444,
+ "y": -89.45931810189069,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 76.77996826171875,
+ "height": 37.800000000000004,
+ "seed": 1934242967,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762922075,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Name",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "eYsTRT-s2jmVbVm5Lly_T",
+ "originalText": "Name",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 747,
+ "versionNonce": 337781354,
+ "index": "b29",
+ "isDeleted": false,
+ "id": "i5mJP0e_07DJ_uuzPYA6K",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1046.2498114709006,
+ "y": 420.9496250797732,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 36.87677022059006,
+ "height": 59.81886857140171,
+ "seed": 1301850090,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763178208,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "DlcSpY0t-bEfMNzCUU7rz",
+ "focus": 0.7632328411369598,
+ "gap": 5,
+ "fixedPoint": [
+ 0.1183835794315201,
+ 1.0639285416666664
+ ]
+ },
+ "endBinding": {
+ "elementId": "heHppwI4rOM8vklJBBTlf",
+ "focus": 0.004166666666667614,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 59.81886857140171
+ ],
+ [
+ 36.87677022059006,
+ 59.81886857140171
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 699,
+ "versionNonce": 1661756569,
+ "index": "b2A",
+ "isDeleted": false,
+ "id": "sf-d4MxqYTtE946FXQkUJ",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -435.3603894878658,
+ "y": -17.535337969409312,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 205.6741374320203,
+ "height": 47.800000000000004,
+ "seed": 2081699191,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "h1cgfJYFYL-RPEsVOrbl6",
+ "type": "text"
+ }
+ ],
+ "updated": 1724762967601,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 763,
+ "versionNonce": 220621177,
+ "index": "b2B",
+ "isDeleted": false,
+ "id": "h1cgfJYFYL-RPEsVOrbl6",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -369.0612998978322,
+ "y": -12.535337969409312,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 73.07595825195312,
+ "height": 37.800000000000004,
+ "seed": 1157394071,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762967601,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Email",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "sf-d4MxqYTtE946FXQkUJ",
+ "originalText": "Email",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 778,
+ "versionNonce": 56102890,
+ "index": "b2C",
+ "isDeleted": false,
+ "id": "oUfoFMNFqLkawVeOykgcR",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1045.284242763749,
+ "y": 420.9496250797732,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 37.84233892774023,
+ "height": 118.09708607113066,
+ "seed": 1953342442,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763178209,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "DlcSpY0t-bEfMNzCUU7rz",
+ "focus": 0.7717592157202807,
+ "gap": 5,
+ "fixedPoint": [
+ 0.1141203921398597,
+ 1.0639285416666664
+ ]
+ },
+ "endBinding": {
+ "elementId": "OTOyP0Z7HzkHx8g_xe8mf",
+ "focus": 0.004166666666667615,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 118.09708607113066
+ ],
+ [
+ 37.84233892774023,
+ 118.09708607113066
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 804,
+ "versionNonce": 487628138,
+ "index": "b2D",
+ "isDeleted": false,
+ "id": "gxE41qroXCFrB5WJHD43W",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1044.7354169158227,
+ "y": 420.9496250797732,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 39.746472159381256,
+ "height": 177.73061095457388,
+ "seed": 1525614954,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763178209,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "DlcSpY0t-bEfMNzCUU7rz",
+ "focus": 0.7766055769639391,
+ "gap": 5,
+ "fixedPoint": [
+ 0.11169721151803057,
+ 1.0639285416666664
+ ]
+ },
+ "endBinding": {
+ "elementId": "b_y8WPu_eBGlnCjKhGtc5",
+ "focus": 0.004166666666667614,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 177.73061095457388
+ ],
+ [
+ 39.746472159381256,
+ 177.73061095457388
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 817,
+ "versionNonce": 1476456374,
+ "index": "b2E",
+ "isDeleted": false,
+ "id": "PyRDa6nkpPGXFBJ22jOJN",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1048.0929493059239,
+ "y": 808.0930884180393,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 41.89959028225849,
+ "height": 45.37500009042219,
+ "seed": 1702188010,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172728,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "kWxf7N1o9tT0-UIRaDblb",
+ "focus": 0.7996722819934348,
+ "gap": 5,
+ "fixedPoint": [
+ 0.10016385900328274,
+ 1.0639285416666664
+ ]
+ },
+ "endBinding": {
+ "elementId": "DJc_KrjDV00Jxpc1llVQy",
+ "focus": 0.004166666666667613,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 45.37500009042219
+ ],
+ [
+ 41.89959028225849,
+ 45.37500009042219
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 840,
+ "versionNonce": 847575606,
+ "index": "b2H",
+ "isDeleted": false,
+ "id": "Yhx6jySs54fA8bF3HePAK",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1048.0264559647462,
+ "y": 808.0930884180393,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 41.966083623436134,
+ "height": 110.42975450872405,
+ "seed": 1387183850,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172728,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "kWxf7N1o9tT0-UIRaDblb",
+ "focus": 0.8002594459414563,
+ "gap": 5,
+ "fixedPoint": [
+ 0.09987027702927195,
+ 1.0639285416666664
+ ]
+ },
+ "endBinding": {
+ "elementId": "kfuq_E44DiHAAq69dF47E",
+ "focus": 0.004166666666667614,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 110.42975450872405
+ ],
+ [
+ 41.966083623436134,
+ 110.42975450872405
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 725,
+ "versionNonce": 1277255737,
+ "index": "b2I",
+ "isDeleted": false,
+ "id": "CA26A9QS08juCJ0jO6m2G",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -428.35820947582187,
+ "y": 50.15240214701359,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 205.6741374320203,
+ "height": 47.800000000000004,
+ "seed": 1513643481,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "Op1715ZP1R_VvCo062l2M",
+ "type": "text"
+ }
+ ],
+ "updated": 1724762972266,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 799,
+ "versionNonce": 1118921113,
+ "index": "b2J",
+ "isDeleted": false,
+ "id": "Op1715ZP1R_VvCo062l2M",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -381.33911866508515,
+ "y": 55.15240214701359,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 111.63595581054688,
+ "height": 37.800000000000004,
+ "seed": 1191262905,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762976697,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Social ID",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "CA26A9QS08juCJ0jO6m2G",
+ "originalText": "Social ID",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 880,
+ "versionNonce": 1181246646,
+ "index": "b2K",
+ "isDeleted": false,
+ "id": "_cd1tXsZTVVwrCrrvLxvb",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1049.3727840495367,
+ "y": 808.0930884180393,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 40.61975553864522,
+ "height": 183.61635322931397,
+ "seed": 1258440694,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763172729,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "kWxf7N1o9tT0-UIRaDblb",
+ "focus": 0.7883708071755701,
+ "gap": 5,
+ "fixedPoint": [
+ 0.10581459641221505,
+ 1.0639285416666664
+ ]
+ },
+ "endBinding": {
+ "elementId": "1K7dAVCxa1ykZd5n0WWE9",
+ "focus": 0.004166666666667615,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546763,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 183.61635322931397
+ ],
+ [
+ 40.61975553864522,
+ 183.61635322931397
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "rectangle",
+ "version": 779,
+ "versionNonce": 1228910617,
+ "index": "b2L",
+ "isDeleted": false,
+ "id": "JTVeAsunBNQw9qX0Iy-4t",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -433.02632948385116,
+ "y": 122.50826227146567,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 243.01909749625372,
+ "height": 47.80000000000001,
+ "seed": 469949239,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "ZvUZ2bmNkbALc06AIv6mM",
+ "type": "text"
+ }
+ ],
+ "updated": 1724762999065,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 844,
+ "versionNonce": 1977894137,
+ "index": "b2M",
+ "isDeleted": false,
+ "id": "ZvUZ2bmNkbALc06AIv6mM",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -414.85671603845867,
+ "y": 127.50826227146567,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 206.67987060546875,
+ "height": 37.800000000000004,
+ "seed": 1133534295,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724762999065,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Geburtsurkunde",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "JTVeAsunBNQw9qX0Iy-4t",
+ "originalText": "Geburtsurkunde",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 801,
+ "versionNonce": 1440465783,
+ "index": "b2N",
+ "isDeleted": false,
+ "id": "u2lNg5azeqx1W4lHVIpDJ",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -433.02632948385116,
+ "y": 192.5300623919031,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 243.01909749625372,
+ "height": 47.80000000000001,
+ "seed": 224315735,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "geFbt4ueMMu0V_-JG7NYj",
+ "type": "text"
+ }
+ ],
+ "updated": 1724763002905,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 871,
+ "versionNonce": 358075001,
+ "index": "b2O",
+ "isDeleted": false,
+ "id": "geFbt4ueMMu0V_-JG7NYj",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -345.3547705428532,
+ "y": 197.5300623919031,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 67.67597961425781,
+ "height": 37.800000000000004,
+ "seed": 461997687,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763005286,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "IBAN",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "u2lNg5azeqx1W4lHVIpDJ",
+ "originalText": "IBAN",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 113,
+ "versionNonce": 635373366,
+ "index": "b2P",
+ "isDeleted": false,
+ "id": "WWwPN_UvQQDylPPNvgUo2",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1435.9685968881272,
+ "y": -177.07881078511946,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 239.5252511756291,
+ "height": 96.13598516572871,
+ "seed": 2134255863,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "4Ur0AwI4WjPz3uEn6xbKS",
+ "type": "text"
+ },
+ {
+ "id": "XihGYRdbd3cGqBv8_w60f",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763468973,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 63,
+ "versionNonce": 1459063481,
+ "index": "b2Q",
+ "isDeleted": false,
+ "id": "4Ur0AwI4WjPz3uEn6xbKS",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 1520.7112410916643,
+ "y": -147.91081820225511,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 70.03996276855469,
+ "height": 37.800000000000004,
+ "seed": 110359063,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763023165,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Logik",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "WWwPN_UvQQDylPPNvgUo2",
+ "originalText": "Logik",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 765,
+ "versionNonce": 1911094769,
+ "index": "b2R",
+ "isDeleted": false,
+ "id": "kNvlcGIX653BPJrwGbIHw",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -428.8075558145112,
+ "y": 295.67697932489875,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 349.3367201057707,
+ "height": 86,
+ "seed": 1291964735,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "I_FnqszlOeX9JbVXDYOyn",
+ "type": "text"
+ }
+ ],
+ "updated": 1724763033098,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 881,
+ "versionNonce": 1691752401,
+ "index": "b2S",
+ "isDeleted": false,
+ "id": "I_FnqszlOeX9JbVXDYOyn",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": -400.8910878514696,
+ "y": 319.7769793248988,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 293.5037841796875,
+ "height": 37.800000000000004,
+ "seed": 2085835103,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763033098,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Durchschnittsverdienst",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "kNvlcGIX653BPJrwGbIHw",
+ "originalText": "Durchschnittsverdienst",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 1314,
+ "versionNonce": 1738757110,
+ "index": "b2T",
+ "isDeleted": false,
+ "id": "rpyutHs6BegVB9OngLQDR",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 94.74246092212309,
+ "y": 552.9418556208062,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 478625009,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "JK3iN0KHvFeyAimLrPenV",
+ "type": "text"
+ },
+ {
+ "id": "APQ-F3sprAL_APPnWh3U3",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763280148,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 1447,
+ "versionNonce": 318058218,
+ "index": "b2U",
+ "isDeleted": false,
+ "id": "JK3iN0KHvFeyAimLrPenV",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 102.38344972930292,
+ "y": 558.0418556208062,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 211.2078857421875,
+ "height": 37.800000000000004,
+ "seed": 1062500049,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763235008,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Plantle Interface",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "rpyutHs6BegVB9OngLQDR",
+ "originalText": "Plantle Interface",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 1024,
+ "versionNonce": 55365686,
+ "index": "b2V",
+ "isDeleted": false,
+ "id": "7dw6EYzFJKphtD-S8Oo_s",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 96.95711817435415,
+ "y": 640.4180980368171,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 86,
+ "seed": 1142833535,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "CpycweJGbqlAJFOSKGDdl",
+ "type": "text"
+ },
+ {
+ "id": "APQ-F3sprAL_APPnWh3U3",
+ "type": "arrow"
+ },
+ {
+ "id": "I5FdNyVMe-IKYrclnhpd8",
+ "type": "arrow"
+ },
+ {
+ "id": "NHMK4wYchJBlg4gwdFshB",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763295847,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 1120,
+ "versionNonce": 1950240438,
+ "index": "b2W",
+ "isDeleted": false,
+ "id": "CpycweJGbqlAJFOSKGDdl",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 132.04009306551836,
+ "y": 645.6180980368172,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 156.32391357421875,
+ "height": 75.60000000000001,
+ "seed": 1861728671,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763262194,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Plant Crush \nInterface",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "7dw6EYzFJKphtD-S8Oo_s",
+ "originalText": "Plant Crush Interface",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "rectangle",
+ "version": 1011,
+ "versionNonce": 237680490,
+ "index": "b2X",
+ "isDeleted": false,
+ "id": "v6pFziSXet_R14ptidIgY",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 98.33392908669214,
+ "y": 768.3786921451757,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 226.48986335654715,
+ "height": 48,
+ "seed": 2078927615,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [
+ {
+ "id": "rEINy0W8Doh5dI678StDF",
+ "type": "text"
+ },
+ {
+ "id": "NHMK4wYchJBlg4gwdFshB",
+ "type": "arrow"
+ }
+ ],
+ "updated": 1724763298861,
+ "link": null,
+ "locked": false
+ },
+ {
+ "type": "text",
+ "version": 1093,
+ "versionNonce": 556488310,
+ "index": "b2Y",
+ "isDeleted": false,
+ "id": "rEINy0W8Doh5dI678StDF",
+ "fillStyle": "solid",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 0,
+ "opacity": 100,
+ "angle": 0,
+ "x": 104.67291594074698,
+ "y": 773.4786921451757,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 213.8118896484375,
+ "height": 37.800000000000004,
+ "seed": 1385313055,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763265593,
+ "link": null,
+ "locked": false,
+ "fontSize": 28,
+ "fontFamily": 6,
+ "text": "Memory Inteface",
+ "textAlign": "center",
+ "verticalAlign": "middle",
+ "containerId": "v6pFziSXet_R14ptidIgY",
+ "originalText": "Memory Inteface",
+ "autoResize": true,
+ "lineHeight": 1.35
+ },
+ {
+ "type": "arrow",
+ "version": 774,
+ "versionNonce": 1535856246,
+ "index": "b2Z",
+ "isDeleted": false,
+ "id": "APQ-F3sprAL_APPnWh3U3",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 45.94947943173318,
+ "y": 251.04704407038687,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 43.792981490389906,
+ "height": 325.79481155041935,
+ "seed": 2060020598,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763280148,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "j9DRT4gJDcPgHEgkOw4ku",
+ "focus": 0.7772407207587563,
+ "gap": 5.000000000000028,
+ "fixedPoint": [
+ 0.11137963962062185,
+ 1.052009661016949
+ ]
+ },
+ "endBinding": {
+ "elementId": "rpyutHs6BegVB9OngLQDR",
+ "focus": 0.0041666666666676155,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546738,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 325.79481155041935
+ ],
+ [
+ 43.792981490389906,
+ 325.79481155041935
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 854,
+ "versionNonce": 955568874,
+ "index": "b2a",
+ "isDeleted": false,
+ "id": "I5FdNyVMe-IKYrclnhpd8",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 46.16548504914499,
+ "y": 251.04704407038687,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 45.79163312520916,
+ "height": 432.27105396643026,
+ "seed": 1034710698,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763290175,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "j9DRT4gJDcPgHEgkOw4ku",
+ "focus": 0.7754371061807392,
+ "gap": 5.000000000000028,
+ "fixedPoint": [
+ 0.1122814469096305,
+ 1.052009661016949
+ ]
+ },
+ "endBinding": {
+ "elementId": "7dw6EYzFJKphtD-S8Oo_s",
+ "focus": 0.0023255813953493667,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546738,
+ 0.49883720930232534
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 432.27105396643026
+ ],
+ [
+ 45.79163312520916,
+ 432.27105396643026
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 951,
+ "versionNonce": 1446080246,
+ "index": "b2b",
+ "isDeleted": false,
+ "id": "NHMK4wYchJBlg4gwdFshB",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 47.89347306466426,
+ "y": 251.04704407038687,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 45.440456022027874,
+ "height": 541.2316480747888,
+ "seed": 630923766,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763301751,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "j9DRT4gJDcPgHEgkOw4ku",
+ "focus": 0.7610086648616045,
+ "gap": 5,
+ "fixedPoint": [
+ 0.11949566756919781,
+ 1.0520096610169494
+ ]
+ },
+ "endBinding": {
+ "elementId": "v6pFziSXet_R14ptidIgY",
+ "focus": 0.004166666666667614,
+ "gap": 5,
+ "fixedPoint": [
+ -0.02207604316546738,
+ 0.4979166666666662
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 541.2316480747888
+ ],
+ [
+ 45.440456022027874,
+ 541.2316480747888
+ ]
+ ],
+ "elbowed": true
+ },
+ {
+ "type": "arrow",
+ "version": 794,
+ "versionNonce": 196137514,
+ "index": "b2c",
+ "isDeleted": false,
+ "id": "XihGYRdbd3cGqBv8_w60f",
+ "fillStyle": "cross-hatch",
+ "strokeWidth": 4,
+ "strokeStyle": "solid",
+ "roughness": 1,
+ "opacity": 100,
+ "angle": 0,
+ "x": 750.6131242692546,
+ "y": -303.38349843853837,
+ "strokeColor": "#1e1e1e",
+ "backgroundColor": "transparent",
+ "width": 805.0180982066871,
+ "height": 121.30468765341891,
+ "seed": 995783542,
+ "groupIds": [],
+ "frameId": null,
+ "roundness": null,
+ "boundElements": [],
+ "updated": 1724763516688,
+ "link": null,
+ "locked": false,
+ "startBinding": {
+ "elementId": "GOgYWsJqMKWtfglBG0S-2",
+ "focus": 0.000987860273972828,
+ "gap": 5,
+ "fixedPoint": [
+ 0.4995060698630136,
+ 1.0600948333333333
+ ]
+ },
+ "endBinding": {
+ "elementId": "WWwPN_UvQQDylPPNvgUo2",
+ "focus": -0.0008349850340128459,
+ "gap": 4.999999999999993,
+ "fixedPoint": [
+ 0.49958250748299315,
+ -0.05200966101694913
+ ]
+ },
+ "lastCommittedPoint": null,
+ "startArrowhead": null,
+ "endArrowhead": null,
+ "points": [
+ [
+ 0,
+ 0
+ ],
+ [
+ 0,
+ 60.652343826709455
+ ],
+ [
+ 805.0180982066871,
+ 60.652343826709455
+ ],
+ [
+ 805.0180982066871,
+ 121.30468765341891
+ ]
+ ],
+ "elbowed": true
+ }
+ ],
+ "appState": {
+ "gridSize": 20,
+ "gridStep": 5,
+ "gridModeEnabled": false,
+ "viewBackgroundColor": "#ffffff"
+ },
+ "files": {}
+}
\ No newline at end of file
diff --git a/Software-Engineering/Projektziele(table).tgn b/Software-Engineering/Projektziele(table).tgn
new file mode 100644
index 0000000..284452b
--- /dev/null
+++ b/Software-Engineering/Projektziele(table).tgn
@@ -0,0 +1 @@
+{"rows_views":[[{"style":{"borders":"ltrb","font_style":{"bold":true},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"ltrb","font_style":{"bold":true},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"ltrb","font_style":{"bold":true},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"ltrb","font_style":{"bold":true},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"ltrb","font_style":{"bold":true},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}],[{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}},{"style":{"borders":"","font_style":{},"text_color":"","bg_color":"","halign":"center","valign":"top","padding":{"top":10,"bottom":10,"left":5,"right":5},"border_color":""}}]],"model":{"rows":[[{"value":"Nr.","cspan":1,"rspan":1,"markup":[1,3]},{"value":"Klassifizierung","cspan":1,"rspan":1,"markup":[2,15]},{"value":"Beschreibung","cspan":1,"rspan":1,"markup":[1,12]},{"value":"Messkriterium","cspan":1,"rspan":1,"markup":[1,13]},{"value":"Priorität","cspan":1,"rspan":1,"markup":[1,9]}],[{"value":"1","cspan":1,"rspan":1,"markup":[1,1]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Hauptszene","cspan":1,"rspan":1,"markup":[1,10]},{"value":"Hintergrund und Logik zu Spielerbewegung sowie\nPflanzenplazierlogik wurde implementiert.","cspan":1,"rspan":1,"markup":[1,88]},{"value":"Muss","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"2","cspan":1,"rspan":1,"markup":[1,1]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Titelmenü (Startmenü des Spiels)","cspan":1,"rspan":1,"markup":[1,32]},{"value":"Zugehörige Menüpunkte zum Starten, Laden eines \nSpiels, zur Charakterauswahl und zu den Einstellungen \nwurden erstellt, dessen Logik implementiert und getestet.","cspan":1,"rspan":1,"markup":[1,160]},{"value":"Muss","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"3","cspan":1,"rspan":1,"markup":[1,1]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Shopszene","cspan":1,"rspan":1,"markup":[1,9]},{"value":"Logik zum Kaufen und Verkaufen von Pflanzen, Kauf von\nPflanzensamen und Shopinterface wurde implementiert \nund getestet.","cspan":1,"rspan":1,"markup":[1,120]},{"value":"Muss","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"4","cspan":1,"rspan":1,"markup":[1,1]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Weltszene","cspan":1,"rspan":1,"markup":[1,9]},{"value":"Szene sammt Szenenwechsellogik und -animation wurde \nimplementiert und getestet.","cspan":1,"rspan":1,"markup":[1,80]},{"value":"Kann","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"5","cspan":1,"rspan":1,"markup":[1,1]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Implementierung der Pflanzenlogik bezüglich\nBewässerung und Pflanzenwachstum","cspan":1,"rspan":1,"markup":[1,76]},{"value":"Realistische Funktionalität wurde nach der Implementierung\ngetestet.","cspan":1,"rspan":1,"markup":[1,68]},{"value":"Muss","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"6","cspan":1,"rspan":1,"markup":[1,1]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Backend in Form einer Datenbank \nzur Speicherung aller Spieler- und Pflanzendaten","cspan":1,"rspan":1,"markup":[1,81]},{"value":"Spieler und Pflanzendaten werden korrekt gespeichert und \nausgelesen, Debuggingtools dienen zum Testen der Werte.","cspan":1,"rspan":1,"markup":[1,113]},{"value":"Muss","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"7","cspan":1,"rspan":1,"markup":[1,1]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Bereitstellung von Github Actions zum automatisierten \nKompilieren des Papers sowie des Spiels \nals ausführbare Datei","cspan":1,"rspan":1,"markup":[1,117]},{"value":"Testweises Kompilieren der aktuellen Stände von Paper\nund Spielprojekt auf Github","cspan":1,"rspan":1,"markup":[1,81]},{"value":"Muss","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"8","cspan":1,"rspan":1,"markup":[1,1]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Texturen für Pflanzen, Töpfe und\nweitere Assets des Spiels","cspan":1,"rspan":1,"markup":[1,58]},{"value":"Speicherung aller benötigten Assets auf Github mit \nentsprechender Verfügbarkeit in der Spielengine","cspan":1,"rspan":1,"markup":[1,99]},{"value":"Muss","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"9","cspan":1,"rspan":1,"markup":[1,1]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Logoerstellung","cspan":1,"rspan":1,"markup":[1,14]},{"value":"Nutzung eines fertigen Logos in allen Facetten des Spiel\nmit der Zufriedenheit aller Gruppenmitglieder","cspan":1,"rspan":1,"markup":[1,102]},{"value":"Soll","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"10","cspan":1,"rspan":1,"markup":[1,2]},{"value":"Hauptziel","cspan":1,"rspan":1,"markup":[1,9]},{"value":"Fertigstellung des Papers","cspan":1,"rspan":1,"markup":[1,25]},{"value":"Alle Kapitel wurden fertig gestellt mit zusätzlicher \nUnterzeichnung der ehrenwörtlichen Erklärung aller\nGruppenmitglieder.","cspan":1,"rspan":1,"markup":[1,123]},{"value":"Muss","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"11","cspan":1,"rspan":1,"markup":[1,2]},{"value":"Termin","cspan":1,"rspan":1,"markup":[1,6]},{"value":"Fertigstellung der Spieleentwicklung","cspan":1,"rspan":1,"markup":[1,36]},{"value":"Das Spiel wird am 29.10.2024 um 23:59 Uhr fertig\ngestellt in seiner Entwicklung.","cspan":1,"rspan":1,"markup":[1,80]},{"value":"Kann","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"12","cspan":1,"rspan":1,"markup":[1,2]},{"value":"Termin","cspan":1,"rspan":1,"markup":[1,6]},{"value":"Endpräsentation","cspan":1,"rspan":1,"markup":[1,15]},{"value":"Vorstellung des Projekts bei der Endpräsentation mit \nzusätzlicher Abgabe der Folien bei Moodle \nbis zum 29.10.2024 um 23:59 Uhr","cspan":1,"rspan":1,"markup":[1,128]},{"value":"Muss","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"13","cspan":1,"rspan":1,"markup":[1,2]},{"value":"Termin","cspan":1,"rspan":1,"markup":[1,6]},{"value":"Abschluss des Projektes","cspan":1,"rspan":1,"markup":[1,23]},{"value":"Pünktliche Abgabe des Source-Codes und der \nEndpäsentation auf Moodle am 29.10.2024 \num 23:59 Uhr und des Papers am 05.11.2024 \num 23:59 Uhr","cspan":1,"rspan":1,"markup":[1,140]},{"value":"Soll","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"14","cspan":1,"rspan":1,"markup":[1,2]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Sehr gute Bewertung des Projekts","cspan":1,"rspan":1,"markup":[1,32]},{"value":"Gewünschte Bewertung vom Stakeholder wird erreicht","cspan":1,"rspan":1,"markup":[1,50]},{"value":"Soll","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"15","cspan":1,"rspan":1,"markup":[1,2]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Lerneffekt bei Nutzern des Spiels zum Wissen über\nPflanzen und Ökosysteme","cspan":1,"rspan":1,"markup":[1,73]},{"value":"Feedback von Nutzern des Spiels","cspan":1,"rspan":1,"markup":[1,31]},{"value":"Soll","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"16","cspan":1,"rspan":1,"markup":[1,2]},{"value":"Sozial","cspan":1,"rspan":1,"markup":[1,6]},{"value":"Entwicklung von Gewohnheiten bei der Pflanzenpflege\nder Haus- oder Gartenpflanzen des Nutzers","cspan":1,"rspan":1,"markup":[1,93]},{"value":"Feedback von Nutzern des Spiels","cspan":1,"rspan":1,"markup":[1,31]},{"value":"Soll","cspan":1,"rspan":1,"markup":[1,4]}],[{"value":"17","cspan":1,"rspan":1,"markup":[1,2]},{"value":"Leistung","cspan":1,"rspan":1,"markup":[1,8]},{"value":"Nutzer haben Spaß am Spielen von Grow Green","cspan":1,"rspan":1,"markup":[1,43]},{"value":"Feedback von Nutzern des Spiels","cspan":1,"rspan":1,"markup":[4,31]},{"value":"Kann","cspan":1,"rspan":1,"markup":[1,4]}]]},"theme":null,"fixed_layout":false,"markup":{"instances":[{},{"style":{"fontWeight":"","fontStyle":"","textDecoration":"","color":"","backgroundColor":""}},{"style":{"fontWeight":"","textDecoration":"","color":"","backgroundColor":""}},null,{"style":{"fontWeight":"400","fontStyle":"normal","textDecoration":"","color":"","backgroundColor":""}},null]},"options":{"table_caption":"","table_label":"tab:my-table"}}
\ No newline at end of file
diff --git a/Software-Engineering/Softwareengineering Paper von Philip Algosim.pdf b/Software-Engineering/Softwareengineering Paper von Philip Algosim.pdf
new file mode 100644
index 0000000..455fdac
Binary files /dev/null and b/Software-Engineering/Softwareengineering Paper von Philip Algosim.pdf differ
diff --git a/Software-Engineering/Steckbrief.xlsx b/Software-Engineering/Steckbrief.xlsx
new file mode 100644
index 0000000..0d95bf8
Binary files /dev/null and b/Software-Engineering/Steckbrief.xlsx differ
diff --git a/Software-Engineering/greenhouse.png b/Software-Engineering/greenhouse.png
new file mode 100644
index 0000000..e68b9ba
Binary files /dev/null and b/Software-Engineering/greenhouse.png differ
diff --git a/Studienarbeit I/.DS_Store b/Studienarbeit I/.DS_Store
new file mode 100644
index 0000000..49fd9c7
Binary files /dev/null and b/Studienarbeit I/.DS_Store differ
diff --git a/Studienarbeit I/Inhalte für Kapitel.md b/Studienarbeit I/Inhalte für Kapitel.md
new file mode 100644
index 0000000..44b4fc1
--- /dev/null
+++ b/Studienarbeit I/Inhalte für Kapitel.md
@@ -0,0 +1,75 @@
+# Inhalte für Kapitel
+
+### 1. Einleitung (250 Wörter) ✅
+- grobe Einführung ins Thema
+- Ziel der Arbeit darlegen
+- folgende Kapitel erwähnen
+
+### 2. Problemstellung (500 Wörter) ✅
+Teilabschnitte in Absätzen erklären ohne Überschriften
+#### 1. Was ist das eigentliche Problem? (~150 Wörter)
+- Leser-Schreiber-Problem
+- Datenkorruption durch unkoordinierte Schreibvorgänge
+- Performance-Einbußen durch zu restriktive Synchronisation
+#### 2. Warum ist das relevant/schwierig? (~150 Wörter)
+- Timing-Probleme sind schwer vorhersagbar
+- Debugging von Synchronisationsfehlern ist aufwendig
+#### 3. Was fehlt bisher? (~100 Wörter)
+- Keine intuitive Visualisierung solcher Synchronisationsprobleme
+- Schwer verständlich für Lernende/Entwickler, da das Problem schon gelöst ist
+- Abstrakte Konzepte bleiben theoretisch
+#### 4. Konkrete Anforderungen (~100 Wörter)
+- Entwicklung einer Anwendung, die diese Probleme **sichtbar macht**
+- Desktop-Anwendung mit zwei kommunizierenden Instanzen
+- Praktisches Verständnis fördern
+**Problemstellung = "Hier sind die konkreten Schwierigkeiten, die existieren, und das will ich dagegen tun."**
+
+### 3. Theoretisch Grundlagen (1000 Wörter) ✅
+- Leser-Schreiber-Problem (400 Wörter)
+ - Problemdefinition
+ - Klassische Varianten
+ - Theoretische Lösungsansätze
+- ISO/OSI Modell (270 Wörter)
+ - Relevante Schichten für Ihr Projekt
+ - Fokus auf Transport- und Anwendungsschicht
+- TCP (280 Wörter)
+ - Ist Anforderung fürs Projekt
+ - Verbindungsaufbau/-abbau
+ - Zuverlässige Datenübertragung
+ - Relevanz für Ihr Problem
+
+### 4. Entwurf (1000 Wörter)✅
+Grundsätzlich nur Struktur, kein Code genau erklären!
+#### 4.1 Systemarchitektur (300 Wörter)✅
+- Gesamtübersicht des Systems
+- Komponentendiagramm
+#### 4.2 Frontend (330 Wörter)✅
+- Struktureller Aufbau vom Frontend
+- Verwendete Technologien/Bibliotheken
+- Diagramm für Aufbau
+- Abläufe grob erklären für UI Aufbau
+- Visualisierungskonzept
+#### 4.3 Backend (400 Wörter)
+- Struktureller Aufbau vom Backend
+- Synchronisationsstrategie
+- Diagramm für Aufbau
+- Abläufe grob erklären für Serveraufbau mit Portlistening
+
+### 5. Algorithmen (1300 Wörter)✅
+Unter anderem Go-Bibliotheken erklären bzw. Abwägung zwischen Go-Bibliotheken!
+
+### 6. Diskussion von Ergebnissen (500 Wörter) ✅
+- Auf konkrete Ergebnisse in der Software eingehen wie die aktuelle Lösung des Verbindungshandlings z.B.
+- Vergleich verschiedener Lösungsansätze
+- Limitationen der aktuellen Implementierung
+- Skalierbarkeit
+
+### Fazit (380 Wörter) ✅
+- Zusammenfassung der Ergebnisse
+- Erreichte Ziele vs. ursprüngliche Anforderungen
+- Abschluss mit kleiner Reflexion des Projekts
+- Anregungen/Ideen für die Zukunft
+- Möglichkeiten für Studienprojekt II
+
+### Anhang
+- Längere Codesnippets zum Verweisen
\ No newline at end of file
diff --git a/Studienarbeit I/Studienarbeit_I___Network_Interaction_in_Go.zip b/Studienarbeit I/Studienarbeit_I___Network_Interaction_in_Go.zip
new file mode 100644
index 0000000..8f9e3f2
Binary files /dev/null and b/Studienarbeit I/Studienarbeit_I___Network_Interaction_in_Go.zip differ
diff --git a/Studienarbeit I/TAG DER INFORMATIK Poster - Network Interaction in GoLang (Alexander Betke, Theo Leuthardt).pdf b/Studienarbeit I/TAG DER INFORMATIK Poster - Network Interaction in GoLang (Alexander Betke, Theo Leuthardt).pdf
new file mode 100644
index 0000000..1c0672f
Binary files /dev/null and b/Studienarbeit I/TAG DER INFORMATIK Poster - Network Interaction in GoLang (Alexander Betke, Theo Leuthardt).pdf differ
diff --git a/Studienarbeit II/.DS_Store b/Studienarbeit II/.DS_Store
new file mode 100644
index 0000000..78bab4b
Binary files /dev/null and b/Studienarbeit II/.DS_Store differ
diff --git a/Studienarbeit II/Inhalte.md b/Studienarbeit II/Inhalte.md
new file mode 100644
index 0000000..bcb9ca1
--- /dev/null
+++ b/Studienarbeit II/Inhalte.md
@@ -0,0 +1,28 @@
+---
+share_link: https://share.note.sx/kce43il1#4EXkK8s6Yf+GsV46leOCXZUiTeIrCIxRNvupy6vOwU8
+share_updated: 2025-12-09T13:51:04+01:00
+---
+
+# Inhaltswünsche von Zimmi
+
+- Funktionale und Nichtfunktionale Anforderungen
+- Literaturarbeit
+- Grafiken/Struktogramme zu Aufbau und Kommunikation der Modelle, Aufbau des Architektur Stacks, TCP Protokoll Struktur (**Entwurfskapitel**)
+- Screenshots der Anwendung in Light Mode (**Algorithmenkapitel** oder **Anhang**)
+
+# Inhaltsverzeichnis
+
+1. **Abstract**
+2. **Einleitung**
+3. **Problemstellung**
+4. **Anforderungsanalyse**
+ 1. Funktionale
+ 2. Nichtfunktionale
+5. **Theoretische Grundlagen** (Erklärung aller notwendigen Prinzipien für die Entwicklung der Erweiterung, z.B. tiefere theoretische Erklärung des Findens von anderen Instanzen im lokalen Netzwerk)
+6. **Entwurf** (Referenzen zu Anforderungen)
+ 1. Strukturelle Veränderungen im Backend
+ 2. Strukturelle Veränderungen im Frontend
+7. **Algorithmen** (Referenzen zu Anforderungen)
+ 1. Pro konkreter Codeänderung ein Unterabschnitt
+8. **Diskussion** (Vergleich Vorher/Nachher nach der Erweiterung der Software in Aspekten wie der Nutzerfreundlichkeit und der Nutzbarkeit der Software)
+9. **Fazit**
\ No newline at end of file
diff --git a/Studienarbeit II/Studienarbeit_2_Leuthardt_Betke.pdf b/Studienarbeit II/Studienarbeit_2_Leuthardt_Betke.pdf
new file mode 100644
index 0000000..65d3809
Binary files /dev/null and b/Studienarbeit II/Studienarbeit_2_Leuthardt_Betke.pdf differ
diff --git a/Studienarbeit II/Vortragsnotizen.md b/Studienarbeit II/Vortragsnotizen.md
new file mode 100644
index 0000000..787ce92
--- /dev/null
+++ b/Studienarbeit II/Vortragsnotizen.md
@@ -0,0 +1,46 @@
+# Vortragsnotizen:
+
+## 1. Status Quo (auch Randbedingungen)
+### Technologien
+- Golang als Programmiersprache (unverändert)
+- Goland als IDE (in Studienprojekt I)
+- VSCode (Editor mit Extension wegen besserer WSL Kompatibität)
+- Fyne als Frontend-Go-Library (unverändert)
+- Überlegung: Frontend-Framework als Frontend mit REST-API Kommunikation (React, Angular, Vue)
+ - mehr Aufwand der nur die Inconvinience von Fyne lösen würde
+ - Probleme mit Wails für Web-Framework-Desktop Apps
+ - somit mehr Aufwand als funktionale Veränderungen
+ - deshalb bei Fyne bleiben mit Kommunikation über Signal Channel
+
+- TCP/IP als Protokoll weiterhin
+- Testing: Zwei Szenarien:
+ - Zwei Computer (inconvinient)
+ - Zwei Instanzen auf dem selben Computer oder zwei VMs haben sich eher bewährt wegen Zeiteffizienz
+
+### Funktionalitäten
+- Bisher bauen wir auf einer Software auf mit:
+ - Netzwerk: Lokale automatische TCP-Verbindungen
+ - TCP-Paketversand automatisch in drei verschiedenen Verzögerungen
+ - Pakete werden visualisiert über Balkendiagramme
+ - Verbindungsstatus LED für den User
+ - Dark Mode für Barriefreiheit, wie reduzierte Augenbelastung und bessere Lesbarkeit
+ - Fenster kann im Vollbild genutzt werden mit automatischer Skalierung der UI-Elemente
+ - Cross-Platform kompatibel, Auslieferung für Windows, Linux und MacOS
+
+## Frontend-Erweiterungen
+### Peer-Discovery
+- Vorher: Nutzer kann nicht sehen mit welchem anderen Peer er verbunden ist, nur dass er überhaupt verbunden ist oder nicht
+- Snapdrop UI nicht realisiert weil:
+ - Fyne arbeitet mit statischen Layouts und nativen Widgets
+ - Radar-Zeichnung im Canvas zu komplex zur Erhaltung der Wartbarkeit des Code
+ - Stattdessen Stärke von Fyne: Grid-Layout
+ - Für Snapdrop Frontend-Austausch durch Web-Framework nötig leider (besser lösbar darin)
+
+- **Button Grid** für verfügbare Instanzen, blau/weiß oder blau/schwarz für hohen kontrast
+- Grid wird vom Backend alle 100ms aktualisiert
+- **Responsiveness im Button Grid Container** :
+ - Schmales Fenster: Nur zwei Buttons nebeneinander
+ - Breites Fenster: Vier Buttons nebeneinander,
+- Vorher: User klickt auf Button -> verbindet sich -> kann nur disconnecten indem er das Programm schließt
+- Disconnect Button im verbunden Zustand
+- Keine Peers werden angezeigt, weil die aktuelle Instanz schon verbunden ist
\ No newline at end of file
diff --git a/Studienarbeit II/Workspace fürs Schreiben.md b/Studienarbeit II/Workspace fürs Schreiben.md
new file mode 100644
index 0000000..111d780
--- /dev/null
+++ b/Studienarbeit II/Workspace fürs Schreiben.md
@@ -0,0 +1,13 @@
+# Workspace Struktur
+
+studienarbeit/
+├── network-interaction/
+├── network-interaction-deepwiki/
+├── studienarbeit-i/
+└── studienarbeit-ii/
+
+**Github-Repo Network-Interaction**: https://github.com/theoleuthardt/network-interaction
+**Github-Repo Studienarbeit II**: https://github.com/theoleuthardt/studienarbeit-ii
+**Deepwiki**: https://deepwiki.com/theoleuthardt/network-interaction/
+**DeepwikiToMarkdown**: https://github.com/zxmfke/deepwiki-md-chrome-extension
+
diff --git a/Studienarbeit II/deepwiki.zip b/Studienarbeit II/deepwiki.zip
new file mode 100644
index 0000000..35e8b93
Binary files /dev/null and b/Studienarbeit II/deepwiki.zip differ
diff --git a/Studienarbeit II/evaluation_studienarbeit_i.md b/Studienarbeit II/evaluation_studienarbeit_i.md
new file mode 100644
index 0000000..0d99629
--- /dev/null
+++ b/Studienarbeit II/evaluation_studienarbeit_i.md
@@ -0,0 +1,101 @@
+# Evaluation
+Diese Evaluation der Studienarbeit I ist in numerierte Teilbewertungskriterien unterteilt.
+Jedes Kriterium hat Inhalte, die bewertet werden, einen Bewertungstext und eine Punktzahl.
+
+## 1. Theoretische Betrachtungen
+### Inhalte des Bewertungskriteriums
+- Literaturarbeit
+- Kritische Diskussion voriger Arbeiten
+- Nachvollzierbarkeit der Aussagen
+- Entscheidungskriterien
+- Argumentationsweise
+
+### Bewertung
+Literaturarbeit ist vorhanden. Die vorigen Arbeiten werden ausführlich besprochen (Punkt 3.1). Argumentationsweise ist
+logisch, die Entscheidungskriterien sind nachvollziehbar.
+
+### Punktzahl
+20 von 20
+
+## 2. Praktische Ausführung
+### Inhalte des Bewertungskriteriums
+- Analyse, Entwurf, Konzept
+- Dis kussion von Realisierungsansätzen
+- Evaluierung, Testen
+- Praktische Anwendung fachlichen Wissens
+- Auswahl und Einsatz von Hilfsmitteln
+
+### Bewertung
+Die Anforderungsanalyse scheint spärlich zu sein: Im Punkt 2.3. sind neben den Anforderungen vielmehr die algorithmische
+Vorgehensweise besprochen. Im Punkt 6 tauchen plötzlich "die Limits und Skalierbarkeit der Software" auf, die nicht unter
+Anforderungen aufgelistet sind. Es wäre ratsam, die Anforderungen in funktionale und nicht-funktionale zu unterteilen und
+strukturiert (z.B. als Tabelle) darzustellen [-2]. Die Anforderung bezüglich Sprache Go findet man dort auch nicht explizit,
+obwohl in anderen Teile ist sie präsent. Die Programme sind strukturiert geschrieben. Fazit und Ausblick sind vorhanden.
+Die im Studium erworbenen Kenntnisse sind fachlich umgesetzt.
+
+### Punktzahl
+23 von 25
+
+## 3. Eigeninitiative, Einsatz und Arbeitsstil
+### Inhalte des Bewertungskriteriums
+- Eigene Ideen, Selbstständigkeit
+- Krit ikfähigkeit
+- Arbeitsstil
+- Arbeitsorganisation
+
+### Bewertung
+Die Erarbeitung erfolgte selbstständig. Organisierte und strukturierte Arbeitsweise ist gut erkennbar.
+
+### Punktzahl
+5 von 5
+
+## 4. Inhalt der Dokumentation
+### Inhalte des Bewertungskriteriums
+- Fachlicher Gehalt
+- Darstellung der Zielrichtung
+- Definition der Randbedingungen
+- Herausarbeiten der Schwerpunkte
+- Diskussion der Ergebnisse
+
+### Bewertung
+Ziele sind im Punkt 2 zu erkennen. Forschungsansatz und Vorgehensweise sind wohl durchdacht. Die Randbedingungen sind
+leider nicht vorhanden, aber lassen sich teilweise im Text erkennen. Die Schwerpunkte sind passend erarbeitet und vorgestellt.
+Es fehlen aber die im Punkt 2.3 versprochenen grafischen Darstellungen der funktionierenden Anwendung [-2]. Ergebnisse
+sind kritisch evaluiert und diskutiert.
+
+### Punktzahl
+18 von 20
+
+## 5. Form der Dokumentation
+### Inhalte des Bewertungskriteriums
+- Gliederung, Übersichtlichkeit
+- Stil, Grammatik
+- Verweise, Zitierungen
+- Literaturverzeichnis, Literaturquellen
+
+### Bewertung
+Die Gliederung ist gut strukturiert und bildet den Inhalt der Arbeit ab. Die Auslegung wird passend mit Bildern,
+Source-Code und Tabellen begleitet. Stil und Grammatik sind für eine wissenschaftliche Arbeit geeignet. Literaturverzeichnis
+enthält gute Referenzen. Umfang der schriftlichen Arbeit ist kurz (22 Seiten) [-2].
+
+### Punktzahl
+8 von 10
+
+## 6. Referat
+### Inhalte des Bewertungskriteriums
+- Einführung ins Thema, Sachgehalt
+- Aufbau, Bezüge, roter Faden
+- Timing, Umgang mit Medien
+- Vorbereitung, Kompetenz, Vortragsstil
+- Folien (Lesbarkeit/Aufteilung/Quellen)
+
+### Bewertung
+Das Referat stellt das Thema umfassend dar. Der rote Faden ist nachvollziehbar. Aus der Präsentation wird klar, dass
+die grundlegenden Ziele, Anforderungen und die Methodik, es umzusetzen, vorstellbar für den Autor sind. Timing ist optimal,
+Vortragsstil ist kompetent. Die Folien sind gut lesbar, die Literaturquellen sind vorhanden.
+
+### Punktzahl
+20 von 20
+
+## Gesamtpunktzahl
+94 von 100
\ No newline at end of file
diff --git a/Studienarbeit II/presentation_notes.md b/Studienarbeit II/presentation_notes.md
new file mode 100644
index 0000000..787ce92
--- /dev/null
+++ b/Studienarbeit II/presentation_notes.md
@@ -0,0 +1,46 @@
+# Vortragsnotizen:
+
+## 1. Status Quo (auch Randbedingungen)
+### Technologien
+- Golang als Programmiersprache (unverändert)
+- Goland als IDE (in Studienprojekt I)
+- VSCode (Editor mit Extension wegen besserer WSL Kompatibität)
+- Fyne als Frontend-Go-Library (unverändert)
+- Überlegung: Frontend-Framework als Frontend mit REST-API Kommunikation (React, Angular, Vue)
+ - mehr Aufwand der nur die Inconvinience von Fyne lösen würde
+ - Probleme mit Wails für Web-Framework-Desktop Apps
+ - somit mehr Aufwand als funktionale Veränderungen
+ - deshalb bei Fyne bleiben mit Kommunikation über Signal Channel
+
+- TCP/IP als Protokoll weiterhin
+- Testing: Zwei Szenarien:
+ - Zwei Computer (inconvinient)
+ - Zwei Instanzen auf dem selben Computer oder zwei VMs haben sich eher bewährt wegen Zeiteffizienz
+
+### Funktionalitäten
+- Bisher bauen wir auf einer Software auf mit:
+ - Netzwerk: Lokale automatische TCP-Verbindungen
+ - TCP-Paketversand automatisch in drei verschiedenen Verzögerungen
+ - Pakete werden visualisiert über Balkendiagramme
+ - Verbindungsstatus LED für den User
+ - Dark Mode für Barriefreiheit, wie reduzierte Augenbelastung und bessere Lesbarkeit
+ - Fenster kann im Vollbild genutzt werden mit automatischer Skalierung der UI-Elemente
+ - Cross-Platform kompatibel, Auslieferung für Windows, Linux und MacOS
+
+## Frontend-Erweiterungen
+### Peer-Discovery
+- Vorher: Nutzer kann nicht sehen mit welchem anderen Peer er verbunden ist, nur dass er überhaupt verbunden ist oder nicht
+- Snapdrop UI nicht realisiert weil:
+ - Fyne arbeitet mit statischen Layouts und nativen Widgets
+ - Radar-Zeichnung im Canvas zu komplex zur Erhaltung der Wartbarkeit des Code
+ - Stattdessen Stärke von Fyne: Grid-Layout
+ - Für Snapdrop Frontend-Austausch durch Web-Framework nötig leider (besser lösbar darin)
+
+- **Button Grid** für verfügbare Instanzen, blau/weiß oder blau/schwarz für hohen kontrast
+- Grid wird vom Backend alle 100ms aktualisiert
+- **Responsiveness im Button Grid Container** :
+ - Schmales Fenster: Nur zwei Buttons nebeneinander
+ - Breites Fenster: Vier Buttons nebeneinander,
+- Vorher: User klickt auf Button -> verbindet sich -> kann nur disconnecten indem er das Programm schließt
+- Disconnect Button im verbunden Zustand
+- Keine Peers werden angezeigt, weil die aktuelle Instanz schon verbunden ist
\ No newline at end of file
diff --git a/Studienarbeit II/studienarbeit-ii.zip b/Studienarbeit II/studienarbeit-ii.zip
new file mode 100644
index 0000000..3b28999
Binary files /dev/null and b/Studienarbeit II/studienarbeit-ii.zip differ
diff --git a/_Templates/Vorlesung-Template.md b/_Templates/Vorlesung-Template.md
new file mode 100644
index 0000000..e876a97
--- /dev/null
+++ b/_Templates/Vorlesung-Template.md
@@ -0,0 +1,53 @@
+# VL{{NR}} — {{THEMA}}
+
+> **Modul:** {{MODUL}}
+> **Datum:** {{DATUM}}
+> **Folien:** {{ANZAHL}} Seiten
+
+---
+
+## Kernkonzepte
+
+> Die wichtigsten Konzepte dieser Vorlesung auf einen Blick.
+
+### 1. {{Konzept}}
+
+- ...
+
+### 2. {{Konzept}}
+
+- ...
+
+---
+
+## Zusammenfassung
+
+> Ausführliche Zusammenfassung der Vorlesungsinhalte.
+
+...
+
+---
+
+## Wichtige Begriffe
+
+| Begriff | Definition |
+|---|---|
+| ... | ... |
+
+---
+
+## Prüfungsrelevanz
+
+> Was davon ist besonders klausurrelevant?
+
+- ...
+
+---
+
+## Offene Fragen
+
+- [ ] ...
+
+---
+
+> *Zusammenfassung erstellt mit Claude · {{DATUM}}*
diff --git a/ptb2/PTB2_Sichtvermerk_kr_troegmar.pdf b/ptb2/PTB2_Sichtvermerk_kr_troegmar.pdf
new file mode 100644
index 0000000..7d9b65a
Binary files /dev/null and b/ptb2/PTB2_Sichtvermerk_kr_troegmar.pdf differ
diff --git a/ptb3 seminar/Bewertung+Theo+Leuthardt.pdf b/ptb3 seminar/Bewertung+Theo+Leuthardt.pdf
new file mode 100644
index 0000000..65c7f8d
Binary files /dev/null and b/ptb3 seminar/Bewertung+Theo+Leuthardt.pdf differ
diff --git a/ptb3 seminar/ERM_aktuell.png b/ptb3 seminar/ERM_aktuell.png
new file mode 100644
index 0000000..b5ed884
Binary files /dev/null and b/ptb3 seminar/ERM_aktuell.png differ
diff --git a/ptb3 seminar/ERM_neu.png b/ptb3 seminar/ERM_neu.png
new file mode 100644
index 0000000..c0ab971
Binary files /dev/null and b/ptb3 seminar/ERM_neu.png differ
diff --git a/ptb3 seminar/Java.png b/ptb3 seminar/Java.png
new file mode 100644
index 0000000..4be53c3
Binary files /dev/null and b/ptb3 seminar/Java.png differ
diff --git a/ptb3 seminar/PP_Vorlage.pptx b/ptb3 seminar/PP_Vorlage.pptx
new file mode 100644
index 0000000..3924cec
Binary files /dev/null and b/ptb3 seminar/PP_Vorlage.pptx differ
diff --git a/ptb3 seminar/PT2_PP.pptx b/ptb3 seminar/PT2_PP.pptx
new file mode 100644
index 0000000..eeede72
Binary files /dev/null and b/ptb3 seminar/PT2_PP.pptx differ
diff --git a/ptb3 seminar/PTB_III_Sichtvermerk.pdf b/ptb3 seminar/PTB_III_Sichtvermerk.pdf
new file mode 100644
index 0000000..909528e
Binary files /dev/null and b/ptb3 seminar/PTB_III_Sichtvermerk.pdf differ
diff --git a/ptb3 seminar/Projektstruktur.png b/ptb3 seminar/Projektstruktur.png
new file mode 100644
index 0000000..6c781e6
Binary files /dev/null and b/ptb3 seminar/Projektstruktur.png differ
diff --git a/ptb3 seminar/ausweisapp2.jpg b/ptb3 seminar/ausweisapp2.jpg
new file mode 100644
index 0000000..4ff7412
Binary files /dev/null and b/ptb3 seminar/ausweisapp2.jpg differ
diff --git a/ptb3 seminar/confluence.svg b/ptb3 seminar/confluence.svg
new file mode 100644
index 0000000..22249e1
--- /dev/null
+++ b/ptb3 seminar/confluence.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/ptb3 seminar/erm.png b/ptb3 seminar/erm.png
new file mode 100644
index 0000000..1c86753
Binary files /dev/null and b/ptb3 seminar/erm.png differ
diff --git a/ptb3 seminar/erm_nobg.png b/ptb3 seminar/erm_nobg.png
new file mode 100644
index 0000000..22ff749
Binary files /dev/null and b/ptb3 seminar/erm_nobg.png differ
diff --git a/ptb3 seminar/gitlab.svg b/ptb3 seminar/gitlab.svg
new file mode 100644
index 0000000..5fbbedd
--- /dev/null
+++ b/ptb3 seminar/gitlab.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/ptb3 seminar/jpa.webp b/ptb3 seminar/jpa.webp
new file mode 100644
index 0000000..390ff2b
Binary files /dev/null and b/ptb3 seminar/jpa.webp differ
diff --git a/ptb3 seminar/personalausweis.jpg b/ptb3 seminar/personalausweis.jpg
new file mode 100644
index 0000000..e585781
Binary files /dev/null and b/ptb3 seminar/personalausweis.jpg differ