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