December 2003 - cypherpunks-legacy

Diogeneseses
by dance＠cicero.spc.uchicago.edu 17 Dec '03

17 Dec '03

>It's probably not all that surprising that we have a plethora of >Diogeneseseses, considering the role "he" played in _Ender's Game._ >Pr0duct C1pher (sp?), on the other hand, probably won't ever have a 'nym >conflict. _Ender's Game_ you say? Hmm. I simply assumed that we had a plethora of Diogeneses because Diogenes was a kick-ass Cynic. This has *nothing* to do with cipher. Cynicpunks anyone? Hmm. _/_/_/ _/_/_/ _/_/_/ _/ _/ All men recognize the right of _/ _/ _/ _/ _/_/ _/ revolution; that is, the right _/_/_/ _/ _/ _/_/_/ _/ _/ _/ to refuse allegiance to, and to _/ _/ _/ _/ _/_/_/_/ _/ resist, the government, when its _/_/_/ _/_/_/ _/_/_/ _/ _/ _/_/_/ tyranny or its inefficiency are _/ great and unendurable. --Thoreau, Civil Disobedience

1 0

cfs & remailers
by allan＠elvis.tamu.edu 17 Dec '03

17 Dec '03

Has anyone considered using a CFS directory (or directories) for a remailer's files, spool, etc? Any thoughts about such security measures? -- Allan Bailey, allan(a)elvis.tamu.edu | "Freedom is not free." Infinite Diversity in Infinite Combinations | allan.bailey(a)tamu.edu Esperanto: MondLingvo, lingvo internacia.

4 5

First Virtual
by L. Todd Masco 17 Dec '03

17 Dec '03

Does anybody know anything about a new company named "First Virtual"? I know they got NSB from BellCore and a couple of other researchers. -- L. Todd Masco | "Cowboy politicians sucking up to the aristocracy, not cactus(a)bb.com | even sure if they like democracy..." - TR-I

1 0

Re: First Virtual
by Jef Poskanzer 17 Dec '03

17 Dec '03

>Does anybody know anything about a new company named "First Virtual"? I > know they got NSB from BellCore and a couple of other researchers. % whois first | egrep -i virtual First Virtual Corporation (FVC-DOM) FVC.COM First Virtual Corporation (NET-FVC) FVC 199.181.72.0 First Virtual Holdings Inc. (NET-FV-NET) FV-NET 199.171.113.0 First Virtual Holdings, Inc. (FV-DOM) FV.COM First Virtual Holdings, Inc. (THECARD-DOM) THECARD.COM First Virtual Holdings, Inc. (CARD-DOM) CARD.COM % whois fvc.com First Virtual Corporation (FVC-DOM) 3393 Octavius Drive, Suite 102 Santa Clara, CA 95054 Domain Name: FVC.COM Administrative Contact, Technical Contact, Zone Contact: Gallmeister, Bill (BG43) postmaster(a)FVC.COM (408) 738-2220 Record last updated on 22-Apr-94. Domain servers in listed order: NS1.SVC.PORTAL.COM 156.151.6.20 UUCP-GW-1.PA.DEC.COM 16.1.0.18 UUCP-GW-2.PA.DEC.COM 16.1.0.19 % whois fv.com First Virtual Holdings, Inc. (FV-DOM) POB 3627 Rancho Santa Fe, CA 92067-3627 Domain Name: FV.COM Administrative Contact: Stein, Lee (LS48) leestein(a)SCRIPPS.EDU 1 619 759 9300 Technical Contact, Zone Contact: Rose, Marshall T. (MTR) mrose(a)DBC.MTVIEW.CA.US (415) 968-1052 Record last updated on 19-Mar-94. Domain servers in listed order: DBC.MTVIEW.CA.US 192.103.140.1 TRYSTERO.RADIO.COM 192.101.98.3

1 0

Re: cfs & remailers
by markh＠wimsey.bc.ca 17 Dec '03

17 Dec '03

> Another potential problem with sendmail->cfs interaction is that > CFS doesn't implement NFS file locking. This isn't much of an issue with > a single host and a single instance of CFS, but could be a problem if the > mailboxes are read and written by other machines or are remotely mounted > by the machine running sendmail. Some versions of sendmail support "dot locking", which effectively does away with this problem. Mark

1 0

Zimmermann debate with NSA on 8/25
by Philip Zimmermann 17 Dec '03

17 Dec '03

Subject: Zimmermann/NSA debate in California There will be a debate between Philip Zimmermann and Clinton Brooks of the National Security Agency, on Thursday, 25 August, at 5:45pm Pacific Time, in Thousand Oaks, California. The debate is organized by the World Affairs Council, and will be held at the Thousand Oaks Inn, at 75 Thousand Oaks Blvd. To get there, take Highway 101 north from LA to the Moorpark exit, turn right onto Moorpark, left at first light, one block down on right side. The debate will be on the issues of crime, terrorism, privacy and civil liberties on the information superhighway, and the role of cryptography in these issues. Philip Zimmermann is the creator of Pretty Good Privacy (PGP), the most widely used software in the world for E-mail encryption. Zimmermann is under criminal investigation for publishing free encryption software, resulting in its widespread use around the world, allegedly in violation of US export restrictions on encryption software. Clinton Brooks is assistant to the director of the NSA, and was instrumental in the creation of the controversial Clipper Chip and the Escrowed Encryption Standard. There will be cocktails and a light buffet at 5:45, and the program will start at 6:30. Admission is $15 if you preregister, or $25 at the door. Preregistration can be done by mailing a check, or by credit card via phone or fax, to: World Affairs Council 1051 Calle Yucca Thousand Oaks, CA 91360 or call 805 498-6312 or fax 805 532-1306 (include credit card number, expiration date, and event) This announcement may be widely distributed.

1 0

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

17 Dec '03

> > What I think is a better idea was proposed here last year, and I think > > someone was doing it for a while. It is for someone to volunteer to > > be the keeper of the remailer aliveness information. He runs scripts > > every day to ping the remailers, keeps lists of which remailers are > > currently active, and so on. > > This does seem like a better idea, except for one thing: > Everybody has got to trust the Keeper of the Aliveness Info. > I'm not sure how much of a problem this is, nor am I sure that > the newsgroup method neccesitates any less trust. A major problem with having a single-point aliveness-info source is that watching traffic to that source gives you some idea who's about to send anonymous messages - multiple sources mean there are N sources to wiretap to get the same information, which may be nearly as bad. On the other hand, a broadcast method like a usenet group has the advantage that you can read the newsgroup without being very obvious, except locally. A mailing list is somewhere in between. Similar problems occur with anonymous single remailers in the absence of good reordering; many new remailer users, or users of unreliable remailers precede their real anonymous messages with a ping of some sort, such as a message through the remailer chain pointing back to themselves. If you're using a news reader without NNTP, or with NNTP only for the local non-tapped LAN, you may be ok. Another alternative are mailing lists (NOT human-readable ones like cypherpunks) which reforward the remailer newsgroup information, preferably encrypted. Newsgroups are obviously easy to inject bogus information into, but that's the way it goes; any non-trusted system is, well, non-trusted.... Bill

1 0

Statistics on remail message sizes
by Hal 17 Dec '03

17 Dec '03

A couple of weeks ago Eric asked for statistical information on remailer message sizes. I put in a size-counter a week ago (just piping each message into wc >> remail2/SIZE.REMAIL) or so, and here are some results. They show 645 messages logged, a sample of what the logs look like, the average size of a message in characters (counting the header) of about 15K, and a histogram of message sizes rounded to the nearest 1000. Note that the histogram is pretty irregular, possibly being affected by repeated sending of certain messages. jobe% wc remail2/SIZE.REMAIL 645 1935 16125 remail2/SIZE.REMAIL jobe% tail remail2/SIZE.REMAIL 58 189 3225 16 90 850 18 121 1016 14 90 896 23 140 1350 653 803 41937 710 860 45666 710 860 45642 20 96 901 28 146 1344 jobe% awk '{sum=sum+$3} END{print sum/NR}' < remail2/SIZE.REMAIL 14794.4 jobe% < remail2/SIZE.REMAIL awk '{print int(($3+500)/1000)*1000}' | sort -n | uniq -c 229 1000 82 2000 50 3000 21 4000 3 5000 45 6000 9 7000 1 8000 1 9000 3 10000 2 11000 1 12000 2 13000 5 14000 3 16000 3 17000 2 18000 1 19000 2 21000 3 23000 1 24000 2 25000 2 26000 2 27000 1 28000 1 30000 1 31000 1 32000 39 34000 37 35000 1 37000 2 38000 2 42000 2 46000 1 48000 1 49000 1 50000 1 51000 1 55000 9 59000 69 60000 I did one other test, which was to see which message sizes were repeated the most. The first number shows the number of lines which have messages of exactly the second number of bytes: jobe% < remail2/SIZE.REMAIL awk '{print }' | sort -n | uniq -c | sort -nr | sed 20q > times2 40 896 40 1350 20 5797 14 1344 11 33845 11 1242 10 892 9 33992 9 1248 8 1753 7 33975 5 1765 5 1757 5 1236 4 901 4 1749 4 1251 3 59725 3 59668 3 5945 It is clear that there is a lot of repetition, probably standard ping messages and the like. This should give enough info to discard the highly repeated sets from the histogram above in order to get a possibly more representative set of numbers. Hal

3 2

RE: cfs & remailers
by Anonymous User 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Bill O'Hanlon <wmo(a)digibd.com> wrote: > In that case, even if I were to keep logs, all that anyone would know from > a message is that a particular user used a remailer, or that a particular > cleartext message had a certain remailer as its jumpoff point. Not both. > (Unless, of course, I'm in collusion with other remailer operators. But > that'salso a non-code issue.) Collusion wouldn't be necessary. If an interested party, such as a "TLA" were to follow the chain backwards, seizing the logs at each successive link, they could eventually find the originator of the message. (This assumes that the logs were detailed enough to record each incoming and outgoing message, and match them up.) > My personal situation is, I run a remailer on a home Unix machine > via a phone line UUCP feed. I am the only user of this machine, > so I do not have to defend against users with local access. My > efforts are intended to block the following foes: my service > provider and any node upstream of it, thieves/misguided law > enforcement types, and phone taps. Encrypting something that I > receive in the clear over an insecure line isn't useful. It is useful against after-the-fact snooping. If they're monitoring you in advance, then no, it wouldn't be of much help. But let's say that someone were to anonymously post a portion of the classified Clipper algorithm to Usenet, with an indication that the rest was to follow in multiple installments. There would be a very strong incentive for some TLA to attempt to trace and arrest this individual before the algorithm was further compromised, even if full-time monitoring of remailers wasn't already on their agenda. If logs were not kept, or were securely destroyed often enough, then by the time the message came out in the clear, the data needed to trace through the early links in the chain would already be gone. -- "Diogenes II" -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLlLAQuRsd2rRFQ1JAQGutgQAmejmA2jS70yGUxT3dJrUnAkshdN28RHy 6pcndcbDsb7Ink4h0eAUMnGN7jxIok+1ltZQK4Lo+nFWCnerAmWd0mT5KihxkRb7 Yyl0cxYqpjD53uTHMZoIS7wyOy9SYPDX3qyNjzo4N6L5KQ1OaksZ+6kUAxVh07cO UqhmI61ZUjE= =R4sg -----END PGP SIGNATURE-----

1 0

Zimmermann on PGP 2.6 myths
by Philip Zimmermann 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- To: All Users of PGP From: Philip Zimmermann, creator of PGP Re: Misconceptions about PGP 2.6 from MIT Date: 18 Aug 94 I'd like to clear up some widely held misconceptions about PGP version 2.6 from MIT. I get a lot of email and phone calls from people who report a lot of misinformation on many Internet newsgroups about this MIT version of PGP. (For those of you who need an introduction to Pretty Good Privacy (PGP), it is a free software package that encrypts email. PGP is the worldwide defacto standard for email encryption. It's available via FTP from net-dist.mit.edu, in the pub/PGP directory. But then, if you haven't heard of PGP, you don't need to read this letter.) Here is a list of misconceptions: Myth #1: PGP 2.6 is incompatible with previous versions. Myth #2: PGP 2.6 is weaker than previous versions, with a back door. Myth #3: PGP 2.6 was released without Zimmermann's cooperation. All of these misconceptions would be cleared up if you read the PGP User's Guide that comes with PGP 2.6, but a lot of people seem to be spreading and believing these myths without looking into the matter empirically and getting the new PGP and reading the manual. Let's go over these myths in detail. - --------------------------------------------------------- Myth #1: PGP 2.6 is incompatible with previous versions. - --------------------------------------------------------- This is untrue. PGP 2.6 will ALWAYS be able to read stuff from earlier versions. PGP version 2.6 can read anything produced by versions 2.3, 2.3a, 2.4, or 2.5. However, because of a negotiated agreement between MIT and RSA Data Security, PGP 2.6 will change its behavior slightly on 1 September 1994, triggered by a built-in software timer. On that date, version 2.6 will start producing a new and slightly different data format for messages, signatures and keys. PGP 2.6 will still be able to read and process messages, signatures, and keys produced under the old format, but it will generate the new format. This change is intended to discourage people from continuing to use the older (2.3a and earlier) versions of PGP, which Public Key Partners contends infringes its RSA patent (see the section on Legal Issues). PGP 2.4, distributed by Viacrypt (see the section Where to Get a Commercial Version of PGP) avoids infringement through Viacrypt's license arrangement with Public Key Partners. PGP 2.5 and 2.6 avoid infringement by using the RSAREF(TM) Cryptographic Toolkit, under license from RSA Data Security, Inc. According to ViaCrypt, which sells a commercial version of PGP, ViaCrypt PGP will evolve to maintain interoperability with new freeware versions of PGP, beginning with ViaCrypt PGP 2.7. It appears that PGP 2.6 has spread to Europe, despite the best efforts of MIT and myself to prevent its export. Since Europeans now seem to be using version 2.6 in Europe, they will have no problems maintaining compatability with the Americans. Outside the United States, the RSA patent is not in force, so PGP users there are free to use implementations of PGP that do not rely on RSAREF and its restrictions. Canadians may use PGP without using RSAREF, and there are legal ways to export PGP to Canada. In environments where RSAREF is not required, it is possible to recompile the same PGP source code to perform the RSA calculations without using the RSAREF library, and re-release it under the identical licensing terms as the current standard freeware PGP release, but without the RSAREF-specific restrictions. The licensing restrictions imposed by my agreement with ViaCrypt apply only inside the USA and Canada. It seems likely that any versions of PGP prepared outside the US will follow the new format, whose detailed description is available from MIT. If everyone upgrades before September 1994, no one will experience any discontinuity in interoperability. Some people are attracted to PGP because it appeals to their rebellious nature, and this also makes them resent anything that smacks of "giving in" to authority. So they want to somehow circumvent this change in PGP. Even though the change doesn't hurt them at all. I'd like to urge them to think this one through, and see that there is absolutely no good reason to try to get around it. This new version is not "crippled" -- in fact, it is the old versions that are now crippled. I hope that PGP's "legalization" does not undermine its popularity. This format change beginning with 2.6 is similar to the process that naturally happens when new features are added, causing older versions of PGP to be unable to read stuff from the newer PGP, while the newer version can still read the old stuff. All software evolves this way. The only difference is that this is a "legal upgrade", instead of a technical one. It's a worthwhile change, if it can achieve peace in our time. Future versions of PGP now under development will have really cool new features, some of which can only be implemented if there are new data format changes to support them. Like 2.6, the newer versions will still read the older stuff, but will generate new stuff that the old versions can't read. Anyone who clings to the old versions, just to be rebellious, will miss out on these cool new features. There is a another change that effects interoperability with earlier versions of PGP. Unfortunately, due to data format limitations imposed by RSAREF, PGP 2.5 and 2.6 cannot interpret any messages or signatures made with PGP version 2.2 or earlier. Since we had no choice but to use the new data formats, because of the legal requirement to switch to RSAREF, we can't do anything about this problem for now. Not many people are still using version 2.2 or older, so it won't hurt much. Beginning with version 2.4 (which was ViaCrypt's first version) through at least 2.6, PGP does not allow you to generate RSA keys bigger than 1024 bits. The upper limit was always intended to be 1024 bits -- there had to be some kind of upper limit, for performance and interoperability reasons. But because of a bug in earlier versions of PGP, it was possible to generate keys larger than 1024 bits. These larger keys caused interoperability problems between different older versions of PGP that used different arithmetic algorithms with different native word sizes. On some platforms, PGP choked on the larger keys. In addition to these older key size problems, the 1024-bit limit is now enforced by RSAREF. A 1024-bit key is very likely to be well out of reach of attacks by major governments. In some future version, PGP will support bigger keys. This will require a carefully phased software release approach, with a new release that accepts larger keys, but still only generates 1024-bit keys, then a later release that generates larger keys. - --------------------------------------------------------------------- Myth #2: PGP 2.6 is weaker than previous versions, with a back door. - --------------------------------------------------------------------- This is not true. I would not allow MIT or anyone else to weaken PGP or put a back door in. Anyone who knows me will tell you that. This is not to say that PGP doesn't have any bugs. All versions have had bugs. But PGP 2.6 has no known bugs that have any net effect on security. And MIT should be releasing a bug-fixed version of PGP 2.6 Real Soon Now. - ---------------------------------------------------------------- Myth #3: PGP 2.6 was released without Zimmermann's cooperation. - ---------------------------------------------------------------- Well, that's not true, either. Or I wouldn't be telling you all this. MIT did not steal PGP from me. This was a joint venture by MIT and myself, to solve PGP's legal problems. It took a lot of manuevering by me and my lawyers and by my friends at MIT and MIT's lawyers to pull this off. It worked. We should all be glad this came off the way it did. This is a major advance in our efforts to chip away at the formidable legal and political obstacles placed in front of PGP; we will continue to chip away at the remaining obstacles. I hope this clears up the myths about PGP 2.6. I urge all PGP users to upgrade to the new version before September. And I urge you all to use the official 2.6 release, not anyone else's incompatible bastardized mutant strain of PGP. Please pass the word around, and help dispel these misguided rumors. This letter may be (and should be) quickly reposted to BBS's and all appropriate newsgroups. --Philip Zimmermann -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLlL/iWV5hLjHqWbdAQFV7AP/VBSa9BiRfTuoBonJdkwTVC8fNGW8aI7n QctOh+GrDaGl26rqtRjxtYTabAo+4B+sw6Dqz5o1OipKF/NuK7PFMzITdGMh940+ MXqOPCSLfDIwNzRzIHYQV/93jeJsixFZu/6j76mMxB6xrETXmswxIRicwm/QUxC1 0jbZEBrb/ug= =u7IY -----END PGP SIGNATURE-----

1 0