Hey,
the paper is from August 2018 (if I looked at the correct one), not so recent :)
And e. g. Philipp Winter questions the usefulness of iat_mode:
substantial performance penalty for a dubious and poorly understood
privacy gain
https://lists.torproject.org/pipermail/tor-relays/2021-February/019370.html
I personally leave my bridges as they are, without iat_mode.
Best,
Fran
On 5/12/23 13:34, George Hartley via tor-relays wrote:
Hello dear relay and bridge hosts,
recently a paper was published, describing a traffic confirmation attack called DeepCorr, which works against Tor users and as such, also hidden services.
The attack allegedly had success rates of up to *96% percent*.
It is being worked on and listed here as a separate ticket:
https://forum.torproject.net/t/tor-dev-critical-deepcorr-traffic-confirmatio... https://forum.torproject.net/t/tor-dev-critical-deepcorr-traffic-confirmation-attack/6720
Until mitigations have been merged into the Tor codebase, I kindly ask you, the driving force behind the network, to set up more bridges with "iat-mode" enabled and set to "1" or "2" - the paper stated that it was significantly harder to launch successful attacks against clients using OBFS4 bridges with timing obfuscation enabled, which is what "iat-mode" really is.
*In a nutshell*, the measure of IAT is the average (or the arithmetic mean) between network packets arriving at a host over a period of time, of the times between packets arriving at a host over a period of time, which you can also call latency.
For security reasons such as defeating DPI and similar network analysis techniques, OBFS4, while at the same time encrypting and making your traffic look like regular TLS traffic, it also offers to try and obfuscate the IAT and packet size by inserting random padding bytes.
For you guys or girls with programming skills or the ability to read and understand code, here is the responsible code:
https://github.com/Yawning/obfs4/blob/40245c4a1cf221395c59d1f4bf274127045352... https://github.com/Yawning/obfs4/blob/40245c4a1cf221395c59d1f4bf274127045352f9/transports/obfs4/obfs4.go#L481
I vote for a fair 50 / 50 distribution of bridges with "iat-mode=1" and "iat-mode=2", even though while IAT mode 2, also called the "paranoid" mode by the author of the code above, may be more effective.
Dear *clients*, you can already enable timing-obfuscation in *one way*, by editing your bridge-line and setting iat-mode from "0" to either "1" or "2" - please be aware that this will only enable timing-obfuscation in one way, the bridge needs to support it too to get packet timing obfuscated in both ways.
Dear *bridge operators*, all it takes is a simple tor configuration file change:
ServerTransportOptions obfs4 iat-mode=1
or
ServerTransportOptions obfs4 iat-mode=2
Your bridge key will very likely stay the same, although I /do not/ have the infrastructure to try this out right now.
It is and has been *very hard* to find *reliable* OBFS4 bridges which also support timing obfuscation, for over a year now - *please consider changing your bridge configuration in order to possibly help clients and hidden services evade timing related attacks such as DeepCorr*.
Yours truly, George Hartley
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays