Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

Let\'s think of the following case: A group of peers want to exchange messages w

ID: 650734 • Letter: L

Question

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?

Explanation / Answer

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.