Hi,
Bis auf Dokumentationen und Debugging gibt es jedoch keinen Grund zur Ausgabe und damit zur Darstellung.
Bist du dir da sicher?!?
Ja, vollkommen.
Also mal überlegen, wo man den MD5/SHA1 Hash benötigt, typische Anwendungsbeispiele sind:
-Hash von einer Datei, wurde diese geändert (Hash muss gespeichert&Ausgegeben werden)
Dazu gibt es mehrere Methoden wobei eine Hexadezimalzahl nicht immer sinnvoll ist. Ausgegeben wird dabei übrigens auch nichts, was nachher menschenlesbar dargestellt werden muß.
BTW: MD5 sollte mittlerweile als gebrochen angesehen und zu kryptographischen Zwecken nicht mehr benutzt werden.
Z.B. bei Dateien die zum Download angeboten werden. (Hexadezimal sinnvoll)
s.o.
- Hash von einer Nachricht die man signieren möchte (Hash muss übertragen werden) (ink. Zertifikate)
(Hexadezimal Sinnvoll)
s.o.
- Hash als Key-Expansion (hier wäre String sinvoller).
s.o.
Aber vorallem für PHP-Programmieren:
Passwort als Hash in der DB/Textdatei speichern. (Hexadezimal sinnvoll)
Da ist es völlig egal. Wenn es trotzdem Probleme bereitet ist eines der beteiligten Programme kaputt oder schlecht programmiert.
Das sind die primären Anwendungsgebiete eines Hashwertes. Würde man den Hash als String speichern, könnte es Verluste geben (Steuerzeichen).
Wo bitte sollte es Verluste geben? Nein, Unfähigkeit des Programmierers ist kein Grund.
Und meistens muss er auch ausgegeben werden, und zwar so dass ein Mensch ihn lesen kann, also ohne Steuerzeichen.
Ja, das ist wohl wahr und zwar in Dokus und Debuggingsessions. Sonst nirgends. Was soll auch ein Mensch damit sonst anfangen?
Also muss man ihn kodieren, da müsste man sich aber auf einen Kodierungstandard einigen.
Der Codierungsstandard ist einfach "roh". Will man etwas anderes haben kann man sich etwas anderes draus basteln.
Desweiteren hat die Berechnung eines MD5/SHA1 Hashes genau 4x32-Bit bzw. 5x32-Bit Integer Ausgaben, ist es sehr leicht, diese Zahlen als Hexadezimal darzustellen.
Oder auch in jeglicher anderen Darstellung. Das macht man ja nicht selber, das macht der Rechner. Das muß aber programmiert werden, deshalb ist es ideal, wenn man die Rohware zur Verfügung hat, da kann man besser mit Arbeiten.
Diese 4/5 Ausgaben werden dann einfach aneinandergehängt, fertig ist der Hashwert..
Der Hashwert ist schon vorher fertig, der muß nicht noch weiter bearbeitet werden.
Und hast du schon mal an die xxxxxxxxxxxxx Personen gedacht, die kein ASCII als Standard-Zeichensatz benutzen?
Was ist mit denen? Die können damit auch keine Hexadezimalen Zahlen darstellen, also wie kommst Du auf diese Leute?
Auf japanisch ist das Byte 0x64 (100) bestimmt nicht wie beim ASCII ein: d.
Doch, da ist es auch ein 'd'. Steht im Gegensatz zu meinem Satz oben? Nein, seit Unicode nicht mehr. Ob der Font den Buchstaben enthält ist natürlich unbekannt.
Was ist wenn die erste 32 Bit Variable folgendes Wert enthält:
0x61626364ASCII: abcd
Das ist nicht sicher, das kannst Du so nicht behaupten. Das kann selbst bei ASCII auch "dcba" oder gar "badc" sein.
Aber bei einem japanischem Zeichensatz??
Keine Ahnung, müßte ich nachschauen (brauche dafür aber den genauen Zeichensatz. Ja, da gibt es wirklich mehrere). Sollte aber das gleiche bei rauskommen.
Und da Hexadezimal Weltweit eindeutig ist, gibt es dort keine Verwechslungen.
Eben sagtest Du noch, das sowas im japanischem Zeichensatz nicht geht, denn die für hexadezimale Darstellung nötigen ASCII-Zeichen "a,b,c,d,e,f" soll es da ja nicht geben.
So können Deutsche und Japaner ohne Probleme Hashwerte austauschen, ohne sich auf eine gemeinsame Kodierung einigen zu müssen.
Und was spricht jetzt gegen die Rohware? Nicht jede Programmiersprache/jedes Transportprotokoll ist derart unfähig mit sowas nicht umgehen zu können.
Zusammengefasst: Nur zum Key-Crunching wäre es Sinvoller, würde die Funktion den Hash als String zurückgeben. Sonst ist der Hexadezimalwert sinnvoller.
Ich kann immer noch nicht nachvollziehen, warum eine Hexadezimalzahl außer in seltenen und zudem nicht produktionsrelevanten Ausnahmen die ideale Lösung darstellen soll.
so short
Christoph Zurnieden