commit 685c0f689d75d83ce4defbc8c361d3ac2612f532 Author: Philipp Winter phw@torproject.org Date: Sun Mar 9 00:14:59 2014 +0100
Elaborate on protocol polymorphism.
While the general idea is explained, there are no exact details. Implementations may use different (CS)PRNGs to derive probability distributions. Such "flow diversity" might even be beneficial.
Conflicts: doc/scramblesuit/scramblesuit-spec.txt --- doc/scramblesuit/scramblesuit-spec.txt | 57 +++++++++++++++++++++++++++++--- 1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/doc/scramblesuit/scramblesuit-spec.txt b/doc/scramblesuit/scramblesuit-spec.txt index f928845..ee925fa 100644 --- a/doc/scramblesuit/scramblesuit-spec.txt +++ b/doc/scramblesuit/scramblesuit-spec.txt @@ -234,10 +234,59 @@ probability distributions from which random samples are drawn. These random samples dictate specific inter-arrival times and packet lengths. Both probability distributions are generated based on a random 256-bit PRNG - seed which is different for every ScrambleSuit server. Servers communicate - their seed to clients in a protocol message whose FLAG_PRNG_SEED bit is set - to "1". The client then extracts the PRNG seed and derives the same - probability distributions as the server. + seed which is unique for every ScrambleSuit server. Servers communicate + their seed to clients in a dedicated protocol message whose FLAG_PRNG_SEED + bit is set. The client then extracts the PRNG seed and derives its own + probability distributions. + +4.1 Deriving Probability Distributions + + Probability distributions SHOULD be derived from the 256-bit seed using a + cryptographically secure PRNG. After the CSPRNG was seeded, the amount of + bins for the respective probability distribution must be determined. + Depending on the CSPRNG's output, the amount SHOULD be uniformly chosen + from {1..100}. The exact way how the CSPRNG's output is used is up to the + implementation. + + After the amount of bins has been determined, every bin is assigned a value + together with a corresponding probability which is in the interval ]0, 1]. + The probability of all bins sums up to 1. Again, the exact way how the + CSPRNG's output is used is up to the implementation. + + For the packet length distribution, all values SHOULD be in {21..1448}. + + For the inter-arrival time distribution, all values SHOULD be in the + interval [0, 0.01]. + + Since the distributions are generated randomly, it is possible that they + cause particularly bad throughput. To prevent this, implementations MAY + trade off obfuscation for additional throughput by carefully tuning the + above parameters. + +4.2 Packet Length Obfuscation + + In general, ScrambleSuit transmits MTU-sized segments as long as there is + enough data in the send buffer. Packet length obfuscation only kicks in + once the send buffer is almost processed and a segment smaller than the MTU + would have to be sent. + + Instead of simply flushing the send buffer, a random sample from the + discrete packet length probability distribution is drawn. Padding messages + are then appended so that the size of the last segment in the burst equals + the freshly drawn sample. + +4.3 Inter-arrival Time Obfuscation + + To obfuscate inter-arrival times, implementations could maintain a + dedicated send buffer. As long as there is data in the send buffer, random + samples from the inter-arrival time distribution are drawn. The thread + processing the send buffer is then paused for the duration of the freshly + drawn sample until the next MTU-sized chunk is written to the wire. This + process is repeated until the send buffer is empty. + + Note that inter-arrival time obfuscation has a drastic impact on + throughput. As a result, implementations MAY implement packet length + obfuscation but ignore inter-arrival time obfuscation.
5. Session Tickets