Long Key Performance
Anonymous
anonymous at anonymizer.com
Fri Apr 19 21:11:02 CEST 2002
Werner Koch wrote:
>On Thu, 18 Apr 2002 18:47 -0700, Anonymous said:
>> Conclusion: Long key sizes are not an important gpg performance issue.
>
>However, I had to replace my mail reading machine from a P100 to a
>P300 because some folks use pretty large key sizes and decrypting
>used to take longer than reading the (small) messages. Well, yes I
>could get a decent machine, but what does it buy me.
Shouldn't decrypting time be driven by your own key size, not your
correspondents? Isn't that how public key works? I have this feeling
that I'm missing something. (Maybe you are talking about the time to
check the signatures?)
Also, given that my timings show that the key database imposes far
greater burdens than a 4096 bit key, I have to wonder how carefully
the actual cause of slowness has been benchmarked. The slow key
database is apparently considered an acceptable burden, but long key
sizes are not. Why?
I've used gpg on pre-Pentium hardware with 4096 bit keys. It was
slow, but usable. I'm sorry that I don't have specific timing values
available.
You seem to be arguing that because you personally don't want to buy
faster hardware, everybody else on the planet should not be permitted
to use key lengths of their choosing.
>I don't see a reason to use a >2048 bit key on a networked box - the
>probability of a remote attack is far out higher than finding a way
>to crack the encryption. How many people are actually using a never
>online connected machine to write and read their email, both peers
>have to do it, you have to trust the recipient not to leak out the
>message - how high is that probability?
A tool should not impose the author's threat model on the users
without a good reason. No such reason exists in this situation.
In your threat model, active and passive attacks are equally likely.
Somebody else might believe that their attackers are shy and unlikely
to mount an active attack, but that those same attackers will quietly
record messages and decrypt them when a better factoring algorithm
becomes available, if one isn't already available to the spooks.
Note that the attack you are positing doesn't have the same properties
as a factoring attack.
>If you really need such a high assurance you won't never use standard
>software but maintain your own audited branch etc.. Everything else
>is plain stupid.
Does this childish insult mean I'm getting my point across?
You seem to be claiming you know exactly how hard it is to factor.
The fact is, however, that you don't. Given that this is a judgment
call, why not let users make their own decision about how comfortable
they are with the hardness of the factoring problem?
Look, Werner, I'm not trying to bum you out. It's great that you put
this project together. But, you are being needlessly difficult and it
makes people less enthusiastic fans.
More information about the Gnupg-devel
mailing list