Channel Initialization Message

When the Mix Chain is set up, every Mix is given an asymmetric key pair. These can be used to encrypt messages, that only that Mix can read. Using this functionality a client wanting to use the Mix Chain and distribute information to them can encrypt this information in layers, depending on which Mix the information is meant for.

How its used

The information for the last Mix has to be asymmetrically encrypted first using its public key, since it will be decrypted last. The resulting cipher text can be appended to further information for the second to last mix, which will then also be asymmetrically encrypted using its public key. This goes on until information for every Mix was encrypted by that Mixes public key.

The resulting cipher text will then be decrypted in correct order by the Mixes, revealing the information that is meant for them and the cipher text for the following Mix which is forwarded along the chain, with each Mix picking out the information and data, that is needed to configure the channel.

Symmetric Keys

The most important information in the channel initialization message are the symmetric keys the Mixes are supposed to use to decrypt requests sent from the client and encrypt responses from the destination, if any. Symmetric keys are used, because asymmetric encryption is more costly computation wise and with potentially high amounts of UDP traffic, it is more performant to use symmetric encryption instead. Establishing new keys for every channel, meaning every connection between two IP:Port pairs decreases the value a key has over time, since its life time is naturally limited.

Counter Prefixes

Since anonymity is based on the messages being sent between the Mixes not being linkable, it is important that even identical plain text messages sent over the same channel look differently. Since the messages are symmetrically encrypted it follows that this is being accomplished using a Block Cipher Mode of Operation, based on that symmetric encryption.

The block cipher mode, that was being chosen is the Counter Mode. This mode uses a counter object in addition to the symmetric key to encrypt plain text blocks. For every block (i. e. 16 Bytes of data) the counter object gets incremented by one, leading to blocks of cipher text dependent on the plain text, which can repeat inside a message and across messages, the symmetric key, which gets used for all messages in a channel and the counter object, which, by incrementing every time, is unique every time.

The nature of UDP, which does not ensure delivery in order or even delivery at all, means that the counter values, which get used by the client for encryption and by the Mix for decryption can get out of sync, resulting in garbled plain text for one or even all following messages. Because of that the counter encryption is limited to the message itself and is restarted with a new counter object for every new message received. This new counter object is created using a pre-shared counter prefix, which makes up the first 8 Bytes of the counter object and an 8 Byte value starting at 1 counting up. That means, that every message must also contain the counter prefix value it was encrypted with. These are sent along in plain view, prepended to the encrypted message for the Mixes to use in decrypting it.

For a Mix to be able to not only decrypt given cipher texts with given counter values, but also to encrypt responses meant for the Client, it also must have a counter prefix object, with which to count up for all the messages it encrypted over time. For this reason a counter prefix object is also sent using the channel initialization message. Whenever a response reaches the Mix, the counter prefix gets incremented by one and used to generate a counter object, which in turn is used to encrypt the given response. This counter object is prepended to the cipher text, just like that client would do it, and sent further along the Mix chain.

Since the counter prefix objects are sent with the message, in theory they would not have to be pre-shared and stored at all, since all the information to decrypt a message (except for the key) is in the message itself, but by prearranging the start of the counter prefix the Mix gains an idea on what range of values to expect and, more importantly, can log which counter prefix values it has already seen, knowing, that they will never appear more than once. This gives the mix the ability to detect replay attacks, since the counter prefix prepended to that message will already have been processed once.

Since the messages are sent using UDP and can get lost or arrive out of order it is not enough to remember the last seen counter prefix, rather a list of already received values has to be kept. That list will grow huge over time, therefore it is sensible to limit the length of this list to something manageable, with all values, lower than the smallest of that list being discarded automatically. Since UDP is often used in time critical applications such as VoIP, discarding very late messages should not negatively impact the quality of the services using the Mix chain. A usable definition of "very late" is up to the implementer and might be a candidate for another attribute configurable using the channel initialization message.

While the Mix does not need to know the starting counter prefix of the following mix to communicate with it, in order to also check its messages for a possible replay attack it needs to know the counter prefix start that Mix was given, which is why that counter prefix is also included in the channel initialization message. This information could be received from the first response message the Mix gets from this channel, but sharing that information explicitly is preferable.