Re: Planning to continue working on Secushare

[Tobias Platen]

I wrote a patch for gnunet-secushare.git that fixes 
the config files that gnunet-arm will read.
The @UNIXONLY@ stuff is removed since that causes a parse error.

Tobias

On Thu, 2021-09-23 at 11:56 +0200, TheJackiMonster wrote:
> 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...
> > 
> > 
>

secushare-config.diff
Description: Text Data