Diskussion:Secure Hash Algorithm/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Secure Hash Algorithm/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Secure_Hash_Algorithm/Archiv#Thema_1

Alter Beitrag ohne Überschrift

Hallo, wie sicher ist MD5 im Vergleich zu SHA? Oder gibt es Besseres?

Zur Zeit benutzen wir MD5, ich habe aber gehört, dass MD5 unter Umständen unsicher ist?

Welches ist das sicherste/effizienteste Verfahren zum Hashing mittels Digesting? Es sollen Daten sicher "gehasht" werden - bis zu 3 TB können es werden.

Vielleicht gibts ja hier einen Experten/Expertin?

Danke und Gruß Malteser

---

MD5 ist eher unsicher

Für MD5 konnten durch analytische Verfahren Kollisionen, unterschiedliche Nachrichten mit gleichem Hashwert gefunden werden. Dies widerspricht zumindest den Designzielen des MD5. In der Praxis dürfte dies allein, trotz Geburtstagsangriff, wohl eher bedeutungslos sein. Dies hängt jedoch von der konkreten Anwendung ab.

Es spricht zumindest nichts dagegen statt dem MD5 den SHA-1 zu verwenden. Auch damit können 3 TB, theoretisch auch noch wesentlich mehr, ohne weiteres verarbeitet werden. Der Sinn einer solchen Hashberechnung leuchtet mir allerdings nicht unbedingt ein. Wem es Spass macht, kann aber noch viele weitere Hashes berechnen.

Franz Scheerer

Weblink

Jacksum, ein open source Programm zur Berechnung von Hashwerten

Priwo 15:54, 25. Apr 2004 (CEST)

---

Herzlichen Dank Priwo für die prompte Antwort :-) Also da wir bis zu 3TB Daten mittels Satelliten-Uplink senden, wäre also SHA-512 doch die bevorzugte Wahl. Danke nochmals für den Link. MfG Malteser 15:57, 25. Apr 2004 (CEST)

Max. Größe einer "gehashten" Datei bei MD5

Hallo!

Du brauchst wirklich keinen SHA-512, wenn es nur um die Dateigröße geht. MD5 speichert die Länge einer Datei (in Bits) in einem 64-Bit-Wert ab. Das macht also 2^64 Bits Maximallänge bzw. (2^64)/8 Bytes, also ca. 2,3*10^18 Bytes. Das entspricht 2,2*10^12 MB oder 2,1*10^9 GB oder 2,1*10^6 TB oder 2048 PB (Petabytes) oder genau 2 EB (Exabytes). Mach Dir also wegen der paar Terabytes, die Eure Dateien lang sind, keine Sorgen. MD5 ist nicht nur sicher genug, sondern auch "groß" genug für Euch.

Alexander Kriegisch

mailto:Alexander.Kriegisch@web.de

Die Geschichte mit der maximalen Dateigröße ist doch einfach nur albern. Die Begrenzung von SHA-1 auf 2^64 Bit ist natürlich praktisch ohne jede Bedeutung.

Mit der Sicherheit sieht die Sache etwas anders aus. Für MD5 sind bereits so genannte Kollisionen, d. h. unterschiedliche Daten mit gleichem Hashwert gefunden worden. Zumindest mit den neueren SHA-Varianten ist wohl für länge Zeit undenkbar. Für viele Anwendungen ist die Kollisionsresistenz nicht von Relevanz.

Franz Scheerer (http://www.scheerer-software.de)

Lemma

Was ist denn das eigentlich für ein Lemma? Mal davon abgesehen, daß der volle englische Name eher eine allgemeine Bezeichnung ist und der NSA bei der Benennung wohl was durchgegangen ist, muß sowas auch noch übersetzt werden? Unter so einem Lemma würde ich allgemeine Informationen darüber was einen sicheren Hash-Algorithmus ausmacht erwarten. Ist die Bezeichnung für Hash der SHA-Gruppe im Deutschen wenigstens verbreitet? Analog zur en: wäre mir ein Lemma wie SHA-Hashfunktionen wesentlich lieber. --jailbird 12:35, 25. Aug 2006 (CEST)

Mir auch :O) Finde das Lemma ebenfalls sehr unglücklich gewählt. Es gibt aber hier leider einige Eindeutschungsfanatiker, die solche Aktionen leider für notwendig erachten. 217.81.114.185 13:09, 25. Aug 2006 (CEST)

Diverse, auch englische Begriffe und Abkürzungen sind auf diesen Artikel als Weiterleitungsseite eingerichtet. Ob die Eindeutschung von SHA so ideal ist, sei mal dahingestellt. Und: SHA-Hashfunktion, secure hash algorithm hash function - wozu zweimal "hash"? Das ist ja fast schon ein LCD-Display ,-) --wdwd 15:57, 25. Aug 2006 (CEST)

Oje, wenn man keine Ahnung hat: Links können verbogen werden und sind sicher kein tragfähiges Argument, um ein blödsinniges Lemma zu behalten. Ob die Eindeutschung ideal ist sei nicht dahingestellt, sondern das ist genau das Thema dieser Diskussion. Die Rede war im OP von SHA-Hashfunktionen nicht von SHA-Hashfunktion. Es gibt bekanntlich mehrere SHA-Varianten. Daher ist die Analogie zum LCD-Display sinnfrei, denn es ginge um die Hashfunktionen mit der Familienbezeichnung SHA. Es gibt ja bekanntlich auch noch andere Hashfunktionen. Die Bedeutung Sicherer Hash-Algorithmus für die Bezeichnung "SHA" zu verbreiten, das ist jedenfalls Quatsch auf Bildzeitungsniveau und daher nichts anderes als Legendenbildung. Und dafür ist die Wikipedia eigentlich nicht gedacht. 217.81.104.92 21:45, 25. Aug 2006 (CEST)

Das Lemma stellt die deutsche Übersetzung der englischen Bezeichnung für einen bestimmten Hash-Algorithmus dar und bezieht sich meines Verständnisses nicht auf die gesamte Menge aller sicheren Hash Algorithmen sondern genau auf einen einzigen: Den SHA. Die unterschiedlichen SHA-Varianten inkludiert. Die Eindeutschung von "Eigennamen" kann fragwürdig sein. Konkret ist die Eindeutschung bei diesem Lemma deswegen kein besonderes Thema, da die englischen Begriffe bzw. Abkürzungen angelegt sind und als #redirect auf diesen Artikel verweisen. Es wäre nur ein Umkopieren des Inhaltes auf einen jetzigen #redirect-Artikel, und den jetzigen Artikel in ein #redirect zu verwandeln. Das sind minimale Details und eher ein typischer Streit um Kaisers Bart. Und secure hash algorithm hash function als Bezeichnung ist auf gleichen Niveau wie liquid crystal display display. --wdwd 10:12, 26. Aug 2006 (CEST)

Article about ONLY those secure hash functionsssssss that belong to the family NAMED: SHA -> oder mit anderen Worten: Entweder Du kannst es tatsächlich nicht verstehen, oder Du willst es bloss nicht verstehen. Ist aber eigentlich (im Vergleich zum Rest der Kryptografie) garnicht kompliziert... Mit dem Bart hast Du aber dennoch recht: Dokumentiert ist die Schwachsinnigkeit des Lemmas ja jetzt an dieser Stelle hinreichend. Der ambitionierte Leser wird es also mitbekommen. Das reicht mir. Um nochmal auf die Frage des OPs zu antworten: Nein, natürlich ist dieser merwürdige Eindeutschungsversuch nicht verbreitet (und es ist wie erwähnt eigentlich nicht die Aufgabe von Wikipedia dieses zu ändern). 217.81.112.82 00:04, 27. Aug 2006 (CEST)

Natürlich ist der Artikel über Redirects zu finden, von daher kann ich das Argument verstehen, eine Diskussion über das Lemma wäre überflüssig.

Aber ich sehe auch keinen Grund darin, dieses Lemma zu behalten (außer daß die Umstellung Arbeit bedeutet), denn wie die IP schon schreibt, ist diese Bezeichnung unüblich. Durch das Lemma und den Einleitungssatz wird diese Bezeichnung jedoch sogar verbreitet und vorangetrieben. Wie ich oben schon schrieb, würde ich unter dem Titel sogar einen anderen Artikel erwarten (aber das kann an mir liegen). --jailbird 12:09, 27. Aug 2006 (CEST)

In der Einleitung wird die Bit-Länge des primären Vertreters SHA-1 nur am Rande erwähnt. Dies sollte deutlicher sein. (nicht signierter Beitrag von 178.191.2.60 (Diskussion) 09:48, 27. Mai 2011 (CEST))

Sicherheitslücken

Erneut finden sich hier schwammige Hinweise auf Sicherheitslücken, die vermeintlich 2006 veröffentlicht wurden. Was ist darüber tatsächlich bekannt. Sind verschiedene Nachrichten M, M' mit sha1(M)=sha1(M') bekannt oder handelt es sich nur um Gerüchte.

Naja, es handelt sich wohl wieder einmal um haltlose Spekulationen. Ein Link auf die entsprechende Meldung bei Heise ist ja ok, aber diese ausufernden Spekulation sollten wirklich etwas gekürzt werden. 84.169.206.53 11:43, 15. Nov. 2006 (CET)

Ein gewisser Benutzer:P._Birken scheint anderer Meinung zu sein. Eine Begründung für seine ständigen Reverts gibt es jedoch offenbar nicht. 84.169.206.53 11:53, 15. Nov. 2006 (CET)

Ich finde es auch nicht nett, wenn trotz Deiner Aufforderung zur Diskussion in den Änderungskommentaren nicht darauf eingegangen wird. Ich finde auch, daß im Zweifel lieber etwas weniger im Artikel stehen sollte als nicht Belegtes. Interessant ist allerdings der Kommentar Revert, ich dachte nach der Disku auf Gunthers Seite waer alles geklaert? Diese Diskussion konnte ich nicht finden, wo steht die? --jailbird 16:32, 15. Nov. 2006 (CET)

Benutzer Diskussion:Gunther#Diskussion:Wasserstoff --Gunther 16:46, 15. Nov. 2006 (CET)

Ach so, ich dachte es wurde dort dieser Artikel diskutiert, aber es ging nur um den Benutzer. Zum Verhalten hier muß ich sagen, daß sich weder die IP noch P. Birken mit Ruhm bekleckern. Geht es hier wirklich darum, daß ein unter zwei Benutzernamen gesperrter Teilnehmer keine Änderung machen darf? D.h. ein anderer User würde mit dem gleichen Edit durchkommen? --jailbird 17:03, 16. Nov. 2006 (CET)

Das Argument von Fsswsb ist ja, dass die Probleme nicht belegt seien. Das ist falsch, wie du im Artike leicht haettest sehen koennen. Was wieder beweist: jede Diskussion mit oder ueber ihn ist reine Zeitverschwendung. --P. Birken 17:10, 16. Nov. 2006 (CET)

Dieses gegenseitige Rumgerevertiere bringt doch nichts. Meines Erachtens ist die Datenlage zumindest für die 2006 vorgebrachten Angriffsszenarien auch etwas dünn (ausser der auch von Heise gebrachten Meldung) und persönlich wäre ich zumindest für eine andere Formulierung. Aber könnten wir nicht vielleicht die für die Asiacrypt 2006 (Anfang Dezember) angekündigte wissenschaftliche Publikation der IAIK der TU-Graz abwarten und den Artikel bis dahin einfach so lassen? --jailbird 13:43, 18. Nov. 2006 (CET)

Mittlerweile ist der Artikel gesperrt. Was dort über die vermeintlichen Schwächen des Algorithmus steht sind aber weiterhin nur ziemlich haltlose Spekulationen. Eine seriös wirkende Darstellung zu den "Schwächen" habe ich [[1]] gefunden. Es bleibt aber wohl bis auf weiteres dabei, dass bisher keine kollidierenden Nachrichten mit gleichem SHA-1-Werten berechnet wurden. Da selbst solche Kollision nur sehr bedingt die Sicherheit bestehender Anwendungen gefährden, kann der SHA-1 zumindest nicht als ein reales Sicherheitsrisiko betrachtet werden.

Bullshit im Artikel

"Mit SHA-384 und SHA-512 können (theoretisch) Daten bis zu einer Größe von 2128 Bit verarbeitet werden. In der Praxis sind Dateien mit mehr als 264 Bit jedoch unrealistisch"

Was soll denn dieser Bullshit? Die Digestgröße hat nichts mit der maximalen Dateigröße zu tun die verarbeitet werden kann! 89.59.121.223 20:41, 30. Aug. 2007 (CEST)

ACK -- damage 08:42, 6. Sep. 2007 (CEST)

NAK -- Man kann durch die SHA-Algorithmen beliebig viele Daten durchpumpen, aber ... am Ende wird die Nachrichtenlänge codiert, und wenn dafür nur 64 bzw. 128 Bit reserviert sind, geht halt nicht mehr. --RolandIllig 08:36, 19. Jun. 2008 (CEST)

Kollisionsfreiheit in HASHs?

Es soll praktisch unmöglich sein, zwei verschiedene Nachrichten mit dem gleichen SHA-Wert zu finden. Dieses wird auch als Kollisionsfreiheit bezeichnet. Ob SHA-1 dieser Anforderung genügt, kann nicht sicher gesagt werden, da im Sommer 2006 eine wesentliche Schwäche dieses Algorithmus entdeckt und publik gemacht wurde. Grundsätzlich sollte SHA-1 daher nicht mehr in neuen Entwicklungen als sicherer Hash-Algorithmus vorgesehen werden.

Soweit ich weiß, ist KEIN Hash Kollisionsfrei, das liegt einfach daran, das es unendlich viel Eingabe aber nur x Byte Ausgabe. Das paßt per se nicht. Oder ist hier irgendwas anderes, ehr theoretisches gemeint?

Natürlich hat jede Hash-Funktion Kollisionen, allerdings sollte es für kryptographische Hashfunktionen praktisch unmöglich sein, diese mit weniger Berechnungen als den jeweiligen theoretischen Obergrenzen zu bestimmen. (nicht signierter Beitrag von 129.13.186.2 (Diskussion | Beiträge) 11:13, 20. Jun. 2009 (CEST))

Ein anderer erwähnenswerter Punkt wäre das es ein BOINC-Projekt gibt was SHA-1 Kollisionen sucht: http://boinc.iaik.tugraz.at/sha1_coll_search/ Bei dem Projekt Hash-Clash wurden ja mehrere MD5 Kollisionen gefunden...

Die Diskussion bringt zwei Begriffe durcheinander, nämlich "kollisionsfrei" und "fälschungssicher". Kollisionsfrei bedeutet, dass bei zufällig ausgewählten Nachrichten M und N die Wahrscheinlichkeit für den Fall Hash(N)=Hash(M) in der Nähe von 1/2^k liegt, wenn k die Anzahl der Bits im Output ist. In diesem Sinn sind alle derzeit verwendeten Algorithmen als "kollisionsfrei" anzusehen. Fälschungssicher bedeutet das Gleiche, allerdings mit sehr sorgfältig und absichtlich ausgewählten Nachrichten. Und da liegt der Hase im Pfeffer: MD5 ist inzwischen vollständig gebrochen, bei anderen gibt es Ansätze dazu. Um die Auswirkungen auf die Verwendung zu beurteilen, muss man sich aber ein wenig tiefer mit der Sache beschäftigen, als das hier im Diskussionsteil möglich ist. --Gbrands 08:25, 11. Feb. 2010 (CET)

Begrenzung der daten?

Die Begrenzung auf Daten mit maximal 264 − 1 Bit hat keine praktische Relevanz (264 = 18.446.744.073.709.551.616).

is damit die dateigröße der zu hashenden datei gemeint?? wenn ja, dann könnte (rein theoretisch) diese begrenzung in zukunft mal ne praktische relevanz haben. OK, ich geb zu 2048 PetaByte, is nich grad ne kleine Datei nur so rein theoretisch... aja, wie ich auf die 2048 komme? ausgerechnet...

• 18.446.744.073.709.551.616 / 8 (da 8bit = 1 byte)
• /1024 (in KB)
• /1024 (in MB)
• /1024 (in GB)
• /1024 (in TB)
• /1024 (in PB)

alles natürlich unter der vorraussetzung, dass es wirklich um die dateigröße der zu verarbeitenden daten geht^^ greez Mihawk90 17:54, 6. Nov. 2007 (CET)

is damit die dateigröße der zu hashenden datei gemeint?? => Jein. Es geht um die Länge der Eingangsdaten. Handelt es sich dabei um eine Datei, dann kann man das mehr oder weniger mit der "Dateigrösse der zu hashenden Datei" gleichsetzen. Wird in Zweierpotenzen gerechnet (so wie du das getan hast), ist es insbesondere bei so grossen Einheiten wichtig, zwischen SI- und Binärpräfixen zu unterscheiden, siehe den Artikel Byte. Die Angabe der 2 EiB habe ich in den Artikel eingebaut. --Mc-404 12:55, 10. Sep. 2008 (CEST)

Neues Unterkapitel SHA-3?

Momentan ist ja der Wettbewerb für die Nachfolge von SHA-2 am laufen. Eine Erweiterung des Artikels darum wäre durchaus angebracht.

Links dazu: http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo http://www.heise.de/newsticker/Hash-Algorithmus-MD6-aus-SHA-3-Wettbewerb-zurueckgezogen--/meldung/141464 (nicht signierter Beitrag von 213.144.129.134 (Diskussion) 14:43, 2. Jul. 2009 (CEST))

ich bin dagegen und wuerde eher SHA-2 auslagern, siehe unten. --Mario d 21:04, 3. Okt. 2012 (CEST)

Franz/Frank/Null

Ist es sinnvoll, für jede SHA-Familie das Beispiel nochmal zu wiederholen? Ich denke es genügt, bei SHA-1 zu zeigen, dass eine kleine Änderung im Text eine große Änderung im Hashwert bewirkt. Hat der Hashwert des leeren Strings noch einen Nutzen außer zu zeigen, dass ein leerer String keinen leeren Hash o.ä. erzeugt? Wenn nicht, würde es da auch genügen, den einmal zu zeigen. Stattdessen sollte man bei den weiteren SHA-Abschnitten die Besonderheiten/Einsatzzwecke der einzelnen Varianten näher beschreiben, und wenn es da nicht genug zu sagen gibt, sollte man überdenken, ob wirklich Unterabschnitte für jedes SHA-XYZ nötig sind oder ob nicht eine Aufzählung genügt. --IdS 10:34, 26. Sep. 2010 (CEST)

Mich hatte diese erwähnte Beispieldopplung eher verwirrt als erhellt. Für SHA-256 und die folgenden Algorithmen wäre es bestimmt übersichtlicher, wenn sie entfallen. (nicht signierter Beitrag von 62.220.3.220 (Diskussion) 11:33, 12. Jul 2011 (CEST))

Toter Link

Der Link "Pressemitteilung der GI Fachgruppe Krypto: Hashfunktion SHA-1 offenbar gebrochen" ist tot. Im GoogleCache ist nichts und auch nicht im WebArchive. Weiß noch jemand um was es in dem Artikel gibt? (Zumal er ja nur "offenbar" gebrochen ist) PS: Wieso ist die Seite gesperrt? --80.139.121.134 02:23, 10. Dez. 2011 (CET)

danke fuer den hinweis. die sperre hatte vor ein paar jahren ein admin ohne zeitliche beschraenkung gesetzt und vergessen, sie wieder aufzuheben. das wurde mittlerweile nachgeholt. den toten link habe ich entfernt. --Mario d 15:51, 10. Dez. 2011 (CET)

SHA-2 auslagern?

da es mMn keinen sinn macht, den sehr unterschiedlichen SHA-3 hier auf die seite zu packen, waere ich dafuer, SHA-2 auszulagern und jeder version einen eigenen artikel zu spendieren. --Mario d 21:02, 3. Okt. 2012 (CEST)

wie schon auf der SHA-3 Seite angesprochen: ich bin auch dafür. spätestens wenn Pseudocode dazu kommt wird es unübersichtlich! --Exploide (Diskussion) 19:20, 7. Sep. 2013 (CEST)

Wenn ich das richtig sehe, sind sich SHA-1 und SHA-2 algorithmisch sehr ähnlich, von daher glaube ich, dass sie auch auf einer Seite bleiben können. --Sepp (Diskussion) 07:57, 4. Okt. 2012 (CEST)

SHA-2 ist eine weiterentwicklung von SHA-1, aber "SHA-2 includes a significant number of changes from its predecessor, SHA-1" (laut en.WP). ich sehe nicht, wie man die beiden sinnvoll zusammen beschreiben koennte (wird ja im moment auch nicht gemacht), die analyse der beiden wird auf jeden fall getrennte abschnitte brauchen, pseudocode ebenfalls. im endeffekt haben wir dann zwei artikel auf einer seite. --Mario d 13:17, 4. Okt. 2012 (CEST)

Na gut, da hab ich wohl das Wort „Varianten“ hier zu wörtlich genommen und ziehe meinen Einwand zurück. --Sepp (Diskussion) 14:32, 4. Okt. 2012 (CEST)

Was für die Auslagerung spricht, wäre, dass dann jede Version ihre eigenen Einzelnachweise und Weblinks bekommen kann.--Lex parsimoniae (Diskussion) 00:00, 8. Okt. 2012 (CEST)

SHA alias SHA-0

Hallo,
im Artikel ist die Rolle der ersten Implementierung von SHA (später als SHA-0 bezeichnet) schwer zu erkennen.
Vielleicht wäre ein weiterer Abschnitt angebracht?
Grüße --213.23.174.67 13:51, 5. Feb. 2013 (CET)

Defakto spielte SHA-0 nie eine Rolle. Der wurde gebrochen bevor er sich verbreiten konnte. Allerdings sollte man das wohl irgend wie unterbringen. --Fabiwanne (Diskussion) 14:44, 14. Feb. 2014 (CET)

So habe das mal klarer ausgedrückt. Bin aber immer noch nicht wirklich mit der Struktur zufrieden. Vielleicht guckt nochmal einer drüber --Fabiwanne (Diskussion) 14:58, 14. Feb. 2014 (CET)

Charaktereigenschaften

Idee von meiner Seite, das die Eigenschaften eines Algorithmen (Beispiele: Stärke, Ein-, Ausgabegrößen, Typ, von wann etc.) in einer kleinen Tabelle rechts des Textes, ähnlich [2] einbaut werden. Bitte Kommentare!

Halte ich für eine sehr gute Idee. Was sollte denn in der Tabelle stehen? nur die Hashgrößen oder auch z.B. die benötigte Zeit zum verschlüsseln knacken, etc? Ich meine desto mehr desto besser. --Kockmeyer 08:19, 22. Mär. 2007 (CET)

Algorithmus

Hallo! Wenn jemand den SHA-1 SHA-256 etc Algorithmus erklären könnte, bitte. Das Bild hier allein ist nicht aussagekräftig genug. Für mich ist es nämlich immernoch unklar wie aus einer beliebigen Größe Daten eine feste Länge (160Bit oder so) wird. Wenn jemandem noch Anwendungen einfallen, die tatsächlich im Gebrauch sind, dann könnte man die dem Artikel hinzufügen

Aus einer beliebig langen Eingabe kann ganz einfach eine Ausgabe fester Länge werden. Die Quersumme ist ein Beispiel dafür. --RolandIllig 08:43, 19. Jun. 2008 (CEST)

ssha

Im Athentifizierungs-Bereich ist des öfteren von SSHA die Rede, da unter diesem Lemma allerdings nix zu finden war, währe wohl eine Umleitung zu (hier) sinnvoll. bei SSHA handelt es sich nämlich um ein (z.B. für Passwörter verwendetes) Verfahren, bei dem zusätzlich zum zu hashenden Wert ein sogenantes Seed (vgl. salt bei crypt) eingebracht wird, davon wird anschließend der SHA-1 gebildet.

Datum zur Heise-Meldung

Da momentan schonwieder Geruechte um eine weitere Reduktion der des Kollisionsgenerierungsaufwandes umhergeistern, waere das Datum zu der zweiten Heise-Meldung in den Links recht nueztlich. Leider ist der Artikel gesperrt, ich kanns also nicht selbst hinzufuegen. Das Datum waere 19.08.2005.

---

217.235.25.111 10:53, 6. Sep. 2007 (CEST)

Vorschlag für den neuen Kollisionsangriff vom April 2009

Folgenden Text zum neuen kollisionsangriff wollte ich in den Artikel einfügen, konnte es aber nicht, weil ich kein Wikipedia-Account hab:

"Im April 2009 wurde von Cameron McDonald, Josef Pieprzyk und Phil Hawkes auf der Konferenz Eurocrypt ein Kollisionsangriff auf SHA-1 vorgestellt, welcher den Aufwand weiter auf 2⁵² Berechnungen reduziert."

"== Weblinks ==" "=== zu den Schwächen von SHA ===" "http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf" (nicht signierter Beitrag von 129.13.186.2 (Diskussion | Beiträge) 11:13, 20. Jun. 2009 (CEST))

Pseudocode

Kann irgendjemand die 'magic numbers' im Pseudocode erklaeren? Im "FIPS PUB 180-2" steht nichts dazu drin.

Jann.poppinga 10:10, 18. Feb. 2011 (CET)

Distributed Computing Projekt in Graz

Seit 12. Mai 2009 ist das Projekt auf Grund zu geringem Fortschritts pausiert.

siehe http://de.wikipedia.org/wiki/SHA-1_Collision_Search_Graz (nicht signierter Beitrag von 46.206.89.188 (Diskussion) 21:41, 14. Jun. 2011 (CEST))

SHA1 auslagern?

SHA1 auslagern? -- Live Long and Prosper Motte001 • Diskussion • 18:44, 15. Apr. 2016 (CEST)

SHA-1 is a Shambles

• https://sha-mbles.github.io/ (nicht signierter Beitrag von 134.19.179.147 (Diskussion) 21:59, 7. Jan. 2020 (CET))