howto secure older keys after the recent attacks

[Philippe Cerfon]

On Thu, Sep 10, 2009 at 3:45 AM, David Shaw <dshaw at 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?


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


>> So does this mean any harm to me? At some day SHA1 might be fully broken,
>> and then an attacker could use simply these older self signatures instead of
>> the newer ones, or not?
>
> Well, yes and no.  Old signatures are certainly available to both friend and
> foe, but the real question is: use them for what?  What attack are you
> concerned about here?

Well.. not sure... I've heard that one can add many settings to these
signatures like rovcations or policies. But I have not enough
knowledge on them (although I could imagine that someone could
probably use them to do evil things which might be impossible with a
newer hash-algo).
But perhaps it could be used to do some forgery with User IDs?


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


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


> There was a very long discussion of the SHA1 issue a few months back on this
> list.  See, for example,
> http://lists.gnupg.org/pipermail/gnupg-users/2009-May/036338.html and
> http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024999.html
>
> In short, I wouldn't worry all that much about it.

At least at the moment you mean? I mean we had the "same" thing with
MD4, MD5 and so on,... so probably it will hit us with SHA1, too?


> With regards to AES256, I doubly wouldn't worry about it.  See
> http://lists.gnupg.org/pipermail/gnupg-users/2009-August/037107.html
>
> This sort of question tends to cause long threads where everyone throws in
> their own cipher preferences.  Instead of giving my preferences, allow me to
> point at the wonderful defaults in GPG.  They're the default algorithms for
> a reason.
Ok,.. thanks for that information :)


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?
-Currently the default (and I assume suggested) algorithm is RSA,
right? How does DSA2 compare with it? I once read, that RSA would
provide a hash algorithm armor which the DSA's wouldn't have. Is this
still true?
-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?
- 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?


Best wishes,
Philippe.