gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Planning to continue working on Secushare


From: carlo von lynX
Subject: Re: Planning to continue working on Secushare
Date: Thu, 23 Sep 2021 11:39:30 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Thu, Sep 23, 2021 at 11:05:06AM +0200, carlo von lynX wrote:
> The circular topology of end points *does* satisfy the secushare
> expectations on privacy and metadata privacy in particular AFAICT,
> so that's very cool.

Whoopsa I'm posting faster than I am thinking, sorry. No, without
any form of obfuscation such a scheme is not metadata-safe, just
like multicast without onion routing wouldn't be.

A few thoughts on metadata protection in the case of ring topologies.

For maximum metadata protection we would need an onion routing
layer below CADET which would hide any communication between two
participants, or we could be having a second API-compatible CADET
which actually has onion routing inside.. an ORCADET.

I'm wondering if we can also achieve a reasonable degree of metadata
protection by using less optimal ring structures and rather have
multiple shared secrets on an existing ring. It still makes it
clear which social bubbles exist, just not who exactly is talking
to whom.

If we enlarge such circles the metadata protection improves as the
social bubble blurs, but in exchange the reliability  and speed of
the ring is reduced, possibly to the point of not satisfying the job.

Reminds me of the shards of Bitmessage - they were approaching the
problem from the opposite side, starting out with a broadcast
strategy, then reducing the broadcasts to slices of the totality.

There may be some in-between constellation that works well enough 
to achieve plausible metadata protection and there may be mathematical
ways of modeling the architecture to prove how deep we need to dig.
 
For things that aren't time-critical (the secushare higher layers
would know) Jeff's good-ole Mixes might come into play...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]