Best Practices

[Robert J. Hansen]

On 12/9/2010 11:08 PM, David Tomaschik wrote:
> I feel bad for the "litter" this introduces to the keyservers.

Don't.  :)  The keyservers don't have a problem with this litter.  I
wish people showed more care with their certificates, but that's because
I get too many "I forgot my passphrase, help!" emails, not because I
think the keyserver network is getting clogged.

> I currently have a 4096-bit RSA sign/encrypt keypair with no subkeys.  I
> believe, but am not certain, that it was generated with SHA1 hashes. 
> (Is there a way I can check?)  This keypair was generated in May of this
> year.

Well, you have one subkey, it's just that the subkey is capable of both
signing and encryption.  You don't have separate subkeys for separate
tasks, if I understand you correctly.  Some people think this is a bad
idea, since if you're compelled to produce an encryption key to the
authorities (so they can decrypt an email sent to you) you've also
provided them with your signature key (so they can now impersonate you).

> What is the best way to transition my email address?  Add a new UID and
> revoke the old?  Should a new keypair be generated?  What is the
> conventional wisdom on the strength of RSA-4096?

Add a new UID and revoke the old.  You don't need to generate a new
certificate.  RSA-4K is, IMO, phenomenal overkill for the vast majority
of users.  Breaking RSA-2K is believed comparable in difficulty to
breaking 3DES, and that prospect is ... let's just say "implausible."

RSA-3K is roughly comparable to breaking AES-128.  RSA-4K is not very
much harder than that.  Given all this, I really don't see any point in
going past RSA-2K.  Adding another 2,000 bits to the key in order to get
about another 20 bits of symmetric-key equivalent just strikes me as bad
art.

> If a new keypair is generated, what length would be sufficient for a
> decent (10+ year, preferrably 20+) margin of safety?  I know that there
> may be unforeseen advances in computing that allow for keys to be broken
> rapidly (Quantum computing, new sieve algorithms, etc.), but there's
> surely some guidance based on the current generation of things.

There is not.  In twenty years we will see commonplace attacks that
today are just speculative science fiction.  It's incredibly hard to
make good long-term predictions about crypto.

It is possible that in twenty years national governments will have
large-scale quantum processors.  Once that happens, RSA, DSA and ElGamal
all die horrible screaming deaths.

As an example: almost twenty years ago Schneier wrote in _Applied
Cryptography_ of the Chinese Lottery Attack.  It involved putting a
small processor in every Chinese television set, which could be
programmed by broadcasts from Party headquarters.  Each processor would
crunch a small part of the keyspace, and as soon as a hit was achieved
the television would tell the viewer, "You have won!  Call Party
headquarters with this authorization number: [insert key here]."

Twenty years ago the Chinese Lottery Attack was an interesting thought
experiment, but nobody took it seriously.

Today we have RC5-64, distributed.net, seti at home, botnets, Amazon EC2
and all manner of other massively distributed computing frameworks.  The
question today isn't whether a Chinese Lottery Attack is possible: the
question is how much it will cost you to rent your server time.

The future is a scary place.  But fun, too, and I look forward to
getting there.  :)

> In a new keypair, is it safe to use SHA512 for hashes?

Sure, but you don't need to create a new cert to use new hash algorithms.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5598 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20101210/f6640a08/attachment-0001.bin>