Long Key Performance

[Justin Troutman]

----- Original Message -----
From: Enzo Michelangeli <em at who.net>
To: <gnupg-devel at gnupg.org>
Sent: Saturday, April 20, 2002 10:57 PM
Subject: Re: Long Key Performance


> I think that several people here are missing an important point: it's not
> for the developer to decide what the security needs of each user may
> "reasonably" be. Or inquire what their reasons are, as Justin did (is this
a
> sign of post-911 syndrome?).

I didn't inquire on his motives or reasoning, I simply implied, based on one
of his posts that he saw 2048-bit key sizes as a good choice, that indeed,
that was a good choice. WinPT is Timo's free software, it is for him to
decide what security measures he uses. Establishing 2048-bit key max sizes
doesn't juggle the security needs of a user, it balances them on an average
scale for the average user. It doesn't prohibit the user from generating
larger keys with GnuPG itself, just not under WinPT. It's a conservative,
solid choice on his behalf, based on knowledge.


> There is a BIG difference (both philosophic and practical) between warning
> someone, and making decisions on his behalf, in the assumption of knowing
> better. A more useful service to the users, rather than preventing them
from
> using lage keys, would be to document the best guesstimates of CPU power
> use and to break each link of the chain: PK with various keysizes;
symmetric
> cipher; RNG; hash, for signatures; platform-specific weaknesses etc. Then,
> let the user decide how many CPU cycles s/he wants to burn.

By establishing the 2048-bit max key size in WinPT, it's not making the
user's decision as to what key size to use, it's just saying, "Hey, this is
WinPT, this is the maximum key size based on knowledgeable reasoning and
will suffice." If it's that big of a deal, use GnuPG directly and generate.
As for guesstimates of that sort...I don't see it necessary, but not
necessarily outlandish, to document these things, as a user attempting to
generate such large key sizes should know the effects and performance issues
before proceeding so. On the other hand, I won't say it wouldn't be useful
to have the benchmarks in front of you to go by when generating large keys.
If they don't understand these concepts, they really have no inherent need
to generate keys >4096-bit. All in all, I agree with the whole flexibility
of the user-preference/unlimited key size motif. It looks like and sits
well. However, is it (4096-bit limit) truly imposing (or a threat to) on
anything, after you consider all scenarios.


> Current estimates seems to assume that 256-bit ciphers like Rijndael-256
are
> as hard to break as 16Kbit RSA or DH keys (and about 512-bit ECC keys);

With rising in key sizes among symmetrical and asymmetrical, it's not
accurate to assume that you'd need a 16kbit RSA/DH key to correspond to a
256-bit Rijndael key. The attack schemes and security levels on these two
different systems
are quite different in that comparing them is somewhat irrelevant after a
certain point.

> means that the symmetric cipher part is now massively more secure than the
> PK one. It's reasonable to assume that theoretical advances will skew this
> ratio further: so, why do we dismiss the idea of balancing it, especially
> considering that the cipher key protects only one message, but the PK
> keypair protects a large number of them?

You can only compare/balance symmetrical/asymmetrical designs so far. I
believe that a 1024-bit RSA key is somewhere near the vacinity in security
to an 80-bit symmetric key. Other than that, trying to compare keys as key
sizes rise, you lose relevance to the fact that attack/security issues
unique to either symmetric or asymmetric keys come into play much moreso as
the sizes lengthen.

- Justin