Long Key Performance

[Anonymous]

David Shaw wrote:
>On Fri, Apr 19, 2002 at 08:50:01AM +0000, Anonymous wrote:
>> Conclusion: Long key sizes are not an important gpg performance issue.
>
>GnuPG allows you to generate and use 4096-bit keys.  It also works
>fine with 4096-bit keys generated elsewhere.
>
>Maybe I'm not understanding the problem here.  Are you complaining
>about the message asking you to not create a 4096 bit key unless it's
>really needed?

Several points are being made.

1. Yes, there is no reason to scare people away from using long keys.
It is reasonable to warn a user that the key takes twenty minutes to
generate, but vague discouraging messages are not useful.

1.5. The scare message propagates to problems elsewhere.  For example,
WinPT does not generate 4096 bit keys.  Users have to go find gpg and
do it directly.  I am guessing this is due to the WinPT author not
wanting to deal with the interaction or maybe just following the gpg
example.

2. It would be nice to be able to generate keys of any length.  Sure,
exceptionally long keys (i.e., > 4096 bits) are going to cause
performance issues, but if the user is accurately warned, he or she
should be permitted to proceed.  Maybe that user feels exceptionally
uncomfortable about the factoring problem.  Maybe it's just an
experiment to see how big a key their computer can handle.  Maybe it's
just for fun.  There's no reason why a tool should arbitrarily limit
its users.

It seems really weird to me that the gpg team has decided it's somehow
sinful for people to use long keys.  If they want to, why not let
them?

(BTW, when I play with the #defines that control maximum key length,
gpg core dumps.  Not confidence inspiring!  If anybody thinks it
useful, I can try to reproduce the behavior and report it in detail.)

3. The key database is extremely slow.  On my machine it seems to
search only 150 keys/second or so.  It's somewhat amusing that long
keys are considered a serious performance problem, but retrieving keys
off the disk is apparently not.