Re: [tor-dev] bananaphone obfsproxy module

[David Stainton <dstainton415@xxxxxxxxx>]

OK. I've added the Bananaphone commandline options to obfsproxy.

Using Project Gutenberg's Don Quixote
(http://www.gutenberg.org/cache/epub/29468/pg29468.txt)
as corpus and encodingSpec of 'words,sha1,4', model = markov, order = 1
produces a ratio of about 1:12 bytes.
That is for every input byte it outputs around 12 bytes.

The same corpus but with encodingSpec set to 'words,sha1,8' the ratio
is closer to 1:6.
Makes sense since the average word size is 5 bytes and the tokenizer
adds a space to make it 6.

Leif wrote several tokenizers... it should be clear that Bananaphone's
output doesn't have
to resemble natural language. For instance the toByte tokenizer could be used.

This does what you'd expect:
pyobfsproxy.py --log-min-severity=debug bananaphone
--corpus=/boot/initrd.img-3.2.0-4-amd64
--encoding_spec='toBytes,sha1,4' --dest=x.x.x.x:80 client
127.0.0.1:8022

Produces output at a 1:2.

Cheers,

David

On Tue, Oct 29, 2013 at 10:48 PM, David Stainton <dstainton415@xxxxxxxxx> wrote:
> Howdy,
>
> Thanks. Your obfsproxy is a nice piece of work.
>
> Bananaphone + Obfs2 sounds cool!
> Modular transport chains make a lot of sense...
> I like modular transports... recently for fun I wrote a VPN in Python Twisted
> [https://github.com/david415/hushVPN]
> using twisted consumers and producers.
> My idea was to have a modular system where transports could easily be swapped.
> Over UDP it's very fast and I was thinking that maybe I could reuse
> some of that code to write
> packet transports for obfsproxy. For instance Tor over ICMP, DNS etc...
> Obfs2 over Bananaphone over UDP?
>
> Right now the david-bananaphone branch is functional code.
> I've tested it with ssh. SSH over Markov chains! It's laggy but it works.
>
> Leif's design plans are interesting... He will be better at explaining it.
> Perhaps it does something similar to your idea of RHE + Obfs2.
>
> Briefly:
>
> RHE(CRYPTO(HAMMERTIME(TOR)))
>
> - RHE is Banaphone's markov or random weighted Reverse Hash Encoding
> - CRYPTO is NaCl crypto_stream
> - Hammertime: "adds chaff to a bytestream to impede passive timing analysis"
>
> The goal is to not have any distinguishable patterns in the byte
> stream. Is that what Obfs2 accomplishes?
>
> We will do the crypto_stream secret key exchange using NaCl crypto_box
> and Elligator;
> spewing noise after keys are sent Elligator etc...
> We were thinking to first implement the key exchange without
> Elligator... and do that part later.
>
> I'm working on the basic key exchange to work in branch
> david-bananaphone-keyexchange
> https://github.com/david415/obfsproxy/tree/david-bananaphone-keyexchange
> I'm currently troubleshooting a problem with the message passing...
> Maybe I do not understand your api well enough... I'm getting strange behavior.
> It would help if another pair of eyes would look at this.
> Perhaps later I will formulate a question regarding the obfsproxy api...
>
> And I was hoping Leif would help me fix this branch:
> david-bananaphone-nacl-hammertime
> https://github.com/david415/obfsproxy/tree/david-bananaphone-nacl-hammertime
>
> I wrote a naclStreamEncoder coroutine and made hammertime_rh_server
> return coroutine chains with the NaCl stream encoders. It doesn't work
> at all... really a rough draft scribbling of code that makes the
> BananaPhoneBuffer unit tests through an exception...
>
> OK. I will add ALL commandline options to obfsproxy-bananaphone!
> OK... bandwidth overhead calculations... I'll take a look and run some tests.
>
> Onward!
>
> David
>
> On Tue, Oct 29, 2013 at 7:19 PM, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
>> Greetings,
>>
>> I'm the guy who develops obfsproxy. I recently noticed that you are
>> writing a bananaphone module for it. The code looks good and you even
>> understood the pretty-much undocumented obfsproxy API! Nice!
>>
>> BTW, I thought I should let you know that we are currently writing
>> software that combines transports together in chains. This means that
>> you don't have to worry about data redundancy in bananaphone, since
>> you can combine it with an obfuscating transport like obfs2 to create
>> the following chain:
>> tor data -> |obfs2 encoding| ->|bananaphone encoding| -> tor bridge -> |bananaphone decoding| ->|obfs2 decoding| -> tor data
>> This would create a bananaphone-encoded channel which transfers
>> obfs2'ed Tor data (so the bananaphone traffic will look uniform, since
>> obfs2 data is uniform (whether uniform bananaphone traffic is useful for
>> censorship circumvention is a different story))).
>>
>> FWIW, we are still in the process of writing this transport
>> combiner. You can read more about it in:
>> https://trac.torproject.org/projects/tor/ticket/7167
>> https://trac.torproject.org/projects/tor/ticket/9744
>> https://gitweb.torproject.org/pluggable-transports/obfs-flash.git
>> We should also create a Wiki page about it soon, I guess.
>>
>> Anyway, this transport combiner business means that you only have to
>> worry about making the bananaphone transport work. It would also be
>> nice if the transport was configurable, so that we can tweak its
>> parameters easily. I would also be interested in some bandwidth
>> overhead calculations :)
>>
>> BTW, feel free to send me any questions you have about obfsproxy or
>> pluggable transports.
>>
>> Cheers!
>>
>> PS: Feel free to CC the public tor-dev mailing list in your reply if
>>     you want.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev