The #mixnet use is unclear and the lack of #Loopix-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 #Veilid 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 #I2P).
@mike805 @jeffcliff @brewsterkahle There's more to it than that. Both #Loopix and #Gnunet Filesharing go into such scenarios as resilience in the face of a malicious majority.
@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 #Loopix and #Gnunet papers (among others) that would be easily applicable to any mixnet.
@HistoPol @Viss #Mixnets like #I2P 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 #Loopix whitepaper can make for some interesting reading on that topic.
@shoq The answer to your question is no (https://support.torproject.org/about/attacks-on-onion-routing/).
Neither will #I2P on its own suffice if they're willing to do enough collateral damage in their search.
#Loopix implementations (which address padding & timing to a greater degree) also wouldn't suffice for the same reasons.
Out-of-band #AsynchronousCommunication (perhaps mediated through #NNCP) and rebroadcasted through those networks would however help with spreading messages.
#i2p #Loopix #asynchronouscommunication #NNCP #tor
@ceresbzns @dmoonfire @noracodes Part of the nonsense is promoted by a weird insistence on very low latency networking.
Designs like #Loopix 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 is pretty neat. https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/piotrowska
#Loopix #security #usenix #mixnet #anonymity #whitepaper
@icedquinn Using #GNUnet's CADET (https://docs.gnunet.org/handbook/gnunet.html#CADET-Subsystem) and a #Loopix 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 (https://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.
@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 #Loopix on top of #GNUnet just fine.