On Thu, Jan 10, 2013 at 2:18 PM, vmonmoonshine@gmail.com wrote:
I was talking to Roger yesterday on the IRC, and he mentioned that "[S]tegotorus ... has a whole lot of problems". I have heard this many times in different forms by now (in Florence, The sponsor F discussion, etc). But I never saw these "lot of problems" are broken down in a list, so at least one can attack them one by one. It was always "lots of problem".
So, let this email be an appeal to all of you who have some problem, deficiency, architectural dissatisfaction, etc with Stegotorus, write back on this thread, so at least we have written account of these problems and dissatisfactions?
Sorry for taking so long to chime in here. From my perspective, there are four critical problems with Stegotorus as is. I consider the first three still my responsibility to see addressed, but as Roger mentioned, I'm busy being a student, and it's unlikely that I could get another publication out of fixing these problems, so it's hard for me to spend any significant time on it. SRI is still theoretically paying me to do it, but the time would have to come from somewhere, and if I start taking their money again, I go back under their collaboration restrictions. That said, in principle I would be *delighted* to work with anyone who was interested in taking on the bulk of the coding and debugging.
I don't take responsibility for the fourth problem because it's code I had basically no hand in, but it does remain a stumbling block, and if anyone wants to work on it, I am available at least for kibitzing.
1. The cryptography was never completed. In particular, the handshake protocol as described in the paper was never implemented. The program as-is uses "session keys" which are WRITTEN INTO THE SOURCE CODE. Obviously this renders it totally unfit for deployment outside laboratory test environments.
This is totally my fault; I should have forced SRI to let me finish it. But they considered the next problem (below) more time-critical, and I went along, and then I didn't finish that either :-/ I should also mention in this context that I am not all that happy with the cryptographic primitives I picked two years ago (especially the weird elliptic curve thing) and if I ever get back to this, the first thing I'm going to do is have a good hard look at better options (Curve25519, for instance, and I'd like to get away from OpenSSL entirely).
2. The chopper *protocol* has a known deadlock condition due to the lack of explicit acknowledgments. The *implementation* may still have bugs on top of that, and it's possible that sufficiently thorough testing will expose further protocol issues.
I started writing code to fix this but never finished it; there's a git branch (should be both on Github and torproject's git server). This is probably the easiest thing for people to help with right now. It is very easy to trigger the deadlocks even in lab-test conditions; basically all you have to do is try to start up Tor over ST with no cached directory information and a network connection that drops SYN packets from time to time.
(2a. There is a desperate need for a more thorough automated test suite for this program, one that can reliably reproduce the deadlock conditions without your having to set up a remote server and/or a special loopback interface that drops packets.)
3. The code is harder to work on than it ought to be due to my having gotten bogged down in minutiae halfway through a C-to-C++ conversion.
I am actually still hacking on this one in my copious free time, but you shouldn't expect anything in the near future. There are nontrivial yaks still to be shaved (the biggest one is a proper C++ binding for libevent). If it ever gets done I expect that the other problems will become much easier to fix; however, it might be faster overall to scrap the entire existing body of code and start over with Pyobfsproxy or similar.
4. The steganography is not only a joke in terms of actually hiding the secret messages, it's just plain badly written. You know how C from the 4BSD era tends to have a buffer overflow every ten lines or so? It's that bad.
It has been my intention for quite some time to deal with this by (a) writing a "steg" module that just feeds chopper output onto the wire but randomizes packet size and connection length, thus providing a small but strict improvement on obfsproxy, (b) summarily scrapping the existing HTTP and Embed modules, and (c) getting after vmon to finish what he started :) Unfortunately (a) is blocked on problems 2 and 3 above, and (b) is difficult to do without pissing off people at SRI; I'm normally happy to be Mr. Nasty when it comes to code quality, but I only have so much political capital to burn and it might be more important to burn it on e.g. dealing with the collaboration restrictions.
Speaking of, vmon, I know you had trouble getting libcurl and libevent to play nice -- did you ever look at libevhtp?
----
There is also a philosophical concern with proceeding with StegoTorus: there are at least three other projects with which it ought to merge, or at least cross-pollinate: FlashProxy, Kevin Dyer's FTE http://eprint.iacr.org/2012/494.pdf, and the shiny new FreeWave http://www.cs.utexas.edu/users/amir/papers/FreeWave.pdf. Coordinating that kind of thing *is* worth me spending time on with my student hat on, since it's more likely to result in papers than straight-up coding, but I still have a bunch of other projects which are higher priority.
zw