SHA-256/384/512 Released

The Right Brute writes "It appears that the successors to the SHA-1 cryptographic digest algorithm have been released. FIPS 180-2 can be found here which I believe is the final version of the SHA-256/384/512 algorithm (it does not appear to have changed since the last draft). I have an implementation that I did as a CWEB literate programming example that might serve as a good companion to the specification."

Comments

May not be patent-free

[FattMattP]

From page two of http://csrc.nist.gov/publications/fips/fips180-2/f ips180-2.pdf:

10. Patents: Implementations of the secure hash algorithms in this standard may be covered by U.S. or foreign patents.

Oh well. Too bad for us.

Re:May not be patent-free

[foobar104]

Um. Are you reading the same sentence I'm reading?

"Implementations of the secure hash algorithms in this standard may be covered by U.S. or foreign patents." (emphasis mine)

All evidence indicates that the SHA algorithms themselves are not patented. Specific implementations of them may be; there's no restriction on that.

And as far as that goes, I have no problem at all licensing algorithms for things like this. In many cases-- not all, but many-- your choices are (1) license-free or (2) secure, and the two are mutually exclusive.

Re:May not be patent-free

[bo-eric]

Can you name one of those cases where the only available algorithms need licensing? I can't think of a single one.

Algorithm Flaw

[Robbat2]

From page 19, section 6:
"In the following sections, SHA-512 is described before SHA-384. That is because the SHA-384 algorithm is identical to SHA-512, with the exception of using a different initial hash value and truncating the final hash value to 384 bits."

Is it just me, or is there an inherant insecurity in this?

By truncating the final hash value, you are losing 128 bits of message digest. Now in theory I can therefore change the message content, so long as I ensure that the first 384 bits of the digest remain the same. I've just defeated the entire purpose of a secure message digest.

From my own research, using a beowolf cluster in the university where I work, anytime that you have a data set with a larger range of possible values than the size of the message digest, it is possible (but very difficult) to create two messages with the same digest value.

The entire reason I have a strong interest in this, is not just for security, but for file checksums on large downloads. The entire thing that got me started, was a downloaded Slackware ISO from an unofficial mirror, that had the correct checksum, but was hopelessly corrupt due to transmission errors close to my side. There was enough change in the ISO that by fluke chance, the MD5 checksum was identical. That is already a 512 bit checksum that was defeated, albeit in-advertantly.