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

[Henry Baker]

At 12:06 AM 4/15/2021, Christian Huitema wrote:
>On 4/15/2021 2:54 AM, Richard Outerbridge wrote:
>>>On 2021-04-14 (104), at 16:58:10, Kent Borg <kentborg at borg.org> wrote:
>>>On 4/14/21 12:37 AM, Christian Huitema wrote:
>>>>Anonymous rendezvous is a vexing problem.
>>>When you put it that way, it sounds pretty impossible.
>>Sounds pretty much reducible to PSSK.
>
>Excuse my ignorance, but can you spell out PSSK?
>
>Anonymous rendezvous is not entirely impossible.
>
>During the discussion in the DNSSD working group, we saw one plausible proposal.
>
>Assume that each of the parties has a public/private key pair, that authorized peers know the public key of the party with which they want to rendezvous, and that this public key is otherwise kept hidden from third parties.
>
>In short, the public key is treated as a shared secret between parties authorized to discover the owner of the key pair.
>
>The rendezvous can be achieved by encrypting a message with the public key of the party that want to be discovered, then broadcasting that message.
>
>Only the targeted party can decrypt it, and nobody else can find who the message is for.
>
>The message shall include suitable nonce to protect from replay attacks, and the encryption must not reveal the public key.
>
>So, in a sense, the problem is solved.
>
>On the other hand, there is a huge scaling issue because every potential target shall try to decrypt every anonymous discovery attempt.
>
>There were proposals to add various kind of hints to reduce the processing requirement, but you quickly find out that every additional hint reduces the puriy of the scheme and compromises anonymity.
>
>So in that sense, the problem is not solved.
>
>-- Christian Huitema

If one is setting up a point2point connection, then the protocol
can also include timing information for the next rendezvous, which
enables the other party to save power by shutting down and simply
ignore any traffic in the mean time.

Obviously, the protocol has to allow for some degree of clock skew,
as well as error recovery in case the rendezvous is clobbered by
errors or jammed.

This type of protocol may increase latency for ^C/^G types of
interrupts, but this has always been true.