Long Key Performance
justinrt at bellsouth.net
Sat Apr 20 18:36:02 CEST 2002
----- Original Message -----
From: Anonymous <anonymous at anonymizer.com>
To: <gnupg-devel at gnupg.org>
Sent: Friday, April 19, 2002 7:43 PM
Subject: Re: Long Key Performance
>The real issue is whether your choice is arbitrarily imposed on
I will agree that having the option to freely choose any key size is
but I'll comment below as to why having 4096 as a limit isn't a bad thing
prohibits one from being 'secure'.
>You don't know that! This is just a guess based on how far factoring
>has gotten by now. It is important not to exaggerate what we know
>about the mathematics of cryptography.
(nor assume that we should coax or encourage one to use massive key sizes
I'll agree with this to an extent. If you've kept up with cryptography and
factorization progress, you might notice it hasn't advanced as much as many
of us thought. However, I will say that with mathematics, it's in good taste
assume that a breakthrough could happen on a whim, and surely, with math, it
is possible that a single advancement could be a tsunami against public key
and factorization. The point here though, is that I believe and recommend,
in my opinion, that 1024
bit keys will still suffice for a while longer, although, with the current
factorization hype, it may not
be a bad idea to upgrade to at least 2048, which I also believe will be
quite sufficient for a while.
'A while' being <= 10, 12, 14 years or so. There's also that possibility of
the sudden breakthrough
though, but then again, this breakthrough may impact public key cryptography
in such a way that keys
larger than 4096 will fall. For the computing power, general user, time
factor, speeds, et cetera,
2048 for a maximum key size is a conservative and good choice. If you want
4096 and don't mind any
performance slow-downs, as well as have the computing power to spare, then
so be it.
Besides the government or any other large corporation with the power to even
attempt a factorization
on a large number such as 1024-bits, I think for WinPT's sake, it is safe to
say that 2048-bit key sizes
for the maximum will be just fine, as the attacker would have to have one
hell of a juggernaut-like motive
to attempt attacking a key of this size as the weakest link. The whole idea
being, with current factoring progress,
keys <= 4096, average recommendation of 2048, would be the most conservative
choices, in that if the sudden breakthrough
would occur, you have saved computing power over time and still retained
security by using these sizes, rather than 16kbit keys
that will require massive amounts of computer power, as you've quadrupled
the maximum key size, but will still fall to the factoring
breakthrough. All in all, I don't think Bernstein's paper has really changed
things and 2048-4096-bit keys are fine, even 1024, for a
while longer, if you've kept up with things thus far.
>If somebody wants to go to the trouble of using 16kbit key, why not
>let them? If anything, it would show off gpg's implementation.
Like I've said, if you know anything of key sizes in public key systems and
have kept up with factoring progress,
there is no inherent need to use keys of that caliber, as many amateur users
might think "larger is better" and not keep
in mind how a massive breakthrough in factoring could affect keys of any
size, 2048, 4096, 16k, et cetera...
Why go to the trouble? You can save computing time and still retain
sufficient security at <=4096.
Going back to my first comments as to how this limit doesn't prohibit any
security...if you even have the option to
choose >4096-bit keys, considering the possible scenarios and your computing
abilities, would it even be necessary?
Showing off GPG lies not in the key size, as most people (with a decent
knowledge of public key crypto) won't ever attempt generating a key higher
than the maximum even if given the option. To me, the whole appeal lies in
the fact that it's free software, without patenting issues, that performs
If using 16kbit key sizes only to 'show-off' GnuPG, you're merely boasting
security without considering the systems involved and how key sizes really
to a certain point.
My two cents...
Gnupg-devel mailing list
Gnupg-devel at gnupg.org
More information about the Gnupg-devel