Title: IN0042_ITSEC / Hashfunktionen

Front: Wie wird ein HMAC gebildet, wenn m die Nachricht, K der secret key und H die Hashfunktion ist?
Back: innerHash = H(K' xor ipad) | m) HMAC(K. m) = H((K' xor opad) | innerHash)
Wobei K' ein vom Secret Key abgeleiteter Schlüssel mit fester Blockgröße ist.
"|" ist hierbei die Konkatenierung von Strings.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Was ist die Idee einer kryptografischen Hashfunktion?
Back: Erstellen eines „digitalen“ Fingerabdrucks h für ein Dokument / eine Nachricht m, sodass h das Dokument m repräsentiert.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Was ist ein Message Digest?
Back: Ein Message Digest ist eine numerische Representation fester Größe einer Nachricht, die von einer kryptographischen Hashfunktion berechnet wurde.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Wie funktioniert das Merkle-Damgård Verfahren?
Back: Gegeben Kompressionsfunktion f und IV. IV ist ein Initialisierungsblock für die Verarbeitung von Block m1.
1. Zerlegen der Eingabe m in Blöcke: m = m1 | m2 | ... | mn
2. Blockweises komprimieren mit Kompressionsfunktion f
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Wie funktionert das Sponge-Prinzip?
Back: Zwei Phasen:
1. Aufsaugen
- Initialzustand init = r | c mit 0-Bits gefüllt.
1. Ausgeben
- Schrittweise Entnahme von r-Bits aus den Zwischenzuständen; die r-Bits sind Ausgabebits.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Gibt es Einschränkungen bei der Länge des Hashs bei dem Spongeprinzip?
Back: Nein. Länge der Ausgabe ist flexibel bestimmbar. Hash kann eine flexible Länge haben.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Was ist der Unterschied zwischen einer Hashfunktion und einem MAC?
Back: Jeder kann einen Hashwert berechnen, es ist kein Ursprungsnachweis!
Lösung: Einbringen eines gemeinsamen Geheimnisses, z.B. eines shared Key K_AB, in die Hash-Berechnung.
Der Authentizitätsnachweis: Kenntnis des Schlüssels K_AB nachweisen.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Beschreibe den Aufbau eines MACs
Back: - Hashfunktion mit Schlüssel: H: EK * M^* -> M^n
- Pre-shared Secret k_AB zwischen Partnern A, B
- MAC-Berechnung: mac = H(m') mit m' = k_AB | m (m ist die Nachricht)
- Empfänger prüft Authentizität und Integrität von m' mit k_AB
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Was ist ein großes Problem wenn die Hashfunktion bei MAC auf der Merkle-Damgård Konstruktion beruht?
Back: Length Extension Angriffe sind möglich.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Wie funktioniert ein Length Extension Angriff?
Back: 1. Gegeben authentisierte Nachricht: data, h=SHA-1(kmac | data)
2. Konkateniere nun fake an die ursprünglichen Daten: data' = data | fake
3. Berechnung eines validen Hashes kann aber hier ohne Besitz des Secrets erfolgen
h' = SHA-1(h | fake'), (fake ' ist eine gepaddete Version von fake)
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Warum funktionieren Length Extension Angriffe bei SHA-1?
Back: Basiert auf der Merkle-Damgård Konstruktion und gibt somit den internen Zustand als Hashwert h aus.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Welche SHA Hashfunktionen sind resilient gegen length extension Angriffe?
Back: - SHA-3
- SHA-512/256 (Von den 512-bit werden 256-bit weiter genutzt)
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Gegeben ist die folgende Berechnungsvorschrift für einen MAC(m, k_AB) = H(m|k_AB). Warum ist diese Art von Message-Authentication Code als kritisch einzustufen?
Back: Bei der Konstruktion reicht es eine Kollision für die Nachricht m zu finden, um den MAC für jeden beliebigen Schlüssel zu brechen.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Was ist die sicherer? MAC-then-Encrypt oder Encrypt-then-MAC?
Back: Encrypt-then-MAC, da wir zuerst die Integrität des Ciphertext mit dem MAC überprüfen, bevor wir andere Validierungs/Entschlüsselungsmaßnahmen starten.
Andersrum bestünde kein Integritätsschutz, da dieser schon bei der Entschlüsselung des nicht-überprüften Ciphertexts verletzt wird.
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Was ist das Vorgehen beim Erstellen einer elektronischen/digitalen Signatur?
Back: 1. Hashen einer beliebigen Nachricht mit Hashfunktion H
2. Signieren des Hashes (Message Digest) mit Signaturalgorithmus
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png

Front: Wie werden elektronische/digitale Signaturen überprüft?
Back: B erhält sig und m und kennt Hashfunktion H.
1. B besitzt den öffentlichen Schlüssel e von A (offener Austausch) Rekonstruktion eines Hashwertes und durch Signatur-Validierung: RSA_e(sig) = sig^e mod n = h'.
2. Validieren: h' = H(m)?
Title: IN0042_ITSEC::Hashfunktionen
Other fields (not shown on cards):
Logo: tum_logo.png