# Possible SHA-256 implementation weakness

I came across a SHA-256 implementation that seems not to conform to the standard and because I can't change the implementation I would like to know if it's safe for use or can be a potential weakness.

For the last 32 byte block instead of performing this: (As copied from wikipedia)

Add the compressed chunk to the current hash value:
h0 := h0 + a
h1 := h1 + b
h2 := h2 + c
h3 := h3 + d
h4 := h4 + e
h5 := h5 + f
h6 := h6 + g
h7 := h7 + h


It overwrites the current hash value:

h0 := a
h1 := b
h2 := c
h3 := d
h4 := e
h5 := f
h6 := g
h7 := h


Aside from this difference, the implementation in question is equivalent to the pseudo code in wikipedia. It does not produce equivalent output to a correct implementation of SHA-256.

• The "came across a SHA-256 implementation" part of the question is hard to swallow. But whatever, that falls into the more general case of what's considered there.
– fgrieu
Jul 1 '18 at 14:02
• If you hash something longer than 1 block with a normal implementation and something with this implementation, do they return the same result? Jul 1 '18 at 14:40
• They don't return the same result Jul 1 '18 at 14:46
• If the implementation does not produce the correct results it is a failed implementation, don't use and report it.
– zaph
Jul 1 '18 at 15:45
• with just those changes in my code, I cannot replicate your examples, therefore there must be other changes Jul 2 '18 at 10:44

If the implementation does not produce the correct results it is a failed implementation, don't use and report it.

This is pretty much the correct course of action, assuming that the algorithm is supposed to be SHA-256.

Cryptanalysis of the incorrectly implemented algorithm would be non-productive, unless your goal is to maliciously exploit the protocol that is using this hash function.

## Alternatively

It is possible that the author was attempting to be clever or obscure and made such a modification intentionally. There may not be much you will be able to do to help the situation if that is the case; Even if you present collisions/preimages, you may simply garner hostility from the author/users (see the drama around IOTA for an example).

You're not showing the full code, or even telling what the implementation in question is, so we can't know if it's just a quirk of the implementation. But changing the algorithm would change the outputs, which should be immediately obvious if the program is supposed to be interoperable with anything else that uses SHA-256. That should cause problems even before someone considers doing an actual attack on the hash.

If the program is something that will only ever be used with itself and uses a broken hash, then it's just insecure. If they haven't bothered to use a correct implementation of SHA-256, they'll probably have made other implementation mistakes, too.

• I used snippets from wikipedia because the implementation is compatible with the pseudo code in wikipedia except for the difference I described. If it's indeed a weakness I prefer telling the writer about the problem before I expose it. The implementation does produce different digest and therefore not compatible with SHA-256. Jul 1 '18 at 12:10