0
$\begingroup$

Based on RFC 1321 after we recive a message if message size is less than 64 Byte we will append it with a 0x80 and message length + zeroes until it's 64 bit and then generate the digest.

The question is what will happen to exact 64 Byte? based on specification:

Padding is always performed, even if the length of the message is already congruent to 448, modulo 512.

But how is that possible?
You can't append length and other things to it? if it's for example 128 byte then I think 64 byte message digest would be same as 128 bit digest?

$\endgroup$
2
  • $\begingroup$ The MD5 block is 512 bits (64 bytes - not bits!). The padding always appends an one bit, then adds bytes until the length is 448 bits (mod 512) - and then, 8 bits of the length are added and the message becomes a multiple of 512 bits long. See answer below. $\endgroup$ – Mark Aug 15 '17 at 1:31
  • $\begingroup$ @Mark Thanks for the comment, sorry my bad... Made a mistake. $\endgroup$ – Amir Rezai Aug 15 '17 at 8:50
5
$\begingroup$

Padding can be expressed as follows:

  1. Append a bit of value 1.
  2. Append between 0 and 511 bits of value 0. The number of bits to append here must be such that the total length after padding is a multiple of 512.
  3. Append the encoding of the length of the message (not counting the padding bits). That encoding always has size exactly 64 bits.

So, if your input has size 448 bits, then:

  1. After adding the bit of value 1, you get a total length of 449 bits.
  2. You will need to add exactly 511 bits of value 0. Otherwise, the final length won't be a multiple of 512. With these extra 511 bits, length is now 960 bits.
  3. With the length encoding, size is now 960 + 64 = 1024, which is indeed a multiple of 512.

The padded input is then split into blocks of 512 bits, processed in due order.

The sentence in the RFC about a length exactly equal to 448 is meant to clarify the process, in that the extra bit of value 1 is always added. That bit is not optional.


Formally, MD5 takes as input a sequence of bits. However, in most situations, we only hash sequences of bytes. In other words, the input length will always be a multiple of 8. The padding process, when expressed with bytes, becomes:

  1. Append a byte of value 0x80.
  2. Append between 0 and 63 bytes of value 0x00. The number of bytes to append here must be such that the total length (in bytes) after padding is a multiple of 64.
  3. Append the encoding of the length of the message (not counting the padding bytes). That encoding always has size exactly 8 bytes. The length is expressed in bits, i.e. it is eight times larger than the length in bytes.

The padded input is then split into blocks of 64 bytes, processed in due order.

This padding procedure is exactly the same as the one defined for bits; it is just expressed here from a byte-oriented viewpoint.

$\endgroup$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.