Diskussion:Secure Hash Algorithm
Das Archiv dieser Seite ist unter Archiv zu finden.
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)
- 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)
- 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)
- 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)
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)
- 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)
- 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)
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.
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.
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)
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)
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)
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 252 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))
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
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)
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