Yamn Packet Specification

Yamn (Yet Another Mix Network) is a very close relative to Mixmaster. The keyrings, stats and payload format are similar enough that the Echolot Pinger can be used with only minor modification to some Regular Expressions.

The following table presents a simple overview of the principle differences between Yamn and Mixmaster.

Function Mixmaster Yamn
Public Key Encryption RSA NaCl Box
Symmetric Encryption DES3 AES256 (CTR Mode)
Integrity Checking MD5 (Partial only) Blake2 (ed25519 with NaCl)
Pooling Algorithm Dynamic Mix Binomial Mix
Maximum Chain Length 20 10

Payload Format

The term payload describes the entire Yamn payload at it's highest level. The Headers content is described in greater detail in subsequent sections. During client-side message construction, all headers (excluding the first one) and the Body are wrapped in multiple layers of encryption. These layers are stripped, one-by-one at each hop until the plain content is exposed for delivery to the actual recipient.

Field Name Bytes Description
Headers 2560 10 x Headers (1 per hop)
Body 17920 User defined content
Total 20480

Header Format

Each of the 10 headers consists of 256 Bytes split into 4 fields. The first 3 fields contain instructions on how to decrypt the content of the 4th field, the Sealed Header.

Field Name Bytes Description
Recipient key ID 16 KeyID required to decrypt NaCl Sealed header
Sender Public key 32 Public key corresponding to SK used in NaCl Seal
Xsalsa20 Nonce 24 Nonce used during NaCl Seal
NaCl Sealed header 176 160 Bytes + NaCl Overhead
Random padding 8
Total 256

The client generates a NaCl key pair for each hop in the chain. The SK is used to encrypt the Sealed Header and is then discarded. The PK is transmitted within the header. The KeyID informs the recipient Remailer of what SK to use for decryption.

NaCl Sealed Header Format

The Sealed Header contains sensitive content, such as how to decrypt other payload components and further delivery instructions.

Field Name Bytes Description
Packet version 1 Support for multiple packet versions.
Packet Type ID 1 Intermediate Hops=0, Exit Hop=1
Delivery Protocol 1 SMTP=0 (Currently the only option)
Packet ID 16 Unique packet identifier (prevents replay)
AES-CTR Key 32 AES Key required to decrypt subsequent headers and body
Timestamp 2 Days since Epoch in Little-Endian format. A random 0-3 days are subtracted during stamp creation.
Packet Info 64 Packet-Type specific headers
Anti-Tag Digest 32 Blake2 Digest of subsequent headers and body
Padding 11 \x00 Bytes (encrypted)
Total 160

Packet Info - Intermediate Hop

Sealed headers that are specific to Intermediate type hops.

Field Name Bytes Description
Partial AES-CTR IV 12 Random 12 Bytes of 16 Byte IV
Next Hop Address 52 Address of next hop
Total 64

IV's are constructed from 12 random bytes and a 4 Byte counter in Little-Endian format. The top-most header uses sequence 0, the bottom-most header uses sequence 8 and the Body, sequence 9. The format is: RRRRNNNNRRRRRRRR.

Packet Info - Exit Hop

Sealed headers that are specific to the Exit hops. Each complete chain can only contain a single Exit Hop.

Field Name Bytes Description
AES-CTR IV 16 Used to decrypt Body
Chunk num 1 Sequence number for chunked messages
Total number of chunks 1 Number of chunks required for complete Body
Message-ID 16 Common to all chunks of a message
Body length 4 Total length of Body (less padding) in Little-Endian format
Delivery Method 1 Delivery Protocol. 0=SMTP, 255=Dummy
Padding 25 \x00 Bytes (encrypted)
Total 64