Re: [GNUnet-developers] 'Sealed Senders' in CADET

[Christian Grothoff]

On 10/30/2018 10:17 AM, carlo von lynX wrote:
> what keeps us
> from simply dropping sender information in CADET metadata?

By disclosing the full path to the sender we make it easier for the
network to find and optimize paths.

We could drop the paths, but that might cost significant performance
(we're far from the point of being able to tell how much).

Once the path is no longer included, it begins to make sense to discuss
dropping the sender itself (and replacing it with a pseudonym). At that
point, you'd effectively have a half-baked version of OR, except that
the first hops on the path still _do_ see the full path (as the path is
not OR-encrypted), and the path could be 1 hop, and we again _want_
intermediaries to be able to find short-cuts.  So even if you were to
hide the sender then, it doesn't give you any _good_ privacy, in the
sense of strong assurances under a reasonable adversary model (i.e. not
one where you just assume your "guard" is honest).

If we want reasonable assurances that the sender's identity is hidden,
you want to have OR or a mix.  That is planned, but must happen _above_
CADET. Now, importantly, for the OR/mix network to perform well, the
CADET below must perform _really_ well. So anything that badly hurts
CADET performance (see above) is likely to be really bad for OR/mix
users.  So in my view, we should try to make CADET as fast as possible
and with the _clear_ semantics of no anonymity, and then put OR/mixes on
top with again _clear_ semantics of _strong_ anonymity.  The alternative
-- combining some weak notion of privacy and meek performance in the
CADET layer -- seems strictly inferior for _both_ use-cases.

TLDR: one could do this, but would likely be bad for performance and to
achieve strong privacy we need it on another layer.

signature.asc
Description: OpenPGP digital signature