[tor-dev] Brainstorming about steganographic transports

[Zack Weinberg]

On Wed, Jul 25, 2012 at 11:56 PM, Robert Ransom <rransom.8774 at gmail.com> wrote:
> On 7/26/12, David Fifield <david at bamsoftware.com> wrote:
>
>> We can use appid-like signatures to make steganographic channels, if we
>> assume that the signatures are a realistic reflection of actual use of
>> the protocols. But: this relies critically on the accuracy of the model.
>> (Specifically, does it match the censor's model? If he uses simple
>> regular expressions for blocking, then we win; if not, then we probably
>> lose.)
>
> Not quite.  If the language your syntactic model was based on is
> accepted by the particular regular expressions that the censor is
> currently using, you win (until They change to new regexps).
> Otherwise, you lose.

Some aspects of the wire traffic generated by any given protocol are
going to be wholly defined by the protocol specification (including
errata and "everyone does it this way" spackle).  Other aspects can
vary depending on higher-level input to the protocol.  It might be
useful to decompose your arithmetic-coding output model into two
stages: do the generation of said 'higher-level input'
probabilistically, then use an actual implementation of the cover
protocol to produce the fixed components.

Here's another example from StegoTorus: Right now the HTTP request
generator stuffs arbitrary base64-encoded data into the Cookie:
header, making sure to insert equals signs and semicolons to make it
syntactically valid. This isn't _wrong_ per se, because JavaScript
running on the client side can manipulate the cookies to be sent with
the next request, but it is _abnormal_: most cookie-using sites send
down a Set-Cookie header with the first page load and then the browser
will send exactly that string back on all subsequent requests.  I
doubt one could detect this with regexps, but I'm sure I could do it
with a support vector machine or something like that.  (And then we
get to have the argument about what, exactly, DPI boxen are capable
of.)

If we were using an actual implementation of HTTP we would not have
gone down this road in the first place because the client API makes
clear where you do and do not get to stick your payload.

zw