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

[Phillip Hallam-Baker]

I find this 'anonymous rendezvous' concept to be rather mushy and ill
defined. Ditto the concept of 'trusted third party'.

So Alice wants to establish communication with Bob without Mallet knowing
that they are talking. What are we going to allow them?

* Prior knowledge of the credentials, IP address of the other?

* Use of the IP address of the other party's device?

* Third party providing a dead drop?

* How many other people are using the same network?

As with many problems of this sort, unless we start with a clearly defined
understanding of what the constraints are, we cannot understand the degree
to which the communication can be made resistant to traffic analysis.

Note the use of the term 'degree to which'. Tor allegedly provides traffic
analysis resistant messaging but as one student kicked out of Harvard
learned, no traffic analysis resistant network can help you if you are the
only person using that scheme.

The way to firm up the specification is probably to introduce a collection
of Bobs and set up the problem as preventing Mallet knowing which
particular Bob Alice sent the communication to.

I would specify the Trusted Third Party similarly but I remain skeptical as
to the notion that 'zero trust' is possible or even desirable as an
absolute. Every party involved in a communication is trusted to at least
the degree of providing service. We can limit the degree of trust but
trying to eliminate trust completely tends to cause us to end up trusting
some other party more. Rather than place 100% trust in one party, I would
rather divide that trust across two, three or more parties such that they
all need to collude if they are going to successfully attack me.


I have been considering these issues at some length in the design of
Reliable User Datagram, which began as a presentation layer for Web
services. When Alice is talking to her Mesh Service Provider, I want every
request and every response to be authenticated and bound to the credentials
of the client and service via their respective devices and credentials.

This is essentially SOAP/WS-Security redux but greatly simplified because I
only allow for one mode of authentication of the parties (mutual
authentication by means of public key exchange with both sides presenting
an ephemeral challenge).

So I ended up with datagrams that are prefixed with the destination stream
ID which is followed by an encrypted payload and an authentication tag.
[Why MAC when you can encrypt]

One thing I quickly realized is that there is no need for a return address
except during the very initial stages of connection setup.


If people specify precisely what they mean by 'anonymous rendezvous', I can
probably satisfice their requirements if they are consistent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210502/092ca1bb/attachment.htm>