Secure Hash Algorithm - Versionsgeschichte

Leonard Pesch: /* Schwächen */ Konstante Benennung als SHA-1 (statt SHA1)

2025-11-16T22:51:33Z

Schwächen: Konstante Benennung als SHA-1 (statt SHA1)

← Nächstältere Version		Version vom 16. November 2025, 23:51 Uhr
Zeile 26:		Zeile 26:
	Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.		Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.

	Im Oktober 2015 veröffentlichten Marc Stevens, Pierre Karpman und Thomas Peyrin eine Freestart-Kollision für die Kompressionsfunktion von ~~SHA1~~. Damit waren bis dahin geltende Abschätzungen, wann es zu welchen Kosten möglich ist, für SHA-1 aufgrund steigender Rechenleistung Chosen-Prefix-Kollisionen zur Fälschung von TLS-Zertifikaten zu finden, hinfällig.<ref>https://sites.google.com/site/itstheshappening/</ref><ref name="Schneier-SHA1">https://www.schneier.com/blog/archives/2015/10/sha-1_freestart.html</ref> Sie empfahlen, von SHA-1 baldmöglichst zu SHA-2 oder SHA-3 überzugehen.		Im Oktober 2015 veröffentlichten Marc Stevens, Pierre Karpman und Thomas Peyrin eine Freestart-Kollision für die Kompressionsfunktion von SHA-1. Damit waren bis dahin geltende Abschätzungen, wann es zu welchen Kosten möglich ist, für SHA-1 aufgrund steigender Rechenleistung Chosen-Prefix-Kollisionen zur Fälschung von TLS-Zertifikaten zu finden, hinfällig.<ref>https://sites.google.com/site/itstheshappening/</ref><ref name="Schneier-SHA1">https://www.schneier.com/blog/archives/2015/10/sha-1_freestart.html</ref> Sie empfahlen, von SHA-1 baldmöglichst zu SHA-2 oder SHA-3 überzugehen.

	Im Februar 2017 veröffentlichten Google-Mitarbeiter eine erste Kollision von SHA-1. Sie erzeugten zwei verschiedene funktionierende [[Portable Document Format\|PDF-Dateien]] mit gleichem SHA-1-Prüfwert unter enormem Aufwand. Eine einzelne CPU hätte etwa 6500 Jahre dafür benötigt.<ref>Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, Yarik Markov: [https://shattered.io/static/shattered.pdf The first collision for full SHA-1], shattered.io</ref><br />Im Jahre 2019 benötigten öffentlich bekannte Chosen-Prefix-Angriffe 2<sup>66,9</sup> bis 2<sup>69,4</sup> SHA-1-Berechnungen, um Kollisionen zu finden. Das entsprach im Jahre 2017 100 GPU-Jahren Rechenkapazität.<ref>G. Leurent, T. Peyrin: [https://eprint.iacr.org/2019/459.pdf From Collisions to Chosen-Prefix Collisions. Application to Full SHA-1], Inria</ref>		Im Februar 2017 veröffentlichten Google-Mitarbeiter eine erste Kollision von SHA-1. Sie erzeugten zwei verschiedene funktionierende [[Portable Document Format\|PDF-Dateien]] mit gleichem SHA-1-Prüfwert unter enormem Aufwand. Eine einzelne CPU hätte etwa 6500 Jahre dafür benötigt.<ref>Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, Yarik Markov: [https://shattered.io/static/shattered.pdf The first collision for full SHA-1], shattered.io</ref><br />Im Jahre 2019 benötigten öffentlich bekannte Chosen-Prefix-Angriffe 2<sup>66,9</sup> bis 2<sup>69,4</sup> SHA-1-Berechnungen, um Kollisionen zu finden. Das entsprach im Jahre 2017 100 GPU-Jahren Rechenkapazität.<ref>G. Leurent, T. Peyrin: [https://eprint.iacr.org/2019/459.pdf From Collisions to Chosen-Prefix Collisions. Application to Full SHA-1], Inria</ref>

Skranon am 27. September 2025 um 12:37 Uhr

2025-09-27T12:37:32Z

← Nächstältere Version		Version vom 27. September 2025, 13:37 Uhr
Zeile 1:		Zeile 1:
	Der Begriff '''Secure Hash Algorithm''' (kurz '''SHA''', {{enS}} für ''sicherer Hash-Algorithmus'') bezeichnet eine Gruppe standardisierter [[~~Kryptologische~~ Hashfunktion\|kryptologischer Hashfunktionen]]. Diese dienen zur Berechnung eines [[Prüfsumme\|Prüfwerts]] für beliebige digitale Daten (Nachrichten) und sind unter anderem die Grundlage zur Erstellung einer [[Digitale Signatur\|digitalen Signatur]].		Der Begriff '''Secure Hash Algorithm''' (kurz '''SHA''', {{enS}} für ''sicherer Hash-Algorithmus'') bezeichnet eine Gruppe standardisierter [[Kryptographische Hashfunktion\|kryptologischer Hashfunktionen]]. Diese dienen zur Berechnung eines [[Prüfsumme\|Prüfwerts]] für beliebige digitale Daten (Nachrichten) und sind unter anderem die Grundlage zur Erstellung einer [[Digitale Signatur\|digitalen Signatur]].

	Der Prüfwert wird verwendet, um die [[Integrität (Informationssicherheit)\|Integrität]] einer Nachricht zu sichern. Wenn zwei Nachrichten den gleichen Prüfwert ergeben, soll die Gleichheit der Nachrichten, nach normalem Ermessen, garantiert sein. Darum fordert man von einer kryptologischen Hashfunktion die Eigenschaft der [[Kollisionssicherheit]]: es soll praktisch unmöglich sein, zwei verschiedene Nachrichten mit dem gleichen Prüfwert zu erzeugen.		Der Prüfwert wird verwendet, um die [[Integrität (Informationssicherheit)\|Integrität]] einer Nachricht zu sichern. Wenn zwei Nachrichten den gleichen Prüfwert ergeben, soll die Gleichheit der Nachrichten, nach normalem Ermessen, garantiert sein. Darum fordert man von einer kryptologischen Hashfunktion die Eigenschaft der [[Kollisionsresistenz\|Kollisionssicherheit]]: es soll praktisch unmöglich sein, zwei verschiedene Nachrichten mit dem gleichen Prüfwert zu erzeugen.

	== Geschichte – SHA/SHA-0 ==		== Geschichte – SHA/SHA-0 ==
	Das [[National Institute of Standards and Technology]] (NIST) entwickelte zusammen mit der [[National Security Agency]] (NSA) eine Hash-Funktion als Bestandteil des [[Digital Signature Algorithm]]s (DSA) für den Digital Signature Standard (DSS). Die Funktion wurde 1993 veröffentlicht. Diese als Secure Hash Standard (SHS) bezeichnete Norm spezifiziert den sicheren Hash-Algorithmus (SHA) mit einem Hash-Wert von 160 [[Bit]] Länge für beliebige digitale Daten von maximal 2<sup>64</sup> − 1 Bit (≈ 2 [[Exbibyte]]) Länge.		Das [[National Institute of Standards and Technology]] (NIST) entwickelte zusammen mit der [[National Security Agency]] (NSA) eine Hash-Funktion als Bestandteil des [[Digital Signature Algorithm]]s (DSA) für den Digital Signature Standard (DSS). Die Funktion wurde 1993 veröffentlicht. Diese als Secure Hash Standard (SHS) bezeichnete Norm spezifiziert den sicheren Hash-Algorithmus (SHA) mit einem Hash-Wert von 160 [[Bit]] Länge für beliebige digitale Daten von maximal 2<sup>64</sup> − 1 Bit (≈ 2 [[Byte#Binärpräfixe\|Exbibyte]]) Länge.

	SHA ist wie die von [[Ronald L. Rivest]] entwickelten [[MD4]] und [[MD5]] eine [[~~Merkles Meta-Verfahren\|~~Merkle-Damgård-Konstruktion]] mit Davies-Meyer-Kompressionsfunktion, und die Kompressionsfunktion ist auch ähnlich wie bei diesen konstruiert. Mit seinem längeren Hash-Wert von 160 Bit gegenüber 128 Bit bei MD4 und MD5 ist SHA aber widerstandsfähiger gegen [[Brute-Force-Methode\|Brute-Force-Angriffe]] zum Auffinden von Kollisionen.		SHA ist wie die von [[Ronald L. Rivest]] entwickelten [[Message-Digest Algorithm 4\|MD4]] und [[Message-Digest Algorithm 5\|MD5]] eine [[Merkle-Damgård-Konstruktion]] mit Davies-Meyer-Kompressionsfunktion, und die Kompressionsfunktion ist auch ähnlich wie bei diesen konstruiert. Mit seinem längeren Hash-Wert von 160 Bit gegenüber 128 Bit bei MD4 und MD5 ist SHA aber widerstandsfähiger gegen [[Brute-Force-Methode\|Brute-Force-Angriffe]] zum Auffinden von Kollisionen.

	Die Nachricht wird mit einem Endstück [[Padding (Informatik)\|erweitert]], das die Länge der ursprünglichen Nachricht codiert. Dann wird sie in 512 Bit lange Blöcke geteilt, welche nacheinander verarbeitet werden. Dazu wird ein interner Datenblock von 160 Bit mittels einer [[Blockverschlüsselung]] verschlüsselt, mit dem Nachrichtenblock als Schlüssel. Zum Schlüsseltext wird dann der Klartext wortweise [[Division mit Rest#Modulo\|modulo]] <math>2^{32}</math> addiert. Der so berechnete Datenblock wird nun mit dem nächsten Nachrichtenblock verschlüsselt oder nach dem Einarbeiten des letzten Nachrichtenblocks als Hashwert ausgegeben.		Die Nachricht wird mit einem Endstück [[Padding (Informatik)\|erweitert]], das die Länge der ursprünglichen Nachricht codiert. Dann wird sie in 512 Bit lange Blöcke geteilt, welche nacheinander verarbeitet werden. Dazu wird ein interner Datenblock von 160 Bit mittels einer [[Blockverschlüsselung]] verschlüsselt, mit dem Nachrichtenblock als Schlüssel. Zum Schlüsseltext wird dann der Klartext wortweise [[Division mit Rest#Modulo\|modulo]] <math>2^{32}</math> addiert. Der so berechnete Datenblock wird nun mit dem nächsten Nachrichtenblock verschlüsselt oder nach dem Einarbeiten des letzten Nachrichtenblocks als Hashwert ausgegeben.
Zeile 18:		Zeile 18:

	=== Schwächen ===		=== Schwächen ===
	Am 15. Februar 2005 meldete der [[Kryptographie]]experte [[Bruce Schneier]] in seinem [[Blog]]<ref>{{Internetquelle \|autor=[[Bruce Schneier]] \|url=http://www.schneier.com/blog/archives/2005/02/sha1_broken.html \|titel=SHA-1 Broken \|datum=2005-02-15 \|sprache=en \|abruf=2011-12-10}}</ref>, dass die Wissenschaftler Xiaoyun Wang, Yiqun Lisa Yin und Hongbo Yu von [[Shandong University]] in China erfolgreich SHA-1 gebrochen hätten. Ihnen war es gelungen, den Aufwand zur [[Kollisionsangriff\|Kollisionsberechnung]] von 2<sup>80</sup> auf 2<sup>69</sup> zu verringern.<ref>{{Literatur \|Autor=Xiaoyun Wang, Yiqun Lisa Yin und Hongbo Yu \|Titel=Finding Collisions in the Full SHA-1 \|Sammelwerk=CRYPTO \|Datum=2005 \|Seiten=17-36 \|Online=[http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf PDF]}}</ref> 2<sup>69</sup> Berechnungen könnten eventuell mit Hochleistungsrechnern durchgeführt werden.		Am 15. Februar 2005 meldete der [[Kryptographie]]experte [[Bruce Schneier]] in seinem [[Blog]]<ref>{{Internetquelle \|autor=[[Bruce Schneier]] \|url=http://www.schneier.com/blog/archives/2005/02/sha1_broken.html \|titel=SHA-1 Broken \|datum=2005-02-15 \|sprache=en \|abruf=2011-12-10}}</ref>, dass die Wissenschaftler Xiaoyun Wang, Yiqun Lisa Yin und Hongbo Yu von [[Shandong-Universität\|Shandong University]] in China erfolgreich SHA-1 gebrochen hätten. Ihnen war es gelungen, den Aufwand zur [[Kollisionsangriff\|Kollisionsberechnung]] von 2<sup>80</sup> auf 2<sup>69</sup> zu verringern.<ref>{{Literatur \|Autor=Xiaoyun Wang, Yiqun Lisa Yin und Hongbo Yu \|Titel=Finding Collisions in the Full SHA-1 \|Sammelwerk=CRYPTO \|Datum=2005 \|Seiten=17-36 \|Online=[http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf PDF]}}</ref> 2<sup>69</sup> Berechnungen könnten eventuell mit Hochleistungsrechnern durchgeführt werden.

	Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.		Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.
Zeile 28:		Zeile 28:
	Im Oktober 2015 veröffentlichten Marc Stevens, Pierre Karpman und Thomas Peyrin eine Freestart-Kollision für die Kompressionsfunktion von SHA1. Damit waren bis dahin geltende Abschätzungen, wann es zu welchen Kosten möglich ist, für SHA-1 aufgrund steigender Rechenleistung Chosen-Prefix-Kollisionen zur Fälschung von TLS-Zertifikaten zu finden, hinfällig.<ref>https://sites.google.com/site/itstheshappening/</ref><ref name="Schneier-SHA1">https://www.schneier.com/blog/archives/2015/10/sha-1_freestart.html</ref> Sie empfahlen, von SHA-1 baldmöglichst zu SHA-2 oder SHA-3 überzugehen.		Im Oktober 2015 veröffentlichten Marc Stevens, Pierre Karpman und Thomas Peyrin eine Freestart-Kollision für die Kompressionsfunktion von SHA1. Damit waren bis dahin geltende Abschätzungen, wann es zu welchen Kosten möglich ist, für SHA-1 aufgrund steigender Rechenleistung Chosen-Prefix-Kollisionen zur Fälschung von TLS-Zertifikaten zu finden, hinfällig.<ref>https://sites.google.com/site/itstheshappening/</ref><ref name="Schneier-SHA1">https://www.schneier.com/blog/archives/2015/10/sha-1_freestart.html</ref> Sie empfahlen, von SHA-1 baldmöglichst zu SHA-2 oder SHA-3 überzugehen.

	Im Februar 2017 veröffentlichten Google-Mitarbeiter eine erste Kollision von SHA-1. Sie erzeugten zwei verschiedene funktionierende [[PDF-~~Datei~~]]en mit gleichem SHA-1-Prüfwert unter enormem Aufwand. Eine einzelne CPU hätte etwa 6500 Jahre dafür benötigt.<ref>Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, Yarik Markov: [https://shattered.io/static/shattered.pdf The first collision for full SHA-1], shattered.io</ref><br />		Im Februar 2017 veröffentlichten Google-Mitarbeiter eine erste Kollision von SHA-1. Sie erzeugten zwei verschiedene funktionierende [[Portable Document Format\|PDF-Dateien]] mit gleichem SHA-1-Prüfwert unter enormem Aufwand. Eine einzelne CPU hätte etwa 6500 Jahre dafür benötigt.<ref>Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, Yarik Markov: [https://shattered.io/static/shattered.pdf The first collision for full SHA-1], shattered.io</ref><br />Im Jahre 2019 benötigten öffentlich bekannte Chosen-Prefix-Angriffe 2<sup>66,9</sup> bis 2<sup>69,4</sup> SHA-1-Berechnungen, um Kollisionen zu finden. Das entsprach im Jahre 2017 100 GPU-Jahren Rechenkapazität.<ref>G. Leurent, T. Peyrin: [https://eprint.iacr.org/2019/459.pdf From Collisions to Chosen-Prefix Collisions. Application to Full SHA-1], Inria</ref>
	Im Jahre 2019 benötigten öffentlich bekannte Chosen-Prefix-Angriffe 2<sup>66,9</sup> bis 2<sup>69,4</sup> SHA-1-Berechnungen, um Kollisionen zu finden. Das entsprach im Jahre 2017 100 GPU-Jahren Rechenkapazität.<ref>G. Leurent, T. Peyrin: [https://eprint.iacr.org/2019/459.pdf From Collisions to Chosen-Prefix Collisions. Application to Full SHA-1], Inria</ref>

	=== Empfehlungen ===		=== Empfehlungen ===
Zeile 67:		Zeile 66:
	'''erweitere''' message '''um''' bit "1"		'''erweitere''' message '''um''' bit "1"
	'''erweitere''' message '''um''' bits "0" '''bis''' Länge von message in bits [[Kongruenz (Zahlentheorie)\|≡]] 448 (mod 512)		'''erweitere''' message '''um''' bits "0" '''bis''' Länge von message in bits [[Kongruenz (Zahlentheorie)\|≡]] 448 (mod 512)
	'''erweitere''' message '''um''' message_laenge als ''64-Bit [[Big endian\|big-endian]] Integer''		'''erweitere''' message '''um''' message_laenge als ''64-Bit [[Byte-Reihenfolge#Big-endian\|big-endian]] Integer''

	<span style="color:green;">// ''Verarbeite die Nachricht in aufeinander folgenden 512-Bit-Blöcken:''</span>		<span style="color:green;">// ''Verarbeite die Nachricht in aufeinander folgenden 512-Bit-Blöcken:''</span>
	'''für alle''' ''512-Bit'' Block '''von''' message		'''für alle''' ''512-Bit'' Block '''von''' message
	unterteile Block in 16 32-bit [[Big endian\|big-endian]] Worte w(i), 0 ≤ i ≤ 15		unterteile Block in 16 32-bit [[Byte-Reihenfolge#Big-endian\|big-endian]] Worte w(i), 0 ≤ i ≤ 15

	<span style="color:green;">// ''Erweitere die 16 32-Bit-Worte auf 80 32-Bit-Worte:''</span>		<span style="color:green;">// ''Erweitere die 16 32-Bit-Worte auf 80 32-Bit-Worte:''</span>
Zeile 114:		Zeile 113:
	h4 := h4 + e		h4 := h4 + e

	digest = hash = h0 '''append''' h1 '''append''' h2 '''append''' h3 '''append''' h4 <span style="color:green;">//''(Darstellung als [[Big endian\|big-endian]])''</span>		digest = hash = h0 '''append''' h1 '''append''' h2 '''append''' h3 '''append''' h4 <span style="color:green;">//''(Darstellung als [[Byte-Reihenfolge#Big-endian\|big-endian]])''</span>

	''Beachte: Anstatt der Original-Formulierung aus dem FIPS PUB 180-1 können alternativ auch folgende Formulierungen verwendet werden:''		''Beachte: Anstatt der Original-Formulierung aus dem FIPS PUB 180-1 können alternativ auch folgende Formulierungen verwendet werden:''
Zeile 134:		Zeile 133:
	{{Hauptartikel\|SHA-3}}		{{Hauptartikel\|SHA-3}}

	Weil man im Jahr 2004 grundlegende Schwächen der Merkle-Damgård-Konstruktion entdeckte, suchte das NIST nach einer neuen Hashfunktion, die wesentlich zukunftssicherer als SHA-2 sein sollte. Es rief dazu zu einem Wettbewerb auf, wie zuvor bereits für den [[Advanced Encryption Standard]] (AES). Die Wahl fiel im Oktober 2012 auf [[Keccak]], die dann im August 2015 unter der Bezeichnung SHA-3 in verschiedenen Varianten standardisiert wurde. SHA-3 ist grundlegend anders als SHA-2 aufgebaut, nämlich als sogenannte ''Sponge-Konstruktion''.		Weil man im Jahr 2004 grundlegende Schwächen der Merkle-Damgård-Konstruktion entdeckte, suchte das NIST nach einer neuen Hashfunktion, die wesentlich zukunftssicherer als SHA-2 sein sollte. Es rief dazu zu einem Wettbewerb auf, wie zuvor bereits für den [[Advanced Encryption Standard]] (AES). Die Wahl fiel im Oktober 2012 auf [[SHA-3\|Keccak]], die dann im August 2015 unter der Bezeichnung SHA-3 in verschiedenen Varianten standardisiert wurde. SHA-3 ist grundlegend anders als SHA-2 aufgebaut, nämlich als sogenannte ''Sponge-Konstruktion''.

	== Spezifikationen ==		== Spezifikationen ==
Zeile 154:		Zeile 153:
	* [https://www.psw-group.de/blog/sha-1-wird-verabschiedet-sha-2-startet-das-muessen-sie-wissen/1665 SHA-1 wird verabschiedet, SHA-2 startet (Update: SHA-3 wird Standard)] IT-Security, von Christian Heutger, 6. August 2015.		* [https://www.psw-group.de/blog/sha-1-wird-verabschiedet-sha-2-startet-das-muessen-sie-wissen/1665 SHA-1 wird verabschiedet, SHA-2 startet (Update: SHA-3 wird Standard)] IT-Security, von Christian Heutger, 6. August 2015.

	~~===~~ Zu den Schwächen von SHA ~~===~~		'''Zu den Schwächen von SHA'''
	* [[Arjen Lenstra]]: [http://infoscience.epfl.ch/record/164540/files/NPDF-33.pdf ''Further progress in hashing cryptanalysis''], 26. Februar 2005 (englisch, PDF; 89 kB)		* [[Arjen Lenstra]]: [http://infoscience.epfl.ch/record/164540/files/NPDF-33.pdf ''Further progress in hashing cryptanalysis''], 26. Februar 2005 (englisch, PDF; 89 kB)
	* Xiaoyun Wang, Yiqun Lisa Yin, Hongbo Yu: [http://cryptome.org/wang_sha1_v2.zip ''Finding Collisions in the Full SHA-1''] (englisch, PDF; [[ZIP-Dateiformat\|ZIP]]; 190 kB)		* Xiaoyun Wang, Yiqun Lisa Yin, Hongbo Yu: [http://cryptome.org/wang_sha1_v2.zip ''Finding Collisions in the Full SHA-1''] (englisch, PDF; [[ZIP-Dateiformat\|ZIP]]; 190 kB)

Megatherium: Die letzte Textänderung von 2A02:8070:2A82:6300:AEF3:C152:9BD:ECE7 wurde verworfen und die Version 249402820 von Farin12 wiederhergestellt.

2025-03-04T21:34:00Z

Die letzte Textänderung von 2A02:8070:2A82:6300:AEF3:C152:9BD:ECE7 wurde verworfen und die Version 249402820 von Farin12 wiederhergestellt.

← Nächstältere Version		Version vom 4. März 2025, 22:34 Uhr
Zeile 10:		Zeile 10:
	Die Nachricht wird mit einem Endstück [[Padding (Informatik)\|erweitert]], das die Länge der ursprünglichen Nachricht codiert. Dann wird sie in 512 Bit lange Blöcke geteilt, welche nacheinander verarbeitet werden. Dazu wird ein interner Datenblock von 160 Bit mittels einer [[Blockverschlüsselung]] verschlüsselt, mit dem Nachrichtenblock als Schlüssel. Zum Schlüsseltext wird dann der Klartext wortweise [[Division mit Rest#Modulo\|modulo]] <math>2^{32}</math> addiert. Der so berechnete Datenblock wird nun mit dem nächsten Nachrichtenblock verschlüsselt oder nach dem Einarbeiten des letzten Nachrichtenblocks als Hashwert ausgegeben.		Die Nachricht wird mit einem Endstück [[Padding (Informatik)\|erweitert]], das die Länge der ursprünglichen Nachricht codiert. Dann wird sie in 512 Bit lange Blöcke geteilt, welche nacheinander verarbeitet werden. Dazu wird ein interner Datenblock von 160 Bit mittels einer [[Blockverschlüsselung]] verschlüsselt, mit dem Nachrichtenblock als Schlüssel. Zum Schlüsseltext wird dann der Klartext wortweise [[Division mit Rest#Modulo\|modulo]] <math>2^{32}</math> addiert. Der so berechnete Datenblock wird nun mit dem nächsten Nachrichtenblock verschlüsselt oder nach dem Einarbeiten des letzten Nachrichtenblocks als Hashwert ausgegeben.

	== SHA- ==		== SHA-1 ==
			[[Datei:SHA-1.svg\|mini\|Aufbau einer Runde von SHA-0 und SHA-1]]

	Der ursprüngliche SHA wurde wegen eines „Konstruktionsfehlers“ schon 1995 korrigiert und spielte deswegen in der Praxis kaum eine Rolle. Er ist heute als '''SHA-0''' bekannt, die korrigierte Variante als '''SHA-1'''.		Der ursprüngliche SHA wurde wegen eines „Konstruktionsfehlers“ schon 1995 korrigiert und spielte deswegen in der Praxis kaum eine Rolle. Er ist heute als '''SHA-0''' bekannt, die korrigierte Variante als '''SHA-1'''.

Zeile 20:		Zeile 22:
	Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.		Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.

			Im August 2006 wurde auf der CRYPTO 2006 ein weit schwerwiegenderer Angriff gegen SHA-1 präsentiert. Dabei sind bis zu 25 % der gefälschten Nachricht frei wählbar. Bei bisherigen [[Kollisionsangriff]]en wurden die so genannten Hash-Zwillinge nur mit sinnlosen Buchstabenkombinationen des Klartextes gebildet. Diese waren leicht erkennbar.
	Im August 2006 wurde auf der CRYPTO NIGt. Diese waren leicht erkennbar.

	Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.		Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.

2A02:8070:2A82:6300:AEF3:C152:9BD:ECE7: /* SHA-1 */

2025-03-04T19:38:25Z

SHA-1

← Nächstältere Version		Version vom 4. März 2025, 20:38 Uhr
Zeile 10:		Zeile 10:
	Die Nachricht wird mit einem Endstück [[Padding (Informatik)\|erweitert]], das die Länge der ursprünglichen Nachricht codiert. Dann wird sie in 512 Bit lange Blöcke geteilt, welche nacheinander verarbeitet werden. Dazu wird ein interner Datenblock von 160 Bit mittels einer [[Blockverschlüsselung]] verschlüsselt, mit dem Nachrichtenblock als Schlüssel. Zum Schlüsseltext wird dann der Klartext wortweise [[Division mit Rest#Modulo\|modulo]] <math>2^{32}</math> addiert. Der so berechnete Datenblock wird nun mit dem nächsten Nachrichtenblock verschlüsselt oder nach dem Einarbeiten des letzten Nachrichtenblocks als Hashwert ausgegeben.		Die Nachricht wird mit einem Endstück [[Padding (Informatik)\|erweitert]], das die Länge der ursprünglichen Nachricht codiert. Dann wird sie in 512 Bit lange Blöcke geteilt, welche nacheinander verarbeitet werden. Dazu wird ein interner Datenblock von 160 Bit mittels einer [[Blockverschlüsselung]] verschlüsselt, mit dem Nachrichtenblock als Schlüssel. Zum Schlüsseltext wird dann der Klartext wortweise [[Division mit Rest#Modulo\|modulo]] <math>2^{32}</math> addiert. Der so berechnete Datenblock wird nun mit dem nächsten Nachrichtenblock verschlüsselt oder nach dem Einarbeiten des letzten Nachrichtenblocks als Hashwert ausgegeben.

	== SHA-1 ==		== SHA- ==
	[[Datei:SHA-1.svg\|mini\|Aufbau einer Runde von SHA-0 und SHA-1]]

	Der ursprüngliche SHA wurde wegen eines „Konstruktionsfehlers“ schon 1995 korrigiert und spielte deswegen in der Praxis kaum eine Rolle. Er ist heute als '''SHA-0''' bekannt, die korrigierte Variante als '''SHA-1'''.		Der ursprüngliche SHA wurde wegen eines „Konstruktionsfehlers“ schon 1995 korrigiert und spielte deswegen in der Praxis kaum eine Rolle. Er ist heute als '''SHA-0''' bekannt, die korrigierte Variante als '''SHA-1'''.

Zeile 22:		Zeile 20:
	Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.		Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.

			Im August 2006 wurde auf der CRYPTO NIGt. Diese waren leicht erkennbar.
	Im August 2006 wurde auf der CRYPTO 2006 ein weit schwerwiegenderer Angriff gegen SHA-1 präsentiert. Dabei sind bis zu 25 % der gefälschten Nachricht frei wählbar. Bei bisherigen [[Kollisionsangriff]]en wurden die so genannten Hash-Zwillinge nur mit sinnlosen Buchstabenkombinationen des Klartextes gebildet. Diese waren leicht erkennbar.

	Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.		Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.

Farin12: /* Empfehlungen */ letzter Satz, Kommafehler

2024-10-13T21:29:37Z

Empfehlungen: letzter Satz, Kommafehler

← Nächstältere Version		Version vom 13. Oktober 2024, 22:29 Uhr
Zeile 32:		Zeile 32:

	=== Empfehlungen ===		=== Empfehlungen ===
	Als Reaktion auf die bekanntgewordenen Angriffe gegen SHA-1 hielt das [[National Institute of Standards and Technology]] (NIST) im Oktober 2005 einen Workshop ab, in dem der aktuelle Stand kryptologischer Hashfunktionen diskutiert wurde. NIST empfiehlt, SHA-1 nicht mehr für [[digitale Signatur]]en zu verwenden, lässt die Nutzung für Anwendungszwecke, die keine Kollisionsresistenz benötigen, aber noch bis 2030 zu.<ref>NIST Special Publication 800-131A, Revision 2: [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf Transitioning the Use of Cryptographic Algorithms and Key Lengths]. März 2019. Seite 18f.</ref><ref>[https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps NIST Transitioning Away from SHA-1 for All Applications]. 15. Dezember 2022.</ref> Das BSI empfiehlt die Verwendung von SHA-2 oder [[SHA-3]] anstelle von SHA-1.<ref>{{Literatur \|Hrsg=[[Bundesamt für Sicherheit in der Informationstechnik\|BSI]] \|Titel=TR-02102-1 Kryptographische Verfahren: Empfehlungen und Schlüssellängen \|Auflage=2024-01 \|Kapitel=1.5. Umgang mit Legacy-Algorithmen \|Datum=2024-02-02\|Seiten=24 \|Online=https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr-02102.html?nn=433400 \|Zitat=SHA1 ist keine kollisionsresistente Hashfunktion. [..] Als grundsätzliche Sicherungsmaßnahme wird empfohlen, auch in diesen Anwendungen eine Hashfunktion der SHA2- oder der SHA3-Familie einzusetzen. \|Abruf=2024-09-06}}</ref> Im Oktober 2015 empfahl Bruce Schneier SHA-1 nicht mehr zu verwenden.<ref name="Schneier-SHA1" />		Als Reaktion auf die bekanntgewordenen Angriffe gegen SHA-1 hielt das [[National Institute of Standards and Technology]] (NIST) im Oktober 2005 einen Workshop ab, in dem der aktuelle Stand kryptologischer Hashfunktionen diskutiert wurde. NIST empfiehlt, SHA-1 nicht mehr für [[digitale Signatur]]en zu verwenden, lässt die Nutzung für Anwendungszwecke, die keine Kollisionsresistenz benötigen, aber noch bis 2030 zu.<ref>NIST Special Publication 800-131A, Revision 2: [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf Transitioning the Use of Cryptographic Algorithms and Key Lengths]. März 2019. Seite 18f.</ref><ref>[https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps NIST Transitioning Away from SHA-1 for All Applications]. 15. Dezember 2022.</ref> Das BSI empfiehlt die Verwendung von SHA-2 oder [[SHA-3]] anstelle von SHA-1.<ref>{{Literatur \|Hrsg=[[Bundesamt für Sicherheit in der Informationstechnik\|BSI]] \|Titel=TR-02102-1 Kryptographische Verfahren: Empfehlungen und Schlüssellängen \|Auflage=2024-01 \|Kapitel=1.5. Umgang mit Legacy-Algorithmen \|Datum=2024-02-02\|Seiten=24 \|Online=https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr-02102.html?nn=433400 \|Zitat=SHA1 ist keine kollisionsresistente Hashfunktion. [...] Als grundsätzliche Sicherungsmaßnahme wird empfohlen, auch in diesen Anwendungen eine Hashfunktion der SHA2- oder der SHA3-Familie einzusetzen. \|Abruf=2024-09-06}}</ref> Im Oktober 2015 empfahl Bruce Schneier, SHA-1 nicht mehr zu verwenden.<ref name="Schneier-SHA1" />

	=== Beispiel-Hashes ===		=== Beispiel-Hashes ===

Hgzh: Änderungen von 2001:9E8:16D6:2D00:1571:BF5A:51A5:9FA3 (Diskussion) auf die letzte Version von Gunnar.Kaestle zurückgesetzt

2024-09-25T06:44:27Z

Änderungen von 2001:9E8:16D6:2D00:1571:BF5A:51A5:9FA3 (Diskussion) auf die letzte Version von Gunnar.Kaestle zurückgesetzt

← Nächstältere Version		Version vom 25. September 2024, 07:44 Uhr
Zeile 22:		Zeile 22:
	Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.		Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.

	Im August 2006 wurde auf der CRYPTO 2006 ein weit ~~schwerer wiegender~~ Angriff gegen SHA-1 präsentiert. Dabei sind bis zu 25 % der gefälschten Nachricht frei wählbar. Bei bisherigen [[Kollisionsangriff]]en wurden die so genannten Hash-Zwillinge nur mit sinnlosen Buchstabenkombinationen des Klartextes gebildet. Diese waren leicht erkennbar.		Im August 2006 wurde auf der CRYPTO 2006 ein weit schwerwiegenderer Angriff gegen SHA-1 präsentiert. Dabei sind bis zu 25 % der gefälschten Nachricht frei wählbar. Bei bisherigen [[Kollisionsangriff]]en wurden die so genannten Hash-Zwillinge nur mit sinnlosen Buchstabenkombinationen des Klartextes gebildet. Diese waren leicht erkennbar.

	Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.		Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.

2001:9E8:16D6:2D00:1571:BF5A:51A5:9FA3: /* Schwächen */

2024-09-25T06:44:07Z

Schwächen

← Nächstältere Version		Version vom 25. September 2024, 07:44 Uhr
Zeile 22:		Zeile 22:
	Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.		Kurze Zeit später, am 17. August 2005, wurde von Xiaoyun Wang, [[Andrew Yao]] und [[Frances Yao]] auf der Konferenz [[CRYPTO (Veranstaltung)\|CRYPTO 2005]] ein weiterer, effizienterer Kollisionsangriff auf SHA-1 vorgestellt, welcher den Berechnungsaufwand auf 2<sup>63</sup> reduziert.

	Im August 2006 wurde auf der CRYPTO 2006 ein weit ~~schwerwiegenderer~~ Angriff gegen SHA-1 präsentiert. Dabei sind bis zu 25 % der gefälschten Nachricht frei wählbar. Bei bisherigen [[Kollisionsangriff]]en wurden die so genannten Hash-Zwillinge nur mit sinnlosen Buchstabenkombinationen des Klartextes gebildet. Diese waren leicht erkennbar.		Im August 2006 wurde auf der CRYPTO 2006 ein weit schwerer wiegender Angriff gegen SHA-1 präsentiert. Dabei sind bis zu 25 % der gefälschten Nachricht frei wählbar. Bei bisherigen [[Kollisionsangriff]]en wurden die so genannten Hash-Zwillinge nur mit sinnlosen Buchstabenkombinationen des Klartextes gebildet. Diese waren leicht erkennbar.

	Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.		Ein kritisches Angriffsszenario erfordert, dass Angreifer eine zweite, in Teilen sinnvolle Variante eines Dokuments erzeugen, die den gleichen SHA-1-Wert und damit die gleiche Signatur ergibt. Die beim Angriff verbleibenden 75 % sinnloser Zeichen (also Datenmüll) können vor ungeschulten Betrachtern ggf. technisch verborgen werden. Der Angreifer kann behaupten, die gefälschte Variante sei anstatt der originalen Variante signiert worden.

Gunnar.Kaestle: /* Empfehlungen */ Update des Einzelnachweises

2024-09-06T10:26:43Z

Empfehlungen: Update des Einzelnachweises

← Nächstältere Version		Version vom 6. September 2024, 11:26 Uhr
Zeile 32:		Zeile 32:

	=== Empfehlungen ===		=== Empfehlungen ===
	Als Reaktion auf die bekanntgewordenen Angriffe gegen SHA-1 hielt das [[National Institute of Standards and Technology]] (NIST) im Oktober 2005 einen Workshop ab, in dem der aktuelle Stand kryptologischer Hashfunktionen diskutiert wurde. NIST empfiehlt, SHA-1 nicht mehr für [[digitale Signatur]]en zu verwenden, lässt die Nutzung für Anwendungszwecke, die keine Kollisionsresistenz benötigen, aber noch bis 2030 zu.<ref>NIST Special Publication 800-131A, Revision 2: [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf Transitioning the Use of Cryptographic Algorithms and Key Lengths]. März 2019. Seite 18f.</ref><ref>[https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps NIST Transitioning Away from SHA-1 for All Applications]. 15. Dezember 2022.</ref> Das BSI empfiehlt die Verwendung von SHA-2 oder [[SHA-3]] anstelle von SHA-1.<ref>{{Literatur \|~~Titel~~=BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen \|~~Datum~~=~~2023~~-01-09 \|Seiten=24 \|Online=https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr-02102.html?nn=433400 \|Abruf=~~2023~~-04-16}}</ref> Im Oktober 2015 empfahl Bruce Schneier SHA-1 nicht mehr zu verwenden.<ref name="Schneier-SHA1" />		Als Reaktion auf die bekanntgewordenen Angriffe gegen SHA-1 hielt das [[National Institute of Standards and Technology]] (NIST) im Oktober 2005 einen Workshop ab, in dem der aktuelle Stand kryptologischer Hashfunktionen diskutiert wurde. NIST empfiehlt, SHA-1 nicht mehr für [[digitale Signatur]]en zu verwenden, lässt die Nutzung für Anwendungszwecke, die keine Kollisionsresistenz benötigen, aber noch bis 2030 zu.<ref>NIST Special Publication 800-131A, Revision 2: [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf Transitioning the Use of Cryptographic Algorithms and Key Lengths]. März 2019. Seite 18f.</ref><ref>[https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps NIST Transitioning Away from SHA-1 for All Applications]. 15. Dezember 2022.</ref> Das BSI empfiehlt die Verwendung von SHA-2 oder [[SHA-3]] anstelle von SHA-1.<ref>{{Literatur \|Hrsg=[[Bundesamt für Sicherheit in der Informationstechnik\|BSI]] \|Titel=TR-02102-1 Kryptographische Verfahren: Empfehlungen und Schlüssellängen \|Auflage=2024-01 \|Kapitel=1.5. Umgang mit Legacy-Algorithmen \|Datum=2024-02-02\|Seiten=24 \|Online=https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr-02102.html?nn=433400 \|Zitat=SHA1 ist keine kollisionsresistente Hashfunktion. [..] Als grundsätzliche Sicherungsmaßnahme wird empfohlen, auch in diesen Anwendungen eine Hashfunktion der SHA2- oder der SHA3-Familie einzusetzen. \|Abruf=2024-09-06}}</ref> Im Oktober 2015 empfahl Bruce Schneier SHA-1 nicht mehr zu verwenden.<ref name="Schneier-SHA1" />

	=== Beispiel-Hashes ===		=== Beispiel-Hashes ===

Aka: /* Beispiel-Hashes */ Tippfehler entfernt

2024-08-06T10:48:24Z

Beispiel-Hashes: Tippfehler entfernt

← Nächstältere Version		Version vom 6. August 2024, 11:48 Uhr
Zeile 45:		Zeile 45:
	Eine kleine Änderung der Nachricht erzeugt also einen komplett anderen Hash. Diese Eigenschaft wird in der [[Kryptographie]] auch als [[Lawineneffekt (Kryptographie)\|Lawineneffekt]] bezeichnet.		Eine kleine Änderung der Nachricht erzeugt also einen komplett anderen Hash. Diese Eigenschaft wird in der [[Kryptographie]] auch als [[Lawineneffekt (Kryptographie)\|Lawineneffekt]] bezeichnet.

	Der Hash eines Strings der Länge ~~Null~~ ist:		Der Hash eines Strings der Länge null ist:

	SHA1("")		SHA1("")

2A02:3035:60B:A1BE:59C3:FFD3:7B70:EE42 am 8. April 2024 um 21:45 Uhr

2024-04-08T21:45:18Z

← Nächstältere Version		Version vom 8. April 2024, 22:45 Uhr
Zeile 1:		Zeile 1:
	Der Begriff '''Secure Hash Algorithm''' (kurz '''SHA''', {{enS}} für ''sicherer Hash-Algorithmus'') bezeichnet eine Gruppe standardisierter [[Kryptologische Hashfunktion\|kryptologischer Hashfunktionen]]. Diese dienen zur Berechnung eines [[Prüfsumme\|Prüfwerts]] für beliebige digitale Daten (Nachrichten) und sind unter anderem die Grundlage zur Erstellung einer [[Digitale Signatur\|digitalen Signatur]].		Der Begriff '''Secure Hash Algorithm''' (kurz '''SHA''', {{enS}} für ''sicherer Hash-Algorithmus'') bezeichnet eine Gruppe standardisierter [[Kryptologische Hashfunktion\|kryptologischer Hashfunktionen]]. Diese dienen zur Berechnung eines [[Prüfsumme\|Prüfwerts]] für beliebige digitale Daten (Nachrichten) und sind unter anderem die Grundlage zur Erstellung einer [[Digitale Signatur\|digitalen Signatur]].

	Der Prüfwert wird verwendet, um die [[Integrität (Informationssicherheit)\|Integrität]] einer Nachricht zu sichern. Wenn zwei Nachrichten den gleichen Prüfwert ergeben, soll die Gleichheit der Nachrichten nach normalem Ermessen garantiert sein~~, unbeschadet gezielter Manipulationsversuche an den Nachrichten~~. Darum fordert man von einer kryptologischen Hashfunktion die Eigenschaft der [[Kollisionssicherheit]]: es soll praktisch unmöglich sein, zwei verschiedene Nachrichten mit dem gleichen Prüfwert zu erzeugen.		Der Prüfwert wird verwendet, um die [[Integrität (Informationssicherheit)\|Integrität]] einer Nachricht zu sichern. Wenn zwei Nachrichten den gleichen Prüfwert ergeben, soll die Gleichheit der Nachrichten, nach normalem Ermessen, garantiert sein. Darum fordert man von einer kryptologischen Hashfunktion die Eigenschaft der [[Kollisionssicherheit]]: es soll praktisch unmöglich sein, zwei verschiedene Nachrichten mit dem gleichen Prüfwert zu erzeugen.

	== Geschichte – SHA/SHA-0 ==		== Geschichte – SHA/SHA-0 ==