md5 nach RFC 1321



  • Ich Versuch's mal.

    index = (unsigned int)((context->count[0] >> 3) & 0x3f);
      padLen = (index < 56) ? (56 - index) : (120 - index);
    

    mmmh, also das verstehe ich nicht. Was genau ist bei dir Context?
    Sieht für mich folgendermaßen aus:
    1. Du machst einen shr um 3 stellen, da 2^3 = 8 (Umrechnung von Bit zu Byte)
    2. Vom Resultat holst du dir den Wert der unteren 63 Bit
    Jup.

    2. Vom Resultat holst du dir den Wert der unteren 6 Bit
    Die unteren 6 Bit zu holen ist das selbe wie MOD 64 zu rechnen. Also Mod 64Byte, ist Mod 512Bit. Ganzzahlige Vielfache von 512 Bit werden weggeworfen.
    Das ist der Index des letzten benutzen Bytes im letzten Block.
    und dann kommt

    if(index<56)//Wenn genug Platz ist, dann normal auffüllen
       padLen=56-index;
    else//ansonsten ein ganzen Paket mehr nehmen und auch auffüllen
       padLen=64+56-index;
    


  • Dann habe ich es doch richtig verstanden 😉 Das mit den 63 Bit war natürlich ein gedanklicher Mischmasch zwischen 63 (0x3f) und den 6 "Bit" ^^.

    Vielen Dank, sollte sich noch ein Problem ergeben, ergänze ich diesen Thread. Die Sache mit den 64 Byte Blöcken die quasi über der Eingangsnachricht liegen, habe ich aber richtig erläutert oder?

    EDIT: Wofür wurde hier das Char-Array PADDING benutzt?



  • FrEEzE2046 schrieb:

    mmmh, also das verstehe ich nicht. Was genau ist bei dir Context?

    'context' ist eine MD5_CTX struct. die funktion 'MD5Update()' braucht 'ne adresse auf die aktuelle MD5_CTX, einen pointer auf die daten und die länge der daten, dann werden soviele bytes wie die länge angibt, in den MD5-hash hineingemixt (in dem fall eben padLen von den padding-bytes).
    ach ja, such mal im originalcode (der im RFC davei ist) nach 'MDString'. daran siehste auch, wie MD5 benutzt wird und welche aufgaben MD5Update,;MD5Final usw. haben.
    🙂



  • FrEEzE2046 schrieb:

    EDIT: Wofür wurde hier das Char-Array PADDING benutzt?

    ^^na, um die padding-bits (beginnend mit einer 1) mit anzuhängen.
    🙂



  • ;fricky schrieb:

    FrEEzE2046 schrieb:

    EDIT: Wofür wurde hier das Char-Array PADDING benutzt?

    ^^na, um die padding-bits (beginnend mit einer 1) mit anzuhängen.
    🙂

    Ja, aber 128 ist doch keine Angst 😕

    EDIT: 1 meine ich^^



  • FrEEzE2046 schrieb:

    Ja, aber 128 ist doch keine 1

    es geht doch um bits. 128(als byte) hat links eine 1 und dann 7 nullen, die anderen bytes sind jeweils für die restlichen 504 null-bits da. als bit-string ist sieht das array so aus: 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    🙂



  • Ich muss nochmal fragen, da eine meiner Fragen konsequent ignoriert wird 😉

    Also, in der Dokumentation ist nur die Rede davon, dass die Nachricht auf 448 Bit "erweitert" wird. Was passiert aber, wenn die Nachricht größer ist als 56 Byte? Wird dann die Nachricht auf 112 Byte erweitert?



  • 120



  • FrEEzE2046, wie kann man nur so auf dem Schlauch stehen...

    Die Nachricht wird so erweitert, dass gilt

    (Länge-In-Bits(Nachricht) [i]modulo[/i] 512) == 448
    

    Dabei wirst zuerst ein Bit mit Wert 1 angehängt, und dann (solange nötig) Bits mit dem Wert 0.

    Wie du auf die Idee kommen könntest dass der Hash-Wert irgendwie mit Padding versehen werden soll... keine Ahnung. Den Hash-Wert errechnest du ja erst, und der ist immer 128 Bit -- wieso sollte man da irgendein Padding dranhängen. Und wieso auf 448 Bit?

    😕



  • hustbaer schrieb:

    Wie du auf die Idee kommen könntest dass der Hash-Wert irgendwie mit Padding versehen werden soll... keine Ahnung. Den Hash-Wert errechnest du ja erst, und der ist immer 128 Bit -- wieso sollte man da irgendein Padding dranhängen. Und wieso auf 448 Bit?

    😕

    Komme ich überhaupt nicht. Ich habe nie gesagt, dass der Hash selbst vergrößert wird, sondern die Eingangsnachricht.

    Ich hatte nur die Aussage nicht verstanden:

    hustbaer schrieb:

    Die Nachricht wird so erweitert, dass gilt

    (Länge-In-Bits(Nachricht) [i]modulo[/i] 512) == 448
    

    😕

    Warum ist mir jetzt auch nicht mehr klar. Ist ja eigentlich ganz einfach (56, 120, 184, 248, ...)



  • FrEEzE2046 schrieb:

    hustbaer schrieb:

    "Die Nachricht wird so erweitert, dass gilt

    (Länge-In-Bits(Nachricht) [i]modulo[/i] 512) == 448
    

    😕

    Warum ist mir jetzt auch nicht mehr klar.

    Darauf willst du nicht wirklich eine Antwort, oder?



  • hustbaer schrieb:

    Warum ist mir jetzt auch nicht mehr klar.

    Darauf willst du nicht wirklich eine Antwort, oder?

    die frage ist berechtigt. wahrscheinlich ist ohne dieses padding der output nicht 'zufällig' genug, bei bestimmten eingabedaten. warum das genau gemacht wird, steht im RFC auch nicht, musste wohl mal dem rivest 'ne mail schicken.
    🙂



  • Ihm ist nicht klar warum er es vorher nicht kapiert hat!



  • Huch!
    Eine dritte Möglichkeit wie man es verstehen kann 🙂
    Ja, das wird er gemeint haben.

    Ich hatte es noch anders ausgelegt. Wenn man den Satz als rhetorische Frage liest, und böswillig etwas Zynismus unterstellt, bekommt er nämlich nochmal eine andere Bedeutung. Hihi. Hab ich wohl falsch interpretiert. Oops.


Anmelden zum Antworten