[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30716 [Circumvention/Obfs4]: Improve the obfs4 obfuscation protocol
#30716: Improve the obfs4 obfuscation protocol
-------------------------------------------------+-------------------------
Reporter: phw | Owner: phw
Type: task | Status:
| assigned
Priority: High | Milestone:
Component: Circumvention/Obfs4 | Version:
Severity: Normal | Resolution:
Keywords: sponsor28, anti-censorship-roadmap- | Actual Points:
august |
Parent ID: | Points: 20
Reviewer: | Sponsor:
| Sponsor28-must
-------------------------------------------------+-------------------------
Comment (by phw):
Here's a brief overview of where we're at. We should improve both obfs4's
payload ''and'' flow obfuscation. My
[https://trac.torproject.org/projects/tor/ticket/30716#comment:10 above
comment] gave an overview of how we can improve flow obfuscation. To
clarify: blindly incorporating WF defences is unlikely to succeed. We
should instead extend obfs4's flow obfuscation and build an evaluation
framework (which can be inspired by WF work).
The main issue with obfs4's payload obfuscation is that it consists
entirely of uniformly distributed bytes for which Wang et al. built a
reliable classifier in their CCS'15 paper. We should find a way to reduce
obfs4's per-packet entropy – at least for the first ''n'' packets,
assuming that our adversary classifies a flow in the first ''n'' packets.
Keeping flow state is costly, after all.
We identified two approaches for reducing obfs4's per-packet entropy:
1. Adopting LibFTE. We could derive regular expressions from obfs4's
shared secret that we then feed into LibFTE. These regular expressions
should make obfs4 look like "a protocol with structure."
2. Building an entropy "modifier". A silly implementation of this idea
could insert a 0-byte after every second obfs4 byte, which would reduce
the stream's entropy. Again, the way this entropy modifier works should
be derived from obfs4's shared secret. We should parameterise the
modifier with an inflation factor ''i'', which we can gradually scale back
to 0, to improve goodput once our adversary classified the flow.
As cohosh pointed out, the challenge lies in making these improvements
without having us stand out.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30716#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs