how slow are 4Kbit RSA keys? [was: Re: multiple keys vs multiple identities]
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Sep 27 21:33:36 CEST 2010
On 09/27/2010 10:55 AM, Jameson Rollins wrote:
> On Mon, 27 Sep 2010 16:28:07 +0200, Vjaceslavs Klimovs <vklimovs at gmail.com> wrote:
>> 2048 bit keys are suitable - it's "user+sys" what matters in this case,
>> but not "real" by all means, as that includes waiting for passphrase
>> input too.
> I think this is really a UI issue, in which case "real" is what you
> really care about.
It's true that we really do care about "real", but that measurement is
confounded by other factors (human password entry, CPU and I/O
contention, etc) that gnupg developers have no control over.
So in terms of "what kinds of responsiveness can we expect from GnuPG",
i think measuring user+sys is the way to go.
> An operation that takes >1s is annoying if it needs to be done
> frequently, but I'm not sure the operations we're talking about here
> really ones that are done that frequently.
So i think the tradeoff is the cost of the algorithms that require
secret-key use (decrypting, signing) vs. the cost of the algorithms that
require public-key use (encrypting, verifying).
David Shaw pointed out that RSA excels in speed at the pubkey
operations, but is fairly slow on the secret-key operations, if i
so if you're just exchanging signed mails with a group of N people,
that's 1 expensive operation (signing) per message, and N cheap
operations per message (verification).
if you're sending encrypted e-mail to someone, that should be 1 cheap
operation per message (encryption) and one expensive (decryption).
If you receive lots of encrypted mail, and you have to decrypt it each
time you read it on a weak device, that could certainly be expensive
None of this seems to preclude using large/strong primary keys alongside
weaker/shorter, time-limited subkeys, though, afaict.
It sounds like the only concern is about doing your own secret key
operations on low-powered devices. So concern that your correspondents
might be using OpenPGP on a low-power device shouldn't constrain your
own choice of key strength, since your secret key won't be used on that
Does that seem like the right analysis?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 900 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users