[Top][All Lists]

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

Re: Planning to continue working on Secushare

From: Christian Grothoff
Subject: Re: Planning to continue working on Secushare
Date: Sun, 3 Oct 2021 11:56:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

Thanks. Applied as c94699a..d1d0d07. -C

On 10/3/21 11:16 AM, Tobias Platen wrote:
> 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...

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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