Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Preparing To Migrate Off of SHA-1 In OpenPGP

kdawson posted more than 5 years ago | from the orderly-fashion dept.

Debian 152

jamie found a note on debian-administration.org, the first in a promised series on migrating off of SHA-1 in OpenPGP. "Last week at eurocrypt, a small group of researchers announced a fairly serious attack against the SHA-1 digest algorithm, which is used in many cryptosystems, including OpenPGP. The general consensus is that we should be 'moving in an orderly fashion toward the theater exits,' deprecating SHA-1 where possible with an eye toward abandoning it soon (one point of reference: US govt. federal agencies have been directed to cease all reliance on SHA-1 by the end of 2010, and this directive was issued before the latest results). ... So what can you do to help facilitate the move away from SHA-1? I'll outline three steps that current gpg users can do today, and then I'll walk through how to do each one..."

cancel ×

152 comments

Sorry! There are no comments related to the filter you selected.

He's Got a Knife! (5, Funny)

eldavojohn (898314) | more than 5 years ago | (#27876801)

'moving in an orderly fashion toward the theater exits'

An elderly application was trampled to death today as everyone struggled to exit the Sha One theater after someone screamed that an unknown assailant had a knife. After the panic, there was no evidence of injuries from the alleged attack and police are still investigating the presence of an actual weapon.

2^52 (1)

goombah99 (560566) | more than 5 years ago | (#27878201)

I could not really understand the paper in the answer. But it looked to me like they were talking about a reduction of the brute force time to solve the hash from 2^57 trials to 2^52.

2^52 is about 4x10^15. I don't know how many operations this takes to try, but 2^52 cycles of 1Ghz is 1.7 months of time.

So if it takes 10,000 1Ghz cycles to solve this then you need to accelerate this 10,000 times to get it to 1.7 months.

Brute force parallelism at that kind of scale is now very possible

As I said I did not perfectly understand what is meant by a collision 2^52 however so my consequent analysis may be wrong if it means something else.

Re:2^52 (0)

hannson (1369413) | more than 5 years ago | (#27878399)

Lets see:

2^57 = 144.115.188.075.855.872

2^52 = 4.503.599.627.370.496

2^52 / 2^57 = 0,03125 = 3,125%

I didn't read TFA but if my math is correct this is a pretty serious attack. The seriousness didn't really show in the 52 vs 57 but wow, 96% is a lot.

Re:2^52 (0, Flamebait)

cheftw (996831) | more than 5 years ago | (#27879289)

but if my math is correct

Actually it's wildly wrong;

2^57 is way bigger than 144
2^52 is also much bigger than four 4

2^52 / 2^57 = 0,03125 = 3,125%
^none of those are equal

you must be REALLY stupid

Re:2^52 (3, Informative)

Anonymous Coward | more than 5 years ago | (#27879639)

you must be REALLY stupid

typical ignorant american response.

europeans, particularly the french, tend to use the , for what we use the . for and vice-versa.

so in american, this:

2^57 = 144.115.188.075.855.872

2^52 = 4.503.599.627.370.496

2^52 / 2^57 = 0,03125 = 3,125%

becomes this:

2^57 = 144,115,188,075,855,872

2^52 = 4,503,599,627,370,496

2^52 / 2^57 = 0.03125 = 3.125%

which look like much more reasonable numbers.

Re:2^52 (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27881141)

typical ignorant american response.

Fuck yourself, eurotrash faggot piss-ant.

Why is this piece of shit's response modded "informative" but the next one is "Flamebait"?

Re:2^52 (1, Funny)

goombah99 (560566) | more than 5 years ago | (#27879731)

but if my math is correct

Actually it's wildly wrong;

2^57 is way bigger than 144
2^52 is also much bigger than four 4

2^52 / 2^57 = 0,03125 = 3,125%
^none of those are equal

you must be REALLY stupid

I've read that there are places where the people there are so uneducated they often get their commas and periods mixed up. Probably some silly problem with typwriter keys or something I guess. Anyhow how could you expect those backward people who don't even know the right symbol for a decimal point to be able to do math.

Sheesh! good thing you pointed out that bad math to the poor slob. I bet he's feeling pretty stupid right now.

Re:2^52 (2, Informative)

iluvcapra (782887) | more than 5 years ago | (#27879361)

Avoid bignums whenever possible

(2^57)/(2^52) = 2^(57-52) = 2^5 = 32 times speedup

Powers of 2 sneak up on you! :)

Re:2^52 (2, Interesting)

Joce640k (829181) | more than 5 years ago | (#27881059)

It's a collision attack, that means you can make two files with the same SHA1 in 2^52 operations (via the birthday paradox).

In the best possible application of this attack you can make two files, one good, one incriminating and get somebody to sign the good one.

The two changeling files are generated via a randomizing process so generating meaningful text files really isn't possible, the files have to contain binary data with a 'random' appearance. Examples of this would be crypto keys, SSL certificates, stuff like that.

Anybody who makes his own files and signs them is immune to this attack. The SHA1 of your favorite Linux distro is as safe as ever.

So ... this attack isn't very useful in the real world but it does show that SHA1 is slowly being deconstructed, that relationships are being found between input bits and output bits.

First MD5 and now this (0)

Anonymous Coward | more than 5 years ago | (#27876835)

Is there any hash function that actually is secure?

Re:First MD5 and now this (3, Funny)

piripiri (1476949) | more than 5 years ago | (#27876851)

Is there any hash function that actually is secure?

Of course the good ol' rot13 !

Re:First MD5 and now this (3, Funny)

eldavojohn (898314) | more than 5 years ago | (#27876997)

Is there any hash function that actually is secure?

Of course the good ol' rot13 !

Not secure enough, better apply it twice for double protection.

You can tell the men from the boys by how many times they do things. Like when I restart my computer, I do it three times to make sure it will work when the things start back up inside it.

Re:First MD5 and now this (2, Funny)

sadness203 (1539377) | more than 5 years ago | (#27877029)

Pffff, doing it 2-3 times is for amateur.

I personally use a special rrot13. Or if you prefer, Reverse Rot13.

It's so advanced, they are still trying to break it at NSA.

Re:First MD5 and now this (1)

oldhack (1037484) | more than 5 years ago | (#27877589)

Noob. Use your brain. What good will the three-booting do without the chicken bone?

Re:First MD5 and now this (1)

KingPin27 (1290730) | more than 5 years ago | (#27879045)

my GF always says its a good idea to "double up" -- you can never be too sure.

Practice Safe Hex -- Wear a computer condom.

Re:First MD5 and now this (1)

Just Some Guy (3352) | more than 5 years ago | (#27880101)

Of course the good ol' rot13 !

<pedant>ROT13 isn't a hash function.</pedant>

In theory, no (3, Insightful)

3.5 stripes (578410) | more than 5 years ago | (#27876875)

In reality, given the time and effort, processing power, etc... yeah, there are some secure ones.

They're like locks, they make getting in hard enough that most people will look for an easier target.

Re:In theory, no (1, Insightful)

rlseaman (1420667) | more than 5 years ago | (#27877141)

They're like locks, they make getting in hard enough that most people will look for an easier target.

And they're unlike locks, in that a fruitful attack can occur many years afterwards. A lock need only supply protection for a specific period of time - if no bad guys get in during that period, then the security can be regarded as perfect no matter how insipid in design. In cyber-security, even "near-perfect" is as imperfect as "completely lacking" - at least for high priority targets with legacy value.

Re:In theory, no (1)

3.5 stripes (578410) | more than 5 years ago | (#27877523)

Well, we're then assuming that the encrypted file will remain where it is (and in its current form).. if the object behind the locked door was to remain there indefinitely, the same sort of disclaimers apply (the better technology gets, the easier it will be to open)..

Re:In theory, no (1)

Nitage (1010087) | more than 5 years ago | (#27878079)

SHA-1 is a cryptographic hashing algorithm, not and encryption algorithm.

Re:In theory, no (2, Insightful)

AvitarX (172628) | more than 5 years ago | (#27877641)

Considering the time for even a modestly skilled person to get into most locks is < 5 minutes (home locks anyway), I would say that it is not perfect.

High-security locks take longer, as does high-security encryption. We only need to use algorithms that have a MTBF of around 1000 years today, and baring quantum breakthroughs your pretty safe. I mean how long does even the most sensitive data need to remain protected? 30 years?

I guess if you are a high-profile politician/activist, or a murderer a little longer?

Re:In theory, no (1)

AvitarX (172628) | more than 5 years ago | (#27878065)

After thinking critically, I will amend my post.

You really need closer to 10,000 with todays tech, this allows it to take about 20 years before it is feasible to try and get it before the end of 30 years.

And by about 30 years it will be readily crackable.

Re:In theory, no (2, Interesting)

coolsnowmen (695297) | more than 5 years ago | (#27878477)

I mean how long does even the most sensitive data need to remain protected? 30 years?

Whatever the copyright length is...so about forever.

Re:In theory, no (1)

iluvcapra (782887) | more than 5 years ago | (#27879561)

I mean how long does even the most sensitive data need to remain protected? 30 years?

The exact method for constructing an atomic bomb is still secret, though most nuclear physicists could give you a good surmise... The exact method for constructing a Tellar-Ulam thermonuclear bomb is also still a secret that we wouldn't want to be generally available, and that's over 50 years old.

You do make a good point though, that "planned obsolescence" is a good feature to look for, particularly in a government encryption algorithm. The problem is that when attacks are found in these algorithms, they tend to reduce the amount of time required to crack the key by a factor of thousands, so suddenly your 30-year signature on the data is only good for a month, before some attacker can start passing off his messages as yours.

Re:In theory, no (1)

blueg3 (192743) | more than 5 years ago | (#27877767)

No, in proper cybersecurity, one should realize exactly that a particular protection mechanism is only likely to be secure for a limited period of time. There are even expected security times associated with different algorithms and key sizes.

This is why, for example, signing keys should only be valid for a limited period of time. It would be foolish to assume that it will remain secure forever, so it should be designed to become useless before it becomes insecure.

Re:In theory, no (1)

Maximum Prophet (716608) | more than 5 years ago | (#27878133)

Right, almost secure isn't good enough for privacy, where you don't want others to know the contents of a file even after you have passed away. "Mostly Secure", is good enough for multi-million dollar transactions that will be vapor soon after they are completed. As long as someone can't tamper with them during the transfer, it's ok.

A paradox in that an extremely valuable transaction may need less security than an almost worthless (to anyone else) file.

Re:In theory, no (1)

OrangeTide (124937) | more than 5 years ago | (#27878627)

Decrypting my credit card numbers from 10 years ago will do you no good. The security is as important or unimportant for physical security as it is for cyber security.

A filing cabinet with 50 year old government secrets might need to be as physically secure now as it was 50 years ago. Where as my expired and canceled credit card numbers, not so much.

Re:In theory, no (2, Insightful)

rlseaman (1420667) | more than 5 years ago | (#27879399)

A filing cabinet with 50 year old government secrets might need to be as physically secure now as it was 50 years ago. Where as my expired and canceled credit card numbers, not so much.

Yes, but the value of physical security is cumulative. If you manage to protect government secrets for 50 years - even if this involves a $2 padlock and a footlocker - the security can be upgraded at any point to a higher level suitable for current threats. Cyber security on the other hand is only as good as its weakest expression over those 50 years. Expose a rot13 copy of a file even one time and it doesn't matter if you later re-encrypt the file using the NSA's latest and greatest algorithm.

Re:In theory, no (1)

Dragonslicer (991472) | more than 5 years ago | (#27878045)

They're like locks, they make getting in hard enough that most people will look for an easier target.

And just like locks, there isn't really a whole lot you can do to prevent brute force attacks.

Re:In theory, no (1)

Zomalaja (1324199) | more than 5 years ago | (#27878151)

If you are Mr. Bad Guy and you MUST have the document that ensures you world domination, having it encrypted won't make you look for an easier target. A home burglar might, but he/she is just looking for something of value, not something so specific.
Good encryption makes the bad guy say "screw this" after his network of quad core boxes gets no results after 2 weeks/whatever time period of churning.

Re:First MD5 and now this (5, Insightful)

Anonymous Coward | more than 5 years ago | (#27876877)

Perfect security is not feasible. "Secure enough" changes over time.

Mod Parent Up (0)

Anonymous Coward | more than 5 years ago | (#27877855)

And as the time it take to break encryption decrease, so do the time it takes to encrypt something.

Aren't we just throwing more and more bits to the seed?

Re:First MD5 and now this (1)

jd (1658) | more than 5 years ago | (#27879441)

"Perfect security" varies according to what constitutes "perfect". For example, one-time pads can be considered perfect, if you can guarantee the security of the pads.

(One suggested method is to use a cosmological source of randomness and transmit encrypted the position of the radiosource. Since any time delay will result in not having the same pad as the people on either side, the pad is essentially guaranteed secure even if the encryption is broken, provided it cannot be decrypted through the attack faster than it can be decrypted normally.)

This is obviously feasible for, say, GCHQ communicating with the NSA, as they can easily set up small radio observatories at their respective bases. It is equally obviously not feasible for communicating to someone hiking over the Alps, as you can't really fit a decent-sized dish into a backpack.

For very large collaborative groups, it is feasible to use some form of Byzantine key splitting to ensure the key is safe and to do some encryption/decryption in parallel. This is a very different scenario from one person talking to another directly, where both must have the full key and the algorithm complexity is limited by the fact that single computers aren't very good at parallelizing tasks yet.

Re:First MD5 and now this (5, Informative)

swillden (191260) | more than 5 years ago | (#27877035)

Is there any hash function that actually is secure?

There are some for which no known attacks exist. SHA-256 and SHA-512, Whirlpool and Tiger are all pretty thoroughly-reviewed with no weaknesses uncovered. The NIST hash function competition is causing a great deal of new hash function research and we'll almost certainly get a bunch of great new hash functions out of it -- many of them not only secure, but significantly faster than SHA-1.

If you're thinking that "no known attacks" isn't good enough, keep in mind that's as good as it every gets in cryptography, with the sole exception of the One Time Pad

Re:First MD5 and now this (4, Informative)

Kjella (173770) | more than 5 years ago | (#27877585)

If you're thinking that "no known attacks" isn't good enough, keep in mind that's as good as it every gets in cryptography

I think my math teacher would call that a "necessary but not sufficient" condition, I mean anything can be without known attacks by virtue of never having been reviewed. Minimums should include:

1. Published algorithm, no "secret sauce" security by obscurity
2. Solid peer reviews by other cryptographers, definately not just the vendor or their hirelings
3. Strong links to well-researched hard mathematical problems

Of course, nothing can guarantee that the NSA hasn't found some super-secret math thingie that'll cut through it like a knife through hot butter. But cryptography is also about eating your own dog food, if you don't use it for anything valuable who'd trust it? You can't really keep that a secret because you have to tell lots of people that this isn't really secure or they'd use it as if it were. And if you do use it for your valuables, would you really leave that kind of backdoor for someone else to find? Again it doesn't prove anything, but I think most modern crypto algorithms have no weaknesses known to anybody, and if one showed up it'd be just as big a OMG for those who made/approved it as everyone else.

Re:First MD5 and now this (1)

jd (1658) | more than 5 years ago | (#27879495)

The crypto lounge and hash lounge have a list of known flaws/attacks/documented partial attacks in algorithms. It's a good place to start... ...well, to start being paranoid, anyway, as more than a few of the algorithms listed have this nice skull-and-crossbones by them.

Re:First MD5 and now this (1)

wirelessbuzzers (552513) | more than 5 years ago | (#27880573)

Strong links to well-researched hard mathematical problems.

This is usually only true for asymmetric (public-key) crypto. There are hash functions which are provably secure if some math problem is hard... pretty good math problems too (discrete log, not something "easier" like DDH).

But they're fabulously slow, not to mention they operate over prime-order fields instead of on bytes (this is a bigger problem for block ciphers than for hashes). We accept this slowness for public-key crypto because it seems to be required, and because only the header has to go through the public-key part. But every byte has to pass through the symmetric part.

There is an argument to be made that collision-resistance isn't that important (compared to a keyed version) and cryptographers should be willing to pay more for it. In this case, we'd use SHA-1 or MD5 for signatures and some other thing for fancier cases that actually require collision resistance.

Re:First MD5 and now this (2, Informative)

swillden (191260) | more than 5 years ago | (#27881225)

If you're thinking that "no known attacks" isn't good enough, keep in mind that's as good as it every gets in cryptography

I think my math teacher would call that a "necessary but not sufficient" condition, I mean anything can be without known attacks by virtue of never having been reviewed. Minimums should include:

1. Published algorithm, no "secret sauce" security by obscurity 2. Solid peer reviews by other cryptographers, definitely not just the vendor or their hirelings 3. Strong links to well-researched hard mathematical problems

Absolutely correct, with the partial exception of #3. It would be nice, perhaps, if #3 applied, but most symmetric ciphers and secure hash algorithms rely on complexity rather than hard problems.

Re:First MD5 and now this (1)

Maximum Prophet (716608) | more than 5 years ago | (#27878213)

More like no attacks are feasible. If you have an N-bit document, an N-bit quantum computer can attack it. Since the largest quantum computer know is like 3 bits, you should be safe for awhile.

OTP and physical security are the only way to go.

Re:First MD5 and now this (1)

cant_get_a_good_nick (172131) | more than 5 years ago | (#27879111)

One Time Pad has no technical flaws, but still has to be used correctly. I remember hearing that 's how the US broke a rusian nuclear spy ring - the russians got lazy with the one time pad, and the US spies had enough info to see what was happening.

My basic point - if you fix the human side of all these encryption issues, you'll be plugging up a lot of holes. Don't expect a 'perfect security' you can set and forget.

Re:First MD5 and now this (1)

jd (1658) | more than 5 years ago | (#27879525)

Enigma was an approximation to a one-time pad (mostly because you could reconnect the plug boards as you liked and re-order the wheels as you liked), but was likewise cracked because of carelessness of use.

Re:First MD5 and now this (1)

Ex-Linux-Fanboy (1311235) | more than 5 years ago | (#27879411)

SHA-256 and SHA-512, Whirlpool and Tiger are all pretty thoroughly-reviewed with no weaknesses uncovered

Tiger actually is vulnerable to a "pseudo-near-collision" ref [springerlink.com] . No, I have no idea what a "pseudo-near-collision" is, but Tiger's vulnerable to it.

My favorite hash is RadioGatun [wikipedia.org] , but I also like Keccak [wikipedia.org] . I would like Skein [wikipedia.org] , except there is no published variant of it that uses 32-bit words (Whirlpool [1] and Tiger have the same problem).

[1] Yes, you could make a Whirlpool variant with a 128-bit or even 256-bit hash using AES as the compression function, but I prefer to stick to published crypto, since I don't know how to make a truncated differential.

Re:First MD5 and now this (3, Informative)

Amouth (879122) | more than 5 years ago | (#27877067)

by definishion a hash function can't be safe you are taking something that is of unknown size and giving a specific lenght result which will always be the same for a given input.

due to the limited length of the result using inputs larger than the result you can assure at some point there will be a collision (2 diffrent inputs with the same output)

MD5 failed after enough people looked at it and someone figured out how to salt it to get collisions quite quickly.

as proccessing power increases brute force is getting easier - but when you find a way of cutting down the brute force required.. that is when something can become very weak very quickly.

Re:First MD5 and now this (5, Informative)

Anonymous Coward | more than 5 years ago | (#27877185)

That is not what secure means with regard to hash functions. Secure means that it is not feasible to construct a document which has the same hash value as a given document (pre-image attack) or to construct two documents which have the same hash value (collision attack). The complexity of these attacks is ideally such that simply enumerating documents is the fastest way (brute force). Reducing the number of documents which you have to try to find a match makes a successful attack more likely. The complexity which is deemed as breaking the hash function depends on the adversaries and time frames relevant to a particular application.

Re:First MD5 and now this (1)

kestasjk (933987) | more than 5 years ago | (#27878711)

Hash functions have many uses, a hash function can be perfectly secure for one application but not for another. (In fact this is practically always the case for defects found in modern hash functions.)

Re:First MD5 and now this (1)

petermgreen (876956) | more than 5 years ago | (#27879871)

Another big issue with a lot of current hash functions (at least MD5 and I think SHA1 too) is that thier block based nature means that if you can reasonablly generate two collisions of "random garbage" you can reasonablly generate two files with a prefix you choose before generating the collisions, followed by the two sets of "random garbage" followed by a suffix you choose AFTER generating the collisions.

Combine that with a carefully selected file format (IIRC it can be done with pdf) and you can make two files that have the same hash with different meaningfull content visible and no visible random garbage.

This makes "random garbage collision" attacks much worse than they would appear at first sight.

Re:First MD5 and now this (1)

Hatta (162192) | more than 5 years ago | (#27877865)

SHA-1, and monkeys might fly out of my butt!

What's this "Off of" (0, Offtopic)

Anonymous Coward | more than 5 years ago | (#27876885)

"Off of"

Are we in grade school?

SHA2 Family still secure (4, Informative)

marcosdumay (620877) | more than 5 years ago | (#27876957)

From TFA, so others don't have to read it, GPG will stay with SHA 224, SHA 256, SHA 384 and SHA 512.

Re:SHA2 Family still secure (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27877627)

If I understand the attack correctly, I think most real-world SHA-1 usage should be secure for the time being. From the looks of it, the researchers were able to reduce the time necessary to find two inputs that hash to the same digest. This is very different from finding a second input that hashes to a known digest. If that were the case, common hash applications like storing the digest of passwords or a digital signatures would be vulnerable.

But until researchers can take a known digest value and find an alternate set of input data, most real-world applications should be okay. News like this should make people start to look at when they can conveniently migrate away from SHA-1, but it's not something that requires immediate attention.

Re:SHA2 Family still secure (0)

Anonymous Coward | more than 5 years ago | (#27878293)

The attack which created a signed bogus SSL certificate was a collision attack, not a pre-image attack. The researchers managed to produce two signing requests, where one was for a legitimate certificate, which got signed, and the other was for a CA certificate, which would never have been signed. They could then transfer the signature to the CA certificate, because the MD5 hash values which were signed were the same for the two certificates. If a similar attack becomes feasible against SHA1 hashed certificates, that will definitely cause quite a stir.

I Hate PDF. (-1, Offtopic)

GargamelSpaceman (992546) | more than 5 years ago | (#27877051)

I hate PDF. I wish it would die die die. I wish nothing would replace it. TEXT. It' what people read.

Aww man, I just upgraded to SHA-1 (4, Funny)

Anonymous Coward | more than 5 years ago | (#27877075)

I guess I'll just go back to good old MD5.

Re:Aww man, I just upgraded to SHA-1 (1)

DougWare (1515559) | more than 5 years ago | (#27877195)

I hope you were joking... MD5 isn't encryption, it's a hash. Encryption has to be reversible with a passphrase, hashes are not irreversible.

Re:Aww man, I just upgraded to SHA-1 (1)

DougWare (1515559) | more than 5 years ago | (#27877245)

Sorry, I meant to say hashes are irreversible, or that that hashes are not reversible...I changed my train of thought in the middle of a sentence.

Re:Aww man, I just upgraded to SHA-1 (0)

Anonymous Coward | more than 5 years ago | (#27879787)

I hope you were joking... SHA1 isn't encryption either.

Re:Aww man, I just upgraded to SHA-1 (0)

Anonymous Coward | more than 5 years ago | (#27877257)

Uh, DougWare, what do you think SHA stands for? The hash is used as part of the digital

Re:Aww man, I just upgraded to SHA-1 (0)

Amazing Quantum Man (458715) | more than 5 years ago | (#27877309)

So is SHA-1.... Secure Hash Algorithm

And also, that whooshing sound you heard was the joke going over your head.

VeriSign, is that you? (0)

Anonymous Coward | more than 5 years ago | (#27880405)

I realize you're joking, but just yesterday I received an email VeriSign sent to all resellers that they're upgrading to an SHA-1 root certificate for all SSL certificates. Here's the main part of the message:

In our ongoing dedication to providing you and your customers with the optimum balance of strong security and functionality, VeriSign will be upgrading all GeoTrust and RapidSSL SSL products to a 1024-bit, SHA-1 root on May 28, 2009. The root we will chain all the GeoTrust and RapidSSL products to is the Equifax Secure Certificate Authority. thawte SSL certificates will be upgrading to a 1024-bit, SHA-1 root in the future. You will receive advanced notification before any changes are made.

In a related news... (1, Insightful)

Vexler (127353) | more than 5 years ago | (#27877133)

...I am moving "off of" this grammar-school newsletter piece.

This is news for nerds, not news for dropouts.

Not a grammar faux paux (0)

Anonymous Coward | more than 5 years ago | (#27879993)

"Off of" is actually the accepted common usage in the USA (for > 150 years), whereas British English leaves off the "of."

Re:In a related news... (3, Insightful)

Just Some Guy (3352) | more than 5 years ago | (#27880223)

...I am moving "off of" this grammar-school newsletter piece.

See also: idioms. No one where I live, ditch digger or professional, would raise an eyebrow at that phrase. Might I suggest you find larger grammatical fish to fry, or perhaps resolve not to get worked up over regional slang?

Reencrypting Stored Secrets? (-1, Offtopic)

Doc Ruby (173196) | more than 5 years ago | (#27877189)

All secrets encrypted using the old SHA-1 process will remain vulnerable to attacks unless reencrypted with a new, safe process. Is there any SW that tracks the secrets, which cipher/process protects them, and then reencrypts them with the new, safe one?

Note that any secrets that got out there but were considered safely encrypted with SHA-1 might now be cracked, now that SHA-1 is vulnerable. Those copies out there cannot be reencrypted, since it's safe to assume that bad guys have them. This situation is necessary to consider when letting even encrypted secrets out into the wild. Encryption can at best delay decryption, by an unknown duration.

Re:Reencrypting Stored Secrets? (4, Informative)

John Goerzen (2781) | more than 5 years ago | (#27877217)

SHA-1 doesn't encrypt things. It makes a hash of them, to verify they haven't been modified.

There are no secrets encrypted with SHA-1 because SHA-1 doesn't encrypt things.

Re:Reencrypting Stored Secrets? (0)

Anonymous Coward | more than 5 years ago | (#27877321)

SHA-1 doesn't encrypt things. It makes a hash of them, to verify they haven't been modified.

True, though pedantically speaking there are well-documented means of turning any hash function into an encryption algorithm: in fact, I've used SHA myself to do that in software where we were allowed to use hash functions but not algorithms specifically designed for encryption.

Re:Reencrypting Stored Secrets? (0)

Anonymous Coward | more than 5 years ago | (#27878733)

What the fuck are you talking about?

Re:Reencrypting Stored Secrets? (1)

profplump (309017) | more than 5 years ago | (#27878803)

I hate to break this to you, but any "well-documented means of turning any hash function into an encryption algorithm" *is* an algorithm specifically designed for encryption, so you're still breaking the rules.

Re:Reencrypting Stored Secrets? (0)

Anonymous Coward | more than 5 years ago | (#27880357)

I hate to break this to you, but any "well-documented means of turning any hash function into an encryption algorithm" *is* an algorithm specifically designed for encryption, so you're still breaking the rules.

Yeah, I know that, and you know that, but it made my boss happy.

Re:Reencrypting Stored Secrets? (0)

Anonymous Coward | more than 5 years ago | (#27879843)

No....

Re:Reencrypting Stored Secrets? (1, Informative)

Anonymous Coward | more than 5 years ago | (#27877275)

Hash functions are not used in encryption and decryption. Their cryptographic use is in authentication, for example in key exchange protocols and cryptographic signatures.

Re:Reencrypting Stored Secrets? (0)

Anonymous Coward | more than 5 years ago | (#27878531)

In the real world, hash algorithm are used in encryption, not as a cipher but for "key expansion."

Stupid question, but... multiple hashes? (3, Interesting)

tlhIngan (30335) | more than 5 years ago | (#27877269)

Really stupid question (not a cryptographer), but is there anything wrong with using multiple hash algorithms (hopefully none derived from one another)? Surely breaking two or more hashes simultaneously would be far harder?

E.g., MD5 is broken. But what if we use both MD5 and SHA-1?

Re:Stupid question, but... multiple hashes? (3, Informative)

russotto (537200) | more than 5 years ago | (#27877503)

Really stupid question (not a cryptographer), but is there anything wrong with using multiple hash algorithms (hopefully none derived from one another)? Surely breaking two or more hashes simultaneously would be far harder?

E.g., MD5 is broken. But what if we use both MD5 and SHA-1?

Unfortunately not; once you've broken the strongest hash, the rest can be broken in polynomial time.

http://article.gmane.org/gmane.comp.encryption.general/5154 [gmane.org]

Re:Stupid question, but... multiple hashes? (4, Informative)

blueg3 (192743) | more than 5 years ago | (#27877869)

This has nothing to do with multiple hash algorithms. What you're referring to is that finding an n-way collision from a 2-way collision is polynomial time. That is, a 2-way collision is two documents with the same hash, and an n-way collision is n documents with the same hash.

Finding a pair of documents that have the same SHA1 hash doesn't help you find a pair of documents with the same MD5 hash. Indeed, none of the efficient-collision algorithms allow you to find collisions in both SHA1 and MD5 simultaneously. (Note that, as far as I know, there aren't even any efficient preimage attacks on MD5 or SHA1, only collision attacks.)

Using multiple hash algorithms is helpful, yes.

Re:Stupid question, but... multiple hashes? (1)

DangerousDana (1415421) | more than 5 years ago | (#27880029)

Here's an even more off-topic question, but, when brute-forcing an encrypted hunk of data, how does one know when the encryption has been successfully decrypted? Especially so for small data sets. Any hackers wanna weigh in here?

Re:Stupid question, but... multiple hashes? (1)

blueg3 (192743) | more than 5 years ago | (#27880955)

For most systems, think about it in terms of the application developer. Say you encrypt a piece of e-mail with a password-based secret key. (Some function k(p) turns a password p into an n-bit key.) If you supply the wrong password, what should the system do? Usually you want the strength of the system to rest on the cryptography and not the inability to tell if a decryption was successful, so you simply include a marker to indicate if the decryption was successful. (There are standard padding and encoding schemes for this.)

Take an extreme mathematical case, though. Let's say I'm doing 128-bit AES, which operates on 16-byte blocks. Say I use no padding and have a 16-byte message. The decrypter will need to guess based on the properties of the mesage if the decryption worked. Even with only 16 bytes, if those bytes are English text, this is quite doable. If you've carefully chosen your messages so that all 16-byte messages are equally probable, then it's impossible, right? A test decryption e+k->p will produce a valid, reasonable plaintext, regardless of what the encrypted block e or key k are.

This is, incidentally, basically how TrueCrypt's deniable plausability works. The TrueCrypt headers are designed so that, in theory, every possible set of bytes is equally likely. The space the header would be stored in is filled with random data, which has the property that every possible set of bytes is equally likely. You then can't differentiate a block containing a header with one containing no header.

Re:Stupid question, but... multiple hashes? (0)

Anonymous Coward | more than 5 years ago | (#27879367)

Sitting here I think it may even be worse than that.

Lets say I have hash1 and hash2 and do not know the message.

It gives me a nice intersection space to 'test' if I got the right message! As both hash's would have to work.

Re:Stupid question, but... multiple hashes? (3, Informative)

SparkleMotion88 (1013083) | more than 5 years ago | (#27877739)

Surely breaking two or more hashes simultaneously would be far harder

You can't be "sure" about much in cryptography. If m is a message, and f and g are hash functions, you are assuming that you get more security from f(g(m)) than from f(m). You have to define what kind of security you are hoping for. With hash algorithms, you usually want: given m', it is difficult to find some m where h(m) = m'.

So to answer your question, using f(g(m)) would only be more secure than f(m) if f contains some vulnerability and no cryptanalytic vulnerability is introduced by combining f and g. If I don't have any information about either type of vulnerability, I would have no reason to assume that f(g(m)) is more secure than f(m). In this situation, I would stick with f(m) because it has been studied more and people have probably spent time trying to break it.

To put it another way, breaking f(g(m)) does not necessarily require breaking both f and g. The resulting algorithm that you get by composing f with g is still only one algorithm (just like SHA-1), and that is the only algorithm that needs to be broken.

Re:Stupid question, but... multiple hashes? (4, Insightful)

YesIAmAScript (886271) | more than 5 years ago | (#27877837)

I'm not so sure he's talking about applying one hash to the other's output, as much as performing both hashes on the same material and storing both results, also checking both results. Then you'd have to create a collision for both hashes in order to beat the system.

Re:Stupid question, but... multiple hashes? (1)

atfrase (879806) | more than 5 years ago | (#27879153)

I'm not so sure he's talking about applying one hash to the other's output, as much as performing both hashes on the same material and storing both results, also checking both results. Then you'd have to create a collision for both hashes in order to beat the system.

IANAC(ryptogrpher), but..

it seems like the question yet remains whether deriving x (the password, source data, whatever) given both hashes f(x) and g(x) is easier or harder than having only one of the two (just like the question of whether f(g(x)) is harder than f(x)).

On the one hand, I can visualize that as having a smaller set of possible x that, when hashed, yield not only f(x) but also g(x). That reduction in the ratio of collision-hit-x's to all-possible-x's seems like it would at least make brute force harder.

On the other hand, I can also visualize that having g(x) in addition to f(x) is just more data to work with, which seems like it would make the problem easier; i.e. g(x) might not give many clues about x by itself, but combined with clues from a different algorithm f(x), maybe it'd be easier to find x?

Can any real cryptographers comment?

Re:Stupid question, but... multiple hashes? (1)

RiotingPacifist (1228016) | more than 5 years ago | (#27878783)

Such a long post for the content:

f(g(m)) may be stronger or weaker than g(m) or f(m) but i have no evidence either way, however g has been tested more than f.g

OR

I dunno, but SHA-1 has been tested more than MD5 on SHA-1

Re:Stupid question, but... multiple hashes? (1)

m50d (797211) | more than 5 years ago | (#27878653)

Really stupid question (not a cryptographer), but is there anything wrong with using multiple hash algorithms (hopefully none derived from one another)?

Yes, there is a lot wrong with it. I would go into detail but you can find good explanations in any of the past, say, twenty stories posted here about hash algorithms.

Surely breaking two or more hashes simultaneously would be far harder?

No; not by enough to make it worthwhile, possibly not at all. E.g. if you're willing to use 256 bytes of hash, you're much better off using SHA-256 than two 128-byte hashes.

Re:Stupid question, but... multiple hashes? (1)

VeNoM0619 (1058216) | more than 5 years ago | (#27879703)

No; not by enough to make it worthwhile, possibly not at all. E.g. if you're willing to use 256 bytes of hash, you're much better off using SHA-256 than two 128-byte hashes.

Makes some sense, but the difference is, they only have to break 1 algorithm. He is looking at it like "they broke SHA-1, big deal, break another well tested and secure hash algo". But I would say that the more different hashs you throw in, the better (but longer validation process, which some reason to defeat the purpose of a hash, since it's meant to be a short validation).

Re:Stupid question, but... multiple hashes? (1)

m50d (797211) | more than 5 years ago | (#27880841)

He is looking at it like "they broke SHA-1, big deal, break another well tested and secure hash algo".

I know. It's still wrong.

Re:Stupid question, but... multiple hashes? (0)

Anonymous Coward | more than 5 years ago | (#27880515)

I used to use the rot13 algorithm. But for added security, I use it twice.

Yes, I know, trivial example, but it's still a valid point. Adding a second hash on top of a first may reduce the overall strength.

Well that's unfortunate (4, Funny)

Morphine007 (207082) | more than 5 years ago | (#27877289)

Guess the Aussies overpaid, since their $560k "unbreakable" cryptosystem relies on SHA-1 [slashdot.org] . Shock of shocks, I know...

Re:Well that's unfortunate (1)

jd (1658) | more than 5 years ago | (#27879213)

If they pay me another $560k, I'll upgrade them to SHA-2 or Midnight Blue. (Either that, or I'll figure out how to Seuss the names of hashes.)

If so, someone please put this to good use! (3, Insightful)

YesIAmAScript (886271) | more than 5 years ago | (#27877291)

So many major systems are secured with PK systems that depend on SHA-1 hashes now. If this can be broken, someone please put this to good use by making a collision that makes it possible for people to write homebrew code for the PS3 or 360.

I keep hearing about all these hash collisions and how I should be scared, but I wish I could at least get the good with the bad.

Re:If so, someone please put this to good use! (1)

gmuslera (3436) | more than 5 years ago | (#27878573)

Reading about collisions and gaming consoles risk to put the context far away from the crypto topic, specially if you think that PK and SHA-1 could be great as car model names.

Re:If so, someone please put this to good use! (1)

petermgreen (876956) | more than 5 years ago | (#27880073)

Afaict collisions aren't much use for such things, unless you could make two apps one malicious one non-malicious that collided and somehow get the non-malicious one signed to high privilages. But if you are in a position to do that you can just get code with a hidden malicious feature signed.

better packaging for debian (4, Insightful)

bcrowell (177657) | more than 5 years ago | (#27877373)

So what can you do to help facilitate the move away from SHA-1?

One specific thing that would really help would be if debian would make it a priority to do a complete job of packaging the relevant hash functions, along with bindings for popular languages. For instance, I have an open-source perl app [lightandmatter.com] that uses digital watermarks. The user can choose between SHA1 and Whirlpool. However, I want to keep my app simple for users to install, and the perl binding for Whirlpool hasn't been packaged for debian yet, so I've made SHA1 the default. A debian user who wants to use Whirlpool with my app has to jump through hoops, e.g., installing the perl module via CPAN. That's actually a real pain for a debian or ubuntu user, because CPAN and apt don't play nicely; you can get in all kinds of screwed-up states if you try to install half your perl modules using apt and half using CPAN.

TFA is talking about gpg. Well, realistically, the choice of hash function is not the bottleneck in terms of security when it comes to sending encrypted or signed email. The bottleneck is mainly just that it's too hard to use (isn't built in to most GUI email clients), and in the case of encryption it also suffers from negative network effects -- there's no big benefit to me from using gpg encryption in my email unless the people I'm communicating also use the technology. The world's best crypto doesn't do you any good if you don't use it because it's too much of a pain. I think gpg is clearly a case where the perfect has been the enemy of the good. They've been so hung up on protecting the user against obscure vulnerabilities that they've ended up making the darn thing too hard for the vast majority of users. The docs, last time I checked, were basically written in Martian. I have a bachelor's degree in math, I program computers as a hobby, and I've read Schneier's Applied Cryptography. I'm not claiming that makes me a big expert on crypto, but it does put me out in front of the vast majority of the population. Well, I simply cannot figure out all the ins and outs of gpg. Okay, I could, but it would take more time than I'm willing to invest.

Re:better packaging for debian (2, Funny)

Anonymous Coward | more than 5 years ago | (#27878117)

One specific thing that would really help would be if debian would make it a priority to do a complete job of packaging the relevant hash functions, along with bindings for popular languages.

However, as this is Debian they are more likely to "disable" SHA-1 by making it emit the plaintext.

What about SSL certificates? (4, Interesting)

200_success (623160) | more than 5 years ago | (#27878759)

According to x509(1) and ca(1), OpenSSL supports md2, md5, sha1, and mdc2 as options for message digests for certificates. Since MD2 and MD5 are already broken, and SHA1 is now suspect, that leaves just the relatively obscure MDC-2 [wikipedia.org] .

Re:What about SSL certificates? (3, Informative)

Cruicky (1122359) | more than 5 years ago | (#27879175)

The OpenSSL package in Ubuntu supports SHA224, SHA256, SHA384, and SHA512, even though it's not actually shown in the help, with the command line options being -sha224, -sha256, -sha384 and -sha512.

I've been happily using SHA512 with a personal CA for the last year.

It's possible that other distributions have also compiled in support for these hash functions in their OpenSSL packages.

Re:What about SSL certificates? (0)

Anonymous Coward | more than 5 years ago | (#27880245)

A good point; it seems common place for minimal computational power to come first, followed by robust hashing - or at least what is left - in second.

Respective life spans are not to be forgotten and thinking ahead can be a virtue.

Re:What about SSL certificates? (1)

jd (1658) | more than 5 years ago | (#27879249)

A good point, especially given that sites upgraded to SHA-1 from MD5 after the debacle over forged certificates. They're not going to want to upgrade again, especially to something obscure.

Re:What about SSL certificates? (1)

drspliff (652992) | more than 5 years ago | (#27881195)

And not blowfish, sha256, sha512?

Singularity? (0, Offtopic)

Sybert42 (1309493) | more than 5 years ago | (#27879755)

Is this very useful for Singularity-related research? There's a generally open-atmosphere (with Opencog spun off from Novamente), and realization of the stakes involved.

Can someone give me a quick rundown? (3, Interesting)

swordgeek (112599) | more than 5 years ago | (#27880317)

It's been a while since I had to deal with PGP keys and the like, and things have multiplied since then. Is there a simple explanation for the status/compatability/equivalency of...

pgp
openpgp
gpg
gnupg

And any others I'm missing?

effect on digital signature algorithms (1)

huwgently (1337863) | more than 5 years ago | (#27881041)

The NIST article mentions:

The attack primarily affects some digital signature applications, including timestamping and certificate signing operations, where one party prepares a message for the generation of a digital signature by a second party, and third parties then verify the signature.

There's an easy solution here as mentioned in Applied Cryptography (2nd edition). To paraphrase, when given a document to sign using a hash-based digital signature protocol, make sure to make some trivial edits to the document first. Otherwise, you run the risk that the person asking you to sign the document has already calculated a hash collision for that document, meaning that at a later date they can use your signature as "proof" that you signed some more nefarious document which has the same hash. Funnily enough, I think SHA-1 was mentioned somewhere in that same section...

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?