| 1 |
On Tue, Feb 19, 2013 at 10:32:13PM -0800, Alec Warner wrote: |
| 2 |
> I agree that a smartcard is much better security vs a longer key. I |
| 3 |
> don't think attackers targetting Gentoo are going to brute force the |
| 4 |
> key. They are going to steal the key, trivially, by exploiting a 0-day |
| 5 |
> in a crappy browser, or flash, or java, or whatever. A smartcard is |
| 6 |
> the defense against this attack (because the key material is well |
| 7 |
> protected, and they need physical access to actually relocate it.) |
| 8 |
> Storing it in the TPM would also be cool, except TPMs are crap on |
| 9 |
> Linux, *and* most hardware TPMs are crap anyway. |
| 10 |
Exactly. The longer key doesn't block this attack, the smartcard does. |
| 11 |
|
| 12 |
The question being asked becomes: |
| 13 |
"If the smartcard only supports a shorter key is that an acceptable |
| 14 |
tradeoff where a longer key would be used instead?" |
| 15 |
|
| 16 |
I say it's a very acceptable tradeoff, and the require/recommend of the |
| 17 |
proposal reflects this. |
| 18 |
|
| 19 |
> > Also, if there is a Well-Funded-Organization attacking Gentoo, there are |
| 20 |
> > MUCH more effective ways for them to compromise us. Any perceived gains |
| 21 |
> > in that field from requiring DSA2048 and blocking DSA1024 should be |
| 22 |
> > examined very closely. |
| 23 |
> I would ask the opposite question. What is the perceived difficulty in |
| 24 |
> using DSA2048 vs 1024? For the non-smartcard users, the cost is likely |
| 25 |
> trivial. Even your perf data shows that signing requests still |
| 26 |
> complete in 200ms or less, and that is on old / slow hardware. |
| 27 |
This is why I recommended DSA2048, but only required DSA1024. |
| 28 |
I don't want something that says |
| 29 |
"If you use a smartcard, you can use DSA1024, otherwise you must use |
| 30 |
DSA2048" |
| 31 |
That's just too confusing. |
| 32 |
|
| 33 |
> djm works for Google, and I chat with him at least once a quarter. |
| 34 |
> I've seen some patches go by that we could re-purpose for gpg-agent |
| 35 |
> forwarding. For slow machines we could have them sign on a |
| 36 |
> faster-trusted machine with a forwarded agent. |
| 37 |
Major +1 on gpg-agent forwarding request; the smartcard crowd would love |
| 38 |
it too. |
| 39 |
|
| 40 |
-- |
| 41 |
Robin Hugh Johnson |
| 42 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
| 43 |
E-Mail : robbat2@g.o |
| 44 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
Archives