[GNUnet-developers] 'Sealed Senders' in CADET

[carlo von lynX]

Moxie's recent blog post is making the rounds:
https://signal.org/blog/sealed-sender/
(You may not need to read it to make sense of this mail).

In the case of Signal it still has two defects: the way the
clients always talk to the same server over the same TLS
connection, so the cloud service is trusted not to pass that
information to the NSA in accordance to US laws, and the way
we are not granted our own executables and rather have to trust
those from Google Play.

But apart from that, 'Sealed Senders' is a nice display of how
much crypto can revolutionize traditional protocol design.
In our case this method can actually achieve much more as
we can indeed submit messages over non-deterministic routes,
thus truly obfuscating the sending side's metadata.

In order to hide the source field in Signal's messages some
new server side features are introduced: sender certificates
and delivery tokens.

    To prevent abuse, clients derive a 96-bit delivery token from their profile 
key and register it with the service. The service requires clients to prove 
knowledge of the delivery token for a user in order to transmit “sealed sender” 
messages to that user.

We could be doing similar things with extra data stored
in the DHT, but -- I question myself -- do we need that?
In GNUnet we already have peerIds that need to be 
known in order to send to them, we have egos that need
to be known in order to send to them, and we have CADET
ports (aka shared secrets) that are necessary to be
known in order to talk to somebody's device. We already
have several layers of abuse protection -- what keeps us
from simply dropping sender information in CADET metadata?


-- 
  E-mail is public! Talk to me in private using encryption:
   //  http://loupsycedyglgamf.onion/LynX/
  //    irc://loupsycedyglgamf.onion:67/lynX
 //    https://psyced.org/LynX/