[tor-dev] RFC: obfs4 (Name not final)

[Yawning Angel]

Hello,

The people that have been following Pluggable Transport development may
know that I have been working on something tentatively called "obfs4"
recently.  It's rapidly approaching the point where I would like to
open it up for review and feedback, hence the e-mail.

A quick and dirty description would be:

  obfs4 is ScrambleSuit with djb crypto.  Instead of obfs3 style
  UniformDH and CTR-AES256/HMAC-SHA256, obfs4 uses a combination of
  Curve25519, Elligator2, HMAC-SHA256, XSalsa20/Poly1305 and
  SipHash-2-4.

The feature set offered by obfs4 is comparable to ScrambleSuit with
the following differences (implementation specific changes are noted
as such):

 * The key exchange is based on the ntor handshake, and thus
   authenticates the server to the client.  Both obfs3 and ScrambleSuit
   depend on the encapsulated protocol to handle this on it's own.

 * obfs4 always does a full handshake.  ScrambleSuit style session
   ticket handshakes are not supported.  Even with Elligator2 mapping
   taken into account, the obfs4 handshake is significantly faster, so
   there is less of a need for this.

 * (Impl) obfs4proxy currently does not offer Inter-Arrival Time
   obfuscation, but this could easily be added if it is something that
   a lot of people want.  It is worth noting that while obfsproxy and
   obfsclient both support IAT obfuscation, support for it is currently
   disabled by default as a performance tradeoff.

 * (Impl) obfs4proxy is currently written in golang.  Neither a clear
   plus or minus, it does allow people to run bridges on reserved ports
   significantly easier, is probably faster (native code, can use
   multiple cores for most things), but is more annoying to build and
   results in rather large binaries (the go runtime is statically
   linked).

 * (Impl) obfs4 supports a lot of the protocol improvements made to
   ScrambleSuit that are pending merge (See #11271, #11203).  This
   difference is temporary. 

The code and a draft spec is at: https://github.com/Yawning/obfs4  

Open questions:

 * Is the base design and my implementation sane?

 * Should obfs4proxy also have (disabled) IAT obfuscation?  Adding it
   later will not require wire protocol changes.

 * The handshake length mimics ScrambleSuit in terms of maximum
   padding (< 1500 bytes).  Should this be increased to be similar to
   obfs3 (~8k of maximum padding)?  The server side cost for this
   shouldn't be that high.

 * Is this different enough from ScrambleSuit to be worth deploying?  I
   would be ok with this ending up as "just a research project" and
   shelving it if the consensus is otherwise.

 * Should I have named it ScrambleSuit 2?  It's a direct descendant of
   ScrambleSuit and is an obfs derivative only in name at this point.

Future plans:

 * Implement suggestions/improve the code/fix bugs/write more unit
   tests.

 * Improve goptlib.

 * If this is deployed in meaningful amounts, support it in obfsclient.

For the extremely brave, I am running a test bridge with the most
recent snapshot of the code:

  UseBridges 1
  ClientTransportPlugin obfs4 exec /path/to/obfs4proxy
  # Bridge line of doom, all one line.
  Bridge obfs4 178.209.52.110:52810
    67E72FF33D7D41BF11C569646A0A7B4B188340DF
    node-id=Z+cv8z19Qb8RxWlkagp7SxiDQN8=
    public-key=vm+w9k57aMIX/o+A9ef5C7o9xKEkhr7kRBj3N4etDn8=

  As with any PT that requires per-bridge arguments, this also requires
  tor-0.2.5.x.  The node-id in this case happens to be my bridge's
  fingerprint, the public key is the long term key used to validate my
  bridge's identity and generate M_[C,S]/MAC in the handshake (The
  bridge line is a bit of a UI/UX disaster unless people are
  copy/pasting it).  Getting either of them wrong will result in
  handshake failures and tor not bootstrapping.

A few warnings:

 * The spec assumes familiarity with ntor, ScrambleSuit and NaCl's
   crypto_secretbox.

 * The wire protocol is not final and I *will* push builds to the
   bridge as I break backward compatibility without notifying people
   (It's been 0 days since a wire protocol change.).  The test bridge
   will randomly be broken/rebooted/etc as I also use it for other
   things.

 * Development was done with go1.2.x, older versions of the runtime are
   not supported.

 * It would be a terrible idea to use obfs4proxy as anything other than
   a client at this point.

Questions, comments, feedback all appreciated.

-- 
Yawning Angel

PS: I also wrote https://github.com/yawning/or-applet recently.  It's
even less supported/tested than obfs4 is (it is written only for my
laptop), but some people may find it cute.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140521/2452069b/attachment.sig>