SHA-3 Hash

Herkunft / Verwendung: SHA-3 ist eine Hashfunktion, und ging aus dem Gewinner-Algorithmus Keccak des NIST Ausschreibungswettbewerbs hervor. Nach einigen kleinen Anpassungen ist dies nun der neue Standard. Die Hashlänge ist variabel und beträgt 224, 256, 384, oder 512 bit (entsprechend 28, 32, 48 oder 64 Bytes).

Nachdem es in der Vergangenheit mehrere Durchbrüche von Angriffen auf verbreitete Hash-Funktionen wie MD5 und SHA-1 gelangen und grundlegende Schwächen des Merkle-Damgard-Konstrukts publik wurde, entschied sich das NIST zu einer Ausschreibung ähnlich wie bei AES, die dort schon erfolgreich war, um einen Nachfolger zu SHA-2 zu finden.

Von 64 eingereichten Hash-Verfahren wurde 14 für die 2. Runde ausgewählt: Daraus gingen die Finalisten Keccak, BLAKE, Grøstl, JH und Skein und schließlich der Sieger Keccak hervor.

Spezifikation des Algorithmus

Für die Grundlagen des Hash-Algorithmus siehe den ursprünglichen Bewerber-Algorithmus Keccak. Der als NIST-Standard veröffentliche SHA-3 Algorithmus unterscheidet sich allerdings etwas vom Keccak-Algorithmus, insbesondere im Padding, und liefert deshalb für gleiche Daten und gleiche Schlüssel unterschiedliche Hashes.

Die grundlegende Konstruktion – die Schwammfunktion (Sponge Construction) mit der Permutation Keccak-f[1600] – ist bei beiden Algorithmen identisch geblieben. Der eigentliche Unterschied liegt fast ausschließlich beim Padding, hat aber wichtige praktische Konsequenzen: Diese Suffixe verändern die Bitsequenz vor dem Durchlauf durch die Schwamm-Funktion. Dadurch liefern Original-Keccak und SHA3 unterschiedliche Hashwerte für dieselbe Eingabe, obwohl intern dieselbe Permutation und dieselben Parameter (Rate/Capacity) verwendet werden. Das ist in der Praxis relevant: Ethereum zum Beispiel nutzt für seine keccak256-Funktion (z. B. bei Adressberechnung) noch das originale Keccak-Padding, nicht das NIST-SHA3-Padding – weil der Ethereum-Standard vor der finalen NIST-Verabschiedung eingefroren wurde. Keccak-256 und SHA3-256 sind also nicht austauschbar, der unterschiedliche Name drückt diesen Umstand auch aus.

Das NIST führte den Suffix übrigens ein, damit sich verschiedene aus derselben Permutation abgeleitete Funktionsfamilien (SHA3-Hashes, SHAKE-XOFs, später auch cSHAKE, KMAC, TupleHash etc.) nicht gegenseitig kollidieren lassen, wenn dieselbe Eingabe an unterschiedliche Funktionen mit denselben Parametern gegeben wird. Ohne diese Trennung könnte man z. B. theoretisch einen SHAKE-Output so konstruieren, dass er zufällig mit einem SHA3-Hash übereinstimmt.

Beispiel

Klartext:Beispielklartext
SHA-3 224 Hash:9F010B62 EB48A0EE 8F09E922 0058D7A3 12C339FB 4F2B2202 9D156556
SHA-3 256 Hash:9B20100F 57FDFD3A 350BC0E3 C7DE3509 9F19D6E9 64B4AD8F 7C0F8E8F 1239673E
SHA-3 384 Hash:A8C02BA3 A18B3DB7 F87D5A9A 8A348021 B3066795 04E8DDA4 50289B8F B36C4618 BA98E466 06E7BFF2 78431342 E3D98E5C
SHA-3 512 Hash:19D66734 57966229 78DC1D65 CA79428D 8EBD893E 9F086D1F F94A86AE A658D6DF 88438D67 70E437ED 7BBC60A9 7182FD89 D3C43729 9660136C D7167A11 F66E1D

Code / Chiffre online dekodieren / entschlüsseln bzw. kodieren / verschlüsseln (Decoder / Encoder / Solver-Tool)



Quellen, Literaturverweise und weiterführende Links