The misplaced comma causes a misleading TypeError whereas we actually want to
raise a PluggableTransportError.

This fixes <https://bugs.torproject.org/11269>.

At this point, it is difficult for bridge operators to learn the password if
they did not specify it explicitly.  To make that easier, we always dump the
server descriptor to a file.  As a result, bridge operators could simply look
at that file to get a copy & pastable server descriptor.

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

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.

Conflicts:
	unittests.py

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.

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.

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.

python-coverage(1) says that the code achieves 98% coverage:

> Name    Stmts   Miss Branch BrPart  Cover   Missing
> ---------------------------------------------------
> state      71      0     10      2    98%

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>

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>.

The attribute "creationTime" does not exist.  Instead, update the correct
attribute "keyCreation".  This bug broke the server's key rotation.  The patch,
written by Yawning Angel, fixes <https://bugs.torproject.org/11100>.

That should make it clear that the variable is not used without condition.

A dedicated password file is not necessary as the server already has a
persistent state file.

Generally, we require a password (the UniformDH shared secret) which is set by
the bridge operator using "ServerTransportOptions" in Tor's torrc.  Since some
bridge operators won't bother taking care of that, we want a fallback mechanism
which silently generates and publishes a password if ServerTransportOptions is
not used.  We (ab)use obfsproxy's get_public_server_options() which is meant to
sanitise parameters.  We, however, use it to add the password parameter if it's
not there.

The more Pythonic way to do this is a, b = b, a.