--- Maria Lukas van den Berg <[EMAIL PROTECTED]> wrote: [snip]
> However, there is a second requirement. No-one should be > able to create a second keypair B > > - which has the same key ID as A, > - where signatures made with A validate against the public > key of B. > > If such a key B existed, a reader not having the public key > of A could be tricked into thinking a posting signed by B > originates from the same person who also signed postings P_1 > to P_n, because the signatures on *all* of those postings > validate against the public key of B. > > Am I on the right track so far in recognizing the possible > weaknesses of my scheme? > > If so, is it practically possible to create such a key B? > > If so, what measures could be taken to enhance my scheme? > > How about publishing with every posting P_1 to P_n the > fingerprint of A? At least a watchful receipient would then > realize that key B is not the right one for checking the > signatures on postings P_1 to P_n. That's unless the > attacker succeeds in creating a key B which also has the > same fingerprint as A. Is this practically doable? > > And, asking further, how can I make it as hard as possible > to create a key with the same fingerprint as A? Is the > length of the key an issue? Would it, e.g., be more secure > to create a 4096 bit RSA key instead of a 1024 bit DSA key? > > Thanks a lot for your answers and suggestions! > If there is a mailing list where these topics would fit > better, I'd also be interested to ask there. > > Best regards, Luke. Here's one educated opinion on that, that I found: http://lwn.net/2000/0316/a/pgp1.html All the best, Randy _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
