[tor-dev] bananaphone obfsproxy module

[David Stainton]

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 at riseup.net> 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.