On Sep 10, 2009, at 8:02 AM, Philippe Cerfon wrote:

On Thu, Sep 10, 2009 at 3:45 AM, David Shaw <ds...@jabberwocky.com> wrote:
Yes, but it won't actually go away completely. SHA1 is special in OpenPGP. Unlike the other hashes, SHA1 is required to be supported. Removing SHA1 from an OpenPGP preference list doesn't actually remove it, but instead effectively puts it at the end of the list (so it is the lowest ranked
choice).
Uhm,.. what a pity. What would happen if SHA1 gets fully broken? Would
we have to create a new OpenPGP and new keys?

Not a new OpenPGP, exactly, but certainly a revised one. New keys, yes. Of course, SHA1 is nowhere near being fully broken. Heck, even MD5 is nowhere near being "fully" broken (which doesn't mean I recommend people use it, of course).

-But I'd also like to have the signatures themselves using e.g. SHA256 or
SHA512,... but they're alread using SHA1
Can this be changed?
Or can I simply add new self signatures?
Yes

Does this work via --cert-digest-algo option?
If so what must I do to get gpg to:
- resign my own key
- resign other keys
Is it simply with the sign command, or will it complain that there's
already a signture there?

Yes.  To re-sign a key with a new hash, do this:

gpg --cert-digest-algo sha256 --expert --edit-key (thekey)
(pick the user IDs you want to sign)
sign

The "cert-digest-algo" tells GPG which hash to make key signatures with, and the "expert" tells GPG that it is okay to re-sign a user ID that is already signed.

To change the hash you sign with, stick this in your gpg.conf file:

personal-digest-preferences sha256

Oh,.. so what is this --cert-digest-algo then good for?

personal-digest-preferences sets the hash for signatures you make on data. cert-digest-algo sets the hash for signatures ("certifications") you make on keys.

Another thing I've read about is, that gpg keys are using SHA1 hard coded in some places with no way to use another algortihm... which places are
these so one could avoid them perhaps?

You pretty much can't.  The key ID itself is derived from SHA1.

I thought the key ID is only used for humans to short check the
keys,.. but not in the system itself?!
So this would basically mean, once SHA1 is broken, we're totally screwed?!

No, just that we need to revise OpenPGP. It's not a disaster - we've done it in the past, and can do it again in the future. It's just a specification that describes a cryptographic system using the best knowledge of the time. If the knowledge changes, we change the specification.

The real headache here is (as always) the practical - what to do with existing keys and such. I suspect that removing SHA1 would effectively mean a new key type for OpenPGP (again, not a disaster - we're on our 4th key type today).

I'd have some additional poor men's questions ;-)...
- When creating a new key,.. it uses the entropy, right? So is there
some way to improve this entropy? Perhaps not using Linux but instead
OpenBSD which might have a better PRNG (don't know if this is actually
the case ;) ) or use a specific Linux kernel version where a newer and
better PRNG was added?

There are occasional debates on who has the better PRNG. The debates usually end with no changes on either side :)

That isn't to say there aren't differences between systems - the FreeBSD PRNG (which seems to have been inherited by OSX) is of a fairly different construction than the Linux one, which has led to some mild controversy in the past. Notably, the Linux one blocks if you run out of gathered entropy, and the FreeBSD one does not. FreeBSD /dev/random is similar to Linux's /dev/urandom.

See also http://www.entropykey.co.uk/

-Currently the default (and I assume suggested) algorithm is RSA,
right? How does DSA2 compare with it?

Given the same key length and same hash, they are (massive armwave!) roughly equal for real-world use. If you like, you can define "roughly equal" as "usually so much stronger than the rest of the system that fiddly differences are irrelevant". The actual difference you find between the two is more in implementation and use issues, like DSA signatures being physically smaller than RSA signatures (nice for email), RSA being more widely supported in hardware doodads (smartcards, crypto math chips, etc), and RSA allowing more hash flexibility than DSA.

Read NIST SP 800-57 for lots of detail on strength, but they basically conclude the same thing: roughly equal for real-world use.

I once read, that RSA would
provide a hash algorithm armor which the DSA's wouldn't have. Is this
still true?

I'm not exactly sure what you mean by "hash algorithm armor". RSA in OpenPGP does have a additional protection (usually called a "hash firewall") that DSA lacks. This gives some protection against hash substitution attacks, but it's not a major deal either way.

-My course's professor showed us some number from NIST (don't recall
the exact ones, though) where they suggested about something like
this:
15360 (or so) bits for the asymetric key <-> 512 bits for the hash
size <-> 256 symmetric key
should lead to about the same "strenght"...
So we have 512/256 bits for the later two,.. but per default much less
for the asymmetric... Does this mean, that the other two are overkill
for what we use in gpg?

It's true that NIST's guidelines say that to truly get the maximum juice out of a 512-bit hash, you should use a 15360-bit key, but that doesn't mean you must. That overall strength of the system is the weakest point, so as long as that weakest point is strong enough, you're fine.

A 15360-bit key is wildly impractical. I doubt we'll ever see keys of that size in use. When technology progresses to the point of that being necessary (no time soon) we'll move on to other algorithms that are stronger per-bit, like ECDSA.

- When creating new keys (I'd like to "convince" some more friends to
take part :) )... should they create their keys with gpg1 or gpg2? Or
is the key generation equally secure?

Equally secure.  In fact, it's almost the same code.

David


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to