[tor-dev] All the problems about Stegotorous

[Zack Weinberg]

On Thu, Jan 10, 2013 at 2:18 PM,  <vmonmoonshine at 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