Preparing To Migrate Off of SHA-1 In OpenPGP

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..."

Comments

In theory, no

[3.5 stripes]

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

[rlseaman]

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

[AvitarX]

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

[rlseaman]

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:First MD5 and now this

[Anonymous Coward]

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

In a related news...

[Vexler]

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

This is news for nerds, not news for dropouts.

Re:In a related news...

[Just Some Guy]

...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?

If so, someone please put this to good use!

[YesIAmAScript]

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.

better packaging for debian

[bcrowell]

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 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:Stupid question, but... multiple hashes?

[YesIAmAScript]

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:2^52

[Anonymous Coward]

Fuck yourself, eurotrash faggot piss-ant.

actually i'm an ameritrash piss-ant.

who happens to be aware of the fact that the world does not revolve around america.

and that there is more than one way of communicating.