Re: Adding generic cryptographic self-authenticating block on DHT

On May 29 2023, at 6:18 am, marty1885 <[email protected]> wrote:

> There are two key properties I want to achieve
> with this project. First, I want to ensure strong
> privacy guarantees for both the sender and
> receiver of messages. Second, I want to enable
> communication between parties who may not be
> online simultaneously.

It depends what you mean by "privacy guarantees" really.

You mention metadata privacy, as opposed to the content privacy supplied
by Axolotl flavored messangers, like Signal, Wire, Matrix, and maybe
even some FANG ones like WhatsApp.  And Briar is fairly p2p.  And some
new ones poped up.

As a warning, content privacy remains a sizable design space, even
assuming servers, witness all the nooks and crannies discovered by the
MLS people.  A priori, one should do a "peer-to-peer messanger" by
learning MLS well, and then removing the server dependencies in MLS. 
Matrix worked on this some, but maybe side tracked now, or maybe they succeeded.


> Any flaws you can think of in this design?

Afaik DHTs cannot provide much metadata protection:  You leak metadata
if you repeatedly check DHT addresses. You leak identity if you've only
one DHT mailbox. 

There exist related schemes like FuzzyTags which pro-actively leak
metadata, but gain efficiency:

https://openprivacy.ca/work/cwtch/
https://openprivacy.ca/discreet-log/01-anonymity-bandwidth-and-fuzzytags/index.html

Tor already beats all these designs.  Pond too.


There exist numerous schemes with metadata privacy stronger than Tor,
but they all incur similar or really greater complexity:

An MIT lab pumped out slightly-new semi-analyizable metadata privacy
schemes for years.  As a rule, these were mixnets for the forward
direction, but then PIR for receivers, aka servers.

Among pure mixnets, loopix flavors like Nym typically have mixnets for
the forward direction, but really loopix providers are servers to whom
users leak their IP, and they never take receiver anonymity seriously.

At a theory level, all these schemes focus upon servers for various
reasons, like reliability, vetting server operators, etc.  Nym has a
semi-open node set, so they can sell their staking token, but they'd dp
a closed node set if their economic model permitted.

We'd plans for a mixnet based messanger way back when I worked for gnunet:
https://github.com/burdges/lake/tree/master/Xolotl/papers

It'd achieve your goals using only mixnets, including the open node set.
It depends heavily upon SURBs though, which brings a lot of failure
modes that require finesse.


All stronger metadata defenses add latency, so they'll never work with
TCP and UDP.*  As a result, they all need all new latency tolerant
protocols and applications.  An email-like messangers makes sense.  Also
git makes sense.  Yet, what about everything else?  That's another conversation.

Best,
Jeff

* Nym sends TCP and UDP traffic over their mixnet, but this leaks who
connects to who fastere than Tor does.  They justify this by dropping
down to an onion routing threat model and arguing the adversary has
trouble doing traffic fingerprinting.