The Lost Biro Project – Technical Specs version 0.1beta030218
The Purpose of this highly secret project is to take back what our governments have taken from us, the Internet user, we want back our privacy and this protocol is our tool to reclaim our territory from the kind of people that try to limit our ability to express ourselves and be honest with each other without fear of pain and misery. The final purpose of this project is to make the Internet a safe place where the only way you can be hurt is by taking the Internet away from you by severing your umbilical cord to this virtual playground and forcing your back into the real world.
This attack resends a message multiple times in order to find similarities in the output of a TLBP mailer.
This attack modifies messages so they can be recognized later on in Chaum Mix Chains1.
This attack watches the time at which messages arrive at the TLBP mailer and tries to correlate them with the time when messages leave this same, or another, TLBP mailer.
This attack tries to link your writing style with anonymous messages.
This attack tries to limit your use of TLBP mailers by the use of legal tools, like local laws or new legislation.
These attacks try to overload the hardware of the TLBP network, thus making messages disappear from it never to be seen again.
These attacks try to get system administration rights on computers in the TLBP network, thus allowing the attacker to do things this paper did not anticipate (like altering the software on that computer).
This attack tries to convince the user of the TLBP network that he is someone else then he really is. Very philosophical stuff.
These attacks are the hardest to perform and require both a good skill in advanced math, knowledge of existing crypto algorithms and attacks, analytical skills and an ability to think of things other people cannot think of.
Most problems with current day software fall into this category. Like Buffer Overflows, Out of Memory errors, Buffer Underruns, Illegal memory accesses, Unchecked function inputs, Non Terminating procedures, Endless loops, Software races. In general the kind of thing I like to think I am good at avoiding ;-)
Very primitive, your basic sledge hammer approach will fit into this category, not that this technique can also be used on living creatures like TLBP Operators or their users.
This is the most dangerous kind of attack. The kind of attack that catches you of guard and which you didn't prepare for. Kind of the way I published this protocol to the world while our governments are still trying to regulate how Internet traffic should be stored on police operated computers and how far they can push their luck before people will start to get mad and take back what is theirs to begin with.
Right now there are only two protocols which I deem worth mentioning in this paper.
Mixmaster2 was designed, drafted and coded by people like Lance Cottrell3, Ulf Möller4 and others who have taken over this project from them.
This is a pseudonym project by Frans Kaashoek from MIT5. It is not very private though due to the use of only Type I Cypherpunk remailers. That is why I wrote TLBP protocol.
Forward Secrecy is nothing new in the remailer world. Here is the new data format though (in pseudo form, note how it seeds TLBP servers with public keys and routing info for these public keys):
[hashcash4SMTP] /* this data field allows the user of a TLBP server to pay for processing this message, it is on top of the message so it may be processed as quickly as possible, TLBP Ops should set this value fairly low as it will also index one of their secret keys and having this key removed from the TLBP secret key pool is a thing that should be encouraged towards users, the hashcash will however prevent flooding of the TLBP in pools to a small extend */
[RSA(session key + IV)] /* this second data field will allow the TLBP server to decrypt the rest of the message, both the IV and the session key are encrypted to one of the TLBP servers secret keys */
[random data] /* this is the payload of TLBP Forwarding message. At every 4096 octet boundary a new TLBP Forwarding message might start or after a validly decrypted block there might be a replied message, after which there should be a TLBP Forwarding message again. Note that this protocol allows Forwarding messages to be stacked to a single address and at least one of these messages might fail to decrypt. TLBP servers are recommended to order multiple messages from small to large and to leave the really insanely large messages in a single Forwarding message to the next remailer (or user) */
That is of course just on the outside, as your ISP will see it. This inside is much more interesting that the outside of encrypted messages ;-) That is why you are reading this paper after all.
[hashcash4sendingthecurrentmessage] /* this field allows the TLBP server to demand the user to collide on the whole of the message in the payload that follows, including all the other stuff inside this TLBP forward message. It should be set as low as possible or even to zero, but it should allow a TLBP Op to force the user to regenerate new hashcash for each non-identical message send */
[hashcash4storingpublickeyacoupleofdays] /* this data field allows the user to pay more hashcash then required so that his public key, that will follow next, may be stored for a longer time at the TLBP server than public keys for which less hashcash was being payed. This value will collide on the public key and the extended features below only so it can be pregenerated during idle CPU Cycles by the user */
[Public RSA key of the user] /* easy, this is the key that proofs ownership of the secret key that goes with it. It is also used to encrypt TLBP Reply messages */
[semaphore4keyreuse] /* this is the E. W. Dykstra Semaphore, which should always be set to one! Use this option to reuse the same public RSA key multiple times at your own risk, setting it to zero or lower means it will remain valid for ever. Because it is a semaphore, the value of this setting will be decreased by one every time the public RSA key of the user (above) is being encrypted to. When the semaphore reaches zero because of this decrement, the public key must be wiped from the TLBP server software automatically. If the Semaphore is set to -1 Simple Reply Secrecy will be disallowed by the sender and the TLBP server should notify any people trying to use this paradigm that will be discussed later on in this paper. Setting it to -1 will also prevent the TLBP server from informing the user of public keys of him that might have expired or might even punish the user by keeping this key shorter (since he won't be able to find out this fact anyway), like there is a downside to anything that is cool :-) /
[maximum4payload2reply] /* this very important field allows TLBP servers to cut of excess data on reply messages. This both protects the users privacy by disallowing easy to spot message sizes as well as protecting his mailbox by limiting the effect a mailbomb will have on his virtual Internet experience, this field will be set in units of 4096 octets of outside encrypting and defaults at 32kb because that seems very reasonable to me and will be ignored on Forward Secrecy Messages. It may be set by users to shrink messages like they did with the garbage and cutmarks directives in Cypherpunk remailers, but users are recommended to leave this setting alone as the TLBP will take care of this on Forward Secrecy Messages by themselves and add garbage by themselves on Reply Secrecy Messages */
[length of payload] /* this is just for the TLBP server to know where decryption of this message stops. Note that the above fields fix the place for this data field and note that it makes no sense to start counting at any other value that zero itself if this value exists (take that you IPv4 designers!) */
[RSA signature with the above public key on everything inside this Forwarding message that isn't garbage or trash] /* easy, this is both a checksum and proof of ownership of the secret key that goes with the users public key */
[payload in simplified RFC 822 format] /* this (huge) data field contains the next mix and the routing data using standard RFC 822 headers. Software implementors should not assume that RFC 822 might not one day be obsolete or replaced by something better, so code well and use #define statements in a separate header file instead of constants every time you need them */
[To: header] /* this header only has a single sec e-mail address in the format user@domain.toplevel. It is used by the TLBP server to route the message to the next remailer or the final user in a chain and may be used for as long as the public key above is stored on the TLBP server in order to be able to report errors and dumped messages if needed somehow */
[From: header] /* this header should always match the source of the outside Forwarding message and should be dropped by the TLBP server if they do not for whatever reason. There may only be a single From address in the same format as the address of the field above and it may be used to report dropped traffic and other TLBP server errors. It should be discarded together with the users public key above */
[Reply-To: header] /* this header is used to route messages back to the initiator of an anonymous conversation and may include multiple fields under the condition that they are in the same format as the two fields above, separated by comma's and a single space after that, it may even be set empty, but this is not recommended */
[optional] /* these fields might not exists, while still being valid for use in the TLBP protocol */
[newline character] /* just like in RFC 822 */
[body of message in some specified format I have yet do decide on] /* hard, but I am working on it */
[garbage of unknown length] /* just ignore this garbage unless you like that kind of thing, the whole message should be dropped if this data doesn't seem random after running CPU-Hungry statistical tests on it, but like I said, you have to like that kind of thing ;-) */
This protocol is the first implemented system that allows people to complain to the abuser who has send them a message (as long as their reply-blocks are functional). Basically, every TLBP server uses only replyable addresses in their exit strategy. When a user replies to an anonymous message, the TLBP server searches for the References header in its databases and tries to match it with a public key (it has generated the matching Message-ID header after all if everything is right). The TLBP server then encrypted to this public key, removes the key and traffic info from the database and sends it on to the initiator of the anonymous communication that was replied to. This is repeated at every TLBP server until either the original initiator get his reply or someone else does in case the system was abused by the initiator by providing false e-mail addresses. This is why it is so important in this protocol to try and check the From header in the payload of a Forwarding message. The Dykstra Semaphore allows the return mix to be reused and abused as many times as the users and Operators of the TLBP network allow. Note that using the Semaphore allows replay attacks among other nastiness! Allowing Simple Reply Secrecy is not recommended, but some people are just lazy and can't be bothered to download their own client or to prepend a reply-block to their messages. In case multiple TLBP servers are hosted on the same machine (which is not recommended by the general remailer public these days of excess paranoia), the To line can also be used to match up the right Message-ID with the right public user key. TLBP servers are not allowed to do anything in addition to what is written here as it might break the protocol even further!! (this is a feature, not a bug).
This paradigm works just like the Nym.Alias.Net servers do in Frank Kaashoek's paper, only a lot more secure and simple due to the properties of the TLBP has that Type I remailers lacked so dearly. If you have payed attention while reading the above the way it functions should be obvious by now.
A TLBP server will keep its data as long as his hard drive space and memory efficiency under the current TLBP loads allow. The Cleanup strategy is the most interesting part for a TLBP Server programmer and Operator to deal with. Rules to take into consideration right now are:
How expensive does the Op want to make the use of his server for new users?
How expensive does the Op want to make the use of his server under heavy loads?
How are public user reply blocks aged and are the function sets and trust on this user added into this mix? Like would do you collect stamps for this remailer so you can get a discount for future use?
Do you block people that get harassed, or do you just get the hashcash needed to send to them higher and higher with each new complaint you get as an administrator?
How can you predict which public keys will never be used again and how sure can you be of this?
How can you make sure your server doesn't go down if your TLBP load gets just a little bit higher than usual? Can you sustain the load under your current hashcash economy rules for your TLBP server or do you need to tweak them until your TLBP server has proved itself to the community?
I could write a book on stats. While stats are not really needed while the system is not under full deployment, here are some things I would like to consider to include in these stats:
The last time the TLBP server was rebooted
The last time the TLBP was maintained by the Operator
The last time there was a windows of exposure due to a vulnerability in the TLBP server
The operating system and version plus build of the TLBP server the TLBP server runs
The version numbers of essential software on this server which holds the secret keys and seeds of its users, like Sendmail plus version number
Any other pieces software and services that have been installed on the same server at the moment of stats generation
Any comments the TLBP Operator might want to include, like the fingerprint and e-mail address of his PGP encryption keys
Every stat we should assume the ISP of the TLBP server has access to (non including the little protection offered by the stacking together of messages to the same address, that was not added to the protocol for security but for reliability and efficiency).
The above stats are only info for the user of the TLBP server, they should be standardized in the first implementation draft of the protocol, but they could all be left out in case the remailer operator doesn't feel like giving out this information to anyone (silly as it sounds, hiding the specifics of the platform you are running on can make an attackers job harder, e.g. That I why I do not recommend the use of statistics of the kind of system the server runs on like CPU speeds, hard disk space and RAID level, ADSL speed, things like that. Also, they are of no importance to the user at all and can be added in in the comment field by show-off Operators anyhow).
There are more important stats however, and these are they as I see now, they are not optional! Every TLBP server should generate all of them and TLBP clients should drop the TLBP server is any of these stats are invalid or left out:
hashcash4TLBPkey, hashcash4SMTP (should always be included, except on Simple Reply Secrecy Messages or requests for help), hashcash4replyblockstorage (every extra bit doubles the storage time on average), hashcash4message (should be set to zero, should only be used by TLBP Operators as a last defense before going down under extreme loads). Note that these values are only indicators and are adapted to real time TLBP loads. If you want to be safe, pay a little more cash than is asked from you for better service by the TLBP Server.
Total number of messages processed during last 24h (in, out, dropped, only anonymous traffic is counted that was encrypted or decrypted to any kind of TLBP key)
Total amount of hashcash payed over last 24h (this should give the user a feeling for the load the remailer is under, compare these figures to the NasdaQ index to get a feel for how to interpret them).
Note the absence of info about remailer pool sizes and default latency. These are secret to the TLBP Server and Operator and can change without any prior notice.
There are more stats however that the ISP of the TLBP server has access to, and which the user should also have access to. These fields are again not optional! They are of great importance to the client software I envision! The are the same as the above, only more detailed:
There must be a table with all TLBP e-mail addresses (even small ones that respond to stats and key requests), for each of these TLBP the in, out and dropped traffic must be specified separately. This will allow the client software to draw nice graphs (perhaps 3D?) of all inter-TLBP server traffic and get a good feel for where things go wrong (when they do). It will also allow TLBP users to spot the places where they will have most cover traffic and less e-mail loss.
There must be a table with message size distribution for TLBP in, out and dropped boxes. This will allow the TLBP user to hide their traffic even better.
There must also be a table with the distribution of hashcash paid at that remailer, but only for public keys from the user and secret keys from the TLBP server. Be sure not to use the same unrecommended value at each TLBP hop, since your Attackers will spot this.
There must also be a list of top remailer users if their remailer users becomes above a certain threshold, only inbox traffic count should be specified together with the IP address of the user that connected to the POP3 or IMAP servers of the remailer. It should be able to trace, but not proof abuse this way.
There should be well specified numbers and texts assigned to each reason why a message was dropped from the server that will help users find out why their messages didn't get through. I have thought up several so far: 'not enough hashcash', 'bad signature', 'encrypted to expired TLBP key', 'no response from server', 'message too big', 'invalid RFC 822 headers'.
These stats should be signed by the TLBP server somehow and this TLBP server certifying key should in turn be signed by the Operator. Installing any version of PGP or GnuPG is not recommended by me at all!
Getting keys to the user is hard. In fact, I can't seem to solve it elegantly! Requesting a key should cost a lot of hashcash since the secret key will remain on the TLBP for a while. By paying more than advised in the stats or the help message form the TLBP server, these keys will remain valid longer (twice as long for every bit spend? Maybe just a single day longer for every bit or this bit will just be decreased every time the hard disk of the TLBP server gets full).
When requesting a key from the TLBP server, the stats will also be included in the reply back and the TLBP server should be able to encrypt this info to the user somehow. (A TLBP user could pose as a TLBP server without any hashcash requirements, but I haven't finalized this yet).
This help message should be send in case the TLBP server doesn't know what else to do with the messages it gets. It might be advisable to force users to register with the TLBP server with their real e-mail address first to avoid list-linking attacks and things like that.
In the help message the current hashcash needs and challenge should be stated and this may be very much like in the paper by Adam Back6. Also the (self-signed) Operator key and current TLBP server certification key should be included. A few links and some explaining about the server should get the majority of users underway I guess.
Later, the protocol is already pretty abuse proof as it is now.
Pings are easy with this protocol. I think special clever messages could be drafted that either route back to the user (giving info about chains and latency) or reply back on themselves where an TLBP help message could be used as an e-mail echo server (note, TLBP Operators should white list themselves at other TLBP Servers for this to work!). Just use your imagination and you should be fine implementing this protocol. This protocol should stop functioning where your imagination stops, so don't make a mess of the protocol like Rprocess7 did with Mixmaster 2.04 :-(
This protocol was thought up and drafted by: Thomas J. Boschloo Hagedoornstraat 31 1783 HZ Den Helder The Netherlands (if we are not nuked by the USA yet for putting their war criminals on trial)1“Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms” by “David Chaum” from “University of California, Berkeley, California” in “Communications of the ACM, February 1981, Volume 24, Number 2”
2The Mixmaster Project, version 2.90 <Http://mixmaster.sourceforge.com>
3Anonymizer <Http://www.anonymizer.com>
4Ulf Möller <Http://web.archive.org>
5Nym.Alias.Net <Http://nym.alias.net>
6Adam Back <http://cypherspace.org/hashcash>
7Rprocess <http://potatoware.cjb.net>