Keys without signatures

[Joe Smith]

"Maria Lukas van den Berg" <maria.l.vandenberg at gmx.de> wrote in message 
news:20060305152333.GC4266 at vandenberg.localhost...

The following post is based on my understanding. I think I'm correct,
but it is possible I am wrong.

>Assume that I create a keypair A and sign my Usenet postings
>using A. I do not want to rely on any signatures on the
>public key of A. Instead I define my identity via the
>postings I make. This means that after I published postings
>P_1 to P_n, I want to be able to do a posting P and by a
>signature on P to prove that P was posted by the same person
>who also posted P_1 to P_n, i.e., me. (Unless my private key
>and passphrase got compromised.)

This is entirely reasonable. By doing that people can reasonable assume that 
unless the key is compromised,
or that the private key is held by more than one person (a group key), the 
poster of all the messages are the same.

You are asking about how the web of trust relates to identity. The simple 
fact is that identity is far from clear.
In the case where one simply wants to veryify that two messages were created 
by the same entity, then the
web of trust is not needed. In the case that one only eeds to know that the 
holder of the key ca read and send email
of a particular email address then a bot that verifies email adresses and 
then signs the key is usefull.

The web of trust is most useful in the case where verifying that a 
particular individual who uses a given name in the real
world is the holder of the key is what is important.

>I am aware that no-one can practically generate a signature
>for some posting that will validate against the public key
>of A. This is the one component I need for my scheme.
>
>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,

Short key id's are not secure, there are many keys with duplicate short ids.
Long ids are more secure, but it is still easier to duplicate that than 
duplicating the fingerprint, as long ids
are only a partial fingerprint.

>- where signatures made with A validate against the public
>  key of B.

First of all the OpenPGP signature format is designed to resist such an 
attack by doing things like including the key id.
Looking at just the underlying crypto: This is all but impossible.

If just one signature needed to validate using this new key then it might be 
somewhat easier than the attack you
mention as your first component.

If *all* signatures are to validate then this is really becomes as hard as 
making the key you describe as impractical
as your first component.

>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?

I'm pretty sure this is not a weakness. If one was able to create such a key
it would cause major problems. Even the web of trust would have problems
becaue the key creator could use his/her real info in the UID and get 
his/her key
into the web of trust. This would no be cheating the system any as that 
person really
would control that new key.

>If so, is it practically possible to create such a key B?

 I would say no.

>If so, what measures could be taken to enhance my scheme?

If I am correct this is irrelevant.

>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?

Fingerprint duplication (ignoring the other contraints) is considered fairly 
difficult.
It would however be much easier to duplicate a fingerprint using brute force 
than creating
the key you described above. Nevertheless it is still fairly impractical. 
Combining this with
the other features of key B described above really would pretty much require 
creating a key
with identical cryptographic material to your key. If somebody could do that 
then it
would be a real problem.


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

This question is reasonably on-topic here.
The only better place I can think of is the newsgroup comp.sci.crypto

>Best regards, Luke.