diff --git a/20220519/ad-20220519.txt b/20220519/ad-20220519.txt
index 1403571d3ba53c5c847b3a25a2361f02b0d78b9f..1b7b3f76dee654b06b7dee25ca00d9599998f5e1 100644
--- a/20220519/ad-20220519.txt
+++ b/20220519/ad-20220519.txt
@@ -29,7 +29,7 @@ Damit sich die Teams nicht gegenseitig blockieren:
- "Dummy"-Funktionen für 64-Bit-Zahlen schreiben,
um damit schon mal die Schnittstelle festzulegen.
- - Später dann die Dummy-FUnktionen gegen die richtigen austauschen.
+ - Später dann die Dummy-Funktionen gegen die richtigen austauschen.
Beispiel:
diff --git a/20220609/ad-20220609.txt b/20220609/ad-20220609.txt
new file mode 100644
index 0000000000000000000000000000000000000000..ff9a82a8cc194c0b3f4a8a86e60769babc8ed1f5
--- /dev/null
+++ b/20220609/ad-20220609.txt
@@ -0,0 +1,181 @@
+Fehlererkennung und Fehlerkorrektur
+===================================
+
+Parität, 09.06.2022, 11:05:40
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Nachricht enthält n Datenbits und ein Paritäts-Bit.
+ - Ungerade Parität: Die Gesamtzahl der Eins-Bits muß ungerade sein.
+ ungerade Anzahl von Daten-1-Bits --> Paritäts-Bit muß 0 sein.
+ gerade Anzahl von Daten-1-Bits --> Paritäts-Bit muß 1 sein.
+ - Gerade Parität: Die Gesamtzahl der Eins-Bits muß gerade sein.
+
+Anders formuliert: Die n+1-Bit-Zahl aus den Datenbits und dem Paritäts-Bit
+ ... muß insgesamt ungerade/gerade sein.
+ = ... muß bei Division durch 2 einen vorgegebenen Rest liefern.
+
+Nachteil: nur 1 Bit-Fehler erkennbar
+
+Verbesserungsidee: durch etwas anderes teilen
+
+CRC, 09.06.2022, 11:05:27
+~~~~~~~~~~~~~~~~~~~~~~~~~
+Nachricht enthält n Datenbits und m Paritäts-Bits.
+
+Wir betrachten die n+m-Bit-Zahl als ein Polynom über { 0, 1 } (mod 2).
+
+CRC: Bei Polynomdivision muß ein vorgegebener Rest bleiben.
+ (Siehe "Tafelbild".)
+
+--> sehr zuverlässige Fehlererkennung,
+ sehr leicht zu implementieren, auch in Hardware
+
+--> nicht geeignet gegen gezielte Manipulation
+
+Kryptographische Hash-Funktionen, 09.06.2022, 13:02:24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Spezielle Funktionen: Nur 1 Bit anders im Input --> völlig anderer Output
+
+Für digitale Signaturen:
+ - nicht mehr empfohlen: MD5
+ - aktuell empfohlen: SHA-2 (= SHA-224, SHA-256, SHA-384 und SHA-512)
+ NICHT empfohlen für Passwort-Hashes
+
+Passwort-Hashes:
+ - Wir speichern Passwörter nicht im Klartext, sondern als Hashes.
+ Es ist nicht möglich, vom Hash auf das Passwort zu schließen.
+ - Authentifizierung: Der Server kennt das Passwort nicht, sondern nur den Hash.
+ Der Benutzer gibt das Passwort ein.
+ Der Server berechnet den Hash und prüft, ob dieser stimmt.
+ Er merkt sich insbesondere nicht das Passwort.
+ - Salt: Wir speichern eine zusätzliche Zufallszahl auf dem Server
+ und bilden den Hash über das Passwort zusammen mit der Zufallszahl.
+ - Man sieht nicht sofort, wenn Passwörter (zufällig) gleich sind.
+ - Man kann keine Hashes "auf Vorrat" anlegen.
+ Beispiel:
+ - Alle Benutzer verwenden Passwörter von 8 Zeichen Länge.
+ Dies entspricht etwa 8 * 6 = 48 Bits Zufall.
+ - Ein Angreifer berechnet "auf Vorrat" die Hashes aller 48-Bit-Zahlen.
+ - Aus einer versehentlich öffentlich gewordenen Tabelle ("Leak")
+ lassen sich leicht die Passwörter rekonstruieren.
+ - Gegenmaßnahme: Salt, z.B. 8 Bit
+ --> Die "Vorratstabelle" müßte dann nicht mehr "nur" alle 48-Bit-Zahlen
+ erfassen, sondern alle 56-Bit-Zahlen.
+ --> Obwohl das Salt bekannt ist (Teil der Tabelle),
+ erhöht es die Sicherheit.
+ - Problem mit SHA-2 als Passwort-Hash:
+ SHA-2 läßt sich schnell berechnen, insbesondere mit GPUs.
+ --> Durchprobieren riesiger Mengen von Passwörtern geht relativ schnell,
+ auch mit Salt.
+ Trotzdem hilft auch hier das Salt, denn es verhindert,
+ daß man mehrere Passwörter gleichzeitig angreift.
+ - Für diesen Zweck geeignetere Hash-Funktionen:
+ bcrypt, scrypt, argon2, evtl. auch pbkdf2
+ Nicht leicht auf GPUs berechenbar, insgesamt langsamer.
+ --> Möglicherweise daher für kryptographische Signaturen schlechter geeignet,
+ {weil dort größere Datenmengen ge"hash"t werden}
+ weil dort Hashes über größere Datenmengen gebildet werden.
+ --> Bei kryptographischen Signaturen besteht nicht das Problem
+ {mit der ge"leak"ten Nachricht nicht,}
+ mit der versehentlich öffentlich gewordenen Nachricht nicht,
+ denn die Nachricht ist ja absichtlich öffentlich
+ (Falls nicht, hilft Verschlüsselung.)
+ bzw. weil es ohnehin aussichtslos ist, anhand des kryptographischen Hashes
+ die Nachricht zu erraten.
+
+Fehlerkorrektur, 09.06.2022, 13:36:48
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Hamming-Code: siehe frühere Lehrveranstaltungen
+https://www.cvh-server.de/~pgerwinski/net-2013ss.pdf, Seite 28 bis 30
+
+Reed-Solomon-Code: Fehlererkennung und -Korrektur
+
+ - Anwendung: QR-Codes, optische Datenträger, Raumsonde Voyager 2
+
+ - Prinzip: Funktionsgraphen von Polynomen
+ 3 Punkte --> eindeutig für Polynom 2. Grades
+ 4 Punkte --> Polynom 2. Grades überbestimmt
+ 4 Punkte, einer falsch --> Polynom 2. Grades paßt nicht --> Fehlererkennung
+ 5 Punkte --> auch Fehlerkorrektur möglich, notfalls durch Ausprobieren
+ (die richtige Parabel kommt häufiger vor)
+ --> "einstellbares" Fehlererkennungs- und korrekturverfahren:
+ nur 3 Punkte: keine Fehlererkennung und -korrektur, nur die Daten
+ 4 Punkte: Fehlererkennung
+ 5 Punkte: Fehlererkennung, 1 Fehler korrigieren
+ 6 Punkte: Fehlererkennung, 2 Fehler korrigieren
+ ...
+
+ - In der Praxis: Polynom über endlichem Körper, z.B. mit 5 Elementen
+ Mathematik: Dies funktioniert alles genauso wie in den reellen Zahlen.
+ Z.B.: Man vereinbart vorher die Stützstellen (x-Koordinaten)
+ und übermittelt die Funktionswerte (y-Koordinaten).
+
+ ( { 0, 1, 2, 3, 4 }, +, · ) (mod 5)
+
+ Stützstellen: alle, also 0, 1, 2, 3, 4
+
+ Parabel übermitteln, z.B. x²,
+ also a2 = 1, a1 = 0, a0 = 0,
+ also die Nachricht ( 1, 0, 0 )
+
+ Funktionswerte berechnen:
+ 0² = 0
+ 1² = 1
+ 2² = 4
+ 3² = 4
+ 4² = 1
+
+ Funktionswerte übermitteln, Übertragungsfehler
+
+ x | y
+ ---+---
+ 0 | 0
+ 1 | 1
+ 2 | 4
+ 3 | 3 <-- falsch; richtig wäre: 4
+ 4 | 1
+
+ Gleichungssystem aufstellen und lösen --> widersprüchliche Ergebnisse --> Fehler erkannt
+
+ Gleichungssystem aufstellen und lösen für jeweils 3 der Punkte
+
+ Parabel: a2 x² + a1 x + a0
+
+ 0: a2 · 0² + a1 · 0 + a0 = 0 \
+ 1: a2 · 1² + a1 · 1 + a0 = 1 } a0 = 0, a2 + a1 = 1, a2 + a1 = 1
+ 2: a2 · 2² + a1 · 2 + a0 = 4 / 4a2 + 2a1 = 4, 2a2 + a1 = 2
+ 3: a2 · 3² + a1 · 3 + a0 = 3 ------------
+ 4: a2 · 4² + a1 · 4 + a0 = 1 -a2 = -1, a2 = 1, a1 = 0
+ --> Nachricht rekonstruiert
+ Auf diese Weise bekommen wir häufiger die richtige
+ Nachricht rekonstruiert als falsche, ...
+
+ ... es sei denn, die Übertragung enthält mehr als 1 Fehler.
+
+ In der Praxis häufig: Körper mit 8 oder 16 Elementen.
+ Diese sind NICHT { 0, 1, ..., 7 } bzw. { 0, 1, ..., 15 }.
+
+ Zur Illustration: Körper mit 25 Elementen.
+ Dieser ist NICHT { 0, 1, ..., 24 }, sondern
+ { 0, 1, 2, 3, 4 } [ sqrt(2) ] ("adjungiert Wurzel 2"). Das bedeutet:
+
+ - Wir haben die Zahlen { 0, 1, 2, 3, 4 } modulo 5
+ und zusätzlich w = sqrt(2) mit der Eigenschaft w · w = 2
+ und zusätzlich alle Kombinationen davon, also z.B. 3 + 2w.
+
+ - Dann können wir multiplizieren, z.B.:
+ (3 + 2w) · (1 + w)
+ = 3 · 1 + 2w · 1 + 3w + 2w²
+ = 3 + 5w + 2 · 2
+ = 3 + 0w + 4
+ = 2
+
+ - Jede Zahl: x + y·w (ähnlich komplexen Zahlen: x + y·i)
+
+ - Speicherung als 5-Bit-Zahl (0..31; wir verschwenden die Werte 25 bis 31)
+ oder als 6-Bit-Zahl mit jeweils 3 Bit für "normalen Teil" und "w-Teil" (schneller,
+ aber wir verschwenden mehr als 1 Bit, also mehr als die Hälfte aller Werte)
+
+ Zur Illustration: Körper mit 4 Elementen: siehe
+ https://de.wikipedia.org/wiki/Endlicher_K%C3%B6rper#Der_K%C3%B6rper_mit_4_Elementen
+
+ - In der Praxis in der Praxis: fertige Bibliothek
diff --git a/20220609/polynome-20220609.xcf.gz b/20220609/polynome-20220609.xcf.gz
new file mode 100644
index 0000000000000000000000000000000000000000..49c31ba8022409dee8c0c2c8853575d39b952422
Binary files /dev/null and b/20220609/polynome-20220609.xcf.gz differ