-----BEGIN PGP SIGNED MESSAGE----- *** Background Cypherpunk remailers have been very effectively keeping the net.cops at bay--mostly because the net.cops aren't _real_ cops. Lance has offered a standard that goes quite a distance towards defeating the latter opponent. I hope that my suggestions can close the gap. The remailers, and their mailers, use IDEA, RSA, MD5, PGP, and D-H. *** Threat Model Our attacker, Eve, is a wealthy national government. Eve has corrupted at least some of the law enforcement agencies, but not much of the judiciary. Contact with the remailers has not been outlawed. Individual use of strong crypto has not been outlawed. ( I know this probably violates the equality of power demand, but...) Alice and Bob are sending each other messages through the net, and know that they are being watched. Eve does not have the secret (PGP/RSA) keys of anyone she has not explicitly compromised. The historical examples might be Chinese dissidents, Afgan or Nicuaraguian freedom fighters, David Koresh, Randy Weaver, or Mary of Scotland. *** Goal Our goal is to help Alice and Bob carry on an extended conversation without Eve being able to produce proof that either one of them actually sent any real message. This include the possibility that on occasion, theirs is the only real message in the remailer net. By produce I include manufacture. Forward security for all involved is preferable. *** Attack Modes I believe that there are five primary modes of attack: traffic analysizing individual remailers, traffic analysizing the remailer net as a whole, compromising remailers, correlating the reception of messages by Bob or Alice with their later outside actions, and fabricating messages from Alice to Bob. *** Basic Abilities Eve knows all of our protocals, and can convince the Internet that she is anyone. She records all traffic into or out of all remailers, as well as Alice and Bob. She runs most of the remailers, and can temporarily and selectively block traffic through the remailers. *** Attack Methods. I will not redetail the standard attacks which include flushing, spam- copying, single copying (stuttering), size matching, or We Dai. I will, however, detail certain attacks that I believe are either new or have not been generally discussed. ** Fabricating Evidence As we have seen with our own government, lack of evidence is a condition that governments can correct by fiat. (Randy Weaver) Alice has to be able to prove that a message on the Internet "from" her to a remailer did not in fact originate with her. ** Sandwiching (This attack may not be possible at this time. But it is hard to know...) If Eve owns remailers on either side of another, she may seed "random" data with particular data in order to determine what IDEA key was used on the data. ** Remailer Spoofing Eve can attempt to process messages on a remailer's behalf. ** Message Body Matching If a copy of a message can be sent through, the first part of the body (following the headers) can be compared. If random garbage has been tacked on by the other remailer, it will be distinguished. *** Definitions for Standard Remailers and mailers together are generically called users. Alice is sending a message to Bob. All remailers operate on ticks. At certain GMTs, all remailers process all of their accumulated messages, then forward them, holding some over for the next batch. The term message refers to either the final message to be sent to Bob, or its encrypted counterparts--including padding. A header is a set of communications to a remailer, or to Bob. A message packet is a message with all of its headers. A T1 packet is the collection of all message packets going from one user to another on a given tick, with additional header information. *** Standard for Exchanging T1 Packets T1 packets are IDEA encrypted. The key is exchanged through a DH exchange which takes place inside previous T1 packets. The keys are DHed so that the compromise of one T1 packet does not lead to the compromise of all subsequent packets. In order to establish the original IDEA keys, a sender would contact a reciever with a special "origination" packet request. Such requests would intiate contact between users, or could be used to establish secure IDEA tick keys in the event of a failed connection, or compromised key. This packet includes a disposable RSA key, which the receiver would use to PGP a disposable RSA key in return. IDEA keys for future packets could be passed through these RSA keys. The RSA keys would themselves be signed by the public key associated with each user. *** The Structure of a T1 Packet T1 packets would include the DH key exchanges for future ticks, a timestamp, all message packets destined for the reciever this tick, an MD5 of the previous T1 packet recieved (decrypted), and an MD5 of the rest of the message, as a checksum. This could be turned into a signature, possibly with the timestamp. If the MD5 from the previously recieved packet matches, the copy of the old sent T1 packet is destroyed. If it is bad, the old packet is resent, with a different key. *** Selection of Message Packets to a User Mailers specify a number of message packets that they receive each tick from various remailers. If a remailer has more messages packets for a mailer on a given tick than the mailer receives, the extras are held over, and a notice is sent so that the mailer can determine if he should raise his limit. If the number of "real" packets to a user is below his limit, dummy packets are sent to him through other remailers, on a sliding scale. A user sends the same number of message packets to each remailer every tick. There is a minimum number of message packets that a remailer will send to each other remailer each turn. /* This eliminates the ability to trace a flood of messages, even if they all took the same path. */ Messages being held are flaged with the number of ticks that they have been held. There is a maximum number of ticks that a message packet can be held. Mailers send the same number of message packets each tick to each remailer that they might use. *** Use of Dummy Message Packets Dummy message packets are used to pad traffic. Dummy messages are always sent at least to third party remailers. The distribution of these third parties is random. /* If Eve runs some remailers, she can immediately eliminate dummy message sent to her machines. But if these do not originate in the machine that sent the message, her gain is much weakened. If Eve controls most of the remailers, it may be necessary to send dummy messages through three remailers in order to obscure traffic flow. If the distrubtion were flat, real messages would stand out. */ *** The Structure of a Message Packet All message bodies are standard sized, and have a standard number of standard sized headers. The reconstitution of oversized messages is handled by Bob's client. The division of oversized messages is handled by Alice's client. An exception is made for mail-to-news gateways, to reconstitute the oversized message at the last remailer. Such exceptions include a rough check to insure that the message is either valid ASCII armour, or some language. The header to a remailer includes the forwarding address, a timestamp, and the IDEA keys to be used on each other header, as well as the body. (Each is different. See below.) After decrypting, the headers are circulated. When creating the timestamp for a header number n, Alice uses the time of the nth tick coming. The top header itself is RSAed with the user's public key. /* If Eve manages, though a sandwich attack, to divine the idea key used on a header, she can use this to trace the message. If we include only the key and an increment, she can get this information if she has two remailers before the good one. If we include the key, an increment, and a permutation of the headers, she can guess the key. */ The header for Bob includes an MD5 of the message, flags in case the message is oversized, and a timestamp. *** Elimination of Duplicate Packets An MD5 record is kept of every message, every header, and every T1 packet recieved or sent for M ticks. M is related to the number of headers and the maximum number of ticks that a message is held--with room for error. If a match is found, the entire packet is rejected. If a message arrives with a timestamp older than M ticks, it is rejected. If a message arrives with a timestamp in the future, it is held until that time. *** Incorporation of Encrypted Reply Blocks Encrypted Reply Blocks would be the PGPed version of a header set. The receiver would know the IDEA keys used on the body, and the order, so he could reverse the operation. The keys could even be included in the final header. It is not possible in this system to allow multiple encrypted reply block responses without possible compromise of the recipient. *** Weaknesses Clients are required to be as sophisticated as hosts. Clients must be able to handle lots of dummy mail. Both hosts and clients must have access to good, secure, random data sources. Hosts must be able to protect their data for a period of hours or days. Hosts and clients need to be able to protect their DH information. Nathan Flame on!! -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLzmk/XmgMs8UcStNAQEQQQgAkJyeh2vgOnsbVzuHrqGKVPE0pIoh37ms DtMxD7mJVMp40fGlQJmk8dT3WeVUpgeFIvJxeNvMZ86jyN51smZkjqUBNWFhJikT HBnAlDuf82g1GbuhPsR9J2vMTtTHcsfs+ytTWDp2g+xr1nWHngki4wBjPy2oOCP9 dxu5vamUnDy0oFatMmGxIZyN9jTzB7NynaXVLkDWL3Hh8amUwyW9nq7LGQJ8Oiuh 2xY4uizxJ+/SjxnATxUznT9i099xC3ClpRGX1n/3fdXY5Mu5MAJoRO6sjL5Fakz4 3i0qWNlv8ZJCqCetSqnQrINFFd6bpDhiAz5/CU4kQ9/HtStIVl/88A== =kziG -----END PGP SIGNATURE-----