Recommended key size for life long key

[John Clizbe]

Robert J. Hansen wrote:
> 
>> Based on the guess that 10kbit has the potential of not being broken
>>  within a person's life span: What problems would you experience if 
>> you chose to use a 10kbit key today instead of a 4kbit key (which 
>> seems to be the common choice - but which we are fairly certain will 
>> be broken before 2100)? THIS (i.e. the problems by using 10kbit
>> today instead of 4kbit) being the focus of the document.
> 
> Then you're putting the cart before the horse.  If you're basing that on
> a *guess*, then my guess is for RSA-16k and Werner's guess is for RSA-8k
> and Phil Stracchino's guess is for RSA-4k and... [3]
> 
> You first need to provide evidence that your RSA-10k projection has a
> good chance of being correct in 87 years.  Once you do that, *then* it
> will be time to start looking at timing data and thinking about how best
> to adopt RSA-10k today.  But before you do that, your guess is no more
> valid than mine, Werner's, or Phil Stracchino's.  And we could all come
> up with our own timing data and talk about the need to adopt our
> guesses, and the ultimate result would be an awful lot of confusion.  A
> great deal of heat and very little light.
> 
> 
> [3] These guesses are completely made up, and I'm just using the names
> of random people within the community.

And Rob's friend, John Clizbe, hasn't even made a projection for RSA, because
if he wants anything past 3072 bit RSA, he's going to switch to ECC.

But honestly, I think that even switching to ECC is no guarantee we'll have
more than 25 years or so of security. Frankly, predicting tech progression is
the worst kind of voodoo. Over the summer of 2010, readers of the
[Cryptography] mailing list were reminded that in 1993, the "experts" thought
that 1024-bit RSA 'should be ok (safe from key-factoring attacks) for "a few
decades".' 1.75 decades later it's essentially history. [few>=3]

There /IS/ a reason NIST and the TLAs aren't pushing 4k and higher RSA, it's
inefficient. For multiple senses of "inefficient". RSA-3072 has a 128-bit
keyspace, RSA-4096 has only about a 140-bit keyspace. That's a lot of
additional time/energy for crypto operations for only another, what, 12 bits?
Past RSA-3072, RSA becomes a phenomenally inefficient way of adding keyspace.
It just gets exponentially more ridiculous as key sizes increase.

Several minutes to verify a signature makes such large key sizes non-starters.
Folks using a baseline of a 1GHz cellphone seem to have no idea of the
lifetimes involved in MIL-SPEC equipment. I'm sure there are some 1 MIPS VAX
11/780s still in military service somewhere. /MAYBE/ the 233Mhz hardened
Pentium chips have been decommissioned by now.

I should do a rebuild of libgcrypt on a 500MHz 64-bit uSPARCii. The timings
from the make test phase ARE NOT pretty. At least it would be better than
pulling numbers out of /dev/ass.
-- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
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: 475 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130909/503a4be1/attachment.sig>