Zum Inhalt springen
Financial Context Wiki

Kryptografische Hashfunktionen

Ein verifizierungsorientierter Leitfaden zu kryptografischen Hashfunktionen, der Sicherheitseigenschaften, Bytecodierung, SHA-2, SHA-3, Keccak, Blockchain-Anwendungen und Implementierungsrisiken behandelt.

Aktualisiert

Nur zu Bildungszwecken; keine Anlageberatung oder Beratung zur Implementierung kryptografischer Verfahren. Ein übereinstimmender Hashwert allein beweist weder Authentizität noch Eigentum, Autorisierung, Finalität oder Datenverfügbarkeit.

Direkte Antwort

Eine kryptografische Hashfunktion bildet eine als Bytes dargestellte Nachricht deterministisch auf einen Hashwert mit festgelegter Ausgabelänge ab. Für einen Hash fester Länge mit n Bit gilt die grundlegende Beziehung:

h = H(m), where h is in {0,1}^n

Dieselben Bytes und derselbe Algorithmus erzeugen denselben Hashwert. Die Änderung eines einzigen Eingabebits sollte unvorhersehbar viele Ausgabebits verändern, doch dieser Lawineneffekt ist nicht die Sicherheitsdefinition. Die wichtigsten Sicherheitsziele sind Urbildresistenz (zu einem gegebenen Hashwert lässt sich praktisch keine Eingabe finden, die ihn erzeugt), Zweiturbildresistenz (zu einer gegebenen Eingabe lässt sich praktisch keine andere Eingabe mit demselben Hashwert finden) und Kollisionsresistenz (es lassen sich praktisch keine zwei beliebigen unterschiedlichen Eingaben mit demselben Hashwert finden).

Hashing ist keine Verschlüsselung: Es gibt weder einen Entschlüsselungsschlüssel noch die Zusicherung, dass die Eingabe wiederhergestellt werden kann. Da unendlich viele mögliche Nachrichten auf einen endlichen Ausgaberaum abgebildet werden, müssen Kollisionen existieren. Sicherheit bedeutet, dass es für den gewählten Algorithmus und die gewählte Ausgabelänge rechnerisch nicht praktikabel ist, eine nutzbare Kollision zu finden.

Ein Hashwert stellt für sich genommen auch keine Authentizität her. Das erneute Berechnen des Hashes einer Datei erkennt eine Abweichung nur dann, wenn der erwartete Hashwert und der Algorithmus über einen vertrauenswürdigen Kanal bezogen wurden. Protokolle erzielen stärkere Garantien, indem sie Hashes mit Signaturen, Nachrichtenauthentifizierungscodes, authentifizierten Datenstrukturen, Konsensregeln oder Proof of Work kombinieren.

Funktionsweise

  1. Die exakten Bytes festlegen. Textcodierung, Groß- und Kleinschreibung, Leerzeichen, Feldreihenfolge, Ganzzahldarstellung, Längenpräfixe und Serialisierung wirken sich auf m aus. Ein Protokoll muss eine kanonische Codierung festlegen und den Hash an einen Algorithmus, eine Version, ein Netzwerk und einen Zweck binden.
  2. Die vorgegebene Konstruktion ausführen. SHA-256 bereitet eine Nachricht begrenzter Länge vor, teilt sie in Blöcke und aktualisiert iterativ einen internen Zustand. SHA3-256 verwendet eine auf KECCAK basierende Sponge-Konstruktion. Beide liefern 256-Bit-Hashwerte, sind aber unterschiedliche Funktionen und erzeugen keine austauschbaren Ausgaben.
  3. Sicherheit anhand der benötigten Eigenschaft beurteilen. Bei einem idealen Hash mit n Bit erfordert eine generische Urbildsuche ungefähr 2^n Auswertungen, während eine generische Kollisionssuche aufgrund des Geburtstagsparadoxons ungefähr 2^(n/2) Auswertungen benötigt. Die Ausgabelänge allein genügt nicht, wenn der Algorithmus gebrochen, der Hashwert gekürzt oder das umgebende Protokoll fehlerhaft ist.
  4. Das Protokoll um den Hashwert herum aufbauen. Ein digitales Signaturverfahren kann den Hashwert einer Nachricht signieren; HMAC ergänzt einen geheimen Schlüssel zur Nachrichtenauthentifizierung; ein Merkle-Baum bindet viele Blätter an eine einzige Wurzel; und beim Proof of Work werden mögliche Blockheader wiederholt gehasht, bis ein Hashwert einen Zielwert erfüllt. Diese Konstruktionen bieten unterschiedliche Garantien.
  5. Die exakte Funktion der Blockchain verwenden. Bitcoin-Blockheader und Merkle-Knoten verwenden doppeltes SHA-256 in der festgelegten Bytereihenfolge. Die Ausführungsschicht von Ethereum verwendet Keccak-256 aus dem KECCAK-Entwurf vor dessen Standardisierung und nicht das standardisierte SHA3-256. Eine Bezeichnung wie „256-Bit-Hash“ reicht daher für eine Verifizierung nicht aus.
  6. Vor der Interpretation den Kontext prüfen. Zu prüfen sind die Quelle des erwarteten Hashwerts, die Algorithmuskennung, die Bytecodierung, die Domäne oder Blockchain, die Block- und Zustandsreferenz, der Bestätigungsstatus sowie mögliche Kürzungen. Eine korrekte Berechnung im falschen Kontext bleibt eine fehlgeschlagene Verifizierung.

Praxisbeispiele

  • Eine winzige Änderung der Eingabe. Der SHA-256-Hash der fünf UTF-8-Bytes für hello lautet 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Wird das erste Byte durch ein großes H ersetzt, ergibt sich 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. Aus den unterschiedlichen Hashwerten geht nicht hervor, welches Byte geändert wurde.
  • Die Sicherheitsstärke entspricht nicht in jedem Angriffsmodell der Länge des Hashwerts. Ein idealer 256-Bit-Hash bietet ungefähr 2^256 Rechenaufwand für eine Urbildsuche, aber nur 2^128 für eine Kollisionssuche. Dieser Unterschied ist wichtig, wenn ein Protokoll auf Kollisionsresistenz angewiesen ist, wie dies bei Abläufen mit digitalen Signaturen häufig der Fall ist.
  • Ein Merkle-Beweis authentifiziert die Zugehörigkeit relativ zu einer einzigen Wurzel. Der Prüfer hasht das codierte Blatt mit jedem bereitgestellten Geschwisterknoten in der festgelegten Reihenfolge, bis er die gebundene Wurzel rekonstruiert. Eine Übereinstimmung beweist weder, dass die Wurzel final ist, noch dass die Blattdaten wahr oder ausgelassene Daten verfügbar sind.
  • Proof of Work ergänzt eine Zielwertregel. Bitcoin akzeptiert einen möglichen Header nur dann, wenn dessen doppelter SHA-256-Wert, gemäß den Konsensregeln interpretiert, kleiner oder gleich dem codierten Zielwert ist. Der Hashwert wird nicht kollisionsresistenter, nur weil Miner mehr Arbeit aufgewendet haben.

Risiken

  • Einen veralteten oder ungeeigneten Algorithmus verwenden, insbesondere SHA-1 einsetzen, wenn Kollisionsresistenz erforderlich ist.
  • SHA3-256, Keccak-256, SHA-256, doppeltes SHA-256 und unterschiedlich gekürzte Varianten als austauschbar behandeln.
  • Den angezeigten Text statt der kanonischen Bytes hashen oder Unicode-Normalisierung, Leerzeichen, Byte- und Feldreihenfolge sowie Längencodierung übersehen.
  • Eine Datei und ihren erwarteten Hashwert vom selben kompromittierten Ort herunterladen, sodass keine unabhängige Integritätsprüfung möglich ist.
  • Einen schnellen Allzweck-Hash direkt zur Passwortspeicherung einsetzen statt eines gesalzenen, eigens dafür entwickelten Passwort-Hashing-Verfahrens mit angemessenem Arbeitsfaktor.
  • H(secret || message) als selbst gebauten Authentifizierungscode verwenden; einige iterative Hashkonstruktionen erlauben Length-Extension-Angriffe, während HMAC für die schlüsselbasierte Authentifizierung entwickelt wurde.
  • Hashwerte kürzen, ohne die daraus entstehende Kollisions- und Urbildsicherheit für die Größenordnung und das Bedrohungsmodell des Protokolls zu berechnen.
  • Eine Codierung protokollübergreifend ohne Domänentrennung wiederverwenden, sodass ein in einem Kontext gültiger Hashwert in einem anderen interpretiert werden kann.
  • Annehmen, dass ein Transaktionshash Bestätigung, Finalität, erfolgreiche Ausführung, Eigentum oder den Ausschluss einer Blockchain-Reorganisation beweist.
  • Annehmen, dass ein Inhalts-Hash die referenzierten Daten abrufbar macht; eine Bindung kann gültig bleiben, obwohl jede verfügbare Kopie verschwunden ist.
  • Zeichenfolgen aus Blockexplorern vergleichen, ohne Bytereihenfolge, Präfixregeln, Serialisierung oder eine möglicherweise abweichende Darstellung interner Kennungen durch die Oberfläche zu prüfen.
  • Kryptografische Primitive ohne standardisierte Testvektoren, gepflegte Bibliotheken, unabhängige Überprüfung und Aktualisierungsverfahren implementieren.

Häufige Missverständnisse

  • Ein Hash besteht aus verschlüsselten Daten. Verschlüsselung ist mit dem richtigen Schlüssel umkehrbar; ein kryptografischer Hash ist ein nicht umkehrbarer Hashwert ohne Entschlüsselungsvorgang.
  • Unterschiedliche Eingaben können niemals denselben Hashwert haben. Bei einer Ausgabe fester Länge müssen Kollisionen existieren. Ein sicheres Verfahren macht es praktisch unmöglich, sie zu finden und auszunutzen.
  • Ein 256-Bit-Hashwert bietet immer 256 Bit Sicherheit. Bei einem idealen 256-Bit-Hash beträgt die generische Kollisionsresistenz ungefähr 128 Bit, und Protokollentscheidungen können sie weiter verringern.
  • Übereinstimmende Hashes beweisen, wer die Nachricht erstellt hat. Ein bloßer Hash enthält kein Geheimnis und authentifiziert keinen Absender; wenn die Herkunft wichtig ist, muss eine Signatur oder ein geeigneter MAC verwendet werden.
  • Keccak-256 und SHA3-256 sind zwei Namen für dieselbe Funktion. Sie beruhen auf eng verwandten Entwürfen, verwenden aber unterschiedliche Standardisierungsparameter und erzeugen verschiedene Hashwerte.
  • Ein On-Chain-Transaktionshash beweist die Abwicklung. Er identifiziert die codierten Transaktionsdaten; Aufnahme in die Blockchain, Ausführungsstatus, Bestätigungen und Finalität sind getrennte Sachverhalte.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...