imported>SchlurcherBot: Bot: http → https

2025-12-01T03:49:35Z

Bot: http → https

Neue Seite

{{Infobox Kryptologische Hashfunktion
|name = SHA-3 (Keccak)
|entwickler = Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche
|datum = Januar 2011 (3. Version)
|abgeleitet = RadioGatún (Vorgänger)
|zertifizierung = [[NIST]] SHA-3 Standard
|hashlänge = je nach Version 224, 256, 384, 512 oder frei wählbar
|struktur = Sponge-Konstruktion
|runden = SHA-3: 24 Keccak: 12 bis 24 (abh. von Größe des Zustandsdatenblocks)
|kryptoanalyse = ''second preimage attack'' von Daniel J. Bernstein auf 6 von 24 Runden von SHA3-512 mit 2506 Funktionsaufrufen und Platzkomplexität 2176 oder auf 8 Runden mit 2511,5 Aufrufen und 2508 Platz
}}

'''SHA-3''' ist eine [[kryptographische Hashfunktion]], die von Guido Bertoni, [[Joan Daemen]], Michaël Peeters und Gilles Van Assche unter dem Namen '''Keccak''' [{{IPA|kɛtʃak}}] entwickelt wurde. Keccak gewann 2012 den vom US-amerikanischen [[National Institute of Standards and Technology|NIST]] organisierten SHA-3-Wettbewerb ({{EnS|''NIST hash function competition''}}) und wurde am 5. August 2015 als SHA-3 standardisiert.

Kryptographische Hashfunktionen werden zum Beispiel für das [[Digitale Signatur|digitale Signieren]] eingesetzt. SHA-3 ist die neueste, effizienteste und sicherste Hashfunktion der [[Secure Hash Algorithm|SHA-Reihe]].

== Geschichte ==
Im Jahr 2004 gab es mehrere Durchbrüche bei Angriffen gegen damals weit verbreitete Hash-Funktionen wie [[Message-Digest Algorithm 5|MD5]] (praktische Kollisionen) und [[Secure Hash Algorithm|SHA-1]] (theoretische Kollision mit großem Aufwand).<ref name="NISTpolicy" /> Unter anderem wurden grundlegende Schwächen der [[Merkle-Damgård-Konstruktion]] gefunden, durch die der Rechenaufwand für bestimmte Angriffsszenarien vermindert wird (wenn auch nicht unbedingt in einem Maß, dass der Angriff praktisch durchführbar wäre). Zwar existiert die [[SHA-2]]-Familie, gegen die es bislang keine praxisrelevanten Angriffe gibt, aber diese Funktionen sind – ebenso wie ihre Vorläufer [[Message-Digest Algorithm 4|MD4]], MD5 und SHA-1 – Merkle-Damgård-Konstruktionen mit Davies-Meyer-Kompressionsfunktion. Man befürchtete, dass Angriffe auf diese Vorläufer zu Angriffen gegen SHA-2 modifiziert werden könnten. Wenn sich auch SHA-2 als gefährdet bzw. unsicher erweisen sollte, hätte man keine standardisierte und als sicher anerkannte kryptologische Hashfunktion zur Verfügung. Deshalb beschloss man, einen neuen Standard zu schaffen, der die aktuelle Forschung berücksichtigt und zukunftssicherer als SHA-2 ist.

Ähnlich wie für die Auswahl der [[Blockverschlüsselung]] AES ([[Advanced Encryption Standard]]) veranstaltete das NIST von November 2007 bis Oktober 2012 einen Wettbewerb.<ref name="contest" /> Von den eingereichten Hashfunktionen wurde gefordert, dass sie Nachrichten bis zu einer Obergrenze von mindestens <math>2^{64}-1</math> [[Bit]] hashen und mindestens die vier Hash-Längen 224, 256, 384 und 512 Bit unterstützen. Die teilnehmenden Teams von Kryptografen reichten 64 Hashfunktionen ein, wovon 51 die Teilnahmebedingungen erfüllten und für Runde 1 akzeptiert wurden. Nach Analyse der Sicherheit und Performanz in einem offenen Bewertungsprozess, an dem Kryptologen aus aller Welt teilnahmen, wurden 14 Kandidaten für Runde zwei ausgewählt.

Die Teilnehmer durften in jeder Runde des Wettbewerbs Veränderungen an ihren [[Algorithmus|Algorithmen]] vornehmen, um auf die Ergebnisse der Analysen zu reagieren. Im Fall von Keccak hat man die Zahl der Runden der Permutationsfunktion für eine größere Sicherheitsreserve von 18 auf 24 erhöht und die Länge der Nachrichtenblöcke für einige der Varianten vergrößert und dadurch die Effizienz verbessert.

Im Dezember 2010 wurden die fünf Finalisten bekanntgegeben:
* [[BLAKE (Hashfunktion)|BLAKE]] ([[HAIFA (kryptologisches Verfahren)|HAIFA-Konstruktion]])
* [[Grøstl]] (wide-pipe [[Merkle-Damgård-Konstruktion|Merkle-Damgård]])
* [[JH (Hashfunktion)|JH]] (ähnlich einer Sponge-Konstruktion)
* Keccak (Sponge-Konstruktion)
* [[Skein]] (ähnlich HAIFA)

Am 2. Oktober 2012 wurde Keccak zum Gewinner erklärt und wird seitdem als SHA-3 bezeichnet.<ref name="ergebnis" /> SHA-3 weist eine hohe kryptografische Sicherheitsreserve auf und ist in [[Hardware]] auch effizient implementierbar. Vorteilhaft ist auch der einfache und elegante Aufbau, der die [[Kryptoanalyse]] erleichtert. Ein Kritikpunkt ist jedoch, dass die Performanz bei Software-Implementierung im Vergleich zu den anderen Finalisten eher gering ist.<ref>{{Internetquelle|autor=Mourad Gouicem|titel=Comparison of seven SHA-3 candidates software implementations on smart cards|url=https://eprint.iacr.org/2010/531.pdf|format=PDF|datum=2010-10|zugriff=2014-02-14}}</ref> Es wurde der Vorwurf erhoben, das NIST würde sein Augenmerk zu sehr auf Implementierungen in Hardware legen.

== Funktionsweise ==
[[Datei:SpongeConstruction.svg|mini|300px|Darstellung der Sponge-Konstruktion]]

Keccak ist eine sogenannte Sponge-Konstruktion. Ein Zustandsvektor von <math>b</math> [[Bit]] „absorbiert“ die Nachricht blockweise, die dazu in Blöcke von <math>r < b</math> Bit geteilt wird. Mit jedem Block werden <math>r</math> Bit des Zustandsvektors verändert, wonach die Daten im Zustandsvektor durch eine Permutationsfunktion durchmischt werden. Diese ist eine [[Bijektive Funktion|bijektive]] Abbildung <math>f: \{0,1\}^b \rightarrow \{0,1\}^b</math>, sie permutiert also die <math>2^b</math> möglichen Zustände des Vektors auf [[Pseudozufall|pseudozufällige]] Weise.<ref name="spec" /><ref name="reference" />

Der Zustandsvektor besteht aus 25 Wörtern mit je <math>2^l</math> [[Bit]] und wird mit 0 initialisiert. Der Wert <math>l \in \{0,1, \ldots , 6\}</math> ist ein Parameter des Verfahrens. Der Zustandsvektor ist somit <math>b = 25 \cdot 2^l</math> Bit lang. Der zweite Parameter ist die Bitlänge <math>n</math> des gewünschten Hash-Wertes. In den zum SHA-3-Wettbewerb eingereichten Varianten ist <math>l=6</math> und damit <math>b=1600</math>, und die Länge des Hash-Wertes beträgt <math>n = 224, 256, 384</math> oder <math>512</math>.

Die Nachricht wird durch [[Padding (Informatik)|Anfügen]] eines Endstückes auf ein Vielfaches von <math>r</math> Bit verlängert und dann in Blöcke der Länge <math>r</math> Bit geteilt, mit <math>r</math> als drittem Parameter des Verfahrens. Bei den Wettbewerbsvarianten ist jeweils <math>r=b-2n</math>. Das angefügte Endstück besteht aus <math>0</math> bis <math>r-1</math> Bits mit dem Wert 0, die von 1-Bits eingerahmt werden: <math>100\ldots 01</math>. Das erste 1-Bit macht das Nachrichtenende kenntlich, damit Nachrichten, die sich nur durch unterschiedlich viele 0-Bits am Ende unterscheiden, nach der Erweiterung noch verschieden sind. Das 1-Bit am Ende sorgt dafür, dass sich die Varianten mit verschiedener Hash-Länge wie völlig unterschiedliche Hashfunktionen verhalten. Es markiert das Ende des letzten Blocks und ist jeweils an einer anderen Position, da die Nachrichtenblocklänge <math>r</math> von der Hash-Länge <math>n</math> abhängt. Es wirkt sich somit unterschiedlich auf den Hashprozess aus. Ansonsten könnten zwei (gleiche oder verschiedene) Nachrichten Hash-Werte ergeben, von denen einer ein Anfangsstück des anderen ist.

Die Nachrichtenblöcke werden nun nacheinander in den Zustandsvektor eingearbeitet. <math>r</math> Bit des Zustandsvektors werden mit dem Nachrichtenblock bitweise [[Bitweiser Operator#XOR|XOR]]-verknüpft, und dann werden die <math>2^b</math> möglichen Zustände des Zustandsvektors [[Permutation|permutiert]], was ähnlich wie in einer Blockverschlüsselung (mit konstantem Schlüssel) geschieht. Dazu wird <math>12 + 2 l</math> mal (bei SHA-3 also <math>24</math> mal) eine Rundenfunktion auf den Zustandsvektor angewandt. Diese ist nach den kryptologischen Prinzipien der [[Konfusion (Kryptologie)|Konfusion]] und der [[Diffusion (Kryptologie)|Diffusion]] entworfen und sorgt dafür, dass die Permutationsfunktion den Zustandsvektor mehrmals vollständig durchmischt und dabei chaotisch verändert.

Nachdem der letzte Block eingearbeitet ist, werden <math>n</math> Bit des Zustandsvektors als Hash-Wert ausgelesen, falls <math>n \leq r</math> ist. Anderenfalls werden die Bits des Hash-Wertes in mehreren Schritten entnommen, maximal <math>r</math> Bit in jedem Schritt, und dazwischen werden die Werte des Zustandsvektors wie oben permutiert. Der Gesamtvorgang im Überblick mit <math>m</math> als Ursprungsnachricht:
:<math>m \,\|\, 10^j1 = m_1 \,\|\, m_2 \,\|\, \cdots \,\|\, m_k; \quad |m_i| = r, \, j < r</math>
:<math>s_0 = 0^b</math>
:<math>\begin{array}{l} s_i = f(s_{i-1} \oplus (m_i \,\|\, 0^{b-r})); & i = 1,2,\cdots,k \\ s_i = f(s_{i-1}); & i = k+1,k+2,\cdots \end{array}</math>
:<math>h = \operatorname{trunc}(s_k, r) \,\|\, \operatorname{trunc}(s_{k+1}, r) \,\|\, \operatorname{trunc}(s_{k+2}, r) \,\|\, \cdots</math>
:<math>hash = \operatorname{trunc}(h, n)</math>
Dabei steht <math>\|</math> für die [[Wort (theoretische Informatik)#Konkatenation|Konkatenation]] (das Aneinanderfügen) von Bitketten, <math>0^b</math> ist eine Bittkette aus b Bits mit dem Wert 0, und <math>\operatorname{trunc}(x,n)</math> bezeichnet die ersten <math>n</math> Bit von <math>x</math>.

Der Wert <math>c=b-r</math> ist die sogenannte Kapazität, d. h. die Größe des Teils des Zustandsvektors, der beim XOR-Verknüpfen mit den Nachrichtenblöcken und bei der Entnahme des Hash-Wertes unberührt bleibt. Bei Sponge-Konstruktionen mit Hash-Länge <math>n</math> Bit beträgt die Sicherheit gegen [[Kollisionsangriff]]e <math>\min(n/2, c/2)</math> Bit und gegen [[Preimage-Angriff|Urbild-Angriffe]] <math>\min(n, c/2)</math> Bit, vorausgesetzt, die Permutation der Zustandswerte ist nicht von einer [[Zufällige Permutation|Zufallspermutation]] unterscheidbar.<ref name="sponge" /> Um hinsichtlich der Sicherheit konservativ zu sein, haben die Entwickler die Kapazität auf die doppelte Länge des Hash-Wertes festgelegt(<math>c=2n</math>), wodurch die für ein gegebenes <math>n</math> höchstmögliche Sicherheit gegen jeden Angriff erreicht wird (wegen des [[Geburtstagsparadoxon]]s kann die Sicherheit gegen Kollisionsangriffe nicht höher als <math>n/2</math> Bit sein).

'''Permutationsfunktion'''

Der Datenblock wird permutiert, indem <math>12+2l</math> mal (abhängig vom Wortgrößenparameter <math>l</math>) eine Rundenfunktion darauf angewandt wird. Die Rundenfunktion besteht aus fünf aufeinanderfolgenden Operationen, die von den Erfindern mit [[griechisches Alphabet|griechischen Buchstaben]] bezeichnet wurden. Die Runden unterscheiden sich nur in der Konstante, die in der Iota-Operation mit einem Datenwort verknüpft wird.

Die Wörter des Zustandsvektors werden mit <math>a_{i,j}</math> bezeichnet, mit <math>i,j \in \{0,1,2,3,4\}</math>, und <math>\overline a_{i,j}</math> ist jeweils der neue Zustandsvektor nach jeder Operation. Alle Indizes werden [[Division mit Rest#Modulo|modulo]] 5 genommen (<math>a_{2,-1}</math> ist <math>a_{2,4}</math>). <math>\oplus</math> bedeutet das bitweise XOR, <math>\neg</math> die bitweise [[Bitweiser Operator#NICHT|Negation]], <math>\&</math> die bitweise [[Bitweiser Operator#UND|UND-Verknüpfung]] und a <math>\lll w</math> die [[Bitweiser Operator#Zyklische Verschiebung|Bitrotation]] von <math>a</math> um <math>w</math> Bitpositionen zum höherwertigen Ende hin.

:<math>\theta</math> (Theta): lineare Mischoperation: [[Paritätsbit]]s jeder 5-Wort-Spalte mit den Wörtern der benachbarten Spalten XOR-verknüpfen
::<math>p_j \, \leftarrow \, a_{0,j} \oplus a_{1,j} \oplus a_{2,j} \oplus a_{3,j} \oplus a_{4,j}</math>
::<math>\overline a_{i,j} \, \leftarrow \, a_{i,j} \oplus p_{j-1} \oplus (p_{j+1} \lll 1)</math>

:<math>\rho</math> (Rho): Wörter des Zustandsvektors rotieren
::<math>\overline a_{i,j} \, \leftarrow \, a_{i,j} \lll (w_{i,j} \, \bmod \, 2^l); \; w_{0,0} = 0; \; w_{i,j} = \frac{(t+1)(t+2)}{2}; \; t \in \{0,\dots,23\};</math>
::die Indizes <math>i,j</math> ergeben sich aus der [[Matrix (Mathematik)|Matrizengleichung]] <math>\binom{i}{j}=\begin{pmatrix} 3 & 2 \\ 1 & 0 \end{pmatrix}^t \cdot \binom{0}{1}</math>

:<math>\pi</math> (Pi): Wörter des Zustandsvektors permutieren
::<math>\overline a_{3i+2j,i} \, \leftarrow \, a_{i,j}</math>

:<math>\chi</math> (Chi): nichtlineare Operation
::<math>\overline a_{i,j} \, \leftarrow \, a_{i,j} \oplus (\neg a_{i,j+1} \; \& \; a_{i,j+2})</math>

:<math>\iota</math> (Iota): XOR-Verknüpfen des Worts <math>a_{0,0}</math> mit einer rundenabhängigen Konstanten
::<math>\overline a_{0,0} \, \leftarrow \, a_{0,0} \oplus C_r; \; r = 0,1,\dots , 11+2l</math>
::Das Bit an Position <math>2^m-1</math> (mit <math>0 \le m < 7</math>) in <math>C_r</math> wird durch Bit <math>7r+m</math> eines [[Linear rückgekoppeltes Schieberegister|LFSR]] mit dem erzeugenden Polynom <math>x^8+x^6+x^5+x^4+1</math> gegeben. Die übrigen Bits in den <math>C_r</math> sind 0.

Die Permutationsfunktion als [[C (Programmiersprache)|C]]-Code:
<syntaxhighlight lang="c">
void keccak_p(uint64_t *a, int rounds = 24) {
//a_{i,j} entspricht a[5*i+j]
uint64_t v[5];
uint64_t lfsr = 1;
for (int r=0 ; r<rounds ; ++r) {
// Theta:
for (int j=0 ; j<5 ; ++j) {
v[j] = 0;
for (int i=0 ; i<5 ; ++i) v[j] ^= a[5*i+j];
}
for (int j=0 ; j<5 ; ++j) {
uint64_t h = v[(j+1) % 5];
h = v[(j+4) % 5] ^ (h << 1 | h >> 63);
for (int i=0 ; i<5 ; ++i) a[5*i+j] ^= h;
}
// Rho und Pi:
int i = 0, j = 1;
v[0] = a[1];
for (int t=1 ; t<25 ; ++t) {
int x = i;
i = (3*i + 2*j) % 5;
j = x;
x = 5*i + j;
uint64_t h = v[0];
v[0] = a[x];
int w = t*(t+1)/2 % 64;
a[x] = h << w | h >> (64-w);
}
// Chi:
for (int i=0 ; i<25 ; i += 5) {
for (int j=0 ; j<5 ; ++j)
v[j] = a[i+j];
for (int j=0 ; j<5 ; ++j)
a[i+j] ^= ~v[(j+1) % 5] & v[(j+2) % 5];
}
// Iota:
for (int w=0 ; w < 64 ; w = 2*w+1) {
a[0] ^= (lfsr & 1) << w;
lfsr <<= 1;
if (lfsr & 0x100) lfsr ^= 0x171;
}
}
}
</syntaxhighlight>

Beim Übernehmen eines Nachrichtenblocks werden die ersten 64 Bit aufsteigend mit <math>a_{0,0}</math> XOR-verknüpft, das erste Bit also mit dem niederwertigsten in <math>a_{0,0}</math>. Danach werden ebenso die folgenden Nachrichtenbits in <math>a_{0,1}, a_{0,2}, \cdots , a_{1,0}, \cdots</math> übernommen. Der Hashwert wird am Ende ebenfalls <math>a_{0,0}, a_{0,1}, \cdots</math> entnommen.

== Standardisierung ==
Der NIST-Mitarbeiter John Kelsey schlug im August 2013 auf dem „Workshop on Cryptographic Hardware and Embedded Systems 2013“ (CHES 2013) vor, nur die zwei Sicherheitsstufen 128 Bit und 256 Bit zu standardisieren.<ref name="kelsey2013" /><ref name="RSA2013" /> Die Kapazität ''c'' sollte für die kleineren Varianten SHA3-224 und SHA3-256 auf 256 Bit und für die beiden größeren auf 512 Bit vermindert werden. Das verbessert die Ausführungsgeschwindigkeit, weil die Nachrichtenblocklänge ''r'' entsprechend größer und die Zahl der zu verarbeitenden Nachrichtenblöcke kleiner wird. Ein Urbild-Angriff wäre damit immer noch mindestens genauso schwierig wie ein Kollisionsangriff, auf welchen die Änderung keine Auswirkung hätte.

Einige Forscher kritisierten diese Verminderung der Sicherheit und bemängelten das Verfahren, den Gewinner des Wettbewerbs nachträglich zu ändern, so dass es sich dabei nicht mehr um den ausführlich untersuchten, ursprünglichen Algorithmus handeln würde.<ref>{{Internetquelle|autor=Fabian Scherschel|titel=Kryptographie: NIST will angeblich Sicherheit von SHA-3 schmälern|url=https://www.heise.de/newsticker/meldung/Kryptographie-NIST-will-angeblich-Sicherheit-von-SHA-3-schmaelern-1969456.html |werk=heise online|datum=2013-09-30|zugriff=2013-09-30}}</ref> Die Autoren von Keccak verteidigten andererseits die vorgeschlagenen Änderungen.<ref name="defense" />

Als Reaktion auf die Kritik entschied sich NIST bei den vier Varianten SHA3-224 bis SHA3-512 gegen die Reduzierung der Kapazität.<ref name="kelseymail" /><ref name="fips202draft" /> Diese ist letztlich auch unnötig, da auch die Varianten SHAKE128 und SHAKE256 mit 256 bzw. 512 Bit Kapazität standardisiert wurden. Bis auf die vom Nutzer frei wählbare Hash-Länge entsprechen sie den vorgeschlagenen kapazitätsreduzierten Versionen und bieten somit die gleiche Effizienz.

'''Standard'''

Im August 2015 standardisierte das NIST folgende Versionen von SHA3<ref>https://www.nist.gov/itl/csd/201508_sha3.cfm</ref><ref name="standard" /> (alle Angaben in Bit):

{| class="wikitable"
|- style="text-align:center"
! Name !! Hash-Länge n !! Nachrichten- blocklänge r !! Kapazität c=1600-r !! Sicherheit (Kollision) !! Sicherheit (Urbild) !! Padding-Schema
|- style="text-align:center"
| SHA3-224 || 224 || 1152 || 448 || 112 || 224 || rowspan="4"| 0110*1
|- style="text-align:center"
| SHA3-256 || 256 || 1088 || 512 || 128 || 256
|- style="text-align:center"
| SHA3-384 || 384 || 832 || 768 || 192 || 384
|- style="text-align:center"
| SHA3-512 || 512 || 576 || 1024 || 256 || 512
|- style="text-align:center"
| SHAKE128 || variabel || 1344 || 256 || min(n/2, 128) || min(n, 128) || rowspan="2"| 111110*1
|- style="text-align:center"
| SHAKE256 || variabel || 1088 || 512 || min(n/2, 256) || min(n, 256)
|}

Die Varianten SHAKE128 und SHAKE256 sind sogenannte ''extendable output functions'' (XOFs; Funktionen mit erweiterbarer Ausgabe). Die Länge des Hashwertes ist nicht von vornherein festgelegt, sondern es können nach dem Einarbeiten der Nachricht in den Datenblock beliebig viele Hash-Daten entnommen werden. Nach immer 1344 bzw. 1088 entnommenen Bits wird der Datenblock erneut permutiert, wie oben beschrieben. Diese Varianten arbeiten als [[Kryptographisch sicherer Zufallszahlengenerator|kryptographisch sichere Pseudozufallszahlengeneratoren]], mit der gehashten Nachricht als Saat.

Damit die SHA-3 und die SHAKE-Varianten unterschiedlich hashen, hat man das Schema, mit dem die Nachrichten erweitert werden, geändert. Bei SHA3 wird die Bitfolge 011 angehängt und bei SHAKE hingegen 11111, bevor mit 0-Bits aufgefüllt und am Ende noch ein 1-Bit angefügt wird. Dadurch erreicht man eine Domänentrennung: Nach der Erweiterung kann man der Nachricht ansehen, auf welche der beiden Weisen sie erweitert wurde. Zwei Nachrichten, die auf verschiedene Weise erweitert werden, unterscheiden sich danach also in jedem Fall. Bei der Wahl dieser Padding-Methoden hat man auch an eine spätere Standardisierung von weiteren Hashverfahren auf Keccak-Basis gedacht (z. B. [[Hash-Baum|Baum-Hashverfahren]]).

Auf die Effizienz hat diese Padding-Änderung keine Auswirkung, wenn die Nachricht aus ganzen Bytes besteht, was in der Praxis fast immer der Fall ist. Auch die Nachrichtenblocklänge ''r'' ist ein Vielfaches von acht, und somit auch die Zahl der im letzten Block freien Bits. Entweder muss für die Paddingbits ohnehin ein weiterer Nachrichtenblock angefügt werden, oder im letzten Block ist mindestens ein Byte frei, das die Paddingbits vollständig aufnehmen kann. Im Vergleich zum originalen Keccak-Padding erhöht sich die Zahl der Nachrichtenblöcke also in keinem Fall.

Das geänderte Padding gegenüber dem originalen Keccak-Algorithmus bedeutet auch, dass Keccak und SHA-3 verschiedene Hashfunktionen sind, und diese Bezeichnungen sollten nicht synonym verwendet werden.

Im Dezember 2016 gab das NIST ein Dokument heraus, in dem weitere von SHA-3 abgeleitete Hashverfahren beschrieben werden.<ref name="SP800-185" /> Diese gibt es jeweils in zwei Varianten, mit 256 Bit und 512 Bit Kapazität:

* cSHAKE: ermöglicht explizite Domänentrennung durch einen zusätzlich eingegebenen String
* KMAC: Variante für [[HMAC|Keyed-Hash Message Authentication]]
* KMACXOF: XOF-Version von KMAC mit beliebig erweiterbarer Hash-Ausgabe (entsprechend SHAKE)
* TupleHash und TupleHashXOF: hashen Tupel mit beliebig vielen Strings, wobei verschiedene Tupel unterschiedlich gehasht werden, z. B. auch ("ab", "c") und ("a", "bc") und ("a", "bc", "")
* ParallelHash und ParallelHashXOF: sind dafür ausgelegt, die parallele Rechenfähigkeit moderner CPUs besser zu unterstützen

== Weitere Varianten ==
Die Entwickler von Keccak haben außerdem zwei Baum-Hashverfahren namens ''KangarooTwelve'' und ''MarsupilamiFourteen'' vorgestellt, die mit einer auf 12 bzw. 14 Runden reduzierten Permutationsfunktion arbeiten, gegenüber 24 Runden bei den übrigen Varianten.<ref name="kangaroo12" /> Damit nutzen sie die große Sicherheitsreserve von Keccak aus, um die Effizienz zu verbessern.

== Sicherheit ==
SHA-3 besitzt eine sehr hohe Sicherheitsreserve: Die beste bekannte Kryptoanalyse kann eine auf 8 (von 24) Runden reduzierte Version von SHA3-512 brechen und benötigt dafür den praktisch nicht bereitstellbaren Aufwand von <math>2^{511,5}</math> Funktionsaufrufen und einem Speicherplatz von <math>2^{508}</math>. Damit ist sie nur um den Faktor 1,4 effizienter als ein [[Brute-Force-Methode#Kryptologie|Brute-Force-Angriff]].<ref name="analyse" />

Es ist möglich, die Zustandspermutation mit der vollen Zahl von 24 Runden von einer Zufallspermutation zu unterscheiden, was aber etwa <math>2^{1575}</math> Funktionsaufrufe erfordert.<ref name="submission" /> Ein Angriff auf SHA-3 selbst ergibt sich daraus nicht.

Weil von den 1600 Zustandsbits immer nur ein Teil (um die Kapazität vermindert) ausgegeben wird, ist SHA-3 immun gegen einen Erweiterungsangriff, bei dem man den Hashwert <math>h(N \, \| \, x)</math> einer mit <math>x</math> erweiterten unbekannten Nachricht <math>N</math> unter Kenntnis von deren Hashwert <math>h(N)</math> bestimmt.

== Weblinks ==
* [https://keccak.team/index.html Website von Keccak]
* [https://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo.html The SHA-3 Zoo]
* [https://csrc.nist.gov/projects/hash-functions/sha-3-project SHA-3 at NIST]
* [https://keccak.team/specifications.html Spezifikationen auf der Keccak-Website]
* [https://infsec.de/sha3-256-in-excel/ SHA-3 Demonstrator] in Excel (ohne Makros) von [[Tim Wambach]]

== Einzelnachweise ==
<references responsive>
<ref name="analyse">{{Internetquelle
| autor=Daniel J. Bernstein
| url=https://ehash.iaik.tugraz.at/uploads/6/65/NIST-mailing-list_Bernstein-Daemen.txt
| sprache=en
| titel=Second preimages for 6 (7? (8??)) rounds of Keccak?
| datum=2010
| abruf=2020-07-15
| werk=NIST mailing list
}}
</ref>
<ref name="spec">{{Internetquelle
| autor=Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche
| url=http://keccak.noekeon.org/specs_summary.html
| sprache=en
| titel=The Keccak sponge function family
| datum=2011-01-27
| zugriff=2012-10-03
}}
</ref>
<ref name="reference">{{Internetquelle
| titel=The Keccak reference
| url=https://keccak.team/files/Keccak-reference-3.0.pdf
| autor=Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche
| sprache=en
| datum=2011-01-14
| abruf=2020-08-02
}}
</ref>
<ref name="contest">{{Internetquelle
| hrsg=[[National Institute of Standards and Technology|NIST]]
| url=https://csrc.nist.gov/projects/hash-functions/sha-3-project
| sprache=en
| titel=SHA-3 Project
| abruf=2020-08-10
}}
</ref>
<ref name="ergebnis">{{Internetquelle
| hrsg=[[National Institute of Standards and Technology|NIST]]
| url=https://www.nist.gov/itl/csd/sha-100212.cfm
| sprache=en
| titel=NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition
| datum=2012-10-02
| zugriff=2012-10-03
}}
</ref>
<ref name="NISTpolicy">
{{Internetquelle
| hrsg=[[National Institute of Standards and Technology|NIST]]
| url=http://csrc.nist.gov/groups/ST/hash/policy.html
| sprache=en
| titel=NIST's Policy on Hash Functions
| datum=2012-09-28
| zugriff=2013-03-28
| archiv-url=https://web.archive.org/web/20110609064344/http://csrc.nist.gov/groups/ST/hash/policy.html
| archiv-datum=2011-06-09
}}
</ref>
<ref name="submission">{{Internetquelle
| url=https://keccak.team/files/Keccak-submission-3.pdf
| titel=The Keccak SHA-3 submission
| sprache=en
| autor=Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles van Assche
| datum=2011-01-14
| abruf=2020-07-15
}}
</ref>
<ref name="sponge">{{Internetquelle
| url=https://keccak.team/files/CSF-0.1.pdf
| titel=Cryptographic sponge functions
| autor=Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles van Assche
| sprache=en
| datum=2011-01-14
| abruf=2020-08-26
}}
</ref>
<ref name="kelsey2013">
{{Internetquelle
|autor=Jon Kelsey
|titel=SHA3 Past, Present, and Future

| url=https://csrc.nist.gov/CSRC/media/Projects/Hash-Functions/documents/kelsey_ches2013_presentation.pdf
|zugriff=2013-10-06
}}
</ref>
<ref name="RSA2013">
{{Internetquelle
| url=https://csrc.nist.gov/csrc/media/projects/hash-functions/documents/burr_dimacs2013_presentation.pdf
| titel=SHA3, Where we’ve been, Where we're going
| autor=John Kelsey, Bill Burr
| datum=2013-05-01
| abruf=2020-07-18
}}
</ref>
<ref name="defense">
{{Internetquelle
| autor=Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche
| url=http://keccak.noekeon.org/yes_this_is_keccak.html
| titel=Yes, this is Keccak!
| datum=2013-10-04
| abruf=2020-07-18
}}
</ref>
<ref name="kelseymail">
{{Internetquelle
|titel=Moving Forward with SHA-3
|url=https://csrc.nist.gov/groups/ST/hash/sha-3/documents/kelsey-email-moving-forward-110113.pdf
| autor=John Kelsey
| datum=2013-11-01
| abruf=2020-07-18
}}
</ref>
<ref name="fips202draft">
{{Internetquelle
|url=https://csrc.nist.gov/publications/drafts/fips-202/fips_202_draft.pdf
|titel=SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
| titelerg=DRAFT FIPS PUB 202
|hrsg=NIST
|autor=NIST Computer Security Division (CSD)
|sprache=en
| datum=2014-05
| abruf=2020-07-18
}}
</ref>
<ref name="standard">
{{Internetquelle
|url=https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
|titel=SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
| titelerg=FIPS PUB 202
|hrsg=National Institute of Standards and Technology (NIST)
|datum=2015-08
|abruf=2018-01-08
|sprache=en
}}
</ref>
<ref name="SP800-185">
{{Internetquelle
| titel=SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash
| titelerg=NIST Special Publication 800-185
| autor=John Kelsey, Shu-jen Chang, Ray Perlner
| hrsg=NIST
| url=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf
| datum=2016-10
| sprache=en
| abruf=2020-07-15
}}
</ref>
<ref name="kangaroo12">
{{Internetquelle
| titel=KangarooTwelve: fast hashing based on Keccak-p
| autor=Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche, Ronny Van Keer, Benoit Viguier
| url=https://eprint.iacr.org/2016/770.pdf
| sprache=en
| abruf=2020-07-16
}}
</ref>
</references>

[[Kategorie:Kryptographische Hashfunktion]]

SHA-3 - Versionsgeschichte

imported>SchlurcherBot: Bot: http → https