Is whirlpool vulnerable to length extension attacks? I did not find anything on the topic and hardly anything interesting about whirlpool at all. I am trying to build some HMAC for a program and consider using whirlpool to do so.
2 Answers
Let's split your question into two parts: first the length extension attack problem with Whirlpool, and next your HMAC tool idea.
1. Is whirlpool vulnerable to length extension attack?
Yes, Whirlpool by itself (as a plain hash, not HMAC) is indeed vulnerable to length extension attacks.
Besides Crypto.SE Q&As like “Understanding the length extension attack”, the SkullSecurity.org website offers an explanation in their article “Everything you need to know about hash length extension attacks”. Here's an excerpt:
The attack
An application is susceptible to a hash length extension attack if it prepends a secret value to a string, hashes it with a vulnerable algorithm, and entrusts the attacker with both the string and the hash, but not the secret. Then, the server relies on the secret to decide whether or not the data returned later is the same as the original data.
It turns out, even though the attacker doesn't know the value of the prepended secret, he can still generate a valid hash for {secret || data || attacker_controlled_data}! This is done by simply picking up where the hashing algorithm left off; it turns out, 100% of the state needed to continue a hash is in the output of most hashing algorithms! We simply load that state into the appropriate hash structure and continue hashing.
TL;DR: given a hash that is composed of a string with an unknown prefix, an attacker can append to the string and produce a new hash that still has the unknown prefix.
Example
Let's look at a step-by-step example. For this example:
let secret = "secret" let data = "data" let H = md5() let signature = hash(secret || data) = 6036708eba0d11f6ef52ad44e8b74d5b let append = "append"
The server sends data and signature to the attacker. The attacker guesses that H is MD5 simply by its length (it's the most common 128-bit hashing algorithm), based on the source, or the application's specs, or any way they are able to.
Knowing only data,
H
, andsignature
, the attacker's goal is to append append to data and generate a valid signature for the new data. And that's easy to do!
In that article, they also link to a tool which allows to practically do a length-extention attack on every algorithm you could wish for – including WHIRLPOOL.
The tool – coded in plain C – is available for free and hosted at Github under the name hash_extender
. Quoting its description, hash_extender
…
… implements a length extension attack against every algorithm I could think of:
- MD4
- MD5
- RIPEMD-160
- SHA-0
- SHA-1
- SHA-256
- SHA-512
- WHIRLPOOL
I'm more than happy to extend this to cover other hashing algorithms as well, provided they are "vulnerable" to this attack -- MD2, SHA-224, and SHA-384 are not. Please contact me if you have other candidates and I'll add them ASAP!
2. I am trying to build some HMAC for a program and consider using whirlpool to do so.
This again lifts the length extension attack problem described above, since a HMAC construction (which securely hashes data with a secret key) prevents length extension attacks. For details on how a HMAC construction achieves that, you can check the Crypto.SE Q&A “How does the secret key in an HMAC prevent modification of the HMAC?” which explains that HMACs were designed to void length extension attack issues.
When trying to attack a HMAC,
…the attacker only controls variable-length input to the inner hash, not the outer hash…
So, the answer which practically considers your question title as well as your description is extended to:
Yes, Whirlpool by itself (as a plain hash, not HMAC) is indeed vulnerable to length extension attacks – but since you plan to use it in a HMAC construction (which prevents length extension attacks) you can safely ignore that attack vector. Yet, it should be noted that I'm assuming you implement the HMAC construction correctly.
TL;DR
- Yes, Whirlpool as a plain hash is vulnerable to length extension attacks.
- HMAC constructions prevent length extension attacks, which voids that problem.
-
$\begingroup$ You could just truncate the Whirlpool output. It would be totally acceptable to truncate it to 256 bits for an HMAC, and that would leave another 256 bits of the internal state hidden from the attacker. $\endgroup$– forestCommented Mar 25, 2018 at 23:26
-
$\begingroup$ @forest Well, in the last paragraph before the "TL;DR" I do point out one could use Whirlpool (in a HMAC construction). As for your suggestion: I'm not really confident an simple truncation would be able to provide the same security properties a HMAC construction provides. — But that's probably material for a separate Q&A… ;) $\endgroup$– e-sushiCommented Mar 26, 2018 at 3:20
Yes, it is vulnerable but as mentioned in a comment this is irrelevant when used in HMAC. I'm not sure what you mean you cannot find anything interesting about Whirlpool:
- Official website: http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html
- Publication including reference implementations: http://www.larc.usp.br/~pbarreto/whirlpool.zip
- ISO standard: https://www.iso.org/standard/39876.html
Hope that helps!
-
1$\begingroup$ About Whirlpool regarding length extension attacks. I don't see how listing the official documentation is any help./ $\endgroup$– Maarten Bodewes ♦Commented Oct 2, 2017 at 10:23
-
$\begingroup$ @MaartenBodewes The official website describes it as a Merkle-Damgård hash, which implies length extension attacks being possible. $\endgroup$ Commented Oct 3, 2017 at 13:33
-
$\begingroup$ Hmm, OK that's true - in case there are no pre/post processing steps added to avoid these attacks anyway. But in that case this should be put in the answer. I looked at the pages (not the code) but I could not find a mention of length extension attacks. The same with HMAC, just stating that it is not vulnerable is not enough imho. Assuming that the asker already knows why they are not applicable is not helpful. $\endgroup$– Maarten Bodewes ♦Commented Oct 3, 2017 at 14:45