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."
Prevent email address forgery. Publish SPF records for y
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?
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.
5 44666794829340424572177149721061141426625488491564 0806627990306816 to 1 odds against, btw. These cryptographic hashes are attempts at making "one-way functions", such that knowing the output does NOT help in reconstructing the input )or finding an input that produces the same output). They are quite different than hash functions used in a hash table, for example.
To do this would require trying an impossible amount of random message texts, to find one that hashed the same. Each message (of whatever length) has approximatly a 2^(-384) chance of being the same specific hash output. That is about 3940200619639447921227904010014361380507973927046
If you COULD do what you suggest (more easily than by trying 2^n calculations, for n>112, typically), than just about all cryptographic protocols in use today would probably crumble.
But you are correct, a 384 bit hash that was truncated from 512 is almost certainly less secure, but still impossible to spoof unless a shortcut to brute force searching is ever found.
SHA-1 is 160 bits, and considered more secure by design than MD5 (which is faster), but no one has even found any practical way to spoof MD5 messages (as far as I know).
Your "corrupt" iso did not have same MD5 sum as the uncorrupted image, by any fluke. That is simply impossible. More likely there was something else going on.
And yes, I do mean impossible... I'd bet ~2^120 dollars to your $10 on it (if I had it).
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
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.)