There are new research papers available, suggesting that iat-mode being not set to the default value of 0 resulting in better protection against flow correlation / timing analysis. Here is a recent one that I did not read much into yet: https://arxiv.org/pdf/1808.07285
> Tor’s currently-deployed pluggable transports, showing that meek > and obfs4-iat0 provide little protection against DeepCorr’s flow > correlation, while obfs4-iat1 provides a better protection against > DeepCorr (note that none of these obfuscation mechanisms are > currently deployed by public Tor relays, and even obfs4-iat1 is > deployed by a small fraction of Tor bridges [ 52]). This is just one paper using one machine learning model, but there are others and it is 7AM, so I have to get some sleep before I go to work. Regards, George On Tuesday, September 24th, 2024 at 3:40 PM, boldsuck via tor-relays [email protected] wrote: > On Montag, 23. September 2024 22:27:25 CEST Fran via tor-relays wrote: > > > Philipp Winter regarding iat mode: > > > > > The feature introduces a substantial performance penalty for a dubious > > > and poorly understood privacy gain. If I were to write an algorithm to > > > detect obfs4, I wouldn't bother dealing with its flow properties; there > > > are easier ways to identify the protocol. In hindsight, it was >probably > > > a mistake to expose the iat option to users and bridge operators. > > Yes, I was also wondering if any new research papers have appeared on this > topic. In recent years, Roger and the other Tor Dev's have advised against > using !=(iat-mode=0) If obfs4/Lyrebird iat-mode=0 is not effective, then all > bridges in China and Russia should be blocked within a few days. > My bridge stats don't confirm that: > https://paste.systemli.org/?d3987a7dc4df49fa#7GF2qk8hyTVgkinZshff9Dc9R6ukDDZo6BQqwQURzjQy > > If anything has changed, we should put it on the agenda at the next meetup. > And official instructions on what clients should configure > and what servers should configure. > > Not official yet, I've been hiding the OrPort for bridges for a year now. > https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129 > > > On 23/09/2024 12:15, George Hartley via tor-relays wrote: > > > > > this e-mail applies to you if you are running an obfs4 (now known under > > > the name lyrebird) bridge or want to do so in the future. > > > > > > Some recent posts on this list has shown that traffic timing analysis > > > can be used to locate a users or onion services guard nodes or bridges. > > > This is not really something new. > > But traffic analysis for guard discovery attack has nothing to do > with traffic analysis to detect Tor traffic. > > > If your bridge is distributed by BridgeDB > > Rdsys, BridgeDB is gone. ;-) > > -- > ╰_╯ Ciao Marco! > > Debian GNU/Linux > > It's free software and it gives you > freedom!_______________________________________________ > tor-relays mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
publickey - [email protected] - 0xAEE8E00F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
