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