multiple subkeys and key transition

[Ben McGinnes]

On 10/12/10 9:28 AM, John Clizbe wrote:
> Robert J. Hansen wrote:
>> On 12/9/10 1:30 PM, Ben McGinnes wrote:
>>
>> If/when the time comes for SHA-1 to be completely removed from OpenPGP,
>> the migration path will quite likely involve new keys -- the same way
>> that the V3/V4 migration path in the past necessitated new keys.
>>
>>> Since I prefer a more long-term approach, this should eventually lead
>>> to 8,192-bit encryption keys when 4,096-bit becomes the default.
>>
>> It is unlikely it ever will.  3K RSA keys are believed to be equivalent
>> to a 128-bit symmetric key.  If computational power ever develops to
>> that point, the solution is going to involve moving to entirely
>> different algorithms instead of just tacking on another couple of bits.
> 
> Big ACK to what Rob just said.

Okey-dokies.

> Why 8192?

Bigger is better mentality.  I'm happy to be corrected to whatever is
most usefully secure.  When I created my current key I was essentially
moving from a 1024-bit RSA key made with PGP 2.3a and there were a
whole bunch of reasons to go with something stronger.  At the time I
erred on the side of caution and picked the largest key size available
to me.

> 4096 RSA is extremely *unlikely* to ever be a default.

Good to know.  Presumably the same goes for Elgamal.

> Over the summer, readers of the [Cryptography] mailing list were
> reminded that in 1993 folks thought that 1024-bit RSA 'should be ok
> (safe from key-factoring attacks) for "a few decades".' A later post
> in that same thread went on to compare equivalent strengths of RSA,
> symmetric keys and Elliptic Curve (ECC) keys.

The last bit of documentation I saw on ECC is a little old and stated
that it wasn't well known enough to consider using.  I guess that's
changed now.

> How do elliptic curves compare to RSA today?
> 
> From the National Institutes of Science and Technology (one of the gold
> standards for engineering know-how):
[SNIP]
> 112-bit symmetric is usually a reference to [three-key] 3DES.  (It's
> worth noting that most people in the crypto community are *deeply*
> skeptical of any claims that 3DES can be cracked.  If 112 bits of
> symmetric encryption are good enough for your purposes, then
> RSA-2048 should also be good enough for your purposes.)
> 
> That is to say, a 3072 bit RSA key is as tough as an ECC key based
> on a 256 bit field, which is as tough as a 128 bit symmetric key.
[SNIP]
> A key aspect of Suite B is its use of elliptic curve technology
> instead of classical public key technology. During the transition to
> the use of elliptic curve cryptography in ECDH and ECDSA, DH, DSA
> and RSA can be used with a 2048-bit modulus to protect classified
> information up to the _secret_ level

So my 4096-bit Elgamal key with an AES256 cipher would be somewhere
between SECRET and TOP SECRET (discounting the real information
security policies that are applied by any DoD/spook personnel, in
either your country or mine).

> So, depending on the source, a consensus seems to be forming that
> beyond a 2048 or 3072 bit modulus for DSA2 or RSA, folks need to
> switch to ECC.  2048-RSA is the current default in GnuPG. OpenPGP
> cards will support up to 3072-bit RSA; GnuPG up to 4096-bit RSA and
> 3072-bit DSA2. ECC in OpenPGP is on its way toward becoming a RFC
> and being included in OpenPGP. Larger and larger RSA keys aren't the
> solution, ECC is. The balance of power has tipped away from RSA and
> toward ECC.

Okay, it looks like I've got more reading to do, so I know what to
expect when it puts in an appearance.  Thanks.

> Feel free to ignore everything I've told you. There's no reason you
> should trust me. But by all means, keep asking questions. But
> everything I've read agrees longer RSA are not the path forward.

Since you're backing it all up with verifiable and useful data, I'm
happy to take these suggestions.  In the past I've seen similar
arguments, but rarely with the relevant reference material to back the
assertions up.  So this is all most welcome.

As for more questions, no doubt I'll have more as I plough through all
this stuff.


Regards,
Ben

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