9
$\begingroup$

As RFC 4634 describes in section 6.1, SHA-256 is initialized using eight 32-bit words.

These were obtained by taking the first 32 bits of the fractional parts of the square roots of the first eight prime numbers:

H(0)0 = 6a09e667  
H(0)1 = bb67ae8  
H(0)2 = 3c6ef372  
H(0)3 = a54ff53a  
H(0)4 = 510e527f   
H(0)5 = 9b05688c  
H(0)6 = 1f83d9ab  
H(0)7 = 5be0cd19

These are obviously meant to be "nothing up my sleeves" numbers.

Assuming interoperability — read: compatibility between users — isn't an issue, I've got the following questions:

  1. Are there any security issues related to replacing those SHA-256 initialisation values?

    The plan is the one-time use of a CSPRNG to get alternative values for a specific (in-house) implementation; which I presume to be a safe way to get good alternative values. Please correct me when this assumption is wrong.

  2. Are some initialisation values worse than others?

    In other words: is the Merkle–Damgård construction, and/or the SHA-2 algorithm design as a whole, susceptible to weak initialisation values along the lines of 0-key problems as applicable to cipher analysis? Or could we set them all to zero without any impact on cryptographic security?

NB: pointers to related research paper(s) welcome, but not a "must".

|improve this question|||||
$\endgroup$
  • 4
    $\begingroup$ If there was an attack, even only a collision, we'd call it a free-start collision. (related reading) But because we don't know of any SHA-256 free-start collisions, I suspect it's fine replacing these values. $\endgroup$ – SEJPM♦ Mar 11 '17 at 14:22
  • 3
    $\begingroup$ Related: Malicious SHA-1 $\endgroup$ – CodesInChaos Mar 11 '17 at 16:25
  • $\begingroup$ @CodesInChaos Tnx for the pointer. Makes me think, but I’m not sure if I should worry about that (especially the differential characteristic part) or not (since SHA-1 is a bit different from SHA-2). Do you think this could also be "ported over" to SHA-2 and have a practical impact on cryptographic security? I’m inclined to say “no” (due to the effort needed to find exploitable 64-step characteristics), but I’ld like to be sure I’m not dropping the ball somewhere. $\endgroup$ – e-sushi Mar 11 '17 at 17:55
  • $\begingroup$ @SEJPM Variable IVs as mentioned in the linked answer would indeed be an issue, but as my Q mentions – we’re merely talking about a one-time-only replacement. After that, the IVS will stay fixed as part of a compiled binary. $\endgroup$ – e-sushi Mar 12 '17 at 0:56
  • $\begingroup$ Since 10+ comments were posted (thanks for all that feedback); I moved things to chat where we have a bit more room to breathe, while keeping the Q&A here as readable as possible. $\endgroup$ – e-sushi Mar 12 '17 at 1:25
4
$\begingroup$

  1. Random IVs are fairly clearly ok. NIST secure hash standard defines SHA-512/t with arbitrary t and different IV values that are themselves outputs of SHA2, and Merkle-Damgård hashes basically do the same internally when you have a multi block massage. There should be no reason you could not do the same with SHA-256 or with another PRNG generating the IV values.

  2. Nonrandom IVs are theoretically a different matter. Current (partial) attacks on SHA2 work on the compression function and find collisions for any predetermined IV/chaining value. However, at least in principle some values could be easier to attack. That would not break the whole hash as long as the number of weak IVs is negligible.

    (As in the case of the Malicious SHA1 linked in the comment by CodesInChaos, but with round constants instead of IV.)

|improve this answer|||||
$\endgroup$

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.