7

Cryptographic hash functions pad the input message with some indicator of length. This is done as to avoid attacks and allows an input message of 0000 to be differentiated from 00000. As far as I can see, padding /length inclusion invariably occurs after the message data either immediately after or right up at the end of the block.

Is there some fundamental /security reason that the length of the message can't be pre pended instead? So it would go at the start of the first block. Is it somehow connected with sequentially reading in files /data of unknown length? Would it make a difference if you always knew the length of the message to be hashed?

Paul Uszak
  • 15,390
  • 2
  • 28
  • 77

1 Answers1

8

Is it somehow connected with sequentially reading in files /data of unknown length?

Yes, indeed. It is part of a requirement to perform online message processing, or, in other words, the ability to stream the data without knowing how much data to expect.

Would it make a difference if you always knew the length of the message to be hashed?

Well, yes, in that case you could indicate the message length in advance. Some modes of operation, such as CCM, a authenticated mode for packet encryption, rely on this kind of information. But for hash algorithms it is not required to know the message length in advance and still be secure.

Nothing prevents you to create a protocol to include the message length in advance. If you build it on top of SHA-1 or SHA-2 then this should prevent message length attacks (if implemented correctly). You'd include the message length twice that way, and would lose compatibility with software that just expect the hash.

SHA-3 is already protected against length extension attacks. Length extension attacks may not be applicable to all algorithms or situations. Length extension attacks are mainly an issue for keyed hashes. HMAC is a keyed hash which has deliberately been designed to protect against length extension attacks.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313