Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Alec Warner]

On Tue, Feb 19, 2013 at 7:12 PM, Robin H. Johnson <robbat2@g.o> wrote:
> On Wed, Feb 20, 2013 at 01:34:57AM +0100, Stefan Behte wrote:
>> > 2. root key & signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits
>> > 2.2. RSA, >=2048 bits
> ...
>> 1024 DSA keys seem pretty short to me. Surely it might be inconvenient
>> for some (2-3? please write a mail here!) people with smart cards. But
>> then again, especially people going through the hell of using a
>> physical token would understand the need for decent crypto. ;)
> A physical token defends against a different method of attack than a
> longer key. Simply having a longer key isn't going to help you if store
> the key on the laptop and it gets compromised: presuming the attacker
> extracts your secret key and passphrase). In such a case, the smartcard
> at worst limits him to doing some number of signatures only, or even
> better if the reader has a hardwired pinpad, he gets nowhere at all.

I'm a bit confused.

I agree that a smartcard is much better security vs a longer key. I
don't think attackers targetting Gentoo are going to brute force the
key. They are going to steal the key, trivially, by exploiting a 0-day
in a crappy browser, or flash, or java, or whatever. A smartcard is
the defense against this attack (because the key material is well
protected, and they need physical access to actually relocate it.)
Storing it in the TPM would also be cool, except TPMs are crap on
Linux, *and* most hardware TPMs are crap anyway.

>
> Also, if there is a Well-Funded-Organization attacking Gentoo, there are
> MUCH more effective ways for them to compromise us. Any perceived gains
> in that field from requiring DSA2048 and blocking DSA1024 should be
> examined very closely.

I would ask the opposite question. What is the perceived difficulty in
using DSA2048 vs 1024? For the non-smartcard users, the cost is likely
trivial. Even your perf data shows that signing requests still
complete in 200ms or less, and that is on old / slow hardware.

>
>> I think key rotation is overdoing it and pretty annoying. Better use a
>> non-annoying, long key from the start?
> NOWHERE did I require key rotation. Why do you think that I did?
> My own key is more than a decade old. I need to see about replacing it
> soon, but I've been trying to hold out for the OpenPGP standard to have
> ECC included, before I repeat getting my extremely large web-of-trust.
>
>> > 4. If you intend to sign on a slow alternative-arch, you may find
>> > adding a DSA1024 subkey significantly speeds up the signing.
>> How slow is that actually? Does it make signing very inconvenient?
>> Maybe someone with a slow machine can write about performance and the
>> "annoyence-factor"... ;)
> Some benchmark results from hake.hppa.dev.g.o, 552Mhz PA-RISC box.
>
> Average of running clearsign ~100 times, for various signature types.
> The gpg.conf was set as in my initial post.
>
> DSA1024 0.059830s
> DSA2048 0.158800s
> DSA3072 0.274850s
> RSA1024 0.060020s
> RSA2048 0.173070s
> RSA4096 0.896480s
>
> For reasons of time, while I wanted to create the keys on the host as
> well for timing, I gave up after the first key, DSA1024, took more than
> 3 minutes (I did ensure that /dev/random was not the blocking factor).
>
> If somebody from MIPS or m68k wants to chime in, I think they probably
> have the slowest hardware around presently.

djm works for Google, and I chat with him at least once a quarter.
I've seen some patches go by that we could re-purpose for gpg-agent
forwarding. For slow machines we could have them sign on a
faster-trusted machine with a forwarded agent.

-A

>
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Trustee & Infrastructure Lead
> E-Mail     : robbat2@g.o
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>