[tor-dev] GSoC Update

[Brandon Wiley]

With the TorDev meetup and everything it's been a while since I sent out an
update on the state of the project, although I think we more or less caught
up on the status at the meetup. The bulk of the implementation work had
already been completed, so what I've been working on since then is just
cleaning up the code and rewriting some parts. In particular this week I
rewrote the detectors to be mostly python. The core Bayesian model is still
in BUGS/JAGS and there is still R code to interface with that. However, the
output of the models after training is now converted to a CSV file and the
actually detection code is a python program which reads the CSV file with
the trained model's prediction data and the compares it to the data of a
stream to be classified. This means that you only need R for training the
models. If we can put together a canonical model for each protocol then you
can use it to classify new traffic just using python. I think this is a win
because R was the bulkiest dependency. It also segments the process more
nicely in that there can be some people gathering traces, other people
building models, and then other people running detectors against new traces.

In terms of code cleanup, I've been adding comments and refactoring large
files (in particular pavement.py) to be more readable. I also have the
scoring tasks implemented so that, given the output of the detectors, the
various detectors and encoders are scored based on their number of correct
guesses, false positives, and false negatives. The only functionality left
to implement is some sort of reporting, probably in the form of graphs of
the scores so that detectors and encoders can be compared. The rest of the
work is just going to be refining everything and getting both the workflow
and the code structure to be smooth.

Also, I've stopped working on the string detector because I realized that
it's irrelevant for the two encoders I actually have support for right now:
obfs2 and Dust. They both already use totally randomized packet contents and
so will not be vulnerable to this kind of detector. Other encodings will be
vulnerable, but the string detector can wait until we support these
encodings. So instead I've implemented an entropy detector, which should
work very well against both obfs2 and the current implementation of Dust.
The entropy detector is actually the easiest model so far as the entropy of
a trace is just a single number, so that's convenient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110805/a7b08149/attachment.htm>