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