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@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.
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@gmail.com 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@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.
David Stainton dstainton415@gmail.com 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
-
David Stainton -
George Kadianakis