11
$\begingroup$

There is already a question asking "Why initialize SHA1 with specific buffer?" and my question follows on from this:

Why are the initial states of hash functions often non-zero?

For most, I have been able to find a clear explanation of where the initial values come from, and they are frequently nothing-up-my-sleeve values. That is, they are chosen precisely because they have no significant structure. However, if that is the case, why can they not be left at zero? Is it simply that a zero initial state is itself too suspicious?

(Other related question: "Initialising Sha-512")

Improve this question
$\endgroup$

1 Answer 1

Reset to default
11
$\begingroup$

In early years of hash function design it was unclear how to choose constants (not only initial vectors), and it was widely assumed that the more random they look, the more secure the function is. There is still not much research in this direction. However, there have been several attacks (rotational cryptanalysis, slide attacks, internal difference attacks) that exploited similarity between the constants and their low Hamming weight. It may happen that some choice of constants yields a weakness or even a backdoor that allows a faster collision/preimage search.

Recent attacks on Keccak/SHA-3 would have been slower if Keccak state were initialized with some weird constant, not zero as it is now. This is a property of the Keccak permutation, whereas the encompassing sponge construction is invulnerable to the initial vector choice.

Another reason is to choose distinct IVs to differ functions that are identical, but truncate the output to a different number of bits (like SHA-224 and SHA-256).

Improve this answer
$\endgroup$
8
  • $\begingroup$ In general, all zero/one constants is kind of risky, but most things - even with very obvious patterns - are ok. See Salsa20's "expand 32-byte k" for example. $\endgroup$
    – orlp
    Oct 28, 2013 at 15:37
  • 2
    $\begingroup$ "some wierd constant" - And this is where i get a little confused. Given the choices are explicitly not very wierd (just that they're not quite as obvious as 0x00.. or 0xff..) it seems like one should be able to modify the first inputs of an attack to achieve the same outcome, given the IV is known? $\endgroup$
    – Cryptographeur
    Oct 28, 2013 at 16:03
  • 3
    $\begingroup$ @user8911: Typically, the kinds of things you may want to avoid are e.g. having the IV be equivalent to itself rotated by some number of bits, or perhaps reversed and/or inverted, or otherwise having some simple bit pattern that might make an attacker's work easier. A random IV is very unlikely to have such a pattern, but may raise suspicions if you can't explain why it was chosen; hence "nothing up my sleeve" numbers, which are supposed to be free of such patterns while still not having enough degrees of freedom to hide a back door. $\endgroup$
    – Ilmari Karonen
    Oct 28, 2013 at 18:13
  • 1
    $\begingroup$ Ilmari's comment is an advice to designers; though correct I would give a different one: set IV to zero, and deal with it with the round constants. This is more secure. $\endgroup$
    – Dmitry Khovratovich
    Oct 29, 2013 at 10:08
  • 2
    $\begingroup$ There is subtlety: the reduced version of Keccak would be stronger, it is true, but for the full version this has no effect (at least this is the impression). Moreover, having nontrivial IV in addition to round constants makes the whole structure more complicated and less transparent. It becomes more difficult to argue the resistance to certain attacks, because you would have to prove that your countermeasures do not interact badly with each other. Hence my strategy would be to have fewer but more secure components. $\endgroup$
    – Dmitry Khovratovich
    Oct 29, 2013 at 12:30

Your Answer

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

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