REMAIL: X-Discard header line added
In an effort to make creating more traffic for the Cypherpunks remailers easier, I have added a feature to my remailer. Whenever it receives a message that would otherwise be remailed but contains a header line saying "X-Discard:" it will discard the message and act as though it got remailed. If all of the Cypherpunks remailers supported an automatic discard feature, we could setup cron jobs or whatever kind of software we want to send "junk mail" to the remailers that does not get forwarded on. An idea I just had was to make the X-Discard have a counter. If the number is greater than zero, decrement it and forward the message to another known remailer. If it is less than one or non-numeric, discard the message. Right now, it just discards whatever message has that header. Example Message: ==================================== From: nobody@no.com To: nowhere@bsu-cs.bsu.edu Subject: Test :: Request-Remailing-To: bob&tom@bit.bucket.net X-Discard: Please! Test Message ==================================== Chael -- Chael Hall nowhere@bsu-cs.bsu.edu, 00CCHALL@BSUVC.BSU.EDU, chall@bsu.edu (317) 776-4000 from 8 am - 5 pm CST
On Tue, 15 Jun 1993, Chael Hall wrote:
An idea I just had was to make the X-Discard have a counter. If the number is greater than zero, decrement it and forward the message to another known remailer. If it is less than one or non-numeric, discard the message. Right now, it just discards whatever message has that header.
Seems like a very good idea, at least for the short term, to generate traffic. Just make sure that you do not accept a value for X-Discard that is too large, or else you'll find the same message floating around (Internet Worm sytle) when you *don't* need any extra traffic! If you wanted to really have fun, you could also add X-Discarded-By to keep a list of all sites the message has visitied, and make sure the same message doesn't cycle through the same site too many times. -- Nick MacDonald | NMD on IRC i6t4@jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger i6t4@unb.ca | (506) 457-1931 ^{1024/746EBB 1993/02/23}
In an effort to make creating more traffic for the Cypherpunks remailers easier, I have added a feature to my remailer.
Do you mean easier to create more flow to thwart analysis or easier for an observer to determine which messages it does not need to examine after reaching a certain line in the header. This seems like a nice effort, but will not deter traffic analysis in the slightest. Headers are always unencrypted, so anyone watching the flow will be able to write a 3 line perl script to filter out all of these messages and there is nothing a header line can do to hide this discard information. What might be more usefull is a counter that signals the remailer system to stop passing a message and unwrap part of the message and act upon the instructions there; thus the counter would let tell the system how long to bounce the message around internally and when the counter hits zero it could send the message on to the target. For example you could create a little MIME x-anon-remailer body part that contains lines with the the final destination wrapped in the remailer pubkeys. When the counter hits zero the remailer checks the x-anon-remailer body part of the line that matches its pubkey, decrypts that line to get the final address and then sends the message on. In this sort of system all you would really need to do is send someone a message with your destination address wrapped in one anon remailer pubkey. When Alice replies to Bobs message she includes the x-anon-remailer body part which has the line provided by Bob (or several it Bob provides more than one). Alice sends this message to any remailer entry point and the message gets bounced around the system until the counter hits 0. At this point the remailer checks to see if it can decrypt any of the destination lines, if not it ups the counter by one (and maybe sets a TTL counter so that messages that have destination keys corrupted do not float forever...) and tosses it back into the system, if it can decrypt one of the destination keys it sends the message off to the address Bob has provided inside the destination key (Bob could even have the destination key send it the message into another remailer system if he is sufficiently paranoid). This would make traffic analysis much harder because once the message enters the remailer system it bounces around so much; the remailers become a black box that deliver the message without really knowing anythign about it until the last phase of delivery. This would also not waste bandwidth moving useless messages around. jim
Headers are always unencrypted, so anyone watching the flow will be able to write a 3 line perl script to filter out all of these messages and there is nothing a header line can do to hide this discard information.
The cypherpunks remailers use a little invention called 'header pasting' where header fields may be added into the header after receipt but before processing. These pasted header fields may in addition be put inside encryption wrappers, thus hiding them from the outside world. 'Discard' headers may use this technique. Eric
will not deter traffic analysis in the slightest. Headers are always unencrypted, so anyone watching the flow will be able to write a 3 line perl script to filter out all of these messages and there is nothing a header line can do to hide this discard information.
Eric has already addressed this; I intend to make my remailer PGP capable soon. If not the one on bsu-cs, the new one will have PGP as soon as I can get to it.
paranoid). This would make traffic analysis much harder because once the message enters the remailer system it bounces around so much; the remailers become a black box that deliver the message without really knowing anythign about it until the last phase of delivery.
I'm not sure what you mean about bouncing it around to different remailers, because if there are a lot of remailers, it could take a long time before it finally gets to the appropriate one that can decrypt the destination information (perhaps longer than the TTL and therefore it does not get delivered). With encryption, the remailers don't have to know the recipient until the last phase anyway. In addition, they may not know the contents of the message either.
This would also not waste bandwidth moving useless messages around.
Right now, we have plenty of bandwidth because the remailers don't get much use. ALL: Which is better: X-Discard or X-TTL? I can easily change it to X-TTL. Chael -- Chael Hall nowhere@bsu-cs.bsu.edu, 00CCHALL@BSUVC.BSU.EDU, chall@bsu.edu (317) 776-4000 from 8 am - 5 pm CST
[...]
paranoid). This would make traffic analysis much harder because once the message enters the remailer system it bounces around so much; the remailers become a black box that deliver the message without really knowing anythign about it until the last phase of delivery.
I'm not sure what you mean about bouncing it around to different remailers, because if there are a lot of remailers, it could take a long time before it finally gets to the appropriate one that can decrypt the destination information (perhaps longer than the TTL and therefore it does not get delivered). With encryption, the remailers don't have to know the recipient until the last phase anyway. In addition, they may not know the contents of the message either.
I set the "breakout counter" at 10 and throw it into any port on the remailer web. It bounces around 10 times and then the "deliver this damn message" flag gets tripped and the TTL counter starts. The TTL counter is actually the number of hops from this point on that the message will traverse looking for someone who can decode the encrypted destination address before the message dies or is otherwise checked for problems. It could take a long time to deliver the message, but time latency is another possible means of confounding traffic analysis. What I was basically thinking was that the breakout counter tells the message how many times to randomly bounce around the internal structure of the remailer web (and hopefully becoming lost in the clutter) before it tries to find someone who can deliver it; the TTL would be used once the breakout counter had hit zero and would try to keep a message from bouncing around forever if there is an addressing problem. This would obviously increase the complexity of the system and require a collection of remailers scattered across the net, but it seems to me to have the advantages of providing more security as the number of remailers grows and to allow bepopel to set up thier own forwarding and addressing that is independant of the remailer system (you generate your own destination certificates and can string together whatever you want in the destination, even another hop back into the remailer system.) It may be overly complex, but it just seemed to me that it might offer the possiblity of truly untracable mail: two messages sent into the same entry port with the same destination certificates at the same time could end up coming out of two different exit ports on the black box depending on how they bounced around inside the system. If you want someone to be able to send you a reply to an anonymous message you give them a destination certificate that contains the destination you want the message sent to wrapped in various remailer pubkeys (one or more, it is up to you). They do not need to know where the message is going, they just attach the certificate to thier message and drop it into _any_ remailer and know that it will either get to the destination or get bounced back to them. A distributed anonymous remailer system of sorts... jim
In message
Seems like a very good idea, at least for the short term, to generate traffic. Just make sure that you do not accept a value for X-Discard that
I don't understand what the point is in adding unnecessary, junk traffic to the remailers. Please explain. Peace, -- | Sameer Parekh-zane@genesis.MCS.COM-PFA related mail to pfa@genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/
participants (5)
-
Eric Hughes -
Jim McCoy -
Nickey MacDonald -
nowhere＠bsu-cs.bsu.edu -
zane＠genesis.mcs.com