4
$\begingroup$

Let's think of the following case:

A group of peers want to exchange messages with each other. They use public-key cryptography to sign and encrypt messages. Anyone with any name can join the network. There is no central trusted authority, such as a CA that could issue certificates. When a peer joins, he publishes either, A) a self-signed certificate or B) a public key only, that others can use to him send messages.

Would under such circumstances cryptographic certificates (A) provide any advantage over using just private/public key pairs (B)? As far as I have understood certificates can only make sense if everyone trusts a central authority that issues certificates.

To my mind, that means if a peer joins the network it is sufficient that he broadcasts a message with his name+public key, signed with his private key. Everyone would know that he is in the posession of a private key for the specific public key.

That also implies that we cannot be sure a peer who claims to have a certain name really has this name. (Let's consider each peer has a name, that we don't know.)

What is your opinion about it?

Improve this question
$\endgroup$
1

2 Answers 2

Reset to default
2
$\begingroup$

Well, the obvious problem with just exchanging public keys is, in fact, there is no way of knowing whether a peer who claims a name really has this name. If you are using the name to make cryptographical policy decisions, this is a problem.

As an obvious example, Eve can join the group and claim to be Bob; there's nothing stopper her from doing so.

As a more aggressive example, suppose the real Bob attempts to join the network, and he publishes his name/public key. However, Mallet is sitting in front of Bob; he grabs the name/public key pair, and replaces it with Bob's name/Mallet's public key. Then, everyone thinks that to talk to Bob, they need to use Mallet's public key. When Bob sends a message, Mallet can't listen into that (unless, of course, he replaces everyone else's public keys that Bob gets with his own); however, whenever someone sends a message to "Bob", Mallet can listen in.

What certificates buys you is a binding between an 'identity' and the 'public/private keypair'; at some point Bob talks to the CA, gives the CA his public key, and proves his identity (to the satisfaction of the CA), and in response, the CA gives Bob a certificate that, in essence says 'I, the CA, attest that Bob owns the public/private keypair X'. Later, when Alice wants to talk to Bob, Bob can give her that certificate, and Alice can verify that the certificate was issued by the CA, and the identity listed in the certificate is the one she wants to talk to. As long as she trusts the CA (both that its keypair hasn't been compromised, and that it did a sufficient job in verifying that Bob is who he claimed to be), she knows that the she can use the public key listed in the certificate.

Now, how important is that to you? Well, that rather depends on how much you need to trust the 'identity' that people claim for making security decisions. If you don't use that identity at all, well, it's not a big deal (but it does raise the question: how do you decide whether and to whom you send messages)? If you do, then you really do need some way to verify the claimed identities; the CA approach is a scalable possibility.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Thanks for the extensive answer. Actually I am talking about some kind of p2p network. Due to the nature of this networks, that is completely against central points (of failure[;)]) its not possible to introduce a CA. Are there alternative approaches? $\endgroup$
    – Erik
    May 31, 2012 at 13:23
  • $\begingroup$ @Erik, the web of trust model is one alternative. $\endgroup$
    – mikeazo
    May 31, 2012 at 13:28
  • $\begingroup$ @Erik: if by 'central point of failure', you mean 'you don't want your P2P network to go down if one piece of equipment goes down', you do realize that CAs do not have to be active while people are communicating? On the other hand, if you mean 'you don't to have a centralized place of trust', you do have a valid point (but that doesn't make the question about how to validate identities go away) $\endgroup$
    – poncho
    May 31, 2012 at 13:37
  • $\begingroup$ Yes I know, CA doesn't need to be online any time, but failure could also mean that the CA gets compromised. I put it in brackets anyway, because my main concern why I don't want it is that having a single authority is against p2p design. However, I think I have understood the problem now. Thanks again! $\endgroup$
    – Erik
    May 31, 2012 at 17:10
5
$\begingroup$

There is another advantage that certs provide that has nothing to do with trust issues. Certs are a pretty-much universally-recognised public-key bit-bagging format that's portable to pretty much everything, while there's no such equivalent for raw public keys. By placing your public key in a certificate, you're converting it into an interoperable form that almost anything (even some versions of PGP) can read.

This use of certs as public-key exchange formats is quite common, it's effectively what a self-signed cert is. In addition many crypto tools ignore the rest of the certificate (even when it's issued by a CA) and just use the public key, since that's all they care about, either because the cert/public key are communicated via authenticated channels and the use of a CA is just a distraction, or because all you need is the cert as a token to enable crypto without having to go through all the calisthentics of cert validation.

So I'd always use certs to exchange public keys, not because of any magic surround certs, but because they provide a useful interop format for keys.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.