LisPi · @lispi314
696 followers · 14886 posts · Server mastodon.top

The use is unclear and the lack of -style loop messages seems like a potential problem for cover traffic.

Cover traffic is entirely unmentioned during the entirety of the slides.

It would be possible to build that atop of of course.

There are no mentions of delays in messages nor any other manipulation to mitigate timing analysis.

If nodes select routes based on performance, that's an additional deanonymization risk (shared by ).

#mixnet #Loopix #veilid #i2p

Last updated 1 year ago

LisPi · @lispi314
654 followers · 14133 posts · Server mastodon.top

@mike805 @jeffcliff @brewsterkahle There's more to it than that. Both and Filesharing go into such scenarios as resilience in the face of a malicious majority.

#Loopix #gnunet

Last updated 1 year ago

LisPi · @lispi314
654 followers · 14133 posts · Server mastodon.top

@jeffcliff @mike805 @brewsterkahle Ah, correct. For some reason that very important part about relay membership was completely absent from their main site.

Then I guess it's down to racing with I2P for implementing the additional features to improve on the model's resilience.

For example, their whole Sybil issue has researched countermeasures (and continued research) mentioned in and papers (among others) that would be easily applicable to any mixnet.

#Loopix #gnunet

Last updated 1 year ago

LisPi · @lispi314
427 followers · 8075 posts · Server mastodon.top

@HistoPol @Viss like have a more promising design as far as resistance to such traffic analysis goes. I2P however is not perfect and the small size of the network plays against it, as it makes bruteforce enumeration of its participants an option (if one somewhat expensive).

In general mixnets are the safest design for low-to-high latency networks with surveillance resistance.

The whitepaper can make for some interesting reading on that topic.

#mixnets #i2p #Loopix #mixnet

Last updated 1 year ago

LisPi · @lispi314
415 followers · 7563 posts · Server mastodon.top

@shoq The answer to your question is no (support.torproject.org/about/a).

Neither will on its own suffice if they're willing to do enough collateral damage in their search.

implementations (which address padding & timing to a greater degree) also wouldn't suffice for the same reasons.

Out-of-band (perhaps mediated through ) and rebroadcasted through those networks would however help with spreading messages.

#i2p #Loopix #asynchronouscommunication #NNCP #tor

Last updated 1 year ago

LisPi · @lispi314
144 followers · 2125 posts · Server mastodon.top

@ceresbzns @dmoonfire @noracodes Part of the nonsense is promoted by a weird insistence on very low latency networking.

Designs like handle many of those attacks without any of the weird monetary contortions they include.

You just have to accept higher latency and lower bandwidth as a tradeoff.

#Loopix

Last updated 2 years ago

LisPi · @lispi314
71 followers · 1424 posts · Server mastodon.top
LisPi · @lispi314
71 followers · 1424 posts · Server mastodon.top

@icedquinn Using 's CADET (docs.gnunet.org/handbook/gnune) and a implementation would give you a fairly good mixnet, where each end-node also has a decent amount of cover traffic.

That hasn't been implemented yet afaik.

(secushare.org/) has a number of interesting things to say about GNUnet and the internet.

Also yes, non-CADET traffic *does* offer weaker guarantees than other onion networks. You could implement onions atop GNUnet.

#gnunet #Loopix #secushare

Last updated 2 years ago

LisPi · @lispi314
71 followers · 1424 posts · Server mastodon.top

@icedquinn That is unfortunately the state of it at this point.

It is currently more of a privacy-first meshnet WIP project than a ready solution.

The privacy guarantees are not really weaker than onion routers, but the anonymity guarantees *by default* are as not all uses of it mandate network remixing. You *could* implement on top of just fine.

#Loopix #gnunet

Last updated 2 years ago