December 2003 - cypherpunks-legacy

pgp content type RFC
by Andrew Lowenstern 17 Dec '03

17 Dec '03

Could someone please provide me with the number of the MIME PGP content-type RFC? thanks! andrew

2 1

Re: CERT statement
by Marc Horowitz 17 Dec '03

17 Dec '03

>> What we need to concentrate on is secure systems that are not vulnerable >> to IP spoofing, as opposed to firewalls. You're exactly right. However, getting people to deploy real security systems is nearly impossible. My company sells a kerberos system, and although everyone is saying they want security, nobody really understands what this means, and as soon as we tell them that it actually involves effort, they become far less interested. Even though I've seen companies get hosed because of lame security, the people who matter aren't willing to commit. I'm hoping that as firewalls begin to fall, that the CERT will stop recommending half-assed solutions. We'll have to wait and see. Marc

4 8

"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

Re: Win NT security
by Andrew K Bressen 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >> Kevin Phaup, program manager lead of Microsoft's Business Systems >>Division, put the best spin he could on this first major Windows NT >>shortcoming. ``Pull the data into a database and then massage it,'' he said. >>``We have a new product - System Management Server from the Back Office >>Suite - that could help.'' >> I agree, but why would I want to buy a brand-new operating system that >>needs help out of the box? Because there aren't any that do not. OS/2 1.x and 2.x had no performance monitoring tools, Windows 3.1 and 3.11 didn't initially come with TCP/IP, Mac owners for the longest time had to buy suitcase and still buy ramdoubler, VMS doesn't support RAID out of the box... systems and utility software has been with us for a long time, and will be for a while yet. At one facility where I work (an NYC brokerage) we run at least 200 users each on ultrix, VMS, NT 3.5, WFW 3.11, Windows 3.1, and VM/CMS, and have about ten OS/2 1.3 servers as well. NT users require less help with networking than dos users, more than unix users. Backup is easier with NT than dos, but harder than VMS. RAID is easier than with VMS or unix, but multiple redundantly clustered systems aren't available for NT. Systems management is slightly harder than VMS or unix, but much easier than WFW. NT crashes more than VM/CMS, but less than ultrix 4.2 did and much less than dos windows does. >> What's more, the third-party database solution for security administration >>is a hopeless short-term patch. To be truly effective, it needs a much >>tighter integration with Windows NT's APIs to permit not only systemic >>analysis, but also systemic security changes based on selected criteria. huh? you just specced out what it needs to work; I don't see why this would be a problem for symantec or some similar firm to deliver. The API is published and fairly stable, NT users just have to wait for someone to actually do it. >> If administrators want to change the access rights of every user so they >>can log on at 7 a.m. instead of 8 a.m., they cannot do it with Windows NT >>3.5. They might be able to do it with a third-party product or with Windows >>NT 4.0. they can't do it with unix either without coding some, and with dos windows you can just forget about it. >> ``If someone builds an administration product like that, they'll make a >>lot of money,'' Phaup says. yep. so what makes you say that it is "hopeless"? >> A WEEKEND'S WORK Windows NT has other security problems, as well. For >>example, it does not have data cryptography, which is essential to make sure >>a network is reasonably secure from eavesdropping and integrity breaches. um, what OS does, out of the box? especially in a 1.5 release... heck, I'm not aware of any networkable OS that has end-to-end link and application level encryption, file acl's, and a key management scheme that can be both centrally and distributedly administered. Kerberos and AFS both make a start in these directions, but are not there yet. >>Microsoft, which knows encryption technology, easily could have included the >>appropriate algorithms in software to make Windows NT more secure. please to define easily? the NT 3.5 release slipped enough as it was. >> Microsoft's Phaup agrees it would have been simple to add encryption to >>Windows NT. ``The hooks are all there,'' he said. so are the hooks for UFS support, and for WINS-DNS integration. the os has more hooks than a football field covered in velcro. so what? >> But Windows NT does not need cryptography for C2 certification. And >>perhaps even more telling, Microsoft cannot export cryptography outside the >>U.S. due to export control laws that prohibit it from doing so without >>licensing. Of course, the company could have made two versions of Windows >>NT: one with crytography for domestic use and one without cryptography for >>export. >> >> According to Phaup, Microsoft was reluctant to do so for two reasons. >>``Security is way down on the list of corporate concerns and desires and >>wants in an OS. It's in the top 20, but not the top 3,'' he says. ``And the >>testing cycle would have been a double killer.'' summary: consumers aren't demanding security and it would cost time and money to put it in, so we didn't make it a priority, but we did leave hooks for it. so why are you villifying them? overall, this sounds pretty reasonable. >> Windows NT's last major shortcoming lays in the omission of a feature that >>most security experts consider virtually indispensable: boot control. um, which security experts would these be? I sure don't consider the absence of boot control on my 400 VMS and unix workstations to be much of a concern... >> In the DOS/Windows world, third-party PC security is reasonably attempted >>by forcing users to boot from the C drive and making them log on with IDs >>and passwords. And NT does this. >>... However, if a bootable DOS diskette is inserted in the A >>drive, the PC will boot without a logon, and the A:> will appear. >> >> But if the user attempts to log over to the C drive, the system will come >>back with a message such as: Invalid drive specification. Security experts >>recognize this as an inexpensive technique that will keep out casual >>intruders and nontechnical types. Well, booting off of a DOS diskette in drive A sure won't let you at my NTFS C: drive... though I'm not sure how technical an intruder would have to be to find the users password written down somewhere on their desk, or to try their initials or first name... >> One way to mandate boot control is with a hardware or firmware addition to >>the PC in the form of an add-on card. Or a key lock on the power supply or a passsword lock in the CMOS of the machine, both of which are available from several major hardware vendors, and neither of which cares if the machine is dos, nt, unix, or pick. >> In Windows NT, boot control does not even exist as an option. Huh? The key lock on my DEC PC works just fine, and the CMOS lock on the compaqs here doesn't care what the OS is... >>... Again, this >>suggests that Microsoft's security effort was driven by C2 certification, >>not by security itself. OK, the federal government spends millions of dollars coming up with a security spec for computers that they buy. Microsoft wants to sell the fed NT, so they make sure NT can pass the spec. I fail to see the shortcoming on their part. Out of the box NT is more secure than DOS, Windows, Windows for Workgroups, and most flavors of unix more than two years old. A well administered group of NT machines can be more secure than a poorly administered group of VMS, Novell, or unix systems. It is not the most secure OS ever devised. It sure isn't B2. This doesn't strike me as unreasonable, though we could wish for better. >> Windows NT must evolve quickly to garner a spot in the secure operating >>system arsenal or somehow steal market share from the likes of Novell. It How is Novell more secure or securable than NT? Comparing an OS to a networking system, strikes me as unproductive; people run Novell on servers, not desktops. NT can run a 32 bit API on several 64 bit flavors of hardware, it is multitasking and multithreaded... comparing it to Novell is apples and oranges. If you're comparing Novell+DOS (or DOS/Windows) to NT, then right out of the box, your above statements seem reversed: if the data is on the desktop, and the PC doesn't have extra security hardware, then I can floppy boot the pc and get the data, but I'll need a username and password to get into the NT system. If the data is on the server, then under either system I'll need a username and password. Neither one will stop me from taking the hard drive and sticking into a machine I have control of and getting the data. - --a. k. bressen - --- [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 iQBFAwUBLygs0yoZzwIn1bdtAQG/YQF9EpEzsvQvEDdBnoROxlgAUK0YMrFTR35b FvT1uqcLEqfCo65qJ2qpSmX0SC+Hin5u =eTTq -----END PGP SIGNATURE-----

1 0

Re: Reordering, not Latency (Was: Re: Remailer)
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Andrew Lowenstern asks: > 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? Given the current state of computer security, this should not be too difficult for an organization such as NSA. For each remailer, just hack into a computer on its local ethernet and put it into promiscious mode. Each time an e-mail passes by, have it send the header to some monitoring center using an UDP packet. > 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? Complete monitoring should not be neccessary, having a larger percentage of the traffic just makes the job easier. Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLygz8jl0sXKgdnV5AQFv3wP/USeKOwPBn12m1hC9RPOgwi1Zt4wB+T5J RWM3fYAvpK4gGUB2xOGrSLDh68DNDgSghjwqacBTkEsn+5ENBXd9rrQOjmaMeipI rJuxYSJTiNKhlGro3yY2UW3FScKYks3mi6eJ9G+g5rOOIHqCKtAhkSQJkHeCJOM3 3m2ObHv1gMs= =xmaK -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> Big Bang --> atoms --> complex macromolecules --> biological evolution --> central nervous systems --> social learning --> symbolic communication --> computers --> internetworking --> close-coupled automation --> high-bandwidth brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ?

1 0

link encryption and anonymous interactivity (Was: "Subway" remai
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Adam Shostack writes: > The idea is a very good one, its usually called "link > encryption." The idea is to make it difficult to tell when someone is > using a line by filling that line with random noise that looks like > encrypted data. 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 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLyinajl0sXKgdnV5AQHqMgQAkyA16Ai/s885L68KXFlqsLC6RFU7S8dc +ynRv/LJ1Lp6ZxyBel0sBqXixh3cJDIuZKXOHcUpfir0Wn7ifxgdoj2SvUdHOes+ af9GGZZOvo+hXhzbN/PYUI8AZLVbmqa8ighPUPdXNxA0Fq0ypMn7ZpxhzeW5gPJq mRtK2adKucQ= =alXA -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> Big Bang --> atoms --> complex macromolecules --> biological evolution --> central nervous systems --> social learning --> symbolic communication --> computers --> internetworking --> close-coupled automation --> high-bandwidth brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ?

1 0

Re: Even more unix holy war. Was "Clinton freezes U.S. assets .."
by Bill O'Hanlon 17 Dec '03

17 Dec '03

On Thu, 26 Jan 1995 14:43:39 -0800 (PST) "James A. Donald" wrote: -------- > On Thu, 26 Jan 1995, Perry E. Metzger wrote: > > Unix is perfectly easy to use. Its no worse than DOS. > > Thanks for the entertainment Perry. > (I'm assuming you're being sarcastic.) I had agreed with Perry's statement when I saw it. I've taught classes in both DOS and UNIX. Whenever I've taught people who knew next to nothing about computers, I found people were able to attain a basic "user" sort of skill level in about the same amount of time with about the same difficulty when learning either. If you're going to be snotty and sarcastic, the least you could do is provide a counter-example, to give us something to discuss. After you showed your heinie (IMHO) in your comments about operating system security the other day. I'd think you'd have lost credibility to gain. I mean, I was tempted to make a comment to you much like the one you made to Perry, but I didn't think it was worth the time.

2 1

Traffic monitoring (Was: Reordering, not Latency)
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- eric(a)remailer.net (Eric Hughes) wrote: > If I were doing global Internet monitoring, I wouldn't be doing it > in-band. Too much cooperation by the vendors required; too much > discovery. Rather, I'd gain access to the trunks directly and do my > own demodulation and decoding. How would you get access to the trunks? Aren't they mostly optic fibers now? Also, since Internet traffic is growing at a geometric rate, the probability of anyone or any organization having the capacity to monitor and process ALL of Internet traffic should be very small and decreasing. It would be much easier to install sniffers on selected local networks (e.g., those containing remailers or other entities you're interested in). Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLyirWjl0sXKgdnV5AQG12QP+LXVa/INx3JmwBqmSrZo8kNiteYIG9AwV 9hG+3qUt6/yvkz0v137lPVOGK+J78MkCDVYnPHeBcdYwmZ7Z8mpfaQGaPQnMnj9x Q9z9hbK9JVBYaN7Hpv0OtIobKn2OlEsJjdZxr8mcuqVN/OS1kHarmhtM2pyfxJ/l uY5/UGIlprA= =jIHR -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> Big Bang --> atoms --> complex macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> consciousness --> computers --> internetworking --> close-coupled automation --> high-bandwidth brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ?

2 1

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

17 Dec '03

At 09:10 PM 1/25/95, Michael Handler wrote: > ... 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). The headache with reordering of that sort is that you can't reply to a message until you've seen the message you're replying to. There's a certain level of ordering that can't be changed. --Paul J. Ste. Marie pstemari(a)well.sf.ca.us, pstemari(a)erinet.com

1 0

Re: Win NT security
by Andrew Lowenstern 17 Dec '03

17 Dec '03

> How is Novell more secure or securable than NT? Comparing an OS to > a networking system, strikes me as unproductive; people run Novell > on servers, not desktops. NT can run a 32 bit API on several 64 > bit flavors of hardware, it is multitasking and multithreaded... > comparing it to Novell is apples and oranges. actually, NetWare has a 32-bit API, runs on 64-bit hardware (maybe, they have a SPARC version and may have a PA version, but I haven't kept up), is multitasking and multithreaded. Most people don't think of NetWare as a Real OS(*tm), but it is QUITE robust. You could put it on someones desk, but it doesn't run windows. The main reason it's primarily a server OS is because Novell markets it that way. What is really cool about NetWare that has more cypherpunks relavance than most of this thread is that it has built-in support for single point network logins via RSA authenticated certificates (the inital password exchange is encrypted with RSA as well). This has been a feature for about 2 years now and is, as far as I know, the only major operating system that has native support (at all levels of the OS - not a Unix with kerberos thrown in) for such a thing out of the box. NetWare has a much more sophisticated security system than any Unix I've seen or heard about. My only complaint against Novell here is they think details about the security system are a big secret (such as RSA key lengths and the specific PRNG and hashing algorithms used). Pretty typical corporate mentality at work... While they may use RSA, it is my understanding that Novell in the past has used weak home-grown hashing and encryption algorithms for password storage. andrew

1 0

Even more unix holy war. Was "Clinton freezes U.S. assets .."
by jamesd＠informix.com 17 Dec '03

17 Dec '03

Perry E. Metzger wrote: > > > Unix is perfectly easy to use. Its no worse than DOS. "James A. Donald" says: > > Thanks for the entertainment Perry. Perry E. Metzger wrote: > I see that you have no arguments against my statement... I made no arguments because A: This is not the proper place for such arguments. B: The statement is so flagrantly silly that the proper response is ridicule, not an answer. Bill O'Hanlon wrote: > If you're going to be snotty and sarcastic, the least you > could do is provide a counter-example, to give us something > to discuss. [Childish insults, abuse, and flame bait deleted] Well I did not post examples because other people had been ridiculing unix for me, (but they were too subtle for you to understand), and also because this is not the proper place for such examples. But since you guys insist: Long flame on unix follows. Note that although this flame has nothing to do with cypherpunks it I am discussing unix, not the character and mental abilities of the people I am replying to, unlike the usual posts from Perry and Bill,. Flame on: Perry E. Metzger wrote: > > > Unix is perfectly easy to use. Its no worse than DOS. Bill O'Hanlon wrote: > I had agreed with Perry's statement when I saw it. I've > taught classes in both DOS and UNIX. Whenever I've taught > people who knew next to nothing about computers, I found > people were able to attain a basic "user" sort of skill > level in about the same amount of time with about the same > difficulty when learning either. Perry's statement and yours is true but irrelevant. Why is it that for so long people lived with a make utility that treated tabs differently to blanks. "Hey! My makefile has mysteriously stopped working!" Why is it that scientists still publish in latex? Why is it that so many people are STILL using vi in unix: Because, unless you wish to live in EMACS, it is too hard to get your local unix deities to set stuff up so that you never have to see the accursed vi. If MIS sets up a decent word processor for the secretaries in UNIX or Windows, then the secretaries can do moron work just as easily in either system. In that sense Perry and Bill are perfectly correct. But Unix needs that MIS support to set up the decent word processor and Windows does not. Why do you think all the scientists are publishing their stuff in latex? Do you propose to teach the secretaries latex? Any fool can set up a home network using Windows for Workgroups. I certainly could not set up a home network using Unix, and I doubt that you could either. You probably could do it eventually, but you would spend weeks futzing with the system, you would visit other unix gurus and consult with them, carefully study manuals, copy other peoples configuration files and futz with them, etc. My kid could probably set up windows for workgroups, share the disks and the printer etc, in half an hour, even if he had never seen a PC network before. (Though I would have to install the ethernet cards myself. A few weeks ago MIS replaced everyones Sparc 10s with Sparcstation 20s. It was days before we were functioning again, and for a time I was practically living in my local unix guru's cube. Unix requires a vast sea of arcane obscure knowledge to all kinds of trivial and routine things. Using unix makes everyone dependent on a bunch of gurus in a way that does not happen in DOS. Yes unix can be set up to be great, but it usually is not, and the reason it is not is that IT IS USUALLY TOO HARD EVEN FOR GURUS to do it. (Which is why scientific papers are published using latex.) And when it is finally set up that way, you can only do those things that MIS envisaged you to do, cause if you do what you want to do then the whole damn house of cards comes tumbling down around your ears. For example I have Sun's half assed GUI, which has an almost tolerable editor, similar to Microsofts basic minimum editor, notepad. But a weird file system has been patched on to support source control (Cleartools), and like everything else in unix it sort of half works with the rest of the system, so we have to use vi. Even my unix guru uses vi. And why the hell do I need a unix guru in order to do stuff that dim witted secretaries do easily and routinely in DOS/Windows? And try cut and paste anything except text in Sun's so called GUI. And try to cut and paste *big* amounts of text. And try to fiddle with the background screen etc -- yes it can be done, but it is vastly more difficult and arcane than under Windows. Learning this kind of garbage is exactly like learning Vi. Vi occupies so much brain space that even though I hate and loath it, I find myself typing vi commands in editors that I use vastly more than vi. Exposure to vi has impaired my use of editors I used before vi, editors that are immeasurably superior. People who imagine that vi is a decent editor have suffered brain damage due to exposure to grossly bad tools. They perceive it as easy to use because it has damaged them in the same way as it has damaged me. And why am I using Vi? Well, if unix has lots of wonderful tools available why are lots and lots of people still using the worlds most hated software? Because unless you want to live in EMACS, it is intolerably painful to escape from the clutches of this thoroughly evil editor. Sure MIS *could* set it up so no one need be exposed to the evils of vi. But they do not. Those who imagine that unix is easy to use are suffering from a similar form of brain damage, similar to that caused by vi, but a broader and more serious form. When people talked about teaching secretaries latex, did not you realize they were having a dig at unix? If you did not pick that one up, it shows that unix has already caused extensive brain damage. You must stop your unix habit right now before it is too late. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

2 1

Re: Reordering, not Latency (Was: Re: Remailer)
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> > 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. Effective reordering is the key - as Louis Cypher's article showed, there are forms of reordering which are NOT effective, though the requirement for latency is really a consequence rather than a direct requirement. There are six+ classes of packets that can go through a remailer: 1) Real packets from outside to be remailed to outside. 2) Hostile packets from traffic analysts* outside to outside. 3) Real packets from outside to users on the remailer itself. 4) Real packets from the remailer itself to outside. 5) Cover traffic packets from the remailer to outside. 6) Cover packets from outside friendly remailers. Ingoring categories 3-6 for the moment, the problem with reordering is that the remailer needs to reorder n _real_ packets to get a certain level of security, but can't really tell real packets from hostile ones. If the algorithm is simply to reorder and retransmit batches of n packets, either en masse or in a stream basis as Louis suggests, the analysts can surround each real packet with n hostile packets from known destinations to known destinations and therefore be able to pick out the one real packet on the outbound. The effect of latency L is to provide a reasonable probability that n real packets will have arrived during time L, so the addition of hostile packets does not prevent the mixing between the n real packets. Outbound cover traffic is helpful, but unless it targets the same destinations as the real traffic with some probability, it may not be sufficient to prevent long-term pattern analysis (and cover traffic is mainly useful when sent to other remailers and their co-conspirators; cover traffic sent to a newsgroup or innocent member of the public is generally recognizable as such...) Inbound cover traffic is great, of course - I'm not sure if it totally substitutes for real traffic? Its best use is in systems where real traffic users chain between remailers which also carry cover traffic between them, but there's still some information that can potentially be gleaned about a small** remailer-cloud viewed as a whole by analysts forcing lots of traffic through the cloud, unless the remailers implement adequate reordering models. [* I was going to refer to traffic analysts by the usual term Bad Guys, but someday one of us good guys may want to break into a net run by Bad Guys, so I decided to stay neutral here :-)] [** The current 15-20 remailers are still a relatively small cloud.] Bill

1 0

white noise remailer
by rkmoore＠iol.ie 17 Dec '03

17 Dec '03

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

1 0

Even more unix holy war. Was "Clinton freezes U.S. assets .."
by jamesd＠com.informix.com 17 Dec '03

17 Dec '03

To summarize this thread, and I hope end it. The fans of unix correctly point out that unix can, in principle, be configured to be really nice. Well so can a molten lump of pig iron, in principle, be configured to be something really nice. Out in the real world people do not like dealing with a molten lump of pig iron, and so it is usually not configured to be really nice, which is why we see people editing with vi and publishing with latex. Now sometimes MIS creates a tiny little reserve where things really are really nice, and the secretaries are herded into this little reserve, and within this little reserve everything is almost as nice as windows. (Unless of course you want to cut and paste formatted text and graphics between windows, under the sun OS, but hey, that is an arcane operation that the normal user would never want to do. Right? You cannot really expect MIS to help such special power users can you?) And that is what Bill O'Hanlon meant when he said that for ordinary naive users who had not been exposed to either operating system, unix was no worse than dos. Herd them into the reserve and keep them there, and it is indeed no worse than dos. But the reserve is not really the whole operating system, it is just a little area of safety. And as soon as somebody strolls outside the little reserve to do something that MIS has not specifically planned for and arranged, half a ton of molten pig iron pours down on them, and MIS says: "Hey, don't do that." --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

1 0

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

Even more unix holy war. Was "Clinton freezes U.S. assets .."
by jamesd＠com.informix.com 17 Dec '03

17 Dec '03

I am writing this under sun's unix imitation of Microsoft's and Apples GUI. I am using their almost acceptable ASCII editor. I leave a window open for a long time. Then I attempt close down the window, an operation that I can do in Microsoft Windows with a single double click. In unix I click on the border to bring to popup a menu, carefull drag to the right point on the menu, then release. In addition the menu names are confusing. If you want to minimize a window you have to "close" it. If you want to cause a window to cease to be, you have to "quit" it -- Hey did I not already quit it when I forgot about it and went to do something else. A warning message comes up: I have not saved. I am offered the options of quiting or not quitting. Gee guys, did it never occur to the great unix gurus that at this point the option that the user most likely wants to do is save the file. How come the number one most common option is not in the message box. A thought strikes me. I have set up Microsoft windows with a little icon that allows me to reboot or close down windows with a single double click. What will happen if I attempt to reboot unix. Well the answer is obvious, seeing as unix is made of broken glass with sharp edges everywhere, working on the principle of "You asked for it sucker, you got it, Ha Ha, massive data loss to prove you are no good at unix." So I go to a terminal emulation box (Notice how under unix windows the number running app is terminal emulator, whereas in Microsoft windows people use Windows applications.) I make myself root, and enter my root password. I type sync three times, and then type reboot. And lo, unix reboots. Note that this is substantially more work than double clicking on an icon. Note also that rebooting takes *much* longer than with DOS/Windows. And, as can be predicted from unix basic operating philosophy (Cut the stupid users throat if you can) my open edit windows are cut down *without* any message boxes popping up giving me the option of saving this file before the reboot proceeds. Eventually, at long, long, long, long, long, last, Unix deigns to come back and give me some windows. Naturally the test edits that I did just before rebooting are lost, as I expected from the basic unix cut-the-stupid-suckers-throat philosophy. What I did not expect is that one of the files I *did* want (and saved immediately before rebooting), has not only not kept the changes I made -- the file has completely DISAPPEARED! -- Too bad sucker -- that will teach me -- maybe next time I will type six sync commands before rebooting as a sacrifice to the great God unix in the vain hope that it will spare my data. Or perhaps no number of sync commands could make a difference because some network hiccup postponed the file save, (I was saving to a network drive) so that the file only *appeared* to be saved, but was in reality somewhere on my machine, or somewhere on the network, in unsynced limbo, and my privileges are not such that I can sync the network. Or perhaps it is just another of the many profound mysteries of unix that enable unix gurus to make a living. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

2 1

Even more unix holy war. Was "Clinton freezes U.S. assets .."
by jamesd＠com.informix.com 17 Dec '03

17 Dec '03

And did I mention that "make" used to treat a tab as semanticly different from a space, so that a tab with an invisible space in front of it would result in the makefile failing. Oh yes, I did mention that. Well I guess I will mention it again. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

2 1

Re: LOCKSMITH'S GUILD WANTS L
by doumakes＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- "James A. Donald" <jamesd(a)netcom.com> wrote: > This assumes that governments have the necessary wisdom to tell a bad > architect from a good architect. This does not seem very plausible. > > [snip] > > While universities often issue or refrain from issuing certificates for > corrupt and improper reasons, government supervision on this matter is > unlikely to keep them honest I think you misunderstand the licensing process. The standards for a profession are set by the profession itself. They decide what is an adequate curriculum, for example, and what is an adequate amount of continuing education. They literally write the questions for the licensing exam. They also privately accredit the schools, which is more than adequate to "keep them honest." Then the government administers the exam and issues licenses. The professional associations could do this themselves, making it an entirely private affair, but there remains one function that only government can exert: the government forbids someone without a license from functioning as a professional. In other words, licensing isn't a process of government interference in professions. It's a process of professions seeking governmental imprimateur for their own credentialing process, arguably in the public interest. (YMMV; there may be exceptional professions that just hated the whole idea and were dragged into it kicking and screaming, of which I am unaware.) ObCrypto: It's certainly true that crypto will make it easier to function as a professional without having the credentials. "On the Internet, nobody knows you're a quack." I just see it as something to endure, rather than something to applaud. ______________________________________________________________________ Don Doumakes Finger doumakes(a)netcom.com for PGP public key Foxpro databases built to your specifications. Email me for details. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLygTahtumcu2AjihAQEb7AP8DRfcZJvLZy8mw7jg6wjrjHeNl1IbP5EW h3en/84ENKB2SbmcIXx7TtEl3jGz6bZ2T7JA7Ed3UYC78lq8/QsTgBW41Sh+arbX /j1o6Sot6jYAs5EGiuiD4OoxhRopDMuoZFt9NyRJfTF68jHP1olsjiLwnV0mq3g4 nRUh71wnFmk= =EjEG -----END PGP SIGNATURE-----

2 1

Even more unix holy war. Was "Clinton freezes U.S. assets .."
by jamesd＠com.informix.com 17 Dec '03

17 Dec '03

And did I mention that in DOS you can type rename *.txt *.asc to turn all *.txt files into the corresponding *.asc file but that if in unix you type mv *.txt *.asc not only will it not rename your *.txt files to be *.asc files, but if you have only two *.txt files it will silently destroy the second and issue no warning that anything has gone amiss. Hell, it is only the users data -- stupid user, he can type it in again. And of course I have already mentioned the unix "make" utility. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

3 3

Even more unix holy war. Was "Clinton freezes U.S. assets .."
by jamesd＠com.informix.com 17 Dec '03

17 Dec '03

And did I mention that in DOS you can type: dir filename /s if you suspect that filename is in a subdirectory somewhere and you want the computer to find it for you, but in unix you type: find . -name filename -print but the entertaining thing is that if you type find . -name filename find then merrily goes forth, searches for the file -- which takes an extraordinarily long time, much longer than on my DOS machine, and then, cheerfully throws away what it has found, no warnings, no error message, no explanation. find thinks to itself "Gee, the user asked me to find the file, but he did not tell me to do anything with the information, so, I guess he just wanted me to exercise the network and the hard drive for five minutes or so." And did I mention "curses" You are spared. I will not mention "curses". And did I mention SUID. Well fortunately SUID has already been mentioned by other folk in the "Clinton freezes .." thread. And did I mention that unix has no less than seven families of metasyntactic operators, each of them different from and clashing with the others, that these families follow no logical order of substitution that I can figure out. Yeah, I know, that is what makes the unix shell so powerful. It is remarkably similar to what makes a chainsaw so powerful. It is very good at cutting your fingers off. And once again, I wish to remind you that the unix "make" utility used to treat spaces as semanticly different from tabs. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

3 2

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

Even more unix holy war. Was "Clinton freezes U.S. assets .."
by jamesd＠com.informix.com 17 Dec '03

17 Dec '03

And another vast advantage of DOS Windows is that it is a vastly better environment for developing software than unix. The great strength is of course symbolic debugging -- you can single step your compiled code, and see it displayed symbolicly, with the symbols and statements of your source code, whilst unix programmers are usually reduced to picking through core dumps like grave robbers. You can run your program under the debugger and set it so that when an exception condition occurs, bingo you are in the debugger at the line where the exception occurred, and all the variables as they were when the exception occurred, and the rest of windows, the graphical user interface, has been frozen until you examine the situation to your satisfaction. Try that in Unix. You might be able to do a crude and limited equivalent with a text mode program, but with a GUI program you are hosed. This is the basic reason why unix software sucks -- because the tools for writing it suck. And every unix programmer gets to roll his own user interface, which means that every programmer has to figure out how to roll his own user interface and every programmer does it differently. And windows has the *.rc file system for internationalization. A simple and powerful method for putting everything that needs to be translated in one set of files, and nothing that needs to be translated in the other set. Unix has no equivalent. So every company that needs to internationalize its product hand rolls their own ragged equivalent to to windows *.rc and *.res files, but it cannot be the same because they never hand roll the tools for manipulating and using *.rc and *.res files. Windows has power tools for dealing with this problem. Unix does not. And the power tools that unix does possess not only do not adequately address this problem, they are also likely to cut your hands off. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

3 2

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