Diskussion:Hashfunktion/Archiv/1

message: Es geht mitnichten nur darum irgendwelche Texte zu verkleinern um sie besser vergleichen zu können. Es geht darum eine Datenstruktur aufzubauen in der die Schlüsselsuche eine Komplexität von O(1) hat - das findet sich leider nirgends in dem Artikel Erwähnung.
Du meinst einen Hashtable, hier reden wir aber ueber eine Funktion, die einen Hash berechnet. Du hast aber recht, dass es da einen Zusammenhang gibt. Ausserdem findet sie Anwendung in der Verschluesselung von Passwoertern.
Gruss
-- Sparti 22:08, 23. Mai 2005 (CEST)
thread_title:  Definition unvollständig 

message: Das bezweifele ich. Die Hash-Funktion ist surjektiv, und zusätzlich nicht injektiv. Das wäre ja auch ein Unding. Ich würde es trotzdem lieber erst hier diskutieren, bevor ich das im Artikel ändere.
--84.130.76.132 19:09, 29. Sep 2005 (CEST)
replies: text: Antwort: Alles persönliche Meinung: Injektiv bringt nun wirklich nichts. Surjektiv sollte die Hashfunktion im Idealfall sein. Aber es ist keine Voraussetzung. --Squizzz 19:27, 29. Sep 2005 (CEST)
replies: text:  Surjektivität ist Voraussetzung um eine "gute" Hash-Funktion zu haben. Ansonsten würde ich ja nur Kollisionen haben bzw. es gäbe einen Isomorphismus zwischen Quell- und Zielmenge. Das macht dann eine Hash-Funktion in der Anwendung nutzlos. --84.130.76.132 23:34, 29. Sep 2005 (CEST)
replies: text:  Wieso sollet man (viele) Kollisionen haben, wenn die Funktion nicht Surjektiv ist?? -- sparti 07:52, 30. Sep 2005 (CEST)
replies: text:  Stimmt. Ich sollte erst überlegen und dann schreiben. Gerade durch Surjektivität erreiche ich die Gefahr von Kollisionen. Aber gerade die Surjektivität ist der Sinn einer Hash-Funktion. --84.130.81.51 16:58, 30. Sep 2005 (CEST)
replies: text:  Das ist zwar schon richtiger, aber immer noch nicht ganz korrekt. Bei Indexverfahren moechte ich natuerlich keine Kollisionen, sie lassen sich nur in der Praxis nicht vermeiden, da irgendwann die Anzahl der Elemente groesser ist, als der Wertebereich. In der Kryptographie hingegen moecht ich auf keinen Fall Injektivitaet. -- Gruss sparti 21:55, 30. Sep 2005 (CEST)
replies: text:  "Eine Abbildung h: K \rightarrow S  heißt Hashfunktion, wenn |K|\geq\ |S|  gilt." Das schließt für mich Injektivität aus, das für Injektivität gelten muss |K| < |S| aber ich lasse mich gerne korrigieren! (nicht signierter Beitrag von 87.176.217.128 (Diskussion) 14:58, 23. Mai 2010 (CEST)
replies: text:  Falsch. Beispiel für eine injektive Funktion die deine Bedingung nicht erfüllt: die Identität. --Chire 15:06, 24. Mai 2010 (CEST)

text:  Eine nicht-surjektive Hashfunktion lässt Buckets leer. Dadurch steigt zwangsläufig die Gefahr von Kollisionen, wenn der Füllgrad der Tabelle steigt. Insbesondere ist ein Füllgrad von 100% ohne Kollisionen dann unmöglich. Ist deine Funktion injektiv sind Kollisionen ausgeschlossen - daraus folgt in diesem Falle, dass deine Tabelle nie zu 100% gefüllt sein kann; das reduziert natürlich die Effizient ein wenig. Optimal wäre eine injektive und gleichzeitig surjektive Hashfunktion, wenn du vollständige Daten hast. --Chire 15:06, 24. Mai 2010 (CEST)

text: Das Geburtstagsparadoxon passt hier nicht. Wenn du die Personen nach Geburtstag in der Tabelle ablegst, verwendet du bereits eine nicht-injektive Funktion (nämlich die Abbildung auf den Geburtstag!). Egal mit welcher perfekten Hashfunktion du das danach kombinierst, die Verkettung ist nicht injektiv! - sprich: wenn der Schlüssel bereits nicht eindeutig ist, brauche ich nicht nach einer perfekten Hashfunktion suchen. --Chire 15:06, 24. Mai 2010 (CEST)

text: Hilfestellung zur Injektivität, Surjektivität und Bijektivität, sowie Isomorphismus: Eine Abbildung f: A \rightarrow B ist injektiv, wenn das Urbild f^{-1}(b) eines Elementes b der Zielmenge B eindeutig ist. Sie ist surjektiv, wenn es kein b \in B gibt, für das b \not \in f(A) gilt. Mit anderen Worten: Das Bild von f ist gleich der Zielmenge. Formal: f(A) = B Zuletzt: f ist bijektiv genau dann, wenn sie sowohl injektiv als auch surjektiv ist. Existiert eine bijektive Abbildung h zwischen Strukturen G und H, dann sind diese zueinander isomorph.--84.58.151.165 02:14, 16. Jan 2006 (CET)

text: P.S. in realen Implementierungen wird man oft mehr als eine Hashfunktion verwenden. Typischerweise bildet die erste Hashfunktion die Eingabedaten auf einen Integer-Wert ab. Anschließend wird dieser Integer-Wert "gekürzt" so dass er für die gewählte Tabellengröße passt (die meisten werden keine Hashtabelle mit 2^32 Buckets anlegen wollen!). Dies geschieht meist durch Modulo (gerne mit einer Primzahl) bzw. durch ein logisches "und" (bei Zweierpotenzen). Dieser letzte Schritt ist offensichtlich nicht injektiv. Die Suche nach einer perfekten Hashfunktion in so einer Implementierung ist dann natürlich nicht umbedingt sinnvoll. (Mal davon abgesehen, dass es auch für den ersten Schritt oft gar keine injektive Funktion geben kann) --Chire 15:06, 24. Mai 2010 (CEST)

text: In der Kryptographie ist das nicht unerwünscht. sie sollen nur nicht vorhersagbar sein! Du darfst nicht nur an Hashtabellen denken! --87.174.53.81 00:05, 15. Jun. 2011 (CEST)
thread_title:  Hash-Funktion injektiv? 

message: Wäre es nicht genauer, von bekannten Typen von Hashfunktionen zu sprechen? Auch könnte die Auflistung dann durch weitere wichtige Typen ergänzt werden: universelles Hashing, perfektes Hashing und offene Adressierung. Die dazugehörigen Artikel existieren meines Wissens auch noch nicht.--Paschelino 02:23, 16. Jan 2006 (CET)
thread_title:  Bekannte Hashfunktionen 

message: Es wäre schön, wenn noch auf internes und externes Hashin eingegangen werden könnte! --Master-2000 00:44, 20. Feb 2006 (CET)
thread_title:  internes / externes Hashing 

message: Ist die Zufälligkeit wirklich ein Kriterium einer guten Hashfunktion?
Für mich steht der Begriff im Gegensatz zur Reproduzierbarkeit der Ergebnisse. Außerdem scheint der Begriff im Gegensatz zur dazugehörigen Erläuterung zu stehen.
Zitat aus Zufall: "Zufall ist dann vorhanden, wenn nur aufgrund der Anfangsbedingungen keine Aussage darüber zu machen ist, was geschieht, bzw. wenn bei exakt gleichen Ausgangsbedingungen nicht immer das gleiche passiert." --84.190.84.32 08:53, 7. Mär 2006 (CET)
replies: text: Zufälligkeit und Reproduzierbarkeit schließen einander nicht aus: Pseudozufallszahl --Stepwiz 23:25, 15. Dez. 2006 (CET)
thread_title:  Zufälligkeit 

message: Hallo,
was ist mit dem Artikel los? Der gesamte Bereich Definition einer Hash-Funktion ist - oder scheint zumindest - sehr schräg und undurchsichtig, ja fast fehlerhaft formatiert, vor allem die vorformatierten Bereiche. Wer auch immer durch die Formatierung hindurchsteigt, sollte sie entweder klarer gestalten, oder auf jeden Fall klar machen, was sie zu bedeuten hat. --Zaap 18:15, 19. Apr 2006 (CEST)
replies: text: Wie es aussieht geht das auf Probleme mit der math-Funktion zurück. Kennt sich jemand damit aus? --Zaap 19:09, 19. Apr 2006 (CEST)
replies: text:  Mir ist nicht ganz klar, was Du meinst. Manche Formeln müssen (derzeit) als Bilder dargestellt werden und haben deshalb eine feste Größe, die je nach verwendetem Browser nicht zum Fließtext passt (meistens sind sie zu groß). Vielleicht gibt es demnächst eine Darstellung mittels MathML, aber viele Browser unterstützen das noch nicht ausreichend, der Default wird also wohl erst einmal wie bisher sein.--Gunther 19:15, 19. Apr 2006 (CEST)
replies: text:  Was ich meine habe ich einfach mal in Form eines - verkleinerten - Bildes auf meinen Webspace hochgeladen (jpg, 112 KB). Das sehe ich sowohl in Opera als auch im IE. --Zaap 20:13, 19. Apr 2006 (CEST)
replies: text:  Es gab im Verlauf des heutigen Tages ernsthafte Probleme mit den Servern. Dass solche Probleme nicht wieder verschwinden, liegt meistens am Browser-Cache, versuch' mal F5, Umschalt+F5, oder den Cache zu leeren. Hilft das?--Gunther 23:20, 19. Apr 2006 (CEST)

text:  Jop, heute ist alles wieder im Grünen. Danke! --Zaap 14:09, 20. Apr 2006 (CEST)
thread_title:  Strukturprobleme? 

message: Hallo, ich würde gerne die Schreibweise der Hash*-Artikel vereinheitlichen. Sowohl innerhalb dieses Artikels wie auch in anderen Artikeln ist die Verwendung uneinheitlich. Dabei bin ich mir der Tatsache bewusst, dass prinzipiell wohl beide Schreibweisen regelkonform sind, aber ebenso klar sollte sein, dass eine einheitliche Schreibweise angestrebt werden sollte. Weitere Begriffe sind in diesem Kontext:
*Hashtabelle
*Hashwert
*Hashverfahren
*Hash-Algorithmus
Ich würde hier die Begriffe Hashfunktion, Hashtabelle, Hashwert und Hashverfahren jeweils als ein Wort ohne Bindestrich schreiben. So sollten dann auch die Hauptartikel heißen, die jeweils anderen Schreibweisen werden dann zum Redirect (auf Erhalt der Historie werde ich achten). Hash-Algorithmus erscheint hier in der Bindestrich-Schreibweise angebrachter, da Hashalgorithmus doch ein wenig vielsilbig wird. Ansonsten bin ich auch mit jeder völlig einheitlichen Schreibweise einverstanden (alles ohne/alles mit Bindestrich). Was meint ihr? Mkleine 17:43, 28. Mai 2006 (CEST)
replies: text: Der Duden sieht die Sache offiziell (iirc) so: es ist nach neuer Rechtschreibung gleichwertig, sollte aber innerhalb eines Textes einheitlich sein. Nach alter Schreibweise muss ein Bindestrich stehen. Sehe keinen Bedarf, verschiedene Texte zu vereinheitlichen (Wikipedia hat keine Hausschreibweise, Konsistenz ist in Wikipedia:Rechtschreibung nur innerhalb eines Artikels gefordert). Es spricht natürlich auch nichts dagegen. Dann musst du aber jeweils auch die Artikel aufs passende Lemma verschieben. igel+- 12:16, 29. Mai 2006 (CEST)
replies: text: Ich sehe das soweit ähnlich, mal sehen, ob sich hier noch jemand zu Wort meldet. Idealerweise nimmt man bei getroffener Entscheidung die Schreibweise irgendwann in einen Bot auf, der das dann regelmäßig prüfen kann. Grüße Mkleine 13:22, 29. Mai 2006 (CEST)
replies: text: Sowas wird hier nicht basisdemokratisch entschieden, zumal wir ja nicht parallel auf allen Seiten diskutieren können, die mit Hash beginnen. Du solltest es, wenn du glaubst, es wird der Menschheit nützen, mutig angehen und hoffen, dass du keinen rv fängst. Am besten tust du als Beschreibung der Änderung einen Verweis auf diese Diskussionsseite. igel+- 17:35, 29. Mai 2006 (CEST)
replies: text: Ja Igel. Mal so am Rande: Hast du eigentlich mal bemerkt, seit wann ich hier mitarbeite? Auch wenn es vielleicht gut gemeint ist - den Hinweis auf Links wie den oben genannten brauche ich wirklich nicht. In manchen Regionen sagt man auch Don't teach your grandma how to suck eggs. Ansonsten noch viel Spaß. Mkleine 22:50, 29. Mai 2006 (CEST)
replies: text: Welche Regionen sind das denn? igel+- 00:30, 30. Mai 2006 (CEST)
replies: text: Englischsprachige ... Mkleine 00:32, 30. Mai 2006 (CEST)

text: Ich habe mal in den einschlägigen deutschen Kryptotexten unter Hashfunktion nachgeschaut (Buchmann, Beutelspacher, dt. Übersetzung vom Schneier). Alle schreiben ein Wort ohne Bindestrich. Insofern halte ich es dringend für erforderlich, die Schreibweise hier entsprechend anzupassen und keine Sonderweg zu gehen (der meinem Sprachgefühl auch widerspricht). Grüße vom Zahlendreher 08:07, 15. Jun 2006 (CEST)
thread_title:  Hashfunktion vs. Hash-Funktion 

message: Habe die Redundanz beendet und Hash-Wert weitgehend überführt. Hier die alten Beiträge:
* 2006-11-15 10:47 (diff) P. Birken (Revert)
* 2006-11-15 10:46 (diff) 84.169.206.53 (anon) (unbegründetes Revert zurückgenommen)
* 2006-11-15 09:23 (diff) P. Birken (Revert)
* 2006-11-15 09:01 (diff) 84.169.206.53 (anon) (/* Bekannte Hash-Funktionen */)
* 2006-11-15 09:01 (diff) 84.169.206.53 (anon) (/* Zusätzliche Forderungen für kryptographisch sichere Hash-Funktionen */)
* 2006-11-15 08:59 (diff) 84.169.206.53 (anon) 
* 2006-09-14 11:06 (diff) YourEyesOnly (rv POV)
* 2006-09-14 11:05 (diff) 84.175.6.17 (anon) (/* Praktische Anwendung */)
* 2006-09-10 00:44 (diff) 85.177.194.124 (anon) (/* Praktische Anwendung */)
* 2006-08-25 21:08 (diff) 84.145.140.146 (anon) (Unnachvollziehbare Ausschweifung zu Hashttabellen)
* 2006-07-10 11:53 (diff) (minor) Supaari (redir auflösung im Redundanztext Baustein)
* 2006-07-05 14:29 (diff) Siehe-auch-Löscher (Überlappung, bitte Diskussion beachten unter :de:Wikipedia:Artikel zum gleichen Thema)
* 2006-06-22 16:29 (diff) 81.217.78.114 (anon) (/* Praktische Anwendung */)
* 2006-06-21 08:55 (diff) Priwo (revert wegen Vandalismus)
* 2006-06-21 08:46 (diff) 80.145.87.187 (anon) (/* Praktische Anwendung */)
* 2006-06-21 08:45 (diff) 80.145.87.187 (anon) (/* Praktische Anwendung */)
* 2006-06-06 21:02 (diff) 84.56.202.68 (anon) (/* Praktische Anwendung */)
* 2006-05-30 08:13 (diff) 84.177.21.126 (anon) 
* 2006-04-02 13:46 (diff) 84.182.151.124 (anon) (/* Praktische Anwendung */)
* 2006-02-07 10:33 (diff) 194.95.82.209 (anon) (/* Praktische Anwendung */)
* 2006-02-07 10:32 (diff) 194.95.82.209 (anon) (/* Praktische Anwendung */)
* 2006-01-28 21:26 (diff) (minor) Knallkopf (/* Siehe auch */  Hashtablle verlinkt)
* 2006-01-05 02:25 (diff) (minor) D (Änderungen von :de:Benutzer:84.58.34.109 rückgängig gemacht und letzte Version von :de:Benutzer:Elian wiederhergestellt)
* 2006-01-05 02:23 (diff) 84.58.34.109 (anon) (/* Siehe auch */)
* 2006-01-05 02:22 (diff) 84.58.34.109 (anon) (/* Praktische Anwendung */)
* 2006-01-05 02:21 (diff) 84.58.34.109 (anon) (/* Praktische Anwendung */)
* 2006-01-04 08:05 (diff) (minor) Elian (keine verlinkungen auf seiten im wikipedia-namensraum bitte)
* 2005-12-18 21:15 (diff) Dantor (Fingerprint)
* 2005-12-18 09:03 (diff) (minor) Priwo 
* 2005-12-17 13:03 (diff) 84.178.88.71 (anon) (/* Praktische Anwendung */)
* 2005-12-17 13:03 (diff) 84.178.88.71 (anon) (/* Praktische Anwendung */)
* 2005-10-22 16:40 (diff) (minor) H005 (lizensieren -> lizenZieren)
* 2005-09-28 09:09 (diff) (minor) Obersachse (+ru)
* 2005-08-30 14:27 (diff) (minor) RokerHRO (/* Praktische Anwendung */ ss->ß)
* 2005-08-30 14:21 (diff) (minor) Thomas Willerich (revert zu Version 09:35, 9. Aug 2005)
* 2005-08-30 13:26 (diff) 161.78.3.250 (anon) (/* Praktische Anwendung */)
* 2005-08-09 07:35 (diff) 141.24.112.75 (anon) (/* Praktische Anwendung */)
* 2005-07-23 13:18 (diff) (minor) AlexLehm (/* Praktische Anwendung */)
* 2005-07-23 12:43 (diff) AlexLehm (/* Praktische Anwendung */)
* 2005-07-23 12:38 (diff) AlexLehm (/* Praktische Anwendung */)
* 2005-07-19 19:12 (diff) Stern 
* 2005-06-30 07:29 (diff) (minor) Thomas Willerich (typos. wikify, +link)
* 2005-06-14 10:21 (diff) 84.135.76.46 (anon) 
* 2005-05-24 12:29 (diff) (minor) Udm (/* Praktische Anwendung */)
* 2005-05-24 12:29 (diff) (minor) Udm (/* Praktische Anwendung */)
* 2005-05-15 09:43 (diff) (minor) Priwo 
* 2005-05-14 18:18 (diff) Sparti (Anwendungen)
* 2005-05-14 15:16 (diff) (minor) Gunther (revert (mit P2P hat das rein gar nichts zu tun))
* 2005-05-14 15:13 (diff) 80.137.48.54 (anon) 
* 2005-05-09 07:04 (diff) MaxStrobel 
* 2005-05-08 08:48 (diff) (minor) Sparti (Datenschrott entsorgt.)
* 2005-05-08 07:44 (diff) Freexrf 
* 2005-04-20 12:17 (diff) (minor) Sparti (Link)
* 2005-03-28 13:25 (diff) (minor) Priwo (+kat +links)
* 2005-03-23 11:53 (diff) (minor) Gunther (linkfix :de:Skalare Variable)
* 2005-02-19 10:52 (diff) Eldred ("Verfahren" und anderes nach :de:Hash-Funktion verschoben)
* 2005-01-22 16:55 (diff) 80.129.136.253 (anon) (+ Verweis auf Prüfsumme)
* 2004-10-09 20:58 (diff) 194.230.21.17 (anon) 
* 2004-10-03 13:31 (diff) 194.230.202.103 (anon) 
* 2004-06-09 06:35 (diff) 134.109.132.159 (anon) 
* 2004-05-30 17:40 (diff) (minor) Timo Baumann (deutsche Bezeichnung nach N. Wirth: "Algorithmen und Datenstrukturen" hinzugefügt)
* 2004-04-22 08:20 (diff) 62.167.114.72 (anon) (Link)
* 2004-04-13 20:26 (diff) (minor) Anton 
* 2004-04-10 20:01 (diff) 213.168.72.241 (anon) 
* 2004-03-17 13:33 (diff) (minor) Michael.chlistalla 
* 2004-03-17 13:32 (diff) (minor) Michael.chlistalla 
* 2004-02-17 22:11 (diff) Head (-en:)
* 2004-02-03 06:47 (diff) Media lib (~link rep.)
* 2004-01-31 00:02 (diff) (minor) Anton (Querverweise ergänzt)
* 2004-01-29 16:37 (diff) Kku (wikifiz)
* 2003-09-09 21:30 (diff) HenrikHolke 
* 2003-08-30 04:42 (diff) (minor) ErikDunsing (typos)
* 2003-08-23 23:14 (diff) (minor) Jp (das "r" bei "Statischer Verfahren sind" entfernt)
* 2003-08-20 09:24 (diff) 194.230.228.215 (anon) ('eineindeutig' kann das ganze nicht werden; im Normalfall wird eine grössere Menge auf die kleinere Menge der Hashtabelleneintragindizes abgebildet.)
* 2003-07-07 10:07 (diff) 217.228.28.190 (anon) 
* 2003-01-25 20:17 (diff) (minor) Nerd (en:)
* 2003-01-25 14:00 (diff) (minor) Nerd (umform)
* 2002-11-26 16:34 (diff) (minor) Nerd (erw.)
* 2002-11-24 01:20 (diff) (minor) Ben-Zin (ß)
* 2002-11-21 09:54 (diff) 217.5.141.103 (anon) 
* 2002-11-21 09:53 (diff) 217.5.141.103 (anon) 
-- ReqEngineer Au weia!!! 11:15, 24. Dez. 2006 (CET)
thread_title:  Redundanz zu [[Hash-Wert]] 

message: Die folgende Aussage ist m. E. falsch: "Mit einem Hashcode werden z.B. Binärdokumente gekennzeichnet, um deren Authentizität beim Empfänger prüfbar zu machen, ohne den Inhalt des Dokuments selbst offen zu legen, etwa bei der verbreiteten MD5 Funktion." Zumindest in der Informatik versteht man unter Authentizität nicht nur, dass ein Objekt unverfälscht ist, sondern zudem auch den Nachweis der Quelle (siehe auch Authentizität). Eine Hashfunktion soll dagegen zunächst einmal die Integrität gewährleisten. Das gilt auch für MD5. Erst in Verbindung mit Verschlüsselung (beispielsweise als Digitale Signatur) wird auch die Quelle überprüfbar und damit Authentizität erreicht. 
Außerdem verstehe ich nicht, wieso der Einschub "ohne den Inhalt des Dokuments selbst offen zu legen" dort enthalten ist. Gibt es für diese Einschränkung einen Grund? Mir fällt nicht einmal ein Anwendungsfall ein, in dem die Integrität gewährleistet werden soll, obwohl auf die Inhalte nicht zugegriffen werden kann. --Freischlad 16:56, 20. Feb. 2008 (CET)
replies: text: Was man auf diese Weise machen kann und gemeint sein könnte, ist folgendes: Bevor Adam sich mit Bill über ein geheimes Thema unterhält, möchten beide sicherstellen, dass beiden tatsächlich die geheime Datei X vorliegt – und so verhindern, dass etwa geheime Informationen an uneingeweihte Außenseiter gelangen. Hierzu schickt Adam and Bill eine Challenge, etwa "Adam 2008-02-20 20:03:10", ebenso Bill an Adam etwa "Bill 2008-02-20 20:03:12". Beiden ist es möglich, Y = md5sum(X + "Adam 2008-02-20 20:03:10" + "Bill 2008-02-20 20:03:12") zu berechnen. Bill kann seinen Wert gefahrlos mitteilen und Adam kann anhand dessen sicherstellen, dass Bill tatsächlich X besitzt. Es wurde jedoch "keine" Information über X übermittelt.--Hagman 20:09, 20. Feb. 2008 (CET)
replies: text: Meines Erachtens beschreibt dies einen Message Authentication Code (MAC), der mit einer Hashfunktion gebildet wird. Notwendig dafür ist ein geheimer Schlüssel (die Datei X). Im RFC 2104 ist eine solche Verwendung als HMAC beschrieben (HMAC: Keyed-Hashing for Message Authentication). Ich würde also vorschlagen, den betroffenen Absatz entsprechend zu überarbeiten. --Freischlad 16:31, 6. Mär. 2008 (CET)
thread_title:  Authentizität durch Hashfunktion? 

message: Ich denke der Absatz aus dem Artikel beinhaltet einen Fehler:
"Außerdem gilt schwache Kollisionsresistenz (2nd-preimage resistance): es ist praktisch unmöglich für einen gegebenen Wert x ein davon verschiedenes x′ zu finden, das denselben Hash-Wert h(x) = h(x′) = y ergibt."
Für die Kryptographie ist denke ich starke Kollisionsresistenz gewünscht. Es sollen ja möglichst keine Kollisionen auftreten. Ich ändere das im Artikel. Bitte korrigiert mich, falls ich hier irgendeinen Kryptographiejargon falsch verstanden habe. Edit: Mir ist aufgefallen, dass sich die folgenden Absätze nicht deutlich voneinander unterschieden haben, daher habe ich sie entfernt. Die vorher verwendeten Begriffe "schwache Kollisionsresistenz (2nd-preimage resistance)" und "Beinahe-Kollisionsresistenz (near-collision resistance)" konnte ich in meinem Ersatz nicht unterbringen, da ich sie nicht kenne, und mir der Unterschied nicht klar ist. --Supaari mail 05:15, 1. Mai 2008 (CEST)
replies: text: Ich habe den Abschnitt neu geschrieben. Ich bitte um Verzeihung für die radikale Maßnahme, aber exakte Formulierungen sind hier von entscheidender Bedeutung. Ich hoffe, es sind keine Unklarheiten mehr vorhanden. Die Begriffe schwache und starke Kollisionsresistenz habe ich vermieden, da sie mir in der Literatur nicht begegnet sind. Wenn ich Supaari richtig verstehe, sind damit wohl Resistenz gegen den Zweites-Urbild- bzw. den Geburtstagsangriff gemeint, vielleicht kann das jemand, der die Begriffe kennt, hinzufügen. --Carsten Milkau 14:51, 22. Jul. 2009 (CEST)
thread_title:  Kriterien für kryptographisch sichere Hashfunktionen 

message: Die beiden Bezeichnungen sollten entweder einheitlich verwendet werden, also nur eine davon, oder wenigstens sollte klar sein, dass sie Synonyme sind. (nicht signierter Beitrag von 78.51.233.57 (Diskussion | Beiträge) 12:01, 29. Apr. 2010 (CEST)
thread_title:  Einheitliches Vokabular "Hashcode" / "Hashwert" 

message: Zitat: "Das Auffinden von Dateien aufgrund des Hashwertes ihres Inhaltes ist zumindest in den USA als Softwarepatent geschützt."
Gibt es dazu eine Quelle? -- 91.9.64.176 22:18, 19. Mai 2010 (CEST)
thread_title:  Softwarepatent - Quelle? 

message: zur begruendung meines reverts: der edit macht den satz sinnlos. die laenge des ausgabe ist immer definiert, nicht nur oft. die ausgabe kommt aus der zielmenge, nicht von ihr. "eingaben grosser definitionsmengen" ist mehrdeutig, die definitionsmenge ist nicht die eingabe. es heisst "etwas unterscheiden nach", aber "sich unterscheiden in/durch". --Mario d 16:10, 3. Jul. 2011 (CEST)
replies: text: Ich prgrammiere nicht immer mit Hashs, war auch der festen Meinung, dass "oft" weg muss, habe es aber wegen dem ">>typischerweise<< kleineren Zielmenge", was haarsträubend klingt wenn doch die Länge der Zeichenkette und damit auch Größe je nach Funktion fest definiert ist, dazugeschrieben. Der Einleitungssatz "Eine Hashfunktion oder Streuwertfunktion ist eine nahezu beliebige Abbildung, die zu jeder Eingabe aus einer oft sehr großen Quellmenge eine Ausgabe aus einer typischerweise kleineren Zielmenge erzeugt, den sogenannten Hashcode (oder Hashwert)." ist viel zu kurz um einen Überblick über das Thema zu geben. Es heisst es gibt zu wenig Fachleute, erleichtern wir den zukünftigen den Zugang. Der Rest passt so, also "in". mfg--Niesen 17:11, 3. Jul. 2011 (CEST)
replies: text: du hast recht, ich habe das "typischerweise" entfernt. dass die zielmenge kleiner ist, ist die definition einer hashfkt., der einleitungssatz entspricht damit der definition, die man auch in fachbuechern finden wuerde. ich finde den einleitungsabschnitt recht gelungen, was wuerdest du noch verbessern? --Mario d 17:19, 3. Jul. 2011 (CEST)
thread_title:  Einleitungssatz 

message: Muss der Hashwert unbedingt kleiner sein ? Es gibt durchaus Fälle, mit einer Eingabe von beliebiger Länge wo die Eingabe kleiner als die Ausgabe sein kann. Ein praktisches Beispiel sind Passwörter, die in Schlüssel umgerechnet werden. Hat man eine Hashfunktion, die beliebig lange Strings in 16 byte lange AES-Schlüssel umrechnet, so ist es trotzdem noch eine Hashfunktion, wenn das Passwort einen Buchtaben lang ist. Auch die 16 bit Prüfsumme eine 1 Byte großen Datei, oder die SHA1 Prüfsumme (20 Byte) einer 10 Byte großen Datei ist ein Beispiel für eine kleinere Eingabe. -- 79.225.98.95 20:51, 24. Aug. 2015 (CEST)
replies: text: der hashwert muss nicht kleiner sein als die eingabe. die menge der eingaben ist größer als die menge der ausgaben. --Mario d 13:54, 27. Aug. 2015 (CEST)
thread_title:  Muss der Hashwert unbedingt kleiner sein ? 

message: Ist eine Funktion, die nicht injektiv ist, immer surjektiv? Falls ja, könnte man "nicht injektiv" durch "surjektiv" ersetzen.
Nein, das ist sie nicht. Surjektivität hat eine stärkere Anforderung (zu allen Hashwerten muss jeweils mind. ein Schlüssel existieren). Daher steht nicht injektiv als grundlegende Eigenschaft da, und Surjektivität als wünschenswertes Kriterium. --H3xc0d3r (Diskussion) 06:39, 15. Dez. 2019 (CET)
thread_title:  nicht injektiv = surjektiv? 

message: Der Einleitungssatz,
Eine Hashfunktion (auch Streuwertfunktion) ist eine Abbildung, die eine große Eingabemenge (die Schlüssel) auf eine kleinere Zielmenge (die Hashwerte) abbildet.
, ist nicht richtig!
Die Eingabemenge kann x-beliebig groß sein und die Zielmenge, ist je nach verwendeter Hashfunktion, ist immer nur eine bestimmte Zielmenge. Die Zielmengengröße wird bestimmt durch die Hashfunktion (definierte Größe der Zielmenge)! 
Beispiel MD5 Hash: Eingabe kann beliebig(größer 0) groß sein aber die Zielmenge ist immer 32 alphanummerische Zeichen lang. 
Zitat: die Zielmenge ist immer 32 alphanummerische Zeichen lang.
Das ist unglücklich formuliert. Jeder Wert dieser Menge ist immer 32 alphanummerische Zeichen lang. Es geht aber nicht um die Größe eines Hashwertes, sondern
um die Größe der Menge.
Das Repertoire an möglichen Schlüsseln ist i.d.R. größer als die Anzahl möglicher Hashwerte. Wieviel davon genutzt wird, ist irrelevant. 
Insofern ist der Satz richtig.
--H3xc0d3r (Diskussion) 06:30, 15. Dez. 2019 (CET)
thread_title:  Einleitungssatz