Long Key Performance
justinrt at bellsouth.net
Sat Apr 20 22:31:01 CEST 2002
----- Original Message -----
From: Anonymous <anonymous at anonymizer.com>
To: <gnupg-devel at gnupg.org>
Sent: Saturday, April 20, 2002 2:28 PM
Subject: Re: Long Key Performance
>The goal is not to be secure for the next 18 months. The goal is to
>keep mail private for all time.
Right, this is true. I'm just addressing the current security of the key
sizes in public key systems. I will totally agree on taking caution to
factorization and the fluctuation of its progress, buy over time, it has
indeed taken some strides, but all in all, remained steady in standing in
the past few years or more.
>Also, if you think a publicly available fast factoring algorithm could
>be available in 5 years, then you should be seriously concerned that
>certain private parties may already have it. (NSA, for example, is
>believed to be the world's largest employer of mathematicians.)
(Of course, it is always good to think ahead a few years.)
Right, I can also agree with this. My idea is not to shun the use of 16kbit
keys, but rather say that using <=4096 keys is sufficient. If the
breakthrough comes around any time soon, any key size may fall. I know you
know this and there is no need to recomment on things. I just believe that
using the key sizes permitted by GnuPG at this point will cope with the
factorization capabilities as of now.
I can go on research, discussion and instinct. All in all, there is nothing
wrong with using whatever key size you life, may it be 16kbit or not, but I
don't see the inherent need for GnuPG to allow this.
>But nothing is gained by this limitation! Gpg generates 4096 bit
>keys, so why is WinPT arbitrarily limiting the keys its users can
Well, it's not about limitation, it's about sufficiency based upon the
author's preference. 2048-bit is not a bad choice. If the user prefers, work
outside of WinPT and generate a 4096-bit key.
>You think so. But, other people can just as reasonably think
>otherwise. They should be allowed to act on their belief and
>tolerance of a few seconds delay while encrypting.
The other people are likely ones with systems capable of handling such large
key sizes, while not feeling the performance effects that a lower-end system
would. Maybe a few seconds for them, but not for people with slower systems.
Excuse me for not having benchmarks, but I can tell a difference after
working on different systems running the same cryptographic processes.
I will agree, they should be able to act on their own belief, however,
this belief should be based on something valid, like a decent knowledge of
factoring progress up to date, how it effects certain key sizes, public key
cryptography, etc, rather than mere 'instinct' without reason.
>The cost is not great. So why not?
It's not necessarily a cost issue, as the costs aren't that exponential, but
rather one of knowledge. With the current progress in factoring and the
caution that a breakthrough may occur, how much more beneficial would a
16kbit key be than a 4096-bit, if the certain breakthrough would stifle any
key size? It just goes back to my point that the limits will suffice, not
that 16kbit is naturally larger and more resistant.
>To which "decent knowledge" do you refer? The truth is: we don't
Well, we do know, to an extent. Excluding the possible factoring
we know the most conservative choices for key sizes in public key systems.
Including the breakthrough, we don't know how long exactly they'll remain
secure. Even then, in the end, will the 16kbit key have benefitted anymore
than the 4096-bit key, if neither were factored before the breakthrough
compromised them both? As for Bernstein's paper. It's a very credible
reference to the possibilities, but I don't believe all the twisted hype
around it from the media. It's just a nuisance to those of us who keep up
with the crypto/math scene.
His paper doesn't change things or how we should look at them thus far.
>I challenge you to cite a credible paper which demonstrates that a
>4096 bit number is not easy to factor. Don't bother looking too hard
>- it doesn't exist.
I know this. Never mentioned this at all. By this point in the message, I'll
have come across with my initial point, which generally agrees with yours,
except for the inherent need to boost key sizes.
My two cents,
More information about the Gnupg-devel