Long Key Performance

[Anonymous]

Timo Schulz wrote:
>On Fri Apr 19 2002; 11:07, Anonymous wrote:
>
>> 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.
>
>FYI, WinPT does not use GPG interactive, it uses the unattended
>key generation feature. In this mode you can generate keys in any
>size that GPG supports (currently <= 4096 bits).

Thanks for the info.  Complaints are being made in the proper
quarters. ;-)

>I don't want to start a flame war about the key size but for me 2048
>was a good choice for the maximum key size.

The real issue is whether your choice is arbitrarily imposed on
everybody else.

>The attacker tries the weakest point and that is definitely not the
>key size.

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.

>It should be much easier to guess the password or to steal
>it. A large key is only one step for a secure communication. But of
>course this is my personal opinion and if somebody disagree I will
>accept it.

A fast factoring algorithm could crack a message years after the
password has been destroyed.  To some extent, this is a comparison
between apples and oranges.

The real question is: what is the cost of letting users use keys as
long as they like without any limitation other than memory and cycles?
I haven't looked deeply into the gpg code, but it apparently supports
variable length keys.  Since most computers don't have 4096 bit
registers, I doubt there's any good reason why an encryption program
can't handle keys of any length.

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.