DESIGN

Dissent consists of several relatively independent components,
corresponding to subdirectories in the 'src' directory:

- Transports -- network communication layers such as Tcp, Ssl, Udp
- Connections -- represents an established link using a transport and gives an
  addressing scheme independent of the underlying transport
- Overlay -- organizes and specifies which nodes should connect with other
  nodes
- Crypto -- provides wrappers around external crypto libraries as well as
  extensions to many useful cryptographic techniques
- Identity -- an extension from the addressing of Connections to provide a more
  robust identity also supports various forms of authenication of this identity
- Tunnel -- provides a Socks5 compliant client and server stubs
- Anonymity -- anonymous group communication protocols
- Session -- establishes the set of participants for communicating in ensuing rounds

==============================================================================
Roadmap

I.    Overview
II.   Overlay protocol
III.  Round bootstrapping -- Server Setup
IV.   Round bootstrapping -- Client Setup
V.    Anonymity protocols
VI.   Technical notes
VII.  Terms
VIII. Dissent configuration

==============================================================================
I.    Overview
==============================================================================

The following protocol provides the run-time group formation for running a
Dissent round. It assumes that one or more administrators have formed a group
configuration containing a list of public keys, one for each member in the
group and one for each server within the group, or a certificate authority
certificate with all members in possession of a CA-signed certificate.  Under
anytrust assumptions, the protocol ensures that each server and client have
third-party verifiable authenticated with the group and produces a unique
RoundId that prevents replay attacks, cross-round attacks, and sybil attacks.
The protocol is broken down into 3 parts: the overlay protocol, server setup,
and client setup.

The overlay protocol defines the means by which clients and servers form
overlay level connections intended to verify that the two parties are
connecting with the right group.  There are no intended security properties.

The server setup begins with a pre-specified server, or a proposer, initiating
a round bootstrapping event embedded with causal information to prevent DoS
attacks.  Servers then verify each others identity and agree upon a one time
RoundId with each server contributing to its randomness.  Servers also exchange
information necessary for executing a protocol run including an ephemeral
signing key and other optional information. All this information will be unique
for each round assuming anytrust.

At any point, clients may queue for an upcoming round. Once servers have
completed the server setup, they allow clients to register.  During
registration, clients learn the anytrust RoundId as well as the server round
information. Clients submit their own round information including an ephemeral
public key and optional information for the round. At the conclusion of the
client registration phase, servers agree upon the set of registered clients.

If a malicious client or server sends an invalid message or one that it is not
expected to transmit, it is logged and ignored. Dissent leaves it as an
administrative duty to ensure that the system is operating correctly. A
misbehaving or malfunctioning server will appear in the logs as not having
submitted a message and may also have an error message if a invalid message
were sent. Resolution could be automated by introducing a system like Peer
Review, wherein if a server does not receive a message from another server in a
reasonable amount of times, he can ask the other servers to receive the
message. 

==============================================================================
II.   Overlay protocol
==============================================================================

Before beginning a Dissent round, a group configuration must be established, by
a set of server administrators, for example. A Dissent configuration consists
of a list of servers, mechanisms to connect to the servers (transport type
[TCP,SSL], transport address [IP:Port]), a set of public keys named by a
"Connection"-level address or PeerId (used for authentication), and the
protocol used for anonymous communication. As described in Section VIII, the
hash of this configuration will serve as a group identifier, so that
clients and servers may ensure they have the proper configuration.

To form an overlay, Servers, first, establish connections to every other
server, creating an all-to-all server topology.  Servers begin by first
establishing a transport-level connection followed by an overlay connection.
An overlay connection must be bidirectional and may be layered on top of one or
more transport layer.  The owner of the incoming connection, the inquirer,
transmits an Inquire message and the outgoing connection owner, the responder,
responds with an Inquired; these messages establish the overlay Id of each
peer. In addition, the Inquire message contains the responder's transport
address as viewed by the inquirer, for NAT traversal assistance.

I -> R Inquire (PeerId_I | TransportAddress_R | DissentVersion)

- PeerId_I - Connections:Id as QByteArray - Inbound overlay Id
- TransportAddress_R - Transports::Address as a QString - Responder Transport
  Address
- DissentVersion - int - Running version of Dissent, the receiver should close
  the connection if it does not match his own version

R -> I Inquired (PeerId_O)

- PeerId_R - Connection::Id as a QByteArray - Outbound overlay Id

PeerIds must be the hash of the peer's public key or must be the certificates
common name.

==============================================================================
III.  Round bootstrapping -- Server Setup
==============================================================================

Upon establishing connections or completing a round, Dissent begins
resynchronization. The first server listed in the configuration file, or the
proposer, has the unique role of proposing the start of a round via an Init
message to all servers.

A -> B Init ([PeerId_A | I Nonce | Timestamp | GroupId]_[Signature_A])

- PeerId_A - Connections::Id as QByteArray - A's overlay Id
- I Nonce - QByteArray - Nonce used to ensure uniqueness of Init messages
- Timestamp - 64-bit integer - Time since the "Epoch", ensure causality of
  Init messages
- GroupId - QByteArray - The hash of the group roster
- Signature_A - QByteArray - Signature on [PeerId_A | Init Message |
  EphemeralPublicKey_A | Optional_A], should use A's well known public key

This message will then be embedded in the servers next exchange to address
synchronization issues.  A server may determine if a message is past, current,
or if they have yet to receive an Init.  Historical messages should have an
earlier timestamp, current messages match the Init they have received from the
proposer, and yet to receive have future timestamps but have valid signatures.
The proposer may chose any timestamp he choses, such that an evaluation may be
made using integer comparisons, and that he maintains a consistent timestamp
across the lifetime of the group.

The Timestamp mitigates DoS attacks in which either a malicious server or
external entity might replay an old proposer Init message to confuse other
servers into enlisting in a round other than the latest.  However, the
Timestamp is not essential to ensuring the critical security invariant that
each round eventually acquires a fresh RoundId: even if a proposer maliciously
reuses an old I Nonce and/or Timestamp, the randomness in the Enlist messages
from other servers (below) guarantee RoundId freshness.

After receiving the Init messages, servers transmit to the proposer an Enlist
message.  Enlist messages authenticate servers and contain ephemeral keys used
for signing messages in the rounds and optional data for use in an upcoming
protocol round. The Init message received earlier is included as a nonce and
for synchronization.  

A -> B Enlist ([PeerId_A | Init Message | EphemeralPublicKey_A |
                Optional_A]_[Signature_A])

- PeerId_A - Connections::Id as QByteArray - A's overlay Id
- Init Message - QByteArray - Copy of the Init message sent to begin
  this process
- EphemeralPublicKey_A - QByteArray of DSA key - A's ephemeral key to be used
  in operations during protocol exchanges
- Optional_A - QVariant - Additional data necessary for the protocol round
- Signature_A - QByteArray - Signature on [PeerId_A | Init Message |
  EphemeralPublicKey_A | Optional_A], should use A's well known public key

Once the proposer has received an Enlist from all other servers, he transmits
the complete list to all other servers:

P -> S Enlisted ([List_of_Enlist] | [Signature_P])

- List_of_Enlist - QList of Enlist - The entire set of Enlist messages
- Signature_P - QByteArray - Signature on List_of_Enlist using P's well known
  public key.

Upon receiving Enlisted, all servers execute the round identifier generation
process. Currently, Servers currently employ the following process: RoundId =
Hash([Enlist]) ordered by the Id of the servers.  Thus the ephemeral key in the
Enlist message serves as a guarantee that under the anytrust model the RoundId
has some randomness. RoundIds do not need to be unbiased, only unique, thus an
adversary must find a proper Enlist message that would result in a hash
collision in order to perform a replay attack.

Upon conclusion of producing a RoundId, servers distribute an Agree message to
each other directly, which contains most of the fields of the Enlist message;
however, the Init Message will be replaced by the RoundId.

A -> B Agree ([PeerId_A | RoundId | Timestamp | EphemeralPublicKey_A |
               Optional_A]_[Signature_A])

- PeerId_A - Connections::Id as QByteArray - A's overlay Id
- RoundId - QByteArray - RoundId to be used in the upcoming protocol round
- Timestamp - 64-bit integer - Copied from the Init messages, so clients may
  distinguish causality of Queued messages
- EphemeralPublicKey_A - QByteArray of DSA key - A's ephemeral key to be used
  in operations during protocol exchanges
- Optional_A - QVariant - Additional data necessary for the protocol round
- Signature_A - QByteArray - Signature on [PeerId_A | RoundId | Timestamp |
  EphemeralPublicKey_A | Optional_A], should use A's well known public key

==============================================================================
IV.   Round bootstrapping -- Client Setup
==============================================================================

At the conclusion of this process, servers allow clients to register.  Prior to
registering, clients must connect to at least one server using the same process
as servers connect to each other, Inquire and Inquired messages. First
establishing a transport-level connection, followed by an overlay-level
connection.  When the servers have completed the round identifier generation,
they notify each connected client via a Queued message containing the
accumulated Agree messages exchanged by the servers.  

S -> C Queued (AgreeMessages)

- AgreeMessages - All of the server Agree messages

Clients then respond with a Register message containing a third-party
verifiable authentication context, a signature using private key cryptography,
against the RoundId, an ephemeral key to be used during the protocol, and any
additional information necessary for the upcoming protocol. At this point,
clients should prepare their round to receive messages but not process them.

C -> S Register ([PeerId_C | RoundId | EphemeralPublicKey_C |
                  Optional_C]_[Signature_C])

- PeerId_C - Connections::Id as QByteArray - Sender's overlay Id
- RoundId_C - QByteArray - A identifier to use in the upcoming protocol round
- EphemeralPublicKey_C - QByteArray of DSA key - The ephemeral key to
  be used in operations during protocol exchanges
- Optional_C - QVariant - Additional data necessary for the protocol round
- Signature_C - QByteArray - A public key signature using C's well-known public
  key against PeerId_C, RoundId_C, EphemeralPublicKey_C, and Optional_C.

Upon beginning the registration process, each server accepts registration
messages up to the well-defined time allotted for the registration period.
After this registration window, each server transmits their list of client
registration messages to every other server, using the List message.

A -> B List ([ListOfRegister_A]_[Signature_A])

List - [ListOfRegister_A]_[Signature_A]
- ListOfRegister_A - int | [ClientRegister] - List of all the Register
  messages received
- Signature_A - QByteArray - Signature on QByteArray format of the List of
  Register

Upon receiving the List from all servers, a server computes the union of all
ListOfRegisters, eliminates duplicates by favoring the server ordered earlier
in the configuration file and then hashes the resulting list.  Servers then
sign the resulting list and share among each other their signatures via the
VerifyList.  Clients authenticating with multiple servers and using different
entries for each server are removed.  Since this process is deterministic,
servers need not share the list. Prior to sending the VerifyList, servers
should prepare to receive protocol round messages.

A -> B VerifyList (Signature_A(CompleteListOfRegister))

VerifyList - Signature on Complete List of Register
- Signature_A - QByteArray - Signature on the hashed Complete List of Register

Upon receiving all signatures, servers should begin the round and
simultaneously transmit a Start message to clients initiating the beginning of
the protocol round.  A client registering with multiple servers remains
connected to the server with the lowest Id specified in the configuration.

S -> C Start (CompleteListOfRegister | VerifyListSignatures)

Start - Complete List of Register | VerifyListSignatures
- CompleteListOfRegister - int | [ClientRegister] - List of all the
  Register messages
- VerifyListSignatures - QVariantList - Set of server signatures for the
  complete list of Register messages

A protocol round constitutes one or more anonymous exchanges.  The protocol
round continues for at least 1 exchange or the maximum round duration,
whichever is longer. At which point, each server broadcasts a Stop message with
the reason "Protocol run complete" and immediate set to false.  At any point,
if a server disconnects from any other server, that server immediately
broadcasts a Stop message with reason "Server disconnected x from y" and
immediate set to true.  Because of potential disconnections, the proposer also
redistributes a Stop message upon receiving.

S -> C Stop ([RoundId, Immediate, Reason]_[Signature_A])

Stop - [RoundId | Immediate | Reason]_[Signature_A]
- RoundId - QByteArray - The round identifier
- Immediate - bool - Should stop now or after the current exchange has
  completed
- Reason - QString - The reason for stopping
- Signature_A - The well known public key of the sender of this message

Upon receiving a stop message, the round terminates immediately if immediate is
set to true or upon conclusion of the current round if not. At which point, the
entire process repeats from the first server transmitting an Init message and
clients' Queue. It is assumed that all messages are received in the order they
are sent, and that a Stop message will arrive before either an ensuing Init or
Queued message will arrive.

==============================================================================
V.    Anonymity protocols
==============================================================================
A.    Neff Shuffle
==============================================================================
Neff Shuffle performs a El Gamal style mix net, in which each participant has
one communication slot and the transactions between each servers may be
verified for correctness. Neff Shuffle operates in two modes: an efficient key
shuffle and a less efficient arbitrary data mode. The only difference being the
key parameters used by the shuffle. The protocol executes among a set of
clients, who want to transmit some data, and a set of servers who perform the
shuffle.

1) Servers prepare an ephemeral key and distribute that to all other servers.
To prepare a key, servers use a random number generator seeded by the RoundId
to deterministically produce a group-wide private key whose parameters define
the parameters for these keys. The ephemeral keys are shared as follows:

A -> B ([SERVER_KEY | RoundId | EphemeralPublicKey_A]_[Signature_A])
- SERVER_KEY - int - the message type
- RoundId - QByteArray - The round identifier
- EphemeralPublicKey_A - QByteArray of DSA key - A's ephemeral key to be used
  in operations during protocol exchanges
- Signature_A - Signature using the round key of the sender for this message

2) After the servers have accumulated all the server keys, they insert them
into a list as defined by the server roster order. The servers then sign this
list with their round signing key. They then distribute this signature among
each other:

A -> B ([KEY_SIGN | RoundId | KeySignature_A] | [Signature_A])
- KEY_SIGN - int - the message type
- RoundId - QByteArray - The round identifier
- KeySignature_A - A signature against the keys
- Signature_A - Signature using the round key of the sender for this message

3) After the servers have accumulated all the server signatures, they produce a
second ordered list consisting of the signatures ordering the list in the same
order as the server roster. The list is then sent to each servers downstream
clients:

S -> C ([SERVER_KEYS | RoundId | Keys | KeySignatures] | [Signature_S])
- SERVER_KEYS - int - the message type
- RoundId - QByteArray - The round identifier
- Keys - The set of server keys
- KeySignatures - The set of signatures against the keys
- Signature_S - Signature using the round key of the sender for this message

4) After the clients have obtained the keys, they verify their correctness and
signatures. They then prepare either their data, either an ephemeral public key
that will be used to produce a pseudonym key or converting their arbitrary data
into a group element. The clients then onion encrypt this message using the
last key in the list followed by the next to last all the way to the first key.
They then transmit this to the first server in the list as their anonymous
ciphertext message:

C -> S ([MSG_SUBMIT | RoundId | Ciphertext_C] | [Signature_C])
- MSG_SUBMIT - int - the message type
- RoundId - QByteArray - The round identifier
- Ciphertext_C - Clients anonymous ciphertext
- Signature_C - Signature using the round key of the sender for this message

5) Each server in turn, removes a layer of encryption using their
EphemeralPublicKey_A, sorts the resulting ciphertext by lexicongraphical order,
produces a proof of correctness, and broadcasts this to all other servers.  The
first server includes the initial input by clients. The message follows:

A -> B ([MSG_SHUFFLE | RoundId | [Initial_Ciphertext] | Transcript_A] |
        [Signature_A])
- MSG_SHUFFLE - int - the message type
- RoundId - QByteArray - The round identifier
- Initial_Ciphertext - QByteArray - Server0 (the proposer) inserts the set of
  initial ciphertexts as part of this message, other servers have no value here
- Transcript_A - QByteArray - The shuffle output and proof of correctness
- Signature_A - Signature using the round key of the sender for this message

6) As shuffle results arrive at each server, they verify that the output from a
previous server and the output from the following server verify using the proof
of correctness or transcript. This is done starting from the first server to
the last.  If any validation fails transcript producer has failed to perform
the protocol correctly. If all pass, then servers sign-off on the resulting
anonymous cleartext messages, produced as output from the final server
and distribute among each other these signatures:

A -> B ([MSG_SIGN | RoundId | MsgSignature_A] | [Signature_A])
- MSG_SHUFFLE - int - the message type
- RoundId - QByteArray - The round identifier
- MsgSignature_A - QByteArray - Signature against the final output of the
shuffle, the anonymous cleartext messages
- Signature_A - Signature using the round key of the sender for this message

7) After the servers have accumulated all the server signatures, they prepare
the final message for the clients, a set of all cleartext messages and a
signature from each server verifying the results:

S -> C ([MSG_OUTPUT | RoundId | Cleartext | MsgSignatures] | [Signature_S])
- MSG_OUTPUT - int - the message type
- RoundId - QByteArray - The round identifier
- Cleartext - QByteArray - The set of anonymous cleartext messages
- MsgSignatures - QByteArray - Set of server signatures against the cleartext
messages validating correctness of the shuffle
- Signature_S - Signature using the round key of the sender for this message

=============
Known issues
=============
- This protocol lacks reconcillation, if a server is faulty, there is no
built-in means to correct, it will just halt the protocol
- Clients should transmit their initial ciphertext to all servers, all
servers should ensure that all clients ciphertext are included in the input
to the shuffle

==============================================================================
B.    Client/Server DC-net
==============================================================================
The Client/Server DC-net allows for multiple DC-net message exchanges. In each
exchange, each client and server contributes a ciphertext message that when
combined together reveal that exchange's anonymous cleartext messages.  In this
protocol, clients produce their anonymous ciphertext, transmit it to the
servers, who perform the distribution and work necessary to ensure correctness,
before revealing the anonymous cleartext to clients, which concludes a signle
exchange. The protocol follows.

==============
Base Protocol
==============
0) Clients and servers obtain shared secrets by using registration information.
Optional information introduced during the session bootstrap should include a
Diffie Hellman public key. Prior to performing any DC-net exchanges, they also
perform a bootstrapping phase used to establish pseudonym keys and prepare for
accountability. This takes place as a Neff Shuffle either standalone or as a
component in the setup for a Verifiable DC-net. In either case, the
Client/Server DC-net obtains an ordered list of pseudonym verification keys.

1) Clients produce their ciphertext and transmit that to their upstream server
C -> S ([CLIENT_CIPHERTEXT | RoundId | ExchangeNum | Ciphertext_C] |
  [Signature_C])
- CLIENT_CIPHERTEXT - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- Ciphertext_C - QByteArray - The clients DC-net ciphertext
- Signature_C - Signature using the round key of the sender for this message

2) Servers wait for client ciphertexts and then after a cut-off accept no
further ciphertexts. Each server transmits to the other servers the set of
clients that have transmitted ciphertexts to them:
A -> B ([SERVER_CLIENT_LIST | RoundId | ExchangeNum | HandledClients_A] |
  [Signature_A])
- SERVER_CLIENT_LIST - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- HandledClients_A - QBitArray - a bit array of all possible clients, a server
  sets the bit to 1 if he has a ciphertext for that client
- Signature_A - Signature using the round key of the sender for this message

3) Once a server knows the entire online set of clients, he produces a
matching ciphertext, XORs the client ciphertexts he has locally along with
his ciphertext, and commits to this value via a commit message to the other
servers:
A -> B ([SERVER_COMMIT | RoundId | ExchangeNum | Commit_A] | [Signature_A])
- SERVER_COMMIT - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- Commit_A - QByteArray - A hash of the XORed ciphertext messages
- Signature_A - Signature using the round key of the sender for this message

4) After receiving the commit message from all other servers, the server
distributes the XORed message to all other servers:
A -> B ([SERVER_CIPHERTEXT | RoundId | ExchangeNum | Ciphertext_A] |
  [Signature_A])
- SERVER_CIPHERTEXT - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- Ciphertext_A - QByteArray - The XORed ciphertext messages
- Signature_A - Signature using the round key of the sender for this message

5) Each server verifies the hash matches the received ciphertext, a mismatch
equals an equivocation. If all match, the server XORs all ciphertexts to
produce the anonymous cleartext message, produces a signature against that
message, and transmit it to all other servers:
A -> B ([SERVER_VALIDATION | RoundId | ExchangeNum | MsgSignature_A] |
  [Signature_A])
- SERVER_VALIDATION - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- MsgSignature_A - QByteArray - A's signature against the set of anonymous
  cleartext messages
- Signature_A - Signature using the round key of the sender for this message

6) After each server has received a signature from all other servers, that
server will distribute the anonymous cleartext and set of server signatures to
its downstream clients, concluding a message exchange:
S -> C ([SERVER_CLEARTEXT | RoundId | ExchangeNum | MsgSignatures | Cleartext] |
  [Signature_A])
- SERVER_CLEARTEXT - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- MsgSignatures - QByteArray - Server signatures against cleartext
- Cleartext - QByteArray - Anonymous cleartext
- Signature_S - Signature using the round key of the sender for this message

At this point, all participants have seen the cleartext output for each slot,
the format ensues. In each slot, there are bits for signaling the need for an
accusation phase, documented afterward.

======================
DC-net message format
======================
The subformat for the DC-net cleartext messages or slots follows:
([Accusation_A | ExchangeNum | NextLength_A | Message_A] | [Integrity_A])
- Accusation_A - byte - I was interrupted in a previous exchange and want to
  execute a blame round
- ExchangeNum - int - The index for the current exchange
- NextLength_A - int - the length of this slot for the next exchange
- Message_A - byte array - the message to transmit - 0 if Accusation_A is set
- Integrity_A - byte array - a signature using the pseudonym key produced
  earlier or a secure hash against the message

On the actual wire, messages take another form to prevent attacks against
static content. For example, in exchange_i, a malicious entity successfully
jams a slot without repercussion. If the slot replayed the contents until
success, he could continuously interrupt without fear of detection. Each slot
randomizes the contents to eliminate this attack vector:
[Seed_A | Data_A]
- Seed_A - QByteArray - a seed into a PRNG used to produce a string that may
be XORed into the cleartext DC-net message described above
- Data_A - QByteArray - the resulting XOR between the random string and the
cleartext DC-net message described above

============
Blame phase
============
0) During a blame phase all participants execute a verifiable anonymous
communication exchange, a Neff Shuffle or a Verifiable DC-net. During this
exchange, those who have requested a blame, may transmit an accusation:
([OwnerIndex | AccuseIndex | ExchangeNum] | [Signature_C])
- OwnerIndex - int - the index of the slot
- AccuseIndex - int - bit index into the slot that may be safely deanonymized
  to reveal the disruptor
- ExchangeNum - int - The index for the current exchange
- Signature_C - QByteArray - signature using the slot owner's pseudonym key

1) Servers then transmit blame bits among themselves. Blame bits consist of
all the client bits and their bit included in their ciphertext.
([SERVER_BLAME_BITS | RoundId | ExchangeNum | Bits] | [Signature_A])

2) After accumulating all the server blame bits, each server verifies that the
blame bits matches the ciphertext transmitted by the server earlier, if not,
they have proof of misbehavior. Otherwise each server processes the bits and
discovers which client bit does not match the combined ciphertext of the
servers. That client is now accused by a rebuttal request from each server:
S -> C ([SERVER_REBUTTAL_OR_VERDICT | RoundId | ExchangeNum | Rebuttal |
  ExchangeNum_accuse | AccuseIndex | ServerBits] | [Signature_S])
- SERVER_REBUTTAL_OR_VERDICT - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- Rebuttal - bool - false notifies that this is a rebuttal request
- ExchangeNum_accuse - int - the phase in which the incident occurred
- AccuseIndex - int - bit index into the slot that may be safely deanonymized
  to reveal the disruptor
- ServerBits - QBitArray - the shared secrets bit for each server at the
  AccuseIndex in ExchangeNum_accuse
- Signature_S - Signature using the round key of the sender for this message

3) After a client has received a Rebuttal request, an honest client processes
the ServerBits inorder to determine which server lied and attempted to
incriminate the client. The client then transmits a rebuttal response:
C -> S ([CLIENT_REBUTTAL | RoundId  | ExchangeNum | ServerIndex | Proof] |
  [Signature_C])
- CLIENT_REBUTTAL - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- ServerIndex - int - the index into the server list of the faulty server
- Proof - QByteArray - The Diffie Hellman shared secret between the client and
  faulty server and a proof of knowledge showing that it is correct
- Signature_C - Signature using the round key of the sender for this message

4) Once each server has seen a rebuttal from the clients, they agree on whether
the client or server misbehaved and announce, each server transmits a verdict
signature to all other servers:
A -> B ([SERVER_VERDICT_SIGNATURE | RoundId | ExchangeNum | Signature_V] |
  [Signature_A])
- SERVER_VERDICT_SIGNATURE - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- Signature_V - QByteArray - Signature of A using his round key against
- Signature_A - Signature using the round key of the sender for this message

5) Upon accumulating a signature from all servers, the servers push the verdict
down to their downstream clients:
S -> C ([SERVER_REBUTTAL_OR_VERDICT | RoundId | ExchangeNum | Verdict |
  ExchangeNum_accuse | BadIndex | Signatures_verdict] | [Signature_S])
- SERVER_REBUTTAL_OR_VERDICT - int - the message type
- RoundId - QByteArray - The round identifier
- ExchangeNum - int - The index for the current exchange
- Verdict - bool - true notifies that this is a rebuttal request
- ExchangeNum_accuse - int - the phase in which the incident occurred
- BadIndex - int - the index into the complete group roster (servers followed
  by clients) of the faulty party
- Signatures_verdict - List of QByteArrays - A signature from each server
  attesting to the verdict
- Signature_S - Signature using the round key of the sender for this message

After transmitting or receiving a server verdict, servers and clients,
respectively terminate the current round.

=============
Known issues
=============
- If a server is faulty, it may not want to sign off on it misbehaving
- If a client is faulty, it may not respond to a rebuttal request

==============================================================================
C.    Verifiable DC-nets
==============================================================================

TODO

==============================================================================
VI.   Technical notes
==============================================================================

- Dissent does not directly provide peer-level authentication, that is left to
  the transport.  If peers perform authentication, the identity should be
  matched against what is provided at the overlay level.
- Start may optionally contain group-wide information, if the Anonymity protocol
  requires it. In particular, this might be the Accumulated List of Queued and
  matching signatures from the Listed messages.
- If server has received a Stop message before stopping, it does not need to
  broadcast a Stop message.
- Dissent assumes that messages between two parties are delivered in order.
- The Timestamp in the Init message prevents an adversary from partitioning the
  online server set when the proposer is actively attempting to Init a new
  round
- If a Timestamp has been replayed, the proposer is offline, and there exists
  at least one honest online server, then the round will terminate at the
  RoundId message exchange because there would be no proper proposer
  signature on the RoundId
- If the proposer is the only honest server and a Timestamp has been replayed,
  servers would only be able to replay previous state up until the Start
  message. Honest clients will detect at this point that their registration
  information is either absent, incorrect, or improperly signed.

==============================================================================
VII.  Terms
==============================================================================

Group - a well-defined set of entities that may participate in one or more
  anonymous communication rounds

Round - an instance of a protocol execution, where some subset of the entities
  participate in anonymous communication

Exchange - some rounds support multiple transmissions from participants,
  each transmission and resulting cleartext constitutes an exchange

Dissent Version - 4

Hash function - SHA256

Encryption function - ...

Registration period - 5 minutes

Round duration - 60 minutes

==============================================================================
VIII. Group Configuration
==============================================================================

The Dissent configuration file uses an Ini formatted file. The file specifies
both group and run-time configuration flags for Dissent. The GroupId derives
only from the following fields in the specified order: server_ids and
round_type.