More on Newly Broken SHA-1 362
AnonymousStudent writes "Details are out about the reported broken SHA-1 hash function. The findings are that SHA-1 is not collision free and can be broken in 2^69 attempts instead of 2^80. This is about 2000 times faster. With todays computing power and Moores Law, a SHA-1 hash does not last too long. Using a modified DES Cracker, for the small sum of up to $38M, SHA-1 can be broken in 56 hours, with current computing power. In 18 months, the cost should go down by half. Jon Callas, PGP's CTO, put it best: 'It's time to walk, but not run, to the fire exits. You don't see smoke, but the fire alarms have gone off.' As Schneier suggests, 'It's time for us all to migrate away from SHA-1.' Alternatives include SHA-256 and SHA-512."
Break only affects carefully constructed messages (Score:5, Informative)
Re:Break only affects carefully constructed messag (Score:5, Insightful)
Once an algorithms strength is in doubt by the presence of even one weakness people feel very reluctant to trust it.
Its probably up to everyone to see how this affects their own circumstances. Crypto is always about Knowing your enemy (the paranoia has now kicked in !). When picking a scheme one always makes a number of assumptions - Who are you keeping the information hidden from, what resources do they have, how badly do they want it.
No crypto is powerful, or clever enough (yet!) to be completely unbreakable so its all down to making assumptions:
1)
Would someone be willing to pay $38 million (assuming this is correct) to get my credit card number - probably not.
2)
Would someone be willing to pay $38 million to get insider info on a merger between two banks - each worth over $10 billion.
What unsettles people is that their previous assumptions on SHA-1 are now invalid.
Price (Score:3, Interesting)
There are 8776 hours in a year. Assume the machine has a life of 3 years before it becomes obselete. That means (discouting TVM at 0% for simplicity) the machine can do 470 problems of this type in three years, breaking even at a little over $80 per problem.
Damn that just got a lot lot cheaper.
Re:Price (Score:5, Informative)
Re:Price (Score:2)
Re:Price (Score:2)
Perhaps we should risk-weight the investment too... this is all getting technical and I fear we may incriminate ourselves on plan
Re:Price (Score:3, Interesting)
Re:Break only affects carefully constructed messag (Score:2)
He needs to pay the 38 million only once and can get a million every second day - sounds like a good deal. But OTOH his interest might be different, as you said in your bank merger example. However, there are things that are worth a lot although it is not as obvious as in this case. (Research stuff leading to military and industrial advantages.)
Re:Break only affects carefully constructed messag (Score:5, Insightful)
2)
Would someone be willing to pay $38 million to get insider info on a merger between two banks - each worth over $10 billion.
Except SHA-1 isn't an encryption scheme, it's a hashing algorithm. For your 38 million you could construct an machine that would create two random messages that hash to the same value. Totally useless. Really what you want to do is find a message that hashes to the same value of a specific message. Or even better you'd want to create an arbitrary message, tack on some header or footer and have that hash to some chosen hash.
If I understand message signing and digital signatures, an attacker wants to make it look like they're the intended target. Say I send a signed message to my bank saying "please transfer $1,000,000 to account 123456". An attacker wants to generate a message like "please transfer $1,000,000 to account -attacker account number- that will hash to the same value, so he/she can use the same signed digital signature. The 38 million dollar device won't be able to do that in 56 hours, I doubt you could do it in 56 years (and I highly suspect it would take MUCH MUCH longer).
Re:Break only affects carefully constructed messag (Score:3, Insightful)
Not true. The use of that is creating one legitimate document and apply a certification to it, with the authority of a trusted certifier (who would have verified it, because it is legitimate).
At the same time your $38M machine would create a second document, with whatever information you care to put in, which that certifier would never touch. They have the same hash, so y
Re:Break only affects carefully constructed messag (Score:3, Informative)
Not true. The use of that is creating one legitimate document and apply a certification to it, with the authority of a trusted certifier (who would have verified it, because it is legitimate).
The is that as soon as you try to place specific content in the message, it becomes *much* harder to find a collision that meets your requirements (especially if there are length requirements too).
Now.... Let me bring up one possible use of these issues. If you store passwords as SHA hashes, and if someone can ge
Re:Break only affects carefully constructed messag (Score:2)
Re:"begs the question" (Score:4, Insightful)
sure You ? are
Re:"begs the question" (Score:3, Insightful)
The bastardized definition of "begs the question" was spawned in the minds of ignorant people and draws life from the thick-skulled arrogance of the same.
Re:Break only affects carefully constructed messag (Score:5, Informative)
If they're prepared to spend a realistic level of time on it they could create two of them that hash to the same thing, with a small but effective change to the second.
You sign the first with SHA-1, but your signature also matches on the second, putting you in a weak position when you try and claim "I didn't sign _that_!"
The time/money requirements to do this aren't really practical yet, but they will be soon.
As the sub says, time to start shifting off SHA-1.
Re:Break only affects carefully constructed messag (Score:3, Informative)
Creating pseudo-random numbers that hash to the same value != making any arbitrary document hash to the same value.
assume it is a word document (Score:2, Insightful)
Re:Break only affects carefully constructed messag (Score:2)
Making collisions easy (Score:5, Insightful)
Write the contract in MS Word and use huge uncompressed BMPs for the company logos. You have instantly enough space for subtile changes to create collisions.
Re:Break only affects carefully constructed messag (Score:3, Informative)
So, there are two lessons to be learned.
1. Don't trust SHA1 as part of an algorithm for signing a document that someone else gave you. Actually, this is not so much of a risk, because any reasonable signature algorithm signs more than just a straight hash of the document.
I dunno about that... (Score:2)
[NB: For computer science geeks, a "pre-image of a hash" is more or less the same thing as a "bucket"; for math geeks, it's more or less the same thing as a "variety".]
If they're prepared to spend a realistic level of time on it they could create two of them that hash to the same thing, with a small but effective change to the second.
I dunno - my guess would be that the subspace of all grammatically correct English language sentences [and paragraphs, and chapters/essays/"contracts"] is, for all intent
Collision free hash? (Score:5, Insightful)
Since when is it possible to have a collision free hash when the hashed data has more possibile bit combinations than the hash itself?
Genuine question.
Re:Collision free hash? (Score:4, Interesting)
With 160 bits of hash, the probability that two pieces of data will hash to the same value is incredibly low. Using a brute-force technique, you'd have to use all of the computers on the planet for thousands of years to find a collision. This is, for all intents and purposes, "impossible", and thus the hash is effectively collision-free.
With the new findings, a wealthy organization could actually find a collision with a reasonable amount of money and time.
Re:Collision free hash? (Score:5, Interesting)
The width of hash has little to do with the probability of a collision by an attacker. The cleverness of the hash algorithm is the key to collision resistance. For example, a checksum is a hash that merely breaks the int into 160 bit chunks, adds each chunk to together, takes the lower 160 bits of the sum, resulting a 160 bit hash. It is trivial to find for any given message, multiple messages that checksum hash to the same value. Thus far, no one has proven they can do that with SHA-1 (or MD5 for that matter), at least not trivially.
Of course, once one has a clever algorithm, width of the hash can be a nice factor in building up its strength, assuming the hash algorithm lends itself to scaling that way, as SHA apparently does, with SHA-256, SHA-512 being available.
Of course, for random data corruption due to faulty hardware or software, a 160 bit checksum would be excellent (if costly) protection. But that isn't what we are talking about here.
Re:Collision free hash? (Score:5, Informative)
orders of growth (Score:2, Interesting)
O(2^80) = O(2^69) = O(1). See for example http://mitpress.mit.edu/sicp/full-text/sicp/book/
Re:orders of growth (Score:3, Informative)
Re:Collision free hash? (Score:3, Insightful)
(Stupid Mean Girls quote)"Anything else is like...against the laws of feminism or something!"
Re:Collision free hash? (Score:2, Insightful)
Cheers,
Michael
Re:Collision free hash? (Score:2, Interesting)
Why are hashes like CRC-32, MD5 and SHA-1 fixed length anyway?
Re:Collision free hash? (Score:3, Insightful)
Re:Collision free hash? (Score:2)
I also want to stress that while this is a blow to the faith we placed in SHA-1 (why were we trusting a hash invented by the NSA, anyway?) it doesn't do much for most uses of SHA-1. For example, it could allow you to perform a successful man-in-the-middle attack against an SSL-encrypted HTTP session, but the user might notice something was up when response times were measured in
Re:Collision free hash? (Score:2)
It's quixotic to look for an algorithm that is
Re:Collision free hash? (Score:3, Informative)
Re:Collision free hash? (Score:2)
I think the first ever boring lecture I had was on memory paging and has colision detection of paging algorithms... that is right, hash colisions.
Now, there seems to be too much huff and puff and not enough actual insightful talk about what this actually means, which means the fallout of this will bea bout 68.5
SHA-1 (Score:5, Funny)
Re:SHA-1 (Score:2, Funny)
Re:SHA-1 (Score:4, Funny)
Re:SHA-1 (Score:2)
Hmmm (Score:5, Informative)
Well, doh - it's a hash you silly, there will always be collisions.
Anyway, it's nothing to panic about really. The ammount of computer power needed to crack it is still massive. Unless you're investigated by the NSA, SHA-1 will be fine for quite a while.
Follow-on work (Score:5, Informative)
Re:Follow-on work (Score:2)
I can see the importance of this announcement -it IS a major one, but if someone thinks he has to dump SHA-1 inmediatly because script kiddies might mess with his computer, he's far away from the truth. 2000 times faster than "takes a long fucking time" still takes a long fu
This is big... (Score:4, Interesting)
Re:This is big... (Score:2)
Why not just use SHA-2048, that wont be broken for like...6 years.
Re:This is big... (Score:5, Informative)
Re:This is big... (Score:2)
Re:This is big... (Score:2)
You'll always be upgrading methods to stay ahead of computing power.
Fortunately, it's not that hard to do.
Re:This is big... (Score:3, Informative)
Re:This is big... (Score:2, Interesting)
Well, every new development only postpones the problem. Most secret information is only valuable if it is relatively recent, so "postponing" is usually good enough.
However, if you want to encrypt something and have it unbreakable indefinitely, you're out of luck as far as I know: the typical security argument cryptographers use is "well, if you can break our encryption, you can factor in polytime." But quantum computers can factor in polytime (and who knows what els
Re:This is big... (Score:2)
Scneier mentioned that he thought in last september SHA-1 will be broken, just not that it will be broken this soon.
Re:This is big... (Score:2, Interesting)
Further compromises not far behind? (Score:2)
Aren't these rarely isolated incidents?
Isn't the probability of discovering further compromises by widespread cryptanalysis of this discovery extremely high?
56 Hours? (Score:3, Informative)
Is that assuming that that the collision will be found on the last (or in this case, 590,295,810,358,705,651,712nd time) try?
Because statistically it's just as likely you will find a collision on the first try as you are on the last try.
Re:56 Hours? (Score:2)
Crypto custom... (Score:3, Informative)
Re:Crypto custom... (Score:5, Informative)
It takes roughly 56 hours to go from a message of which hashes to 0xAABBCCDD11223344, to a message of whichh also hashes to 0xAABBCCDD11223344, which means that it would have an identical signature, meaning that the original signature would validate the fake message.
Personally its not the huge end-of-the-world scenario everyone thinks it is. It would probably take tens of thousands of years for this machine to output a well-formatted message that had a hash collision and could not be trivially discarded as gibberish.
Re:56 Hours? (Score:2)
Re:56 Hours? (Score:2)
Which is all well and good once you have the algorithim running. But until you do, all you can say is that the odds of finding the right answer will be the same for any given attempt, be it first, last, or 1,000,002,193,439,329,010.
The True Deadline (Score:4, Interesting)
The cost of cracking SHA-1 in...
3 Years - $9.5 Million
6 Years - $2.3 Million
9 Years - $600,000
12 Years - $150,000
15 Years - $37,000
18 Years - $9,000
21 Years - $2,500
Re:The True Deadline (Score:4, Insightful)
Re:The True Deadline (Score:2)
Re:The True Deadline (Score:2)
Theoretical security concerns... (Score:5, Insightful)
Great.
So, presumably, this devious (and very rich) hacker might produce the following two messages:
"bma p3 rjphta,-9p.u2#H50982u.yha,cp. hxasnip"
and
"BUEQXBBX2 jma93#9g5xbaida htuEXOAhkra1255,y"
And then, of course, he'd somehow trick me into signing "bma p3 rjphta,-9p.u2#H50982u.yha,cp. hxasnip". Because I sign random pieces of gibberish all the time, if asked. And then, having done this, he could go around claiming that I had actually signed "BUEQXBBX2 jma93#9g5xbaida htuEXOAhkra1255,y".
OH NO!
Sure. Moving to SHA-256 is all well and good. But, frankly, I think these reports are horribly overblown. Crypto geeks are jumping up and down with their hair on fire (just like George Tenet!) because their perfect algorithm is slighly less perfect in a way that doesn't have any real practical meaning in most situations.
Meanwhile, there are real security problems out there in the form of poorly written software and poorly administered systems. Please, please do not spend your time rewriting your software to use SHA-256 when you could be patching real security holes. Leave SHA-256 until you have nothing better to do.
Re:Theoretical security concerns... (Score:2)
And yes you do sign gibberish...It is called keys, which are used for encrypted communication. Now I can produce the key with the same hash as your key faster, and (depending on session speed) I can substitute my key for your key.
Now -- all this only means that I can do it about 2048 times faster...not by much, and assuming there are no other weaknesses...the sha-1 hash continues to be pretty good. The increas
Re:Theoretical security concerns... (Score:2)
Obsolutely right!
Re:Theoretical security concerns... (Score:2)
Meaning that to more easily attack my encryption key, you'd have to be in a position to choose it in the first place.
Re:Theoretical security concerns... (Score:3, Informative)
It is because given any string, I can produce another string with the same hash faster.
No, that would be a pre-image attack. This is a collision attack. To perform it, the attacker needs to be able to choose both strings.
Re:Theoretical security concerns... (Score:2)
Oh I see. So this means that I can generate a colliding pair in 2^69, but I have to generate pairs of strings without fixing any of them. Interestingly enough...if the hash is perfect then the collision attack and pre-image attack would require the same computational complexity....which makes me think is usually not the case given any hash function in P memory and time.
Obviously it is the case in the perfect hash function...but the only perfect hash that I can
Re:Theoretical security concerns... (Score:5, Interesting)
So this means that I can generate a colliding pair in 2^69, but I have to generate pairs of strings without fixing any of them.
That's it exactly. In the case of an unbroken hash that outputs 160-bit blocks like SHA-1, you'd need to generate 2^80 hashes, on average to find a collision. The reason this is 2^80 and not 2^159th is the effect of the birthday paradox [wikipedia.org].
Interestingly enough...if the hash is perfect then the collision attack and pre-image attack would require the same computational complexity....which makes me think is usually not the case given any hash function in P memory and time.
That's a very interesting statement. What do you mean by "perfect" and can you elaborate on how a hash that is "perfect" has the same collision and pre-image attack complexity? It seems to me that a "perfect" (my definition) hash that produces n-bit outputs should have no pre-image attack that has better than 2^(n-1) complexity, whereas the birthday paradox will allow a collision attack with approximately 2^(n/2) complexity (that's a really rough approximation, but it's close enough for most purposes).
Obviously it is the case in the perfect hash function...but the only perfect hash that I can think of requires exponential space.
Not so obvious to me, unfortunately, but it could be that I'm just slow. Not an infrequent occurrence, unfortunately :-/
What's the perfect hash function you're thinking of?
Re:Theoretical security concerns... (Score:2)
Please clarify something for me before I panic. You say the attack is 2048 times faster. I gather you get
Re:Theoretical security concerns... (Score:4, Informative)
It might not be that much harder to generate a collision like this:
Here is the paper!! (Score:3, Informative)
whirlpool anyone? (Score:3, Informative)
Re: ante up (Score:2)
I'll see your Public Domain and raise you a TCP/IP network freeforall.
Advice: use toolkits like SASL (Score:5, Informative)
That is why anyone developing new protocols and products that rely on security should use SASL, which abstracts the crypto layers in such a way that it's easy to change them over time.
SASL is an IETF standard and there are open source implementations like Cyrus.
Clearing up some myths... (Score:5, Insightful)
Hash algorithms are one of the least understood principles in cryptography. The established mathematics around them is contemporarily vague, but under constant research. Therefore, anytime a new publication illustrates a flaw, technique, weakness, etc. we should be pleased that our understanding has grown and that a new, more advanced algorithm can be created with the knowledge gained.
This discovery is a not something to panic about, but rather an achievement that will bring about newer, stronger encryption technology.
Breaking encryption systems is like /, stories (Score:2)
--
There is no such thing as duplication, only verification, alas alot verify the stupid.
--
Why use SHA at all? (Score:2)
Having found this [resist.ca] and other comparisons, I see little reason to use SHA (any of the versions of it) for anything. Blowfish (BFS) has military grade strength and is insanely fast to compute. While the newer versions of SHA (-256 & -512) might be significantly mor
Re:Why use SHA at all? (Score:3, Informative)
Hmm...but SHA is a hashing (i.e. one way) algorithm, and Blowfish is an encryption (i.e. bidirectional) algorithm. (For more on this, see the page you actually linked to.)
So you don't use SHA-1 as an encryption algorithm for stuff like SSH, etc., because, well, you can't. Well, you can encrypt, but good luck decrypting :-)
But you might use SHA-1 to generate crypto keys from plaintext data (e.g. passwords) for use by an encryption algorithm. So 'switching to Blowfish' won't help - you need to switch t
todays computing power and Moores Law (Score:2)
Please do not mention moores law. Why not stop all research into CPU core technology, and just wait for my CPU in my computer to double its speed every 18 months.
If anything it is an insult to those minds who give us the CPU power that we have. It is taking it for granted, that these people develop the crazy shit they do.
And I hear people using it far too much, please do not use moores law [slashdot.org].
The findings are that SHA-1 is not collision free (Score:3, Interesting)
NO hash algorithm which is capable of reducing an arbitrary number of bits to a smaller message digest, is ever going to be collision free when the input is larger than the digest. Ever.
The difficulty is normally in finding a collision, whether through brute force or algorithmically.
It would be possible to design a hash algorithm to have no collisions with input of a length smaller than or equal to the message digest. But that is of pretty limited use when we're talking about lengths like 160 bits.
Re:2000 times faster? (Score:5, Interesting)
2^80 = 2^11 * 2^69 = 2048 * 2^69
Re:2000 times faster? (Score:3, Insightful)
Re:2000 times faster? (Score:2, Informative)
2^80 = 1208925819614629174706176
2^80 / 2 ^ 69 = 2^11, which = 2048.
Yep. 2000 times faster.
Re:2000 times faster? (Score:5, Funny)
Re:2000 times faster? (Score:3, Funny)
Re:2000 times faster? (Score:5, Funny)
Just goes to show, the quickest and most effective way to get information on the net is to post something that is wrong.
Re:2000 times faster? (Score:2, Funny)
Whenever I can't figure out how to do something in Linux, I just make a post saying, "Linux sucks because it can't do XXX like Windows can!"
Within 10 minutes, I'll have 50 replies from Linux gurus around the world telling me, "You idiot, Linux's implementation is better than Windows! You just do YYY and ZZZ and boom! Bill Gates sucks!"
Re:2000 times faster? (Score:2)
Re:2000 times faster? (Score:3, Funny)
>>> FIRST CORRECTION
>> 15th actually, and you were wrong anyway.
> Depends on the desired precision.
Certainly. Because 1 is approximately equal to 15 for large values of 1 and small values of 15. If you squint.
Re:2000 times faster? (Score:3, Funny)
While the bumbers are only 11 difference yes, 69 is a much slower method for most 80, though I'm not sure its 2000 either.
Wow. That's an absolutely amazing post. It's so wrong, on so many different levels, in so many different ways, and in so *few* words... impressive as hell. You have my respect, sir.
Re:Yet Another Overblown Crypto Hack (Score:4, Informative)
Attacks on hashes have absolutely nothing to do with discovering any kind of content, they have to do with the reliability of digital signatures, key exchange, data integrity, authentication etc.
As for any kind of cryptography being sufficient...no, not really. Consider CSS...the encryption used on DVDs is no longer considered any kind of barrier to access.
Similarly publicly visible hashes in password files on Unix systems haven't been considered secure for over 10 years, due to the simplicity and success rate of dictionary attacks (plus more recently, brute force is becoming increasingly easy).
Re:Question about bit-flipping in SHA-1 (Score:3, Informative)
Re:Unrealistic? (Score:4, Insightful)
Read the whole comment: By "impossible", Bruce means "so hard it isn't worth trying." Obviously, there is no way to make an absolutely one-to-one correspondence between arbitrary-length messages and fixed-length hashes. The idea, therefore, is to make it so difficult to generate two messages with the same hash that it isn't worth anyone's effort to try.
Absolute security is almost always a chimera. You can only really achieve it with one-time pads, which aren't practical for the vast majority of cases. So you try to make things so difficult to crack that by the time anyone has succeeded, nobody still cares about the security of that message. Ideally, therefore, breaking one message does nothing to help you break any other message.
The crack of SHA-1 does help an attacker break any security system that uses SHA-1 by making it much easier to generate two messages that map to the same hash. This kind of thing makes cryptographers sit up and take notice, and hopefully develop some new algorithms. We have algorithms better than SHA, but until now nobody's had much reason to use them. This should change that.
Wow, a karma whore... (Score:2, Interesting)
(no, it's not even the same nickname)
not yet a fire alarm. (Score:4, Informative)
What, is that new? That already follows from the fact that there are only N possible hashes, and M possible messages, and NM. In other words, if you have an 8-bit hash (256 values) for a, say, 1K message, then you must get a lot of collisions.
If it takes only three days or so to find a collision, what does that mean practically? Almost nothing. Because the collision that you would find is most likely meaningless. The modification that you'd like to apply to the message (while sticking with the same, given hash) is likely to be something very specific, for example, change $1000 to $10.000. And that, unfortunately, is not easy. This vulnerability can't be easily exploited at this point.
But even saying that "if the algorithm has one vulnerability, then it's likely to have others" is totally illogical - unless a whole class of vulnerabilities has been pointed out.
It's not even time to 'walk to the door' because the fire alarm has gone off, as someone said later down in the comments. Instead, it's time to read the Chinese paper, produce more truthful descriptions of how much of a problem we are going to get with this (does it lead to more severe vulnerabilities), and start working on better hashing algorithms.
Re:not yet a fire alarm. (Score:3, Insightful)
Something tells me that the work on better hacking algorithms has already been started.
Re:not yet a fire alarm. (Score:4, Insightful)
What, is that new? That already follows from the fact that there are only N possible hashes, and M possible messages, and NM. In other words, if you have an 8-bit hash (256 values) for a, say, 1K message, then you must get a lot of collisions.
Thank you for addressing this early in the postings. I was about to go insane when I read that in the story post.
Come on, it's the basic Pigeonhole Principle. Computers Science students should have learned this in Discrete Mathematics. If you didn't, it says this: If you've got 10 holes and 11 pigeons in them, then one hole has two pigeons.
If it takes only three days or so to find a collision, what does that mean practically? Almost nothing. Because the collision that you would find is most likely meaningless. The modification that you'd like to apply to the message (while sticking with the same, given hash) is likely to be something very specific, for example, change $1000 to $10.000. And that, unfortunately, is not easy. This vulnerability can't be easily exploited at this point.
Precisely. Really, it doesn't matter if it is easy to find a message with the same hash, if the new message is obviously incorrect or unintelligible.
What I don't understand is why nobody has simply suggested using two distict hashes in any particular application. Say, MD5 and SHA-1 together. The ability to find a collision in a few days for either one may exist, but finding a message that causes a collision for both should be very hard.
Re:not yet a fire alarm. (Score:4, Informative)
To be precise, one hole has at least two pigeons.
Re:Combining SHA-1 and MD-5 as a workaround (Score:3, Informative)
It's certainly theoretically possible. If you use SHA1, which is 160 bits, and MD5, which is 128 bits, then you have a hash that is 160+128=288 bits in length. That yields 2^288 combinations.
There are, however, 2^296