I've been reading about HMAC protecting from length extension attacks, but if the message already specifies it size, is HMAC adding any advantange to simple hashing after prepending a secret?

As example consider a protocol where the message is

user +
server +                 // to prevent attackers sending the same message to others
timestamp +              // to avoid replay
message_content_size +   // to avoid extension attacks
message_content +

where the signature is sha256(user_secret + everything except the signature).

Is HMAC providing anything more in this case?

In other words if the problem is length extension, isn't just adding length field to the message enough? This way no extension is possible and I don't see how can you compute the correct hash of a modified message without knowing the secret...

  • "isn't just adding length enough?" what do you mean by that? Adding more content to your original text in order to become longer?
    – user284677
    Nov 1, 2022 at 19:33
  • @Spyros: I added a hopefully better explanation of what I mean. Sorry but english is not my native language...
    – 6502
    Nov 1, 2022 at 20:32
  • Are you saying that we should append the length of the message (i.e. a number) to the message itself before we hash it? If so, wouldn't (message + length) be your actual message, and as such the length would refer to (message + length)? For example: original message = 100bytes, length of original message = 100, message + length = 101 bytes (keeping it simple - but you get the idea), extented length = 101. Do I get it right?
    – user284677
    Nov 1, 2022 at 21:32

1 Answer 1


It is not a good idea to simply prepend a secret to SHA-256 in this case. In addition to length extension attacks, which don't appear to be a problem with your approach, you need to consider attacks which may occur where the user tries to move bytes from the secret to the message and vice versa.

Even if these are not a concern in your design, it is much better from a protocol design perspective to use a MAC for this purpose. There are security proofs for HMAC that don't apply to your construction, and if your code is subject to audit, it's much easier to simply say, "Oh, we use HMAC-SHA-256" and not to have to explain that you rolled your own design. HMAC also requires less from a cryptographic algorithm, so typically collision attacks against hash functions tend to affect HMAC substantially less.

Even if you were using BLAKE2 or SHA-3, which aren't vulnerable to length-extension attacks, there are specific MAC modes (e.g., KMAC or BLAKE's keyed mode) that are specifically designed to avoid certain types of problems that can occur from just prepending the key to the message and also provide domain separation.

  • I find most of your answer interesting (I don't really know much about security). The only part I cringe a bit about is the audit one... Being audited by someone that can't understand (or doesn't want to understand) your protocols in the details and just care about the fact that you glued together well known algorithms seems a perfect recipe for disasters. In most complex fields I've been interacting with everything is in the details, big pictures arise from details, not the other way around. I'm pretty sure that even here you can glue perfectly working pieces and still make an horrible mess.
    – 6502
    Nov 2, 2022 at 6:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .