Re: [tor-bugs] #8023 [pyobfsproxy]: Where's the pyobfsproxy code?

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#8023: Where's the pyobfsproxy code?
-------------------------+--------------------------------------------------
 Reporter:  arma         |          Owner:  asn
     Type:  defect       |         Status:  new
 Priority:  normal       |      Milestone:     
Component:  pyobfsproxy  |        Version:     
 Keywords:               |         Parent:     
   Points:               |   Actualpoints:     
-------------------------+--------------------------------------------------

Comment(by asn):

 Replying to [ticket:8023 arma]:
 > There's no pyobfsproxy on gitweb.torproject.org -- there is a
 user/asn/pyobfsproxy, but it appears old and doesn't include the obfs3
 module that we apparently shipped (https://blog.torproject.org/blog
 /combined-flash-proxy-pyobfsproxy-browser-bundles).
 >
 > I tried some likely guesses for doing a git clone (maybe it's just
 missing from the gitweb list?), but I couldn't find it that way either.

 You are right that there is no official pyobfsproxy repository.
 pyobfsproxy was developed and deployed quickly and before I thought that
 an official repository would be needed. I created #8027 for this reason.

 > Also, it looks like there's no public spec for the obfs3 protocol. Or
 rather, there are several, since we called it obfs3 before we settled on
 the design (oops -- maybe in the future we should use other names for
 things that we hope will become obfs4). So, where is the design for the
 thing that we're giving actual users? :/

 Yeah, I've been using user/asn/pyobfsproxy.git as a personal repository
 with experimental branches, which probably confuses people who are not me.

 I agree it was a mistake to call all these variants "obfs3", in the future
 we should indeed use other names (maybe even "obfs3_test" could be an
 acceptable name for this situation).

 In any case, to answer your question, the obfs3 that was deployed is the
 one that can be found under the branch "obfs3_take2":
 https://lists.torproject.org/pipermail/tor-dev/2013-January/004334.html
 I will call the deployed obfs3, "obfs3_take2" from now on.

 "obfs3_take2" is *almost* ready. I still need to merge two patches: one
 from Philipp and another one that implements some suggestions of Ian. I'm
 also waiting for a mail reply from Ian, since he had some comments that I
 think I resolved but I want to make sure that he is happy with the
 results. After I receive the mail and merge the patches, I will merge the
 obfs3_take2 branch to master, and consider "obfs3" as done.

 (For an extra fun factor, Ian suggested to change the key derivation
 function of obfs3 so that it uses an IV filled with zero bytes, while
 obfs2 and obfs3_take2 are using an IV derived from the shared-secret. As
 far as I understand, this is mostly an aesthetics matter which will make
 our CTR-mode use more conventional, but it will also break compatibility
 between obfs3_take2 and obfs3. I sent a mail to Ian to make *sure* that
 it's indeed an aesthetics matter, and if it is, I might consider skipping
 this change till the next obfs3-variant. I'm sure that my bridge is the
 only obfs3 bridge out there, and that such a change won't break lots of
 stuff, but I still want to be sure that backwards compatibility is
 maintained. Maybe I could also skip an integer and name the new transport
 "obfs4", but I don't think that that change is important enough to confuse
 people.)

 (Looking at the obfs3_take2 deployment, I don't think I regret its super-
 quick and experimental deployment even though the code deployed might not
 be the final "obfs3" code: obfs3_take2 works correctly, it obfuscates
 stuff, it made me more confident that its implementation is correct, and
 it increased the number of deployed PTs by one. The lesson I learned, is
 that I should name experimentally deployed pluggable transports correctly,
 so that no confusion happens when they stabilize. Maybe I should even
 create a proper procedure for deploying experimental pluggable
 transports.)

 Comments are welcome. Sorry for the wall of text.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8023#comment:2>
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