December 2003 - cypherpunks-legacy

Re: white noise remailer
by Jaeson.M.Engle＠josaiah.sewanee.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is an interesting approach. It could even contain a small set of PGP'd messages like "This is the sound of white noise on the Internet" and "Have fun breaking this one?" In the even someone took the time to break the pgp... >I'm new to all this so please pardon my ignorance, but are you guys >consdidering the following approach: > >The remailer transmits a constant bandwidth of outgoing messages of all >about the same size to a uniformly distributed range of target addresses. >Incoming messages are randomly dispersed within this stream, packed out to >the standard size. > >-rkm > > >--- > >Richard K. Moore - rkmoore(a)iol.ie - Wexford, Ireland - fax +353 53 23970 -----BEGIN PGP SIGNATURE----- Version: 2.6ui iQCVAgUBLyhlIUiLvmPjc4XdAQFRgwQAiSJr09cQav2c+kqz+6a8NSyh4BXf1prx 0hDbn31MlBBWTnezk/+PSCmfE9eXZwLbrLDCtUwIoudhIYxTqAzJV10GK0gWyF7O 6iKg6LTEgsa4DfJC2uc7Knrdj9ln9LK6qy8/I5zM5QZdfZHwYEuEcGS5aPIHdYGT SbKsnUi0rHI= =kUQl -----END PGP SIGNATURE----- aka: (-: Jaeson M. Engle || jme(a)josaiah.sewanee.edu :-) (-: www server: http://josaiah.sewanee.edu/ :-) (-: It's February 8th! IT'S TIME!!! Ask me for details!:-) (-: Finger 'jme(a)josaiah.sewanee.edu' for my Public :-) PGP block.

1 0

Re: Reordering, not Latency (Was: Re: Remailer)
by Andrew Lowenstern 17 Dec '03

17 Dec '03

> Adam Shostack says: > > It may be that the FBI has a couple of Suns handling the whole > > remailer network right now. Perry Metzger replies: > If they are doing that, they are violating the ECPA. They are > allowed to monitor only those things they have a warrant to monitor > (with, of course, all those lovely National Security exceptions). > This is not to say that it isn't being done, but it can't be used > in court. Is this even technically possible? That is, wholesale monitoring of disparate portions of the net from a single access point. Given the distributed and dynamic properties of the Net this would seem impossible. To monitor the entire remailer network an attacker would have to setup packet sniffers upstream from each and every portion of the Net that contained a remailer, wouldn't they? I suppose an extremely resourceful attacker could monitor traffic at crucial points (i.e. transcontinental feeds, points on the NFSnet, CIX, etc...), but there are so many private connections linking networks that it would be very difficult indeed to sniff out every bit of remailer traffic. Is having every bit of remailer traffic necessary for traffic analysis? Or would having a good percentage of it be sufficient? andrew

3 2

<none specified>
by Anonymous 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- My appologies if this has already made it to the list. In article <D2wtJC.C8I(a)freenet.carleton.ca> you wrote: : In a previous posting, Farrell McGovern (ai474(a)FreeNet.Carleton.CA) writes: : > CNN Headline news this morning is running a story saying how the : > Internet is so innsecure that "hackers" can access former VP Quale's : > medical records, number of atomic warheads in a certain state and CIA's : > budget. And all ths is supposedly based upon a "breakthrough" that : > "hackers" have made recently. They say that the Internet will not be able : > to be secure for at least 5 years. : Here's more about it! : : Article #36 (36 is last): : Newsgroups: comp.security.announce : From: ecd(a)why.cert.org (Edward DeHart) : Subject: IP Spoofing Attacks and Hijacked Terminal Connections : Date: Mon Jan 23 16:00:37 1995 : ============================================================================= : CA-95:01 CERT Advisory : January 23, 1995 : IP Spoofing Attacks and Hijacked Terminal Connections : ----------------------------------------------------------------------------- : The CERT Coordination Center has received reports of attacks in which : intruders create packets with spoofed source IP addresses. These attacks : exploit applications that use authentication based on IP addresses. This : exploitation leads to user and possibly root access on the targeted system. : Note that this attack does not involve source routing. Recommended solutions : are described in Section III below. : In the current attack pattern, intruders may dynamically modify the kernel of : a Sun 4.1.X system once root access is attained. In this attack, which is : separate from the IP spoofing attack, intruders use a tool to take control of : any open terminal or login session from users on the system. Note that : although the tool is currently being used primarily on SunOS 4.1.x systems, : the system features that make this attack possible are not unique to SunOS. : : As we receive additional information relating to this advisory, we will place : it, along with any clarifications, in a CA-95:01.README file. CERT advisories : and their associated README files are available by anonymous FTP from : info.cert.org. We encourage you to check the README files regularly for : updates on advisories that relate to your site. : : ----------------------------------------------------------------------------- : : I. Description : : This description summarizes both the IP spoofing technique that can : lead to root access on a system and the tool that intruders are using to : take over open terminal and login connections after they get root access. : We are currently seeing attacks in which intruders combine IP spoofing : with use of the tool. However, these are two separate actions. Intruders : can use IP spoofing to gain root access for any purpose; similarly, they : can highjack terminal connections regardless of their method of gaining : root access. : : IP spoofing : To gain access, intruders create packets with spoofed source IP : addresses. This exploits applications that use authentication : based on : IP addresses and leads to unauthorized user and possibly root access : on the targeted system. It is possible to route packets through : filtering-router firewalls if they are not configured to filter : incoming packets whose source address is in the local domain. It : is important to note that the described attack is possible even if : no reply packets can reach the attacker. : : Examples of configurations that are potentially vulnerable include : - routers to external networks that support multiple internal : interfaces : - routers with two interfaces that support subnetting on the : internal network : - proxy firewalls where the proxy applications use the source : IP address for authentication : : The IP spoofing attacks we are currently seeing are similar to those : described in two papers: 1) "Security Problems in the TCP/IP Protocol : Suite" by Steve Bellovin, published in _Computer Communication Review_ : vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD : Unix TCP/IP Software" by Robert T. Morris. Both papers are available : by anonymous FTP from : : ftp.research.att.com:/dist/internet_security : : Bellovin paper: ipext.ps.Z : Morris paper: 117.ps.Z : : Services that are vulnerable to the IP spoofing attack include : SunRPC & NFS : BSD UNIX "r" commands : anything wrapped by the tcp daemon wrappers - site dependent; check : your configuration : X windows : other applications that use source IP addresses for authentication : : Hijacking tool : Once the intruders have root access on a system, they can use a tool : to dynamically modify the UNIX kernel. This modification allows them : to hijack existing terminal and login connections from any user on the : system. : : In taking over the existing connections, intruders can bypass one-time : passwords and other strong authentication schemes by tapping the : connection after the authentication is complete. For example, a : legitimate user connects to a remote site through a login or terminal : session; the intruder hijacks the connection after the user has : completed the authentication to the remote location; the remote site : is now compromised. (See Section I for examples of vulnerable : configurations.) : : Currently, the tool is used primarily on SunOS 4.1.x systems. However, : the system features that make this attack possible are not unique to : SunOS. : : : II. Impact : : Current intruder activity in spoofing source IP addresses can lead to : unauthorized remote root access to systems behind a filtering-router : firewall. : : After gaining root access and taking over existing terminal and login : connections, intruders can gain access to remote hosts. : : : III. Solutions : : A. Detection : : IP spoofing : If you monitor packets using network-monitoring software such as : netlog, look for a packet on your external interface that has : both its source and destination IP addresses in your local domain. : If you find one, you are currently under attack. Netlog is : available by anonymous FTP from : net.tamu.edu:/pub/security/TAMU/netlog-1.2.tar.gz : MD5 checksum: 1dd62e7e96192456e8c75047c38e994b : : Another way to detect IP spoofing is to compare the process : accounting logs between systems on your internal network. If : the IP spoofing attack has succeeded on one of your systems, : you may get a log entry on the victim machine showing a remote : access; on the apparent source machine, there will be no : corresponding entry for initiating that remote access. : : Hijacking tool : When the intruder attaches to an existing terminal or login : connection, users may detect unusual activity, such as commands : appearing on their terminal that they did not type or a blank : window : that will no longer respond to their commands. Encourage your users : to inform you of any such activity. In addition, pay particular : attention to connections that have been idle for a long time. : : Once the attack is completed, it is difficult to detect. However, : the intruders may leave remnants of their tools. For example, you : may find a kernel streams module designed to tap into existing TCP : connections. : : B. Prevention : : IP spoofing : The best method of preventing the IP spoofing problem is to install : a filtering router that restricts the input to your external : interface (known as an input filter) by not allowing a packet : through if it has a source address from your internal network. In : addition, you should filter outgoing packets that have a source : address different from your internal network in order to prevent : a source IP spoofing attack originating from your site. : : The following vendors have reported support for this feature: : Bay Networks/Wellfleet routers, version 5 and later : Cabletron - LAN Secure : Cisco - RIS software all releases of version 9.21 and later : Livingston - all versions : : If you need more information about your router or about firewalls, : please contact your vendor directly. : : If your vendor's router does not support filtering on the inbound : side of the interface or if there will be a delay in incorporating : the feature into your system, you may filter the spoofed IP packets : by using a second router between your external interface and your : outside connection. Configure this router to block, on the outgoing : interface connected to your original router, all packets that : have a : source address in your internal network. For this purpose, you can : use a filtering router or a UNIX system with two interfaces that : supports packet filtering. : : NOTE: Disabling source routing at the router does not protect you : from this attack, but it is still good security practice to : do so. : : Hijacking tool : There is no specific way to prevent use of the tool other than : preventing intruders from gaining root access in the first place. : If you have experienced a root compromise, see Section C for : general : instructions on how to recover. : : C. Recovery from a UNIX root compromise : : 1. Disconnect from the network or operate the system in : single-user mode during the recovery. This will keep users : and intruders from accessing the system. : : 2. Verify system binaries and configuration files against the : vendor's media (do not rely on timestamp information to : provide an indication of modification). Do not trust any : verification tool such as cmp(1) located on the compromised : system as it, too, may have been modified by the intruder. : In addition, do not trust the results of the standard UNIX : sum(1) program as we have seen intruders modify system : files in such a way that the checksums remain the same. : Replace any modified files from the vendor's media, not : from backups. : -- or -- : : Reload your system from the vendor's media. : : 3. Search the system for new or modified setuid root files. : : find / -user root -perm -4000 -print : : If you are using NFS or AFS file systems, use ncheck to : search the local file systems. : : ncheck -s /dev/sd0a : : 4. Change the password on all accounts. : : 5. Don't trust your backups for reloading any file used by : root. You do not want to re-introduce files altered by an : intruder. : : --------------------------------------------------------------------------- : The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith Bostic, : Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our : understanding of these problems and their solutions. : --------------------------------------------------------------------------- : : If you believe that your system has been compromised, contact the CERT : Coordination Center or your representative in Forum of Incident : Response and Security Teams (FIRST). : : If you wish to send sensitive incident or vulnerability information to : CERT staff by electronic mail, we strongly advise that the e-mail be : encrypted. The CERT Coordination Center can support a shared DES key, PGP : (public key available via anonymous FTP on info.cert.org) or PEM (contact : CERT staff for details). : : Internet E-mail: cert(a)cert.org : Telephone: +1 412-268-7090 (24-hour hotline) : CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), : and are on call for emergencies during other hours. : Fax: +1 412-268-6989 : : CERT Coordination Center : Software Engineering Institute : Carnegie Mellon University : Pittsburgh, PA 15213-3890 : USA : : Past advisories, CERT bulletins, information about FIRST representatives, : and other information related to computer security are available for anonymous : FTP from info.cert.org. : : : : CERT is a service mark of Carnegie Mellon University. : : ------------------------------- : -- : ------------------------------------------------------------------------ : The Information Cowpath is strewn with Meadow Muffins...even the best of : us get the Meadow Muffin Blues every now and then... - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLycwFyoZzwIn1bdtAQH7lQGAqGZx0JupR5oLwwm9wcJkhwZLks3Y1y36 4F9UjunJWFS4sKbts6eLkAT3jakXpTXT =3rGy -----END PGP SIGNATURE-----

4 3

"Subway" remailers
by xpat＠vm1.spcs.umn.edu 17 Dec '03

17 Dec '03

Need ideas/comments: I have been modeling remailer scenarios using IBM VM/ESA virtual machines. After fwaffing a bit, looking at the traffic analysis concern, and taking note of some of the probability work posted recently, I thought I might throw this idea out for a sanity check: "Subway" remailers. "Subway" remailers would exchange identical sized "containers", much like a subway at semi-regular pulses or intervals. It would require a ring of remailers large enough (yeah, I know) to make traffic analysis of entrance and exit points difficult and/or expensive. Each container would contain either fixed or variable slots for multiple messages. Containers could be full, partially full, or even empty. (there would probably have to be a max message size) Subway remailers would be able to carry a message to a designated "last" remailer or to deliver blindly to a "last" remailer of random choosing. Messages may or may not change containers at the various stations/remailers. It could be randomized. Possible header scripts: X-Subway-Script: Ride 2; Latent: 03:30; Ride 3; Deliver; or many other possibilities. The whole container would be encrypted to the next remailer, giving the next remailer the same access to exchange passengers or to make them wait in a latent state. The quirkier matters on this are how to handle PGP so that nothing is compromised and for how the remailers to identify each other as "friendly and operational" so the subway system does not have a traffic jam. Crypto comments please. ------------------------------------------------------------------ P M Dierking |

2 1

anon communication
by Harry S. Hawk 17 Dec '03

17 Dec '03

Re: anon communications Hello... There are many reason that anonymous communications are needed, I will just focus briefly on one that is important to our business. When we post jobs on the Internet we need to remain anonymous. We do this when we place ads in the NY Times as well. This is just one reason why anonymous communication on the Internet is very important. Harry Hawk Manager of Computer Services Warwick Baker & Fiore 212 941 4438 habs(a)warwick.com /hawk

1 0

Re: Reordering, not Latency (Was: Re: Remailer)
by nobody＠replay.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On Wed, 25 Jan 1995 Michael Handler wrote: >On Wed, 25 Jan 1995 Louis Cypher wrote: > >> In recent discussions, the consensus >> was that message reordering was superior to (and the actual intent of) >> latency. Reordering is not sufficient, a form of latency is required >> to make it effective. > > I have literally hundreds of messages archived from the CP list of >several months back where Eric Hughes repeatedly states that reordering, >not latency, is the key. Reordering of a sufficient magnitude will >introduce latency inherently. Otherwise you are still vulnerable to >traffic analysis (which is an art, not a science, remember). > >-- >Michael Handler <grendel(a)netaxs.com> If you read my analysis with more care, you will note that I do not argue that latency is superior to reordering, nor that it should be used in place of reordering. Reordering is far superior to latency. My point is that pure reordering is vulnerable to attack. It is less vulnerable if combined with latency. Also note that this was a repost of a message I sent to the list some months ago. I sent it because it seemed similar to the work that Wei Dai has been posting. -Louis Cypher -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLyiy0qyHUAO76TvRAQF6qAQAk6IDl+UknPQ+c6hbmPvlgCtF2xwG0KZ3 aUXiuv/XJ5e5prRwLQ4X6rOUSflT2f+mRPO4fveVmWePWcr8BtV6LUQM+qJOLe5k Ay7CD+OGN9ni9EhRbIg3Sgdv6yB8cX2CpdMSByFD8J9rM240UWqSt/DgNQIlkTtC Jx+0NQP80QA= =aKOE -----END PGP SIGNATURE-----

1 0

Re: CERT statement
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- In article <9501270023.AA17883(a)snark.imsi.com>, Perry E. Metzger <perry(a)imsi.com> wrote: >Well, sort of. A key management system that operates sort of like >Kerberos' is necessary. However, thats really far from >sufficient. Most Kerberized protocols authenticate only at the >beginning of the session -- very very hijackable. I just want to chime in that telnet{,d} clients are available that do encrypt every packet, built upon Kerberos v5 (and the GSSAPI) for key management. There are even libraries that sit on top of sockets with the same interface and do the encryption (and therefore the implicit authentication) of every packet. I'm sure Perry knew this, but I'm also sure others didn't. I'm afraid I don't have any pointers at the moment (though I know that they are in use in some parts of CMU), and unless your need is urgent and you already use kerberos you should just wait for the new swIPe. - - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus(a)hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLyh9zBNhgovrPB7dAQGk+gP/TatFUjwI79UT1UY5IQK82wlQ/jK7tOXb HX6zWCVU48l/vfAWHSYdS1QSQEeUMH4Z+lnW4lxW0G9fWDk/LxSlyJqnw/zDEbK+ 16ePq/6AWsCCA5Gt2HchAfVoC72iYOeU0oDMQJerr6K6s2FLZrR4vSEQAUSbkoJz VHLjcR6mrog= =JYyc - -----END PGP SIGNATURE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLyi2nSoZzwIn1bdtAQFSiwGAspboooxRv7cVKp3/aPZGVaLkkscfSh/y PKrOIuBmAoaHmMwUGwV73ygYc3N1bvs0 =PKb8 -----END PGP SIGNATURE-----

1 0

Mixmaster and remailers
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

Here is a text version of an essay on Mixmaster and remailers in general. I am going to try to put this in HTML and stick it on my home page. If you want the original Mac version (distributed at today's San Diego Cypherpunks meeting) let me know (Word 5.0). The list software has been balking when I try to post in MIME encoded. The figures will be in the HTML, and are in the Mac version. -------------------------------- **Cypherpunk remailers. The structure of current remailer messages is a nested set of encrypted messages. Each message is encrypted to a remailer. The message contains the instructions for each remailer (such as where to send the message next) and the message to be forwarded. Each remailer removes a layer of encryption, and accompanying instructions, takes any requested actions, and sends the message on to the next destination. Figure 1 The figure above graphically represents a message that will be sent through 3 remailers (A,B,C) and finally to Bob. The boxes represent encryption, with the name of the person to whom the message is encrypted is outside the upper left corner of the box. One important fact is immediately clear from this diagram; the message shrinks after each hop. Cypherpunk remailers do several things: Send a message to another email address or post it to a new group. Accepts encrypted messages with instructions for processing hidden inside the encrypted envelope. Strip of all (or at least some) mail headers. Add new headers (like subject lines). Remove some information from the end of the message. Encrypt part of the message using a key specified in the message. Some but not all remailers can also do the following: Hold messages for some fixed or random time (latency). Reorder messages keeping a fixed minimum number in the remailer at all times. **Attacks on Cypherpunk remailers. Since anonymous remailers are designed to prevent traffic analysis, the best way to understand their weaknesses is to study various attacks that an opponent might use against them. I will assume a very powerful opponent, both to present a worst case scenario, and because it is possible to resist these attacks using second generation remailers. *Threat model. I assume that an attacker is able to record the contents of all messages into and out of all remailers, along with the times they arrive and depart. All messages are monitored as they leave the sender's machine, and as they arrive at the destination. The attacker is able to send an unlimited number of messages through the remailers, including previously intercepted messages. Messages can also be prevented from arriving at their destinations (denial of service). The attacker has compromised some (but not all) of the remailers, and knows the source, destination, and contents of all messages passing through the compromised remailers. This set of attacker abilities and resources is the threat model. *Trivial Attacks. >From the threat model it is prima facie obvious that unencrypted messages can be tracked, so I will consider only encrypted communications. The use of only one remailer is also insecure. If that remailer is compromised, you have no security because the operator knows both the originating and final addresses. *Reordering. Chains of remailers with encryption are better, but still vulnerable. Messages can be traced through these remailers, because incoming messages are forwarded directly after processing. When a message arrives, another leaves immediately. With no further information the attacker knows that these are the same message despite any precautions that may have been taken. This can even be done retroactively using mail logs (if those are kept). This is the biggest problem with standard Cypherpunk remailers. The first fix proposed was to delay incoming messages for some random length of time. If this time were longer than the time between message arrivals, then it would be impossible to know (with certainty) which incoming message corresponded to which outgoing message. This proposal Is weak in several respects. The exact amount of protection provided by latency is unknown. It depends on the traffic through the remailer at that time. If there are many messages arriving in the average holding time, then the identity of the message is reasonably well disguised, but if there is very little traffic (due to normal fluctuations, network outages, or denial of service attacks) then little or no protection is provided. To provide some minimum level of protection, considering only normal traffic variations, the latency must be much larger than it would have to be at times maximum traffic. Although reordering solves this problem, it also opens up another possible attack. Reordering always involves keeping some number of messages in the remailer at all times. These messages are called the message "pool." The most efficient reordering scheme is to keep N messages in the pool, and to send out one of the (N+1) messages in the pool (including the one that just arrived) chosen at random. Unfortunately this scheme is susceptible to a "spam" attack. An attacker sends many more than N messages to the remailer. These messages will displace all the real messages in the pool, leaving only messages which the attacker can recognize.If many more than N messages are sent to a remailer then the its pool of messages will contain only planted messages (which can be recognized). If the attacker sends another batch of messages after your message arrives, your message will be flushed back out of the pool. Since the attacker can recognize his own message, yours will be obvious. Combining latency and reordering gives some resistance to this attack. Rather than sending out one message from the pool each time a new message arrives, periodically all but N messages in the pool are sent. If, during an average period, several real messages have arrived then even if the pool of messages if flushed out, there will be more than just your message mixed in with the attacker's messages. If the attacker combines the spam with a denial of service attack, then your message would be the only non-attacker message again. There is nothing you can do if the attacker can ensure that yours is the only message traversing the entire network of remailers. With ideal remailers your message could be any one of the messages passing through any remailer at the same time. If yours is the only message passing through the remailer network, then you are toast. *Size & Distinguishability. Suppose now that your message is chained through remailers that are delaying and reordering at every hop. Your messages can still be tracked by size. By default messages decreases in size by a small (and approximately known) amount at each hop. Even if your message is well mixed with the other messages in the remailer, and even if they are all different sizes, they are still distinguishable. It is possible to have the remailer remove padding from the message at each hop, but this only to decreases the size of the message, and only to a minimum established by the size of the actual message you want to send. You are also limited by the fact that extremely large messages will stand out, since your message must change size by a large fraction of its own size at each hop to ensure maximum confusion. While removing padding at each step makes traffic analysis much more difficult, it does leak information. All messages that leave a remailer larger than your message was when it arrived are known not to be yours, and if the use of this feature is unusual, then your message will stand out as being the only one to change size by a nonstandard amount. The solution is clear; All messages should be exactly the same size. *Replay attacks Unfortunately reordered, indistinguishable messages, can still be tracked. This attack can be used to follow a message to its final destination, or to backtrack from the end to the original sender. Both of these techniques use a type of spam attack. To trace a message forward through the chain of remailers, the attacker captures your message and sends many copies of it to the first remailer. Many identical messages will then emerge from the remailer and move on to the next remailer. This bump in remailer traffic will show the rout of the message. When it becomes too dispersed from reordering, the message can be captured between two remailers, and many copies re-introduced at that point. To prevent this attack remailers must refuse to send any message more than once. This can be done by including a random ID number for each hop, which the remailer records. Unfortunately this places large storage demands on the remailer, but the impact can be limited if old IDs are removed from the list, or the remailer's key is changed periodically (at which point the list can be cleared). A better solution is to require anonymous ecash postage in each layer. If the message is resent, then the cash has been doubly spent, and the remailer would refuse to send it. This also has the benefit of making spams expensive, and of motivating remailer operators to provide superior services. **Mixmaster. The only type 2 remailer is Mixmaster. Its design philosophy is strongly influenced by Chaum's paper on digital mixes (the origin of its name). Below is a diagram of the structure of a Mixmaster packet. Rather than 4 there are actually 20 headers. Messages are sent as one or more packets (messages consisting of multiple packets are called multi-part messages). Figure 2 When remailer A gets this message, it will decrypt the PGP encrypted packet at the top, and check to see if it has seen the ID number before. If so, the message is discarded. The first header (before decryption) is added to the end of the list of headers, and all the others are shifted up one. All headers and the body packet (the section at the end with the text to be sent) are decrypted with the IDEA key in the header. This reveals a PGP encrypted header for the next remailer at the top, and obscures the old top header (now at the bottom of the stack). The header for the last remailer in the chain contains a flag indicating that it is the last hop, and if it is part of a multipart message. If this packet contains the entire message (it is not a multi-part message), the body is decrypted and the plain text is placed in the reordering pool, ready to be sent on. If it is only one part of the message, the Message ID number is used to identify the other parts as they arrive. When all the parts have arrived the message is reassembled, and placed in the pool. If not all parts arrive within some time limit, then the message is discarded. Only the last remailer in the chain can see that a group of remailer packets are all part of a single message. To all the others, they are completely independent. All Mixmaster packets are exactly the same length, and all bits are encrypted with an IDEA key at every hop, so no information about the identity of the message is visible to the observer. Even a compromised remailer can only know the previous and next locations in the chain. It can not know how many hops have preceded it, or how many will follow (unless it is the final hop). These messages are rather large. Each of the 20 headers are 512 bytes, and the body is 10k. The plain text is compressed to minimize the need for multipart messages, which offer somewhat less security because all parts follow the same chain of remailers. *Future features In the near future the Mixmaster user front end will allow the individual packets of a multipart message to be routed independently. Mixmaster remailers that indicate that they can accept socket connections will exchange messages directly. The messages will be superencrypted with an IDEA key derived from a Diffie-Hellman key exchange. This provides forward security against remailer operators being asked to decrypt intercepted messages. **Nothing is perfect. Even if you are using a perfect network of remailers, you can still be tracked. Only so many messages pass through the network of remailers in any given day. If Alice sending a message usualy correlates with Bob receiving a message, it is likely that she is sending messages to him. This was discussed in some detail in several messages by Hal and Louis Cypher. One defense is to send dummy messages in to the remailer "bramble" so your messages correlate with everything. These must be sent at random times so that your real messages do not stand out. -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Home of "chain" the remailer chaining script. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

Re: link encryption and anonymous interactivity (Was: "Subway" remai
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >This gives me an idea. Imagine a server that allows you to open a >low bandwidth (let's say around 100 cps, in order to reduce costs) >link-encrypted telnet session with it, and provides you with a number >of services, for example a link-encrypted talk session with another >user. You'll need to maintain the link 24 hours a day to defend >against statistical analysis, and of course you can chain a number of >these servers together in a way similiar to chaining remailers. > >This scheme seems to provide untracibility while getting around the >latency cost problem of remailers, thus allowing users to talk to each >other in real time, anonymously. > >Wei Dai > I like this. One complication comes to mind with chaining. You can not set up the whole chain at once. That would give it all away. In some sense you are only mixed with other people who build these "chain links" at the same time. Since you are only likely to build one or two (once built there is no reason to take it down), you want to build it very slowly to allow many links to be built out of the machine you are connected to before you build your link out the next machine in the chain. Also, if other people take their chains down, you must too, or I suspect that there will be some information pointing to the only chain not to have changed (this would only be statistical). I am not so sure about this last argument though. -Lance Cottrell -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLyi3R1Vkk3dax7hlAQFKnQP9FMKTQ+mEmICIPNXOasd2O/SDy4B4yJtv uMX1AcS8jYSoDLUqf1+j6yGj3NW++5sr/6qNE5+DXpOpc3c3plCoiFIRSL8Ir4dw WmW9J2GBtz5pJEjWWnlCfeqvDnaHmleCDnaGv6vo3+sZJrxn/NpUEoHiduLn+yg8 poIBFxw8B6Y= =2X/2 -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Home of "chain" the remailer chaining script. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

Re: Even more unix holy war. Was "Clinton freezes U.S. assets .."
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- Do you have any sort of life whatsoever, James? Writing a gazillion K of flamage on your hot-button topic du jour, especially when you keep lying about wanting to end the thread, is a total waste of your time, esp. if you believe people will read the spew. (I'm half believing that you're going to call me a collectivist because I imply that one writes so that others will read). I've simply never heard of anybody caring. - - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus(a)hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLyiAKhNhgovrPB7dAQFRJAQAkGwvDaHc6FbNsZXglVOuH0I6b79MLqaN cI0rPN2xIwC8w+/cL/jFNaFZDlp4/V1/AZARQaFpY+MMuLsFMBL20c1jAfws/qXO EVFKEWNlRPDo1D85fxvNwT36J+YsLc+PB5ewWlR6AYysh+QBYzZOUhUXJsAo+Lka Kn1PAKFDiZM= =lPZy - -----END PGP SIGNATURE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLyi47yoZzwIn1bdtAQFmWwF/UuqPF693wVp6GlI/mkKypPkyyB8thivm WePmowpndywBGGVhtWiVMcZWzqDGEFo2 =Npk+ -----END PGP SIGNATURE-----

1 0