Slashdot Mirror
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."
The MD5 checksum is 128 bit, not 512 bit. Weaknesses have been shows in it, but so far noone has been able to produce two files with the same MD5 checksum. If you have the corrupted ISO with the same checksum, you have the chance to become famous. Until I see proof I will remain rather sceptical.
Oh and about the 384 bit checksum made from a 512 bit checksum, yes of course the 384 bit checksum is weaker. Otherwise people would use it all the time. There is no reason to think that it is any weaker than a checksum giving 384 bit directly, though. It is believed that if you chop off half of the output bits of SHA-160 (the old SHA) you will have an 80-bit checksum with no weaknesses except for brute force.
Finally! A year of moderation! Ready for 2019?
Is it just me, or is there an inherant insecurity in this?
... a 1 or a 0. And I can't predict whether a certain message will result in a 1 or a 0, though, unless I actually go through the entire process of SHA-1ing it.
It's just you. After the Dobbertin attack on MD5, pretty much everyone with a brain moved to SHA-1. This created some difficulties for apps which were hardcoded to only accept 128-bit hashes, but the accepted method of replacing MD5 in that case was, and remains, to use the first 128 bits of an SHA-1 hash. There is no inherent insecurity here for any well-designed hash function.
A well-designed hash function is one whose output is indistinguishable from random noise. To see what I mean, let's say I have a one-bit hash function. You put in your message and you get out either a 1 or a 0. You can't predict whether a certain message will result in a 1 or a 0, though, unless you actually go through the entire process of hashing.
Now let's say I take a SHA-1 hash of the same message and discard 159 bits. I'm left with
Truncating a trusted hash to a shorter hash length is every bit as trusted as using a hash which was designed for that shorter length in the first place.
The converse is unequivocally not true. One way people like to create larger hashes is to first hash the data, then append the hash to the data and re-hash, then concatenate the two hashes together. It works, yes, but it's not an effective method. If you're using MD5, for instance, there are no more than 128 bits of entropy in your hash--even if you chain MD5 operations together to get a longer hash, you're still limited to 128 bits of entropy. If you want a longer hash size than the one you currently have, your choices are (a) chain your current hash, which will get you the size you need but at no additional security, or (b) use a different hash which is designed for the additional size.
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.
If so, you're the luckiest person ever likely to walk the earth. The odds of any two messages hashing out to identical values are 1 in 3.4 * 10**38. The odds of this happening are 100,000,000,000,000,000,000,000,000,000 Schiffers to 1 against. That's steep.
(What's a Schiffer? Well, it's simple... out of the roughly 10**9 men on Earth, Claudia Schiffer is only sleeping with one of them--her husband. The likelihood that any given guy will be sleeping with Claudia Schiffer is roughly one in a billion. If you tell someone "the odds of this are one in 10**38", they'll just look at you blankly. If you tell them that it's 1<28-zeros>0 times more unlikely than them boffing Claudia Schiffer tonight... that, guys understand.)