Protocol
========

    payload
    
    -> 

    n | padding | m | payload

* n (word32be): the number of bytes of padding
* padding: n bytes of noise
* m (word32be): the number of bytes of the original payload
* payload: the original packet

Implementation
==============

* `n` is deduced from a randomly generated `i = n + m` for each packet.
* When a random `i` is less then `m`, payload is split to `p1` and `p2` to satisfy the constrain, where the length of `p1` is equal to `i` and `p1 + p2 = payload`. `p2` will be sent in the next iteration by the same algorithm.
* `i` is bounded by a maximum `r`, configurable by the `--randomnessInBytes` argument.
* To reduce overhead, `n` is set to `0` whenever `m` is greater then `r`.

Usage
=====
* local:

        neko-obfs --localHost TEXT --localPort INTEGER --remoteHost TEXT --remotePort INTEGER
* remote: 

        neko-obfs --role remote --remoteHost TEXT --remotePort INTEGER --forwardHost TEXT --forwardPort INTEGER
* This tunnel should be used inside an encrypted tunnel.
* For example:

        ss-local (rc4)

          -> neko-obfs -> ss-tunnel (aes-256-cfb)

            -> gfw -> internet

          -> ss-tunnel (aes-256-cfb) -> neko-obfs 

        -> ss-server (rc4)
* Note it's the `ss-tunnel` layer that protects the obfuscation, otherwise
  data and noise length are clearly visible.

Performance
===========

* No noticeable slow down yet (Jul 24, 2017)