• Both hosts have just their public and private key pair (but they do not have the other party’s public key). Bob should be authenticated
  • Assume that the two hosts share clocks that are synced, i.e timestamps can be used.

I have not found any way to do this without some kind of intermediary. My best bet so far is to use the Needham-Schroeder protocol with timestamps in order to prevent replay attacks and authenticate Bob. That is, a third party provides Alice and Bob with a shared key (after both have proven their identity to the third party) that they then use to verify each other. I feel though that there should be some solution that uses the public keys. Any help would be greatly appreciated.

  • 1
    If they don't have each other's key, how Bob can be sure the ping came from Alice and not from Mallory?
    – ThoriumBR
    Commented Nov 17, 2022 at 22:26
  • 3
    She cannot, and that's why you have either a Certificate Authority vouching for TLS certificates, or TOFU (Trust on First Use) for SSH.
    – ThoriumBR
    Commented Nov 17, 2022 at 23:12
  • Please do not vandalize your posts. By posting on the Stack Exchange network, you've granted a non-revocable right for SE to distribute that content (under the CC BY-SA 4.0 license). By SE policy, any vandalism will be reverted.
    – tripleee
    Commented Nov 22, 2022 at 18:23
  • Related: security.stackexchange.com/questions/262597/…
    – mti2935
    Commented Nov 22, 2022 at 18:35

2 Answers 2


Identifying an unknown entity without having any sort of direct or indirect identification data, is not possible.

You either need to have a pre-shared piece of info to use (directly or indirectly) to identify the entity, or rely on a trusted third party.

A solution that you may want to consider is using Certificate Authorities (CAs).

A CA, that Alice and Bob trust, signs Alice's and Bob's public keys. When Alice asks for Bob's public key, she can verify that the public key belongs to Bob by verifying the signature from the CA.

The concept of CAs is so thought through and convenient that almost the whole internet depends on it.

  • Another mechanism is Web of Trust. If Alice trusts Charlie, and Charlie have signed Bob's public key, Alice can trust Bob's key because she trusts Charlie.
    – ThoriumBR
    Commented Nov 22, 2022 at 17:30
  • @ThoriumBR indeed, however if you verify Bob's public key directly, it means that you already know Bob's public key fingerprint (pre-shared piece of info). If you trust Charlie to vouch for Bob's public key, then you use a trusted third party. So I would say that the web of trust is a special case of the two approaches I described in my answer.
    – user284677
    Commented Nov 22, 2022 at 18:02
  • Or Alice trusts Charlie, Charlie trusts Debbie, Debbie sends Bob's key to Alice. The trust relationship means Alice can trust Debbie because of Charlie, and end up trusting Bob's key.
    – ThoriumBR
    Commented Nov 22, 2022 at 18:04
  • @ThoriumBR The point is the same, isn't it? When you use someone you trust to vouch for someone you don't trust, then you use a trusted third party. In you example, Debbie acts as an intermediate CA and Charlie is Alice's root CA in that specific chain of trust. Change the names and you have identical schemes, with the difference that the web of trust does not involve a centralized CA.
    – user284677
    Commented Nov 22, 2022 at 18:11

If find the noise protocol an easy way to visualize what is gained by a given exchange. There is even a very explanatory gui called "noise explorer" which is very search engine findable.

Without any pre-shared or third party trust, it is impossible to know bob from anyone else. This is NN (neither participant is known), there is no authentication and very rough secrecy.

The thinnest solution is a pre-shared symmetric key (password, etc). NNpsk0 or NNpsk2. This of course is vulnerable to a key exposure (anyone knowing the shared key can pretend to be alice or bob). But has full authentication and decent secrecy.

The other way is to trust a third party (CA) (XX) or share the public keys offline (KK).

You must log in to answer this question.