[tor-dev] RFC: obfs4 (Name not final)
phw at nymity.ch
Fri May 23 12:16:49 UTC 2014
On Wed, May 21, 2014 at 06:36:52AM +0000, Yawning Angel wrote:
> * obfs4 always does a full handshake. ScrambleSuit style session
> ticket handshakes are not supported. Even with Elligator2 mapping
> taken into account, the obfs4 handshake is significantly faster, so
> there is less of a need for this.
That's probably a good idea as it leads to less code and complexity. We added
session tickets when we were experimenting with a proof-of-work scheme instead
of the shared secret which is now wrapped around UniformDH. The PoW scheme
turned out to be unpractical but we kept session tickets as they still provided
a small computational benefit.
> * Should obfs4proxy also have (disabled) IAT obfuscation? Adding it
> later will not require wire protocol changes.
I don't think that inter-arrival times are a significant practical threat at
this point. In addition, it has a major impact on throughput which is the
reason why obfsproxy's ScrambleSuit ships with the option being disabled. As
you write, it shouldn't be a problem to add IAT obfuscation later on if it
turns out to be important for some reason.
> * The handshake length mimics ScrambleSuit in terms of maximum
> padding (< 1500 bytes). Should this be increased to be similar to
> obfs3 (~8k of maximum padding)? The server side cost for this
> shouldn't be that high.
I'm not sure if sound decisions can be made without comprehensive data showing
how real-world protocols behave. ScrambleSuit's (and perhaps also obfs3's)
padding length was determined by gut feeling, so ~8k might be fine as well.
> * Is this different enough from ScrambleSuit to be worth deploying? I
> would be ok with this ending up as "just a research project" and
> shelving it if the consensus is otherwise.
While you're at it, there are some other things which might be worth improving:
- ScrambleSuit's framing mechanism is vulnerable to this attack:
In a nutshell, the receiver needs to decrypt the ScrambleSuit header before
it is able to verify the HMAC which makes it possible for an attacker to
tamper with the length fields. While there are probably simpler attacks, it
would be nice to have a fix for this problem.
- We didn't push the idea of polymorphism very far. There are more flow
characteristics such as "packet directions", "total bytes sent", or "total
bytes received" which could be disguised in a systematic fashion. While
reasonable protection against traffic analysis is tricky, we could at least
decrease a classifier's accuracy a bit more. Some ideas could be taken from
this paper: <http://arxiv.org/pdf/1401.6022v1.pdf>
More information about the tor-dev