1 |
> cracker gets my box, keylogs and gets my key's password (or bruteforces |
2 |
> it). |
3 |
|
4 |
There. You just said it. "Gets my box, gets my key's password". Remember |
5 |
the first rule of key management? Protect your private key! |
6 |
|
7 |
If your private key was protected like nothing else, he couldn't get it in |
8 |
the first place. |
9 |
|
10 |
> then he uses my key to sign his own replacement key, adds that to |
11 |
> the keyring and has his part set. |
12 |
|
13 |
Assumed he can get his key into the keyring, this wouldn't gain him |
14 |
anything. He still would need to have his key checked for. |
15 |
|
16 |
As I personally ignore any signatures on any key that are from people I |
17 |
don't personally know and trust, "your" signature on his key wouldn't |
18 |
compromise anything in my system, since his key is effectively untrusted. |
19 |
|
20 |
> all this should be quite simple to do without actually harming enough or |
21 |
> hampering enough to be detected in a system. |
22 |
|
23 |
I really doubt anyone but me is able to steal my GPG private key. In fact, |
24 |
I have two PGP keys for several years now, with corresponding revocation |
25 |
copies, and there hasn't been a single case where someone got access to my |
26 |
private keys. |
27 |
|
28 |
> after this, he only needs to slowly hack into one or five -system |
29 |
> builds, and either use my key, or the new fake one, to go ahead and |
30 |
> smash things. wham, haxor karma. |
31 |
|
32 |
Like I've said, his own key (even if signed by "you") wouldn't get him |
33 |
anything. So an attacker would be more after your key than create his own |
34 |
and let "you" sign it. |
35 |
|
36 |
> that was the sort of faked signatures I was counting for. |
37 |
|
38 |
If it's a faked signature that has been made with your key (without you |
39 |
knowing), that's your problem. Protect your private key, and all is fine. |
40 |
|
41 |
> to have the revocation signatures spread out among the (senior?) |
42 |
> developers and allowing them to revoke others keys would be necessary |
43 |
> for security |
44 |
|
45 |
No. Nobody gets a revoked key copy from me if I don't personally know and |
46 |
trust them in the first place. For example, the only person that has |
47 |
revocation access for my PGP keys is a friend of mine which I personally |
48 |
trust for several years now. |
49 |
|
50 |
> but that still would not help with his newly generated key |
51 |
> thats released in mine (or drobbins?) name. |
52 |
|
53 |
You didn't get it. There's no such way as to "release" or "create" a key |
54 |
"in someone's name". You create a key, and it's created by you. You |
55 |
release a key, and it's released by you (actually it doesn't matter who |
56 |
releases it). Someone signs a key, and it's signed by them. It's that |
57 |
simple. |
58 |
|
59 |
As for trusting signatures on particular keys, see above. |
60 |
|
61 |
> Now that I think of it in theese terms, public keys should not be |
62 |
> distributed with the rsync servers, but only with the iso's and |
63 |
> downloaded from keyservers. |
64 |
|
65 |
What's the whole point of that? Why do you trust key servers more than |
66 |
your local rsync mirror? |
67 |
|
68 |
You might say you don't know the persons running rsync mirrors. Then tell |
69 |
me, who's running the key servers? I don't know either, and I don't care. |
70 |
It simply doesn't matter. The only thing that matters is _widespread_ |
71 |
distribution of the public key. |
72 |
|
73 |
-- |
74 |
Maik Schreiber, Gentoo Developer |
75 |
http://www.gentoo.org |
76 |
mailto:blizzy@g.o |