[Top][All Lists]

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

Re: Planning to continue working on Secushare

From: TheJackiMonster
Subject: Re: Planning to continue working on Secushare
Date: Thu, 23 Sep 2021 11:56:29 +0200
User-agent: Evolution 3.40.4

On Thu, 2021-09-23 at 11:39 +0200, carlo von lynX wrote:
> 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 think it should be possible to use onion routing on the transport
layer below CADET. So CADET would still use peer identities for its
connections but the actual host behind it stays anonymous. Then the
messenger service can hide identities on a user-level.

If we get an awesome app out of this also depends a lot on the user
interface. I'm currently working towards a resposive GUI application
which aims to be comparable to Telegram in terms of design but Threema
in terms of transparency. For example the status of verification for
contacts should be visible and understandable to users. File sharing
inside of groups is also possible in a similar way as Threema
implements it but using the FS submodule of GNUnet instead of central
file servers.

> 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...

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

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