cmixx.md

The xx network cMix Design Specification

Benjamin Wenger
Richard T. Carback III
David Stainton

version 0

Abstract

This document describes the xx network cMix design variations and implementation parameterizations; that is, our mixing strategy which is at the core design of our anonymous communication network.

Introduction

cMix is a verified batch mixing strategy which uses the cryptographic and partial homomorphic properties of the ElGamal encryption protocol, which is described at length in the published cMix paper. However this document will very likely be a much more approachable description of the core designs of the cMix mixing strategy.

One of the main motivations behind the cMix design is the computational efficiency of the real time mixing phase of the protocol which does not perform any public key operations. The real time phase is essentially a series of modular multiplications within a prime order cyclic group. This is made possible by the precomputation phase.

Ciphersuite

For our cMix implementation we are using the RFC 3526 specified 4096 bit Mod P cyclic group for our ElGamal/cMix encryption and homomorphic operations:

This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] + 240904 }

   Its hexadecimal value is:

      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
      C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
      83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
      670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
      E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
      DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
      15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
      ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
      ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
      F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
      BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
      43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
      88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
      2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
      287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
      1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
      93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
      FFFFFFFF FFFFFFFF

   The generator is: 2.

https://datatracker.ietf.org/doc/html/rfc3526#section-5

Message Structure

Due to the nature of how ElGamal encryption works, the cMix payload in the paper is the same size as the encryption keys. In the case of the xx network we use two payloads (defined below as payloadA and payloadB), each are 4096 bits in size as our keys are 4096 bits.

                            Message Structure (not to scale)
+----------------------------------------------------------------------------------------------------+
|                                               Message                                              |
|                                          2*primeSize bits                                          |
+------------------------------------------+---------------------------------------------------------+
|                 payloadA                 |                         payloadB                        |
|              primeSize bits              |                     primeSize bits                      |
+---------+----------+---------------------+---------+-------+-----------+--------------+------------+
| grpBitA |  keyFP   |version| Contents1   | grpBitB |  MAC  | Contents2 | ephemeralRID |    SIH     |
|  1 bit  | 255 bits |1 byte |  *below*    |  1 bit  | 255 b |  *below*  |   64 bits    |  200 bits  |
+ --------+----------+---------------------+---------+-------+-----------+--------------+------------+
|                              Raw Contents                              |
|                    2*primeSize - recipientID bits                      |
+------------------------------------------------------------------------+

* size: size in bits of the data which is stored
* Contents1 size = primeSize - grpBitASize - KeyFPLen - sizeSize - 1
* Contents2 size = primeSize - grpBitBSize - MacLen - RecipientIDLen - timestampSize
* the size of the data in the two contents fields is stored within the "size" field

/////Adherence to the group/////////////////////////////////////////////////////
The first bits of keyFingerprint and MAC are enforced to be 0, thus ensuring
PayloadA and PayloadB are within the group

Contents1 and Contents2 are used to transmit the mix network client's payload whereas the other sections of the message have various other uses. Our source code represents this with a Message type in Go:

// Message structure stores all the data serially. Subsequent fields point to
// subsections of the serialised data.
type Message struct {
	data []byte

	// Note: These are mapped to locations in the data object
	payloadA []byte
	payloadB []byte

	keyFP        []byte
	version      []byte
	contents1    []byte
	mac          []byte
	contents2    []byte
	ephemeralRID []byte // Ephemeral reception ID
	sih          []byte // Service Identification Hash

	rawContents []byte
}

One byte is used to indicate the message format version because it's conceivable we could upgrade the message format in the future. The grpBitA and grpBitB bits are carefully set to avoid 0 vs 1 biasing which would allow for a probabalistic tagging attack:

SetGroupBits takes a message and a cyclic group and randomly sets
the highest order bit in its 2 sub payloads, defaulting to 0 if 1
would put the sub-payload outside of the cyclic group.

WARNING: the behavior above results in 0 vs 1 biasing. in general, groups
used have many (100+) leading 1s, which as a result would cause
a bias of ~ 1:(1-2^-numLeadingBits). with a high number of leading bits,
this is a non issue, but if a prime is chosen with few or no leading bits,
this will cease to solve the tagging attack it is meant to fix

Tagging attack: if the dumb solution of leaving the first bits as 0 is
chosen, it is possible for an attacker to 75% of the time (when one or
both leading bits flip to 1) identity a message they made multiplied
garbage into for a tagging attack. This fix makes the leading its
random in order to thwart that attack

Protocol Phases

Pseudo Code Cryptographic Function Glossary

The following sections are populated with pseudo code examples which are used to explain sections of our cryptographic protocols. It is hoped that this glossary will help you understand the pseudo code.

• |: byte concatenation

• H(x): H is a cryptographic hash function.

• HMAC(key, data): HMAC uses the given key to compute an HMAC over the given data.

• DH(my_private_key, partner_public_key):
  Diffiehellman function used to calculate a shared secret.

• GenerateDHKeypair(): returns a DH keypair

• E(key, payload): Stream-cipher encrypt payload.

• D(key, payload): Stream-cipher decrypt payload.

• Sign(private_key, payload): Returns a cryptographic signature.

• Verify(public_key, data, signature): Returns a boolean which will be true if the signature is a signature of data and is valid for the given public key.

Requisite Mathematical Considerations

You should be familiar with how the diffiehellman shared secret computation works. If not we recommend reading the Diffie–Hellmen wikipedia article.

Remember the transformations of exponents:

g^a * g^b = g^(a + b)

And also remember that just like addition and multiplication, exponentiation is also commutative:

g^a^b = g^b^a = g^(a*b)

And likewise we must remember multiplying the inverse of a term is equivalent to division by that term: