Re: [tor-dev] bananaphone obfsproxy module

[George Kadianakis <desnacked@xxxxxxxxxx>]

David Stainton <dstainton415@xxxxxxxxx> writes:

> 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.
>

Ah. Good to hear! Thanks for all the code :)

> 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?
>

Yep, that's what the obfs2/obfs3 pluggable transports accomplish.

The idea with the transport combining is that you don't need to
implement CRYPTO yourself, since you will be able to use obfs2 to do:
RHE(obfs2(HAMMERTIME(Tor)))


> 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...
>

Hm, what problem are you encountering?

It wouldn't surprise me if the obfsproxy API is suboptimal or broken
in some ways. If you find a problem, please let me know.

> 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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev