Endianness (Bytereihenfolge) und Fingerprints

[STARGÅTE]

Tachchen,

habe mal eine etwas andere Frage zur Bytereihenfolge (Big- und Little-Endian) in bezug auf Fingerprints wie CRC32, MD5 usw.:
Gibt es dort eine Norm, wie man solche Fingerprints, also 32Bit, 128Bit oder größer abspeichert.
Es habe es nun schon öfter erlebt, das ein CRC32-Fingerprint als Long in Big-Endian gespeichert wird, was beim Prüfen natürlich zu einem Fehler führt, wenn man es nicht weiß und die Zahl als Little-Endian ließt.
Der MD5 wird zwar meistens als HEX-String angegeben, ist aber auch nur eine Aneinanderreihung von 16 Byte, gibt es da eine Norm, wie dieser gespeichert wird?

Hintergrund dieser Frage ist: Ob ich, wenn der Benutzer eines Programms Bytereihenfolge auf Big-Endian setzt, wirklich alles "umdrehen" muss/soll, also eben auch MD5-Fingerprints, oder nur Fingerprints die als Long/Quad darstellbar sind, oder nie Fingerprints?

Ich hoffe ihr könnt mir einen Rat geben.

[Mr.L]

Wäre es möglich den Fingerprint "Byte für Byte" in ein Array zu speichern und zu lesen? Dann sollte es doch eigentlich keine Komptibilitätsprobleme
geben, oder irre ich mich?

[STARGÅTE]

Aber genau das ist doch das Problem, welche Reihenfolge wird bei Byte für Byte verwendet?

Nehmen wir an, eine Fingerprint-Funktion gibt einen 16Bit-Schlüssel zurück: 00100111'00010000
Nun gibt es die möglichkeit diesen Schlüssel in genau dieser Form zu speichern:
Erst 00100111 und dann 00010000 (Big-Endian). Aber es gibt halt auch die möglichkeit
00010000 und 00100111 abzuspeichern (Little-Endian).

Es gibt in dem Sinne also kein Byte für Byte, weil es keine fest definierte reihenfolge gibt wie eine Zahl als 2 oder 4 Bytes im Speicher vorliegt, bzw. es vom Prozessor abhängt.
Also selbst wenn ich nun die Dezimalzahl 10000 nehme, kann im Speicher einer Long 00000000'00000000'00100111'00010000 stehen, oder wie es eigentlich überlich ist 00010000'00100111'00000000'00000000.
Somit würde auch das Byte für Byte schreiben unterschiedliche Datein ergeben.

Als Handfestes Beispiel: PB speichert eine LONG im Little-Endian Format, in einem PNG liegt die Breite und Höhe des Bild aber als LONG im Big-Endian Format vor.

[DarkDragon]

Als Handfestes Beispiel: PB speichert eine LONG im Little-Endian Format[...]

Das ist Prozessorabhängig (siehe auch).

[Mr.L]

Speichere den Fingerprint doch als String.
Oder du ermittlest ob das System Big- oder Little-Endian verwendet und schreibst/liest die Bytes in entsprechender Reihenfolge aus.

Code: Alles auswählen

num.l = $00000001
If PeekB(@num) = $01
	Debug  "Little-Endian"
Else
	Debug "Big-Endian"
EndIf

[mk-soft]

Für 32bit und 64bit Compiler

Code: Alles auswählen

Procedure BSWAP32(value.l)
  !mov eax, dword [p.v_value]
  !bswap eax
  ProcedureReturn
EndProcedure

P.S. Nur 64bit Compiler

Code: Alles auswählen

Procedure BSWAP64(value.i)
  !mov rax, qword [p.v_value]
  !bswap rax
  ProcedureReturn
EndProcedure

FF

[Thorium]

Endianess ist nicht Bestandteil der Hashfunktionen, die ich kenne. Das Protokoll oder der Standard, der die Hashes verwendet legt fest wie sie gespeichert oder übertragen werden. Die meisten Netzwerkprotokolle übertragen in Big Endian.

[STARGÅTE]

@mk-soft: Das "drehen" ist nicht das problem, dafür habe ich auch meine Prozedur MirrorMemory()

@Thorium: Soll heißen, in MD5 oder so wird nicht festgelegt, wie die 128 Bit abgespeichert werden, also liegt die Entscheidung wie ich die 16 Byte anordne bei mir, bzw beim Nutzer der es speichert.
Auch die Stringausgabe des MD5 ist ja im Grunde nur eine Hex-Version welche im Littel oder Big-Endian Format vorliegt.

Das heißt dann aber leider, dass man ohne Hintergrundwissen, keine Chance hat vorher zu erkennen, ob der Fingerprint nun Littel- oder Big-Endian ist?

[DarkDragon]

Das heißt dann aber leider, dass man ohne Hintergrundwissen, keine Chance hat vorher zu erkennen, ob der Fingerprint nun Littel- oder Big-Endian ist?

Die hauptsache ist ja, dass du den Vergleich mit gleichem Endian durchführst. D.h. wenn du den Fingerprint übers Netzwerk verschickst musst du Prozessorabhängig entweder swappen oder nicht swappen.

@mk-soft: Das "drehen" ist nicht das problem, dafür habe ich auch meine Prozedur MirrorMemory()

Ich bezweifle, dass du einen kompletten Speicherbereich swappen musst, sondern eher die einzelnen Worte. D.h. wenn du einen Fingerprint in einer durch 16Bit Worte aufgeteilten Struktur hast musst du jedes 16Bit Wort einzeln byteweise swappen.

[STARGÅTE]

Ich bezweifle, dass du einen kompletten Speicherbereich swappen musst, sondern eher die einzelnen Worte. D.h. wenn du einen Fingerprint in einer durch 16Bit Worte aufgeteilten Struktur hast musst du jedes 16Bit Wort einzeln byteweise swappen.

Soll heißen: In einem MD5 wo mit der Wortgröße 32Bit ein 128Bit Fingerprint erstellt wird, bleibt die Wortreihenfolge egal ob Littel oder Big-Endian die selbe? Es wird also immer nur das Wort selbst gedreht?