David Stainton <[email protected]> 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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
