This blog post originally appeared on crypto.is. We've since shut down that website, so I have copied the blog post back to my own for archival purposes.
While most of ritter.vg will function without javascript, this blog post is an exception.
A remailer's packet format is the format of the data it passes to the next remailer. The packet format is somewhat independent of the remailer transport protocol itself - just as a letter is independent of how you recieve it. A courier can hand-deliver a letter to you, it can be dropped in your mailbox by a stranger, or the Postal Service can deliver it. But once you've actually recieved it, you can open it, read it, and take action based on it.
Although packet formats are independent of remailer transport protocol, most remailers do not process more than one type of format. While I initially wanted to create a single blog post covering all the major packet formats - that proved to be extremely long, so it's going to be split up across a couple blog posts. This first one will cover the Mixmaster packet format, as used in the Mixmaster remailer network.
Mixmaster Format
The mixmaster packet format is detailed in mixmaster-spec.txt and can be described as 20 Mix Headers followed by a Mix Paylod. The first Mix Header is encrypted to your public key - you can decrypt it and learn where to send the rest of the data. If the message is a Final Hop, you will be able to decrypt the Payload, and send it to the final destination.
If the message is not a Final Hop - if it is an Intermediate Hop - you will find the address of the next remailer in the chain. Before sending it on, you will decrypt all subsequent Headers (numbers 2 - 20) and the Payload - but you will not find any meaningfull data, as they are encrypted multiple times, in an onion, to keys you don't know. The following animated examples should demonstrate the layering:
Mixmaster Final Message, As Seen by the Final Hop
Mixmaster Intermediate Message, As Seen by an Intermediate Hop
Transport
The above is the binary format of the protocol. The mixmaster packets are then encoded as follows before transit:
:: Remailer-Type: Mixmaster [version number] -----BEGIN REMAILER MESSAGE----- [packet length ] [message digest] [encoded packet] -----END REMAILER MESSAGE-----
Because the Mix Payload is padded to a constant size, and there are always 20 Mix Headers, a Mix Message is a constant size, and the packet length field is always 20480. The Message Digest is computed over the encrypted, binary representation of the Mix Headers+Payload and then base64-ed. Finally, the binary headers+payload themselves are encoded in base64 and broken into lines of 40 characters.
Notes
Some other notes about the Mixmaster Packet Format, tersely:
- The Mix Payload packet is a constant 10236 bytes (plus 4 bytes length) - any message larger than that must be split into message chunks (which will be talked more about in another blog post.) But any message smaller than that is still padded to that size.
- Obviously, there is only room for 20 Mix Headers, so the maximum hop length of a Mixmaster message is 20 hops.
- The format conceals the lenth of the path from each intermediate hop - if you're not the final hop, you don't know how many more hops there are.
- The raw packet format, shown above, has many distinct markers, making it easy to reliably detect it in transit. (This is especially bad for Mixmaster, do you know why? Hint: check out the second blog post.)
- The algorithm and key lengths are hardcoded into the specification, with no room for alternation. Thus we are stuck with
- RSA 1024 with PKCS #1 v1.5 Padding
- EDE Triple DES in CBC Mode
- MD5 as Message Digest Algorithm
- Replay prevention is often built into the packet format, at least partly. In the Mixmaster specification, a server keeps track of all Packet IDs seen so far, and if it sees an identical one, will discard the message as a replay. Mixmaster must expire old packet ids eventually, and so a message can be replayed if the server has expired the packet id. We'll talk more about replay attacks in a future blog post also.
- The format is vulnerable to Tagging Attacks, which I'll go over in more detail with an example in a future blog post.
This blog post is licensed under Creative Commons Attribution 3.0 United States License and is inspired by, and makes heavy use of, the images produced by the EFF & Tor Project here.
Previous Step
Close
Next Step
required, hidden, gravatared
required, markdown enabled (help)
* item 2
* item 3
are treated like code:
if 1 * 2 < 3:
print "hello, world!"
are treated like code: