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 tor-relays@lists.torproject.org 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#7GF2qk8hyTVgkinZshff9Dc9R6ukDDZ...
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 tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays