howto secure older keys after the recent attacks

[Philippe Cerfon]

Hi.

Now something more realistic and pracitcal.

I'm using gpg for anonymous but secured communication together with some of
my friends for some years now....
Recently I've read on severa attacks on SHA1 and AES256 that could also
affect gpg and its keys.

So waht I'd like to see is some step by step howto on securing older keys
(written by some expert probably ;-) ).

I have two keys a the moment one is a 4096 bit RSA key, the oder (for daily
use) has 1024 bits.

Using the pgpdump tool I found out that it has these settings:
Old: Signature Packet(tag 2)(567 bytes)
    Ver 4 - new
    Sig type - Positive certification of a User ID and Public Key
packet(0x13).
    Pub alg - RSA Encrypt or Sign(pub 1)
    Hash alg - SHA1(hash 2)
    Hashed Sub: key flags(sub 27)(1 bytes)
        Flag - This key may be used to certify other keys
        Flag - This key may be used to sign data
    Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
        Sym alg - AES with 256-bit key(sym 9)
        Sym alg - AES with 192-bit key(sym 8)
        Sym alg - AES with 128-bit key(sym 7)
        Sym alg - CAST5(sym 3)
        Sym alg - Triple-DES(sym 2)
    Hashed Sub: preferred hash algorithms(sub 21)(2 bytes)
        Hash alg - SHA1(hash 2)
        Hash alg - RIPEMD160(hash 3)
    Hashed Sub: preferred compression algorithms(sub 22)(2 bytes)
        Comp alg - ZLIB <RFC1950>(comp 2)
        Comp alg - ZIP <RFC1951>(comp 1)
    Hashed Sub: features(sub 30)(1 bytes)
        Flag - Modification detection (packets 18 and 19)
    Hashed Sub: key server preferences(sub 23)(1 bytes)
        Flag - No-modify
    Hashed Sub: signature creation time(sub 2)(4 bytes)
        Time - Fri Oct 28 20:48:23 CEST 2005
    Hashed Sub: primary User ID(sub 25)(1 bytes)
        Primary - Yes
    Sub: issuer key ID(sub 16)(8 bytes)

and a more recent User ID has these:

Old: Signature Packet(tag 2)(566 bytes)
    Ver 4 - new
    Sig type - Positive certification of a User ID and Public Key
packet(0x13).
    Pub alg - RSA Encrypt or Sign(pub 1)
    Hash alg - SHA1(hash 2)
    Hashed Sub: signature creation time(sub 2)(4 bytes)
        Time - Fri Apr 25 01:23:36 CEST 2008
    Hashed Sub: key flags(sub 27)(1 bytes)
        Flag - This key may be used to certify other keys
        Flag - This key may be used to sign data
    Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
        Sym alg - AES with 256-bit key(sym 9)
        Sym alg - AES with 192-bit key(sym 8)
        Sym alg - AES with 128-bit key(sym 7)
        Sym alg - CAST5(sym 3)
        Sym alg - Triple-DES(sym 2)
    Hashed Sub: preferred hash algorithms(sub 21)(3 bytes)
        Hash alg - SHA1(hash 2)
        Hash alg - SHA256(hash 8)
        Hash alg - RIPEMD160(hash 3)
    Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
        Comp alg - ZLIB <RFC1950>(comp 2)
        Comp alg - BZip2(comp 3)
        Comp alg - ZIP <RFC1951>(comp 1)
    Hashed Sub: features(sub 30)(1 bytes)
        Flag - Modification detection (packets 18 and 19)
    Hashed Sub: key server preferences(sub 23)(1 bytes)
        Flag - No-modify


As far as I understand thise means:
- The signatures on them are created with SHA1
- The differ in preferred algorihtms for hashes and compression

Well...
- It seems that I can easily change these preferences via gpg --edit-key,..
so I could simply remove e.g. SHA1
-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?
And if I do so the old ones would still be on the keyservers, right? And no
way to delete them.
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?
Or should I better start with a fresh key without any old signatures?

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?

Thanks for your insight,
Philippe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20090910/b38d01cc/attachment-0001.htm>