[Cryptography] Anonymous rendezvous (was Business opportunities in crypto)

[Jon Callas]

> On Apr 15, 2021, at 11:33, Jerry Leichter <leichter at lrw.com> wrote:
> 
> Look, we all know how this kind of thing works in practice; we've done it forever, without any cryptography.  The reason I bring this up is the long-standing false claim that public-key cryptography allows two parties who've never interacted previously to talk securely to each other, without any other parties being involved.  But it doesn't work like that - it *can't* work like that - in any meaningful sense.

I have no idea if I agree with you or not, but I feel compelled to comment.

I'm going to assert that it both *can* and *does* work that way, but I'm going to take the very same argument you make.

> 
> Sure, you can use DH key agreement to set up a secure discussion ... but absent some additional mechanism, you can make no assertions about *who* you had that secure conversation with.  

Absolutely, and this happens in the real world all the time. In general, people we meet give us assertions that are true. The vast majority of people when you have some conversation with them, give you assertions about themselves. If you never have another conversation with them, it doesn't matter. If the information we get in future conversations doesn't jibe with the past ones, it raises flags.

Even then, there are plenty of edge cases.

This is an issue that I've talked about a lot in cryptographic security. Let's take the case where someone calls you up and says, "Jerry, you don't know me, but there's something important you need to know." While this is a bit dramatic, it's really what happens any time you talk to someone you never met before. You don't know who they are. There are plenty of clues that we all pick up on, but you don't know.

> Full asymmetric cryptography, in and of itself, gives you no more than that.  The original claim was that I could shop in safety because I knew for sure that I was setting up a private connection to Macy's, having never before contacted them.  Except I can only make that assertion to the degree that (a) I trust CA who signed the key not to lie to me; and (b) I trust that the CA *has some additional data to prove to it that the public key it thinks belongs to Macy's does, indeed, belong to Macy's.  *Both* of these bits of trust have proven misplaced in the past, and certainly will be again in the future.

Sure! You are trusting the CA, and CAs have, do, and will make mistakes. Obviously we want to push those to as close to zero as we can, but they happen. The probability that what you think is Macy's actually is Macy's is 1-epsilon, and we presume that epsilon is very small.

Let's go back to that example, and say that after you talk to that person who told you something you need to know, someone who is with you says, "Well, that was weird." You ask what was weird and they say, "That was Bob! I'd know that voice anywhere. Bob used to work with Alice and me at XYZcorp. Wow!" That someone with you is serving the same function as a CA. The CA is an introducer who gives you evidence that the store was Macy's. Your companion is giving you evidence that the mysterious caller is Bob.

Somewhere in your head, you have a lambda name for this person (e.g. "The person who mysteriously called me; who my friend thinks is Bob who worked with them and Alice") and as your interactions with "Bob" progress, the framing that's a lambda name grows and if it makes sense -- not strictly consistent, just makes sense -- you attach the name "Bob" to this person and gradually forget other stuff. Humans call this "getting to know someone."

The point is that I agree with you that the first time you talk to someone you can make no assertions about who they are, but this is not unique to cryptographic protocols, it happens every time you talk to someone for the first time.

> 
> This is an induction.  Having *even once* been a position to exchange information privately with "the real Bob," directly or through third parties, Alice can use that information to communicate securely with that same Bob in the future.  n -> n+1.  But you also need the base case, that first secure connection - and *that* requires something different than the inductive step.

Gosh, this is exactly what the "key continuity" aspects of the ZRTP protocol are. It's what I think its most important cryptography-backed security guarantee is. Key continuity lets ou know that the entity you are talking to this time is the same one that you talked to last time. On top of that, the short authentication string is a quick check on a proxy connection. The two of them together give exactly that induction.

I think it's worth noting that the human versions of this issue are not quite the same as the cryptographic ones. As humans, we use human clues for our induction -- for example, if the voice of someone on the phone sounds this time like it did last time, we generally consider it the same person. In contrast, the cryptographic version of it is much stronger. It's not a fuzzy match based on voice and other biometrics, it's based upon cryptography. It is thus a much stronger induction than the human one, yet it can only identify the device or endpoint, not the person.

So yeah, a public-key cryptographic system has an issue, that of identifying a new pairing. Yet that issue isn't substantially different from, even though there are differences in details, of the basic human problem of talking to a new person. I push back on your claiming that it can't work in a meaningful sense because both of them *do* work in a meaningful sense, and often they reinforce each other. The induction in one domain reinforces the induction in the other, when they jibe, and when they don't jibe, we wonder what's up.

I'll sum up with an anecdote. I was once in the car with my partner and my mobile phone rang, on a cryptographically secure voice call. My partner picked the phone up; explained to the person that no, they aren't me; that I was driving; and offered to relay a message. The person on the other end could have backed out of the conversation with something like, "Tell Jon that Bob called, call me back when there's an opportunity." They didn't. They relayed the message to the person with a good story. I have no idea how much the cryptographic security played into that.

	Jon