Conflicts:
	obfsproxy/transports/scramblesuit/scramblesuit.py

Because of technical problems (see #10887:comment:11) it was not so easy
to write the actual Bridge line that people were supposed to use. Let's
just write the password for now.

Conflicts:
	obfsproxy/transports/scramblesuit/const.py
	obfsproxy/transports/scramblesuit/state.py

Conflicts:
	obfsproxy/transports/scramblesuit/scramblesuit.py

Conflicts:
	obfsproxy/test/transports/test_scramblesuit.py

This argument permits to run obfsproxy in unmanaged mode and
pass a file containing the scramblesuit password. That way
password won't be visible in process list.

We only want to run the packet morphing algorithm when we really need
it -- which is immediately before we send data.  Previously, we would morph
immediately upon receiving data which is not optimal.

This should fix <https://bugs.torproject.org/10991>.  Thanks to Yawning Angel
who pointed out the problem.

Thanks to Yawning Angel for catching this.

To a user, it's not immediately clear that a given password was not well
formed.  The refactored error messages should fix that.  See bug
<https://bugs.torproject.org/11143> for context.

Conflicts:
	ChangeLog

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

The first message makes use of the HMAC key which is derived from the master
key.  It does not use the master key itself.

On occasion, a client's or a server's epoch might already have increased
whereas the epoch of the other party didn't.  This is a benign event and there
is no reason to fail authentication because of this.  As a result, as a server,
we now also test boundary values, i.e., epoch - 1, epoch, epoch + 1.

That's only relevant for UniformDH.

There's no need for the server to determine its own epoch.

Since we no longer process data after authentication has failed, we might as
well increase the closing threshold.  The larger interval hopefully makes
ScrambleSuit bridges less fingerprintable for active adversaries.

If the client did not authenticate after MAX_HANDSHAKE_LENGTH bytes,
authentication has failed.  For obfuscation, we keep the connection open a
while longer but we stop processing all data from that point on to prevent
denial-of-service attacks.  (Partial) patch by Yawning Angel.
For previous discussion, see: <https://bugs.torproject.org/11092>.

We know in which array slice the mark is expected.  As a result, we don't have
to look any further than that.  Patch by Yawning Angel.  See the following
ticket for reference: <https://bugs.torproject.org/11092>.

1. Fix a typo by changing "X" to "Y".
2. Add "M_C" and "M_S" to the respective MAC function as they are also
   authenticated.

The problem was pointed out by Yawning Angel in:
<https://bugs.torproject.org/10893>

The problem was pointed out by Yawning Angel in:
<https://bugs.torproject.org/10893#comment:3>

Conflicts:
	ChangeLog

Adapt the server's behaviour to the spec change of commit 892846eb.  When a
server bootstraps for the first time, it randomly generates a byte threshold
after which unauthenticated connections are closed.

This should fix <https://bugs.torproject.org/11092>.

In particular, discuss strategies which servers should implement if clients
cannot authenticate.  Otherwise, malicious clients could run computation-based
or memory-based denial-of-service attacks.  This problem was reported by
Yawning Angel.

This should fix <https://bugs.torproject.org/11092>.

instead of printing it for every new connection