multiple subkeys and key transition

[John Clizbe]

Ben McGinnes wrote:
> On 10/12/10 1:08 AM, Robert J. Hansen wrote:
>> On 12/9/2010 1:14 AM, Ben McGinnes wrote:
>>>  I am giving very serious thought to creating new keys and
>>> doing a (long-term) transition to them.  This is partly to respond to
>>> known flaws with SHA-1 and take advantage of SHA-256 and higher.
>> 
>> My best counsel is: don't, at least not yet.
> 
> Okay.
> 
>> First, there are no imminent practical attacks on SHA-1.  Second,
>> the OpenPGP Working Group ("the WG") is currently figuring out how
>> to get SHA-1 out of the OpenPGP spec and how to replace it with
>> something better.
> 

If one is still using keys of the old signing default of DSA/1024, a 160-bit
hash is the only choice available. That's dictated by the standard. But there's
no pressing need to generate a new key -- one can just switch to using
RIPEMD-160 instead of SHA-1. The fire alarm for SHA-1 has gone off and it's time
to move safely and calmly to the exits.  It's not worth panicking over, but
folks should have a transition plan in place. For my own use, I waited until I
had obtained a v2 OpenPGP card, the earlier v1 cards were limited to 1024 bit
RSA and only the two stock 160 bit hashes, SHA-1 and RIPMED-160.

Or one can use enable-dsa2 in GnuPG and use any of the SHA2 hashes, they'll just
be truncated down to 160 bits similarly to the SHA-224/SHA-256 arrangement
described below.

The best statement on keeping SHA-1 in use I've read comes from NIST:
   "SHA-1 has recently been demonstrated to provide less than 80 bits of
    security for digital signatures; at the publication of this Recommendation,
    the security strength against collisions is assessed at 69 bits. The use of
    SHA-1 is not recommended for the generation of digital signatures in new
    systems; new systems should use one of the larger hash functions. For the
    present time, SHA-1 is included here to reflect it's widespread use in
    existing systems, for which the reduced security strength may not be of
    great concern when only 80-bits of security are required."
    (NIST SP800-57 Part 1. Footnote 23, page 62.)

NIST recommends SHA-224 for 2048 bit RSA and DSA2 keys and SHA-256 for 3072 bit
keys.  In practice SHA-256 is used for both. The same work is involved bor both.
SHA-224 is just a truncated SHA-256, albeit with a different initialization.

> Userful to know, can I track the WG's progress through this list or is
> that done through the IETF or the OpenPGP site?
> 
>> If you do a transition now, it's possible you'll want to transition
>> again in six months or a year once the WG updates the RFC.
> 
> Urgh, what a hideous thought.

One of the very important, but least notied changes in RFC 4880 was that the WG
made it much easier to amend the RFC without rewriting the entire document. This
is how Camellia was included into OpenPGP and how ECC will most likely be included.

Expect to see some movement once the new NIST hash competition is complete.

>> I'd hold off on this, at least for now.
> 
> Well, my current key has been perfectly fine since it's creation
> nearly a dozen years ago.  I'm still sufficiently sure that there is
> no imminent threat, so I'm happy to just watch and wait and see what
> the WG says.

I just created new keys after almost 8 years, my old key was 1024D/2048ElG. The
new keys are 2048-DSA2/2048-RSA and a 3x2048-RSA OpenPGP card.

3072 just felt like overkill for me.
-- 
John P. Clizbe                      Inet:John (a) Mozilla-Enigmail.org
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 499 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20101209/4f19fa0e/attachment.pgp>