Re: Planning to continue working on Secushare

[Christian Grothoff]

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

signature.asc
Description: OpenPGP digital signature