2

I'm designing an application in which clients generate their own TLS certificates ad-hoc (there's no central authority).

When two clients interact for a first time, I need for them to mutually check their peers' certificate. I know that fingerprints are generally used for this, but I need to keep this more newbie-friendly, hence having them check 20 hex characters (SHA-1) doesn't sound very convincing.

I though about representing the same fingerprint with the characters 0-9a-zA-Z (giving me 62 characters to represent the same value), but it's still 13 digits long.

Is there any common (or maybe not as common) way of having two users validate their mutual certificates? This is a real time, low-latency application, so multiple round trips are possible.

EDIT
Users can exchange information in person in this scenario, so saying (or showing) a code to one another is possible. However, I'd like to avoid them having to eyeball 20 characters and manually check them, mostly for user-friendliness.

Improve this question
6
  • 1
    That's why we have CAs...
    – Lucas Kauffman
    Commented Apr 28, 2015 at 8:28
  • Isn't this exactly what the CA is for?
    – BadSkillz
    Commented Apr 28, 2015 at 8:28
  • Build networks of trust? E.g. you validate the first few clients, or add trusted clients which you manually validate, and then your app can find clients that trust clients that trust clients that trust their peer, and validate it... There's plenty of literature on this kind of applications, so you could estimate how quickly and how often that would work for your app.
    – Steve Dodier-Lazaro
    Commented Apr 28, 2015 at 8:33
  • Like I said, there is no CA in this scenario. It's no possible to rely on one either since users can generate their own certificates ad-hoc (and possibly, with no Internet connection).
    – WhyNotHugo
    Commented Apr 28, 2015 at 8:38
  • 1
    For SSH keys, where there is usually no CA, ASCII Art has been added to simplify human check of a key. However I do not know any similar system applied to X.509 certificates...
    – WhiteWinterWolf
    Commented Apr 28, 2015 at 9:59

1 Answer 1

Reset to default
2

Here's three ideas.

Use a CA
As the commenters already said: Have them trust a CA. It's less painful. And it scales much better. Each participant will only have to verify the CA's authenticity once and then they can communicate with every other participant. (Then of course, you will have to trust the CA, very, very much. -- But I consider this a good trade off in your case.)

Human-to-Human audio method: Use the PGP word list
If you really want the "1-to-1" individual verification, then use an octet word list. It maps each hex byte (0x00 to 0xFF) to one or more words.
PGP has done this: Wikipedia: PGP word list

Machine-readable image method: Use a QR-code
One instant-messenger that I use is called "Threema". And they emphasize end-to-end-security and you don't need to trust a CA. Alice doesn't need to verify Bob's key in order to IM him. But if Alice wants to verify Bob's key, then both meet face to face and Bob presses a show-my-key-as-QR-code button in the app. And Alice selects Bob's contact data and then presses the scan-that-person's-key-via-QR-code button.

(There are three levels of trust in the app. The best level of trust is reserved for the people you have met face to face. Weblink: Threema Levels (Archived here.))

Improve this answer
1
  • Like I said, there's no CA: [...] clients generate their own TLS certificates ad-hoc (there's no central authority). OTOH, the PGP word list sounds interesting, and I'll look into it. QR-codes are great, but I cannot, regrettably, rely on them since it's possible that both users are on their laptops and not mobile phones.
    – WhyNotHugo
    Commented Apr 28, 2015 at 8:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .