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
