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?

Improve this question
$\endgroup$
4
  • 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$
    – Cryptographeur
    Commented Mar 27, 2014 at 9:59
  • $\begingroup$ Thanks for the reply. I guess that affects RIPEMD-256 also. Am I wrong? $\endgroup$
    – xxxxxxxxx
    Commented Mar 27, 2014 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$
    – xxxxxxxxx
    Commented Mar 27, 2014 at 10:49
  • $\begingroup$ I believe you will find the answer in Practical Cryptography Chapter 6.3.1 Length Extensions $\endgroup$
    – CodesInChaos
    Commented Mar 28, 2014 at 11:03

1 Answer 1

Reset to default
3
$\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.

Improve this answer
$\endgroup$
4
  • $\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$
    – xxxxxxxxx
    Commented Mar 28, 2014 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$
    – xxxxxxxxx
    Commented Mar 28, 2014 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
    Commented Mar 28, 2014 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
    Commented Aug 25, 2018 at 20:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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