how slow are 4Kbit RSA keys? [was: Re: multiple keys vs multiple identities]

[Daniel Kahn Gillmor]

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
understand correctly.

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
computationally.

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
device anyway.

Does that seem like the right analysis?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100927/d09485a8/attachment-0001.pgp>