3
$\begingroup$

In the paper for Fortuna the authors say that you can use any good digest algorithm (obviously as long as its output is 256 bit) and then they recommend double SHA-256.

Why? What's the benefit? What happens if I use single SHA-256 or RIPEMD-256, for example?

$\endgroup$
  • 1
    $\begingroup$ I haven't read the paper, but I would expect it's to prevent length-extension attacks on the MD-construction (which is the internal design used by SHA-256). $\endgroup$ – figlesquidge Mar 27 '14 at 9:59
  • $\begingroup$ Thanks for the reply. I guess that affects RIPEMD-256 also. Am I wrong? $\endgroup$ – izaera Mar 27 '14 at 10:48
  • 1
    $\begingroup$ BTW: the paper says nothing about why it chooses double SHA. The only reference to both SHA-256 and double SHA is in this sentence: "A typical hash function, like SHA-256, and hence SHAd-256, processes message inputs in fixed-size blocks". The rest of the paper it uses double SHA-256 for everything. $\endgroup$ – izaera Mar 27 '14 at 10:49
  • $\begingroup$ I believe you will find the answer in Practical Cryptography Chapter 6.3.1 Length Extensions $\endgroup$ – CodesInChaos Mar 28 '14 at 11:03
2
$\begingroup$

Ferguson and Schneier define SHAd-256 in their book Practical Cryptography in Chapter 6.3.1 Length Extensions.

For any hash function SHA-X, where X is 1, 256, 384 or 512 we define SHAd-X as the function that maps m to SHA-X(SHA-X(m)). In particular, SHAd-256 is just the function m ↦ SHA-256(SHA-256(m)).

They clearly defined SHAd-256 to prevent length extension attacks.

I don't know why Ferguson and Schneier also used SHAd-256 when they designed Fortuna, but I assume that they preferred a hash function invulnerable to length extensions over a vulnerable one even if it might not matter for a particular use.

$\endgroup$
  • $\begingroup$ Well, in fact that's the explanation. In Fortuna they calculate the new key for reseeds by doing SHA-256(oldKey || entropy) which is a construction vulnerable to length extension attacks. To avoid that HMAC (for example) does: hash(key || hash(key || message)). And another way to fix it is to do the double hashing. So I guess that's the reason. $\endgroup$ – izaera Mar 28 '14 at 13:09
  • 1
    $\begingroup$ I still don't see how an extension attack could be used there but I guess it may help in getting some knowledge of the internal state of the RNG because what you are doing with the double hash is somewhat to avoid leaking the internal state of the digest. $\endgroup$ – izaera Mar 28 '14 at 13:12
  • $\begingroup$ It's easier to fix a dubious property of a building block than it is to argue why you're absolutely sure that it's not a vulnerability. Another advantage of this approach is that it makes it easier to prove the security of a higher level construction. So even if they believe that length extensions are a problem many cryptographers prefer the safe choice of using a stronger hash. $\endgroup$ – CodesInChaos Mar 28 '14 at 13:16
  • $\begingroup$ @CodesInChaos Sure. The SHA-2 512/256 truncation mode would also prevent length extension attacks without requiring a second hash. But that was published in (?)2011 and Fortuna was published in 2003. Today I think it might make sense to use SHA-3 (or any SHA-3 finalist) in place of $SHA_d\text-256$. $\endgroup$ – Conrad Meyer Aug 25 '18 at 20:24

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.