# First contact when using Public-key cryptography?

Are there any "smart", useful ways when doing first contact in Public-key cryptography? Besides physical contact.

Example: SSH has the "VisualHostKey=yes" (but this also requires to know the image...)

Visual Validation of SSL Certificates in the Mozilla Browser using Hash Images https://www.cs.cmu.edu/afs/cs/user/mjs/ftp/thesis-program/2004/tay,evelyn.pdf

• So you're asking how to establish trust on first contact? Are you looking for practical and deployed solution, for just about all solutions or rather for the basic theoretical approaches to this problem? – SEJPM Dec 15 '16 at 14:36
• "establish trust on first contact" -> yes! – pepite Dec 15 '16 at 14:38

You're asking for techniques to establish trust in a public key upon first connection. There are three major approaches to this problem:

1. Out-of-band-verification. This generally relates to methods which use methods which don't go over the current communication channel to verify a public key.
1. Pinning. If you use pinning, you hard-code your public key (or a hash thereof) somewehere (for example in your app) and then validate that the pin matches the public key. This is also done in browsers, for example Chrome pins the Google certificates. Also there are ways for webservers to signalise that they want their current public key pinned (HPKP).
2. Physical verification. In this scenario you likely want to confirm the public key associated to some physical entity so you go to that person, verify their identity and then associate the public key they claim to belong to them (in person) with them.
3. Other channels. In this scenario you generic "other channels" for your verification. For example if you want to exchange PGP keys, you confirm the hash of the key over Twitter or your favorite messaging app.
2. Certificate Authorities (CAs). This is the approach where one (or a set of) entity(-ies) certifies a public key to belong to a specific entity (eg a person). The signing keys of the CA(s) are verified out of band (as per 1).
1. SSL PKI. For the web, the summary basically describes what is done.
2. DANE. DANE means that you put your public key (or a hash thereof) in the DNS so it can be confirmed "out-of-band" that way. This is placed under "CAs" because the DNS itself is secured by DNSSEC which has a strict CA hierarchie.
3. Web-of-Trust (WoT). In this scenario everybody becomes a CA basically and certifies other people's key depending on the verification they have reached out-of-band. This allows you to traverse the graph that the WoT forms and find a path from you to the new public key, maybe because two of your friends already have seen and verified said public key.
1. PGP WoT. The above is basically how the PGP WoT works.
2. Notary-like Approaches. This is a slightly different approach but is also based on the idea of "many CAs". Basically you have a set of (more or less trusted) notaries and each time you encounter a new website you ask them what public key they see. If these match what you see you have some confidence that your key is good if not, you know you're attacked.
4. Trust-On-First-Use. This approach is the most straightforward one. Assume the first connection is ok and keep the public key or a hash for verification against later connections. Obviously this doesn't solve your problem.

In security we talk about "anchors of trust". You can't just generate trust out of thin air. Establishing trust in a public key basically means that you make a connection between the key and the person / machine who owns it -> ie "I believe that key A3F77B6... belongs to John". If you are making a first-time connection to the other person, then there is no general way to establish that it is actually them and not a man-in-the-middle claiming to be them.

There are many methods for establishing first-time trust, but all of them require some "out-of-band" information. Just to give you an idea, here are some ways:

1. Phone them and read the hash of their public key to make sure you have the correct key.

2. Meet in person to exchange key hashes.

3. If you already trust Cathy's key, and Cathy trusts John's key, then you can extend your trust to John's key. (This is how the PGP "web of trust" works)

4. In a Public-Key-Infrastructure (PKI) you get a trusted Certificate Authority (CA) to issue a certificate saying "We have done the background checking, and this key belongs to John". This is the model that web browsers use to establish first-time trust in a website using https.

5. Others?