0 Daumen
913 Aufrufe

Aufgabe:

Gegeben sei die folgende Hashfunktion h: Z16, Z16 → Z10

definiert als h(m) = h(a|b) = „Dezimaldarstellung(a) + Quersumme(Binärdarstellung(b))“, wobei a und b beliebige Hexadezimalzahlen darstellen und das Ergebnis eine Dezimalzahl ist, und m=a|b (d.h. m ist die Konkatenation der Hexadezimalzahlen a und b).

1) Zeigen sie, dass h() nicht die Eigenschaft „Collision Resistance“ erfüllt.

2) Ist h() sicher gegen „Pre-Image“-Angriffe (Begründung angeben)?


Meine Lösung:

blob.png

zu 2) Ich hatte anfangs die Vermutung, dass es nicht sicher gegen "Pre-Image“-Angriffe ist, aber wählt man als b eine weitere Hexazahl dazu, wird die Wahrscheinlichkeit vergrößert (Leider weiß ich nicht um wie viel...). Habe mal versucht ein paar Wahrscheinlichkeiten aufzuschreiben. Also sage ich es ist sicher gegen "Pre-Image“-Angriffe.

Stimmen meine Lösungen und was wäre die Lösung für 1) und 2)?

Avatar von

1 Antwort

0 Daumen

Antwort mit KI erzeugt

Eigenschaften zeigen der Hashfunktion h: Z16, Z16 → Z10

Um deine Lösungen zu bewerten, gehen wir Schritt für Schritt durch die Problematik und Eigenschaften der gegebenen Hashfunktion \(h\).

Die Hashfunktion \(h: \mathbb{Z}_{16} \times \mathbb{Z}_{16} \rightarrow \mathbb{Z}_{10}\) ist wie folgt definiert: \( h(a|b) = \) „Dezimaldarstellung(\(a\)) + Quersumme(Binärdarstellung(\(b\)))“, wobei \(a\) und \(b\) Hexadezimalzahlen sind.

1) Collision Resistance

Eine Hashfunktion gilt als collision-resistant, wenn es praktisch unmachbar ist, zwei verschiedene Eingaben zu finden, die denselben Hashwert erzeugen. Um zu zeigen, dass \(h()\) nicht diese Eigenschaft erfüllt, muss man also ein Gegenbeispiel finden: zwei unterschiedliche Inputs, die den gleichen Hash-Wert liefern.

Nehmen wir beispielsweise \(a_1|b_1 = 1|1\) und \(a_2|b_2 = 2|0\).

- Für \(1|1\):
- Dezimaldarstellung von \(1\) ist \(1\).
- Quersumme der Binärdarstellung von \(1\) ist \(1\) (\(1\) in Binär ist \(0001\)).
- Daher ist \(h(1|1) = 1 + 1 = 2\).

- Für \(2|0\):
- Dezimaldarstellung von \(2\) ist \(2\).
- Quersumme der Binärdarstellung von \(0\) ist \(0\) (\(0\) in Binär ist \(0000\)).
- Daher ist \(h(2|0) = 2 + 0 = 2\).

Diese zwei unterschiedlichen Eingaben \(1|1\) und \(2|0\) ergeben den gleichen Hash-Wert \((2)\), was beweist, dass \(h()\) nicht collision-resistant ist.

2) Pre-Image Angriffe

Eine Hashfunktion ist sicher gegenüber Pre-Image Angriffen, wenn es für einen gegebenen Hashwert schwer ist, einen originalen Input zu finden, der zu diesem Hashwert führt. Wählen wir als Hashwert z.B. \(3\), so gibt es mehrere \(a|b\) Kombinationen, die zu diesem Hashwert führen können, da sowohl die direkte Dezimaldarstellung von \(a\) als auch die Quersumme von \(b\) in verschiedenen Konstellationen zu \(3\) führen können. Aufgrund der kleinen Output-Domain (\(\mathbb{Z}_{10}\)) und der definierten Hash-Funktionsweise könnten Angriffe theoretisch durch systematisches Ausprobieren erfolgen.

Trotzdem bedeutet die Tatsache, dass es viele mögliche \(a|b\) Kombinationen für einen bestimmten Hashwert gibt, nicht automatisch, dass die Funktion sicher gegen Pre-Image-Angriffe ist. Die Sicherheit hängt vielmehr von der Größe des Suchraums und der Berechenbarkeit ab. Aufgrund der sehr simplen und direkten Berechnungsvorschrift (Dezimaldarstellung plus Quersumme) und des kleinen Suchraums (\(\mathbb{Z}_{16} \times \mathbb{Z}_{16}\)) ist \(h()\) eher als anfällig für Pre-Image-Angriffe zu bewerten, vor allem, wenn systematische oder brute-force Methoden angewendet werden können.

Zusammenfassend:

- Deine Schlussfolgerung, dass \(h()\) nicht collision-resistant ist, ist korrekt.
- Bezüglich der Sicherheit gegenüber Pre-Image-Angriffen scheint deine Bewertung zu optimistisch. Aufgrund der einfachen Struktur von \(h()\) und dem kleinen Definitionsbereich ist die Funktion potenziell anfällig für Pre-Image-Angriffe, vor allem, wenn eine Brute-Force-Suche im kleinen Definitionsbereich praktikabel ist.
Avatar von

Ein anderes Problem?

Stell deine Frage

Willkommen bei der Stacklounge! Stell deine Frage einfach und kostenlos

x
Made by a lovely community