December 2003 - cypherpunks-legacy

Metzger, Denninger square off
by Damaged Justice 17 Dec '03

17 Dec '03

[Forwarded from Wired news. Let's cut to the chase: Which side is in the right? Who can tell me, in plain and simple language, who is fighting for individual freedom and property rights, and who is not?] [LINK] Foes Vow to Take Domain Name Fight to FCC by Gene Koprowski 5:01 pm PST 6 Feb 97 - A proposal by the International Ad Hoc Committee (IAHC) to expand the number of Internet top-level domain names is stirring opposition among alternative domain name providers. Opponents call the plan "unenforceable," and are considering filing a protest with the Federal Communications Commission, indicating that the IAHC policy might violate the 1996 Telecommunication Act's open access provisions. "We didn't want to have to get my guns, rifles, and bombs out - but now we have to," Carl Denninger, president of Macro Computer Solutions, Chicago, a long-time opponent of IACH, tells Wired News. "If someone doesn't point a revolver at them, they will be able to do whatever they want to do." On Tuesday, the intergovernmental body issued a proposal to expand the number of generic top-level domains (GTLDs), adding seven new listings in addition to the existing ones, which include the familiar .com, .net, and .org. The new GTLDs would include .firm, for businesses; .store, for retail businesses; .web, for Web-related companies; .arts, for cultural organizations; .rec, for recreation and entertainment facilities; .info, for information services; and .nom, for individuals. Perry Metzger, a member of the IAHC board, said that the organization, whose members include the International Telecommunications Union and the World Intellectual Property Organization, will likely formally approval the proposal very quickly. "This is not a done deal. The paperwork needs to be signed. An association to handle this has to be set up," says Metzger. "But it will go forward very soon. I'm sure plenty of people will not be in favor of it. But the question is: What can they do to stop it?" The answer is plenty, says Denninger. He and others, like Eugene Kashpureff of Alternic, have long fought the IAHC's attempts to expand the number of GTLDs. They think the creation of these new categories may lead to trademark infringement and other intellectual property problems. They also think the new domain names will "fragment" the Internet, leaving some users unable to communicate with others, if a server does not recognize the name request. Denninger said he received a leaked copy of the IACH proposal earlier this week, and he and his colleagues are considering bringing their protests to the FCC. "We're given open access under the telecom law," says Denninger. "We might talk to the FCC or the Clinton administration about this." Barring that, Denninger will lobby Internet service providers around the country, asking them not to recognize the new GTLDs. "There is no reason to support it. We will do everything in our power to convince ISPs not to go along," he says. As part of that, he is launching a national public relations and lobbying campaign to alert the Internet community about the IACH proposal. [LINK] Copyright ) 1993-97 Wired Ventures, Inc. and affiliated companies. All rights reserved.

2 1

faulty moderation software: duplicate messages
by Attila T. Hun 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Virtually all list postings to the cypherpunks main list are doubled; the first, which is a standard pass through with the message ID of the sender, the second with the message ID of toad.com. Obviously, the first is destined for the unedited list --which did _not_ receive the message. The second has been re-IDd, which I presume is your censorhip mark. I happen to subscribe to all three lists, even though main + flames == unedited is supposedly the intention, it is not. In order to divide the output stream from toad.com, sorting on "Sender: " is the only reasonable differentation (when toad's filters are working): Sender: owner-cypherpunks(a)toad.com Sender: owner-cypherpunks-flames(a)toad.com Sender: owner-cypherpunks-unedited(a)toad.com Sender: owner-coderpunks(a)toad.com in the case cited below, the only differentation between the destinations is that the censored message has a "Message-ID: " from toad.com, while the one intended for unedited has a "Message-ID: " not from toad.com. was either of these destinated from flames? --the main list with duplicated messages has contained any number of messages, including ones from the ASCII art series which should have gone to flames. so, why is the pass through message not being reliably re-headered at toad.com to mark "Sender: owner-cypherpunks-unedited(a)toad.com" --but if it is, why is unedited receiving a duplicate --obviously the duplicate should have gone to flames. BOTTOM LINE: your software is inadequate. my neighbors' kids write better filters than you have installed. +Received: from toad.com (toad.com [140.174.2.1]) + by primenet.com (8.8.5/8.8.5) with ESMTP id EAA05103 + for <attila(a)primenet.com>; Fri, 7 Feb 1997 04:24:48 -0700 (MST) +Received: (from majordom@localhost) by toad.com (8.7.5/8.7.3) id +DAA20391; Fri, 7 Feb 1997 03:21:24 -0800 (PST) Received: from +hermes.ex.ac.uk (hermes.ex.ac.uk [194.83.11.25]) by toad.com +(8.7.5/8.7.3) with SMTP id DAA20386; Fri, 7 Feb 1997 03:21:20 -0800 +(PST) Received: from aba(a)p28-dove-gui.tch.virgin.net [194.168.60.88] +by hermes via ESMTP (LAA22615); Fri, 7 Feb 1997 11:21:06 GMT Received: +(from aba@localhost) by server.test.net (8.6.12/8.6.12) id LAA00460; +Fri, 7 Feb 1997 11:15:30 GMT Date: Fri, 7 Feb 1997 11:15:30 GMT +Message-Id: <199702071115.LAA00460(a)server.test.net> +From: Adam Back <aba(a)dcs.ex.ac.uk> +To: mark(a)infolawalert.com +Cc: cypherpunks(a)toad.com, mclow(a)owl.csusm.edu +In-reply-to: <199702052256.OAA06322(a)toad.com> (message from Mark + Voorhees on Wed, 05 Feb 97 17:05:51 -0400) +Subject: Re: Deloitte-Touche? +Sender: owner-cypherpunks(a)toad.com +Precedence: bulk +X-UIDL: 5456a9a45ccaf4617ae176a63b26efb4 +Received: from toad.com (toad.com [140.174.2.1]) + by primenet.com (8.8.5/8.8.5) with ESMTP id JAA26045; + Fri, 7 Feb 1997 09:00:01 -0700 (MST) +Received: (from majordom@localhost) by toad.com (8.7.5/8.7.3) id +HAA24892; Fri, 7 Feb 1997 07:12:54 -0800 (PST) Message-Id: + <199702071512.HAA24892(a)toad.com> +Date: Fri, 7 Feb 1997 11:15:30 GMT +From: Adam Back <aba(a)dcs.ex.ac.uk> +To: mark(a)infolawalert.com +Cc: cypherpunks(a)toad.com, mclow(a)owl.csusm.edu +Subject: Re: Deloitte-Touche? +Sender: owner-cypherpunks(a)toad.com +Precedence: bulk +X-UIDL: 83079c59aea2b28dc5ded2dc73c5219a -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: latin1 Comment: No safety this side of the grave. Never was; never will be iQCVAwUBMvtvF704kQrCC2kFAQEFAwP/RyyZswe9GznJt4TAEMPnhKcgA9pUsf+k mw+pDcjaJyUfKttoaVz0qRM2hIe33igoPtBDXWf5VD9r+Gz+gry6K+UK7rYCNNE9 MMdYHRV51hYuLKJAY4LNU6j5hoqf5q2Btt/m3F9SFQtD0ellsi4QH/vseJC1YNYh tq3TA+hny/U= =v3sl -----END PGP SIGNATURE-----

2 2

Re: 40-bit RC5 crack meaningless?
by Peter Trei 17 Dec '03

17 Dec '03

Subject: Re: 40-bit RC5 crack meaningless?? From: Peter Trei <ptrei(a)acm.org> > Subject: 40-bit RC5 crack meaningless?? Mr. Strassman allegedly sent the quoted letter to Winn Schwartaus' "infowar" mailing list, and it was then posted by persons unknown to the sci.crypt usenet group. Identity on the internet being the fluid thing it is, I apologize in advance if he never sent this letter, or if it has been modified before it reached me. The quoted letter attempts to minimize the importance of Ian Goldberg's recent bruteforce decryption of export-strength RC5 encryption. In my opinon, as described below, Mr. Strassman's arguments are without merit when applied to the situation the RSA challenges are intended to model - the security of encrypted Internet protocols. As such, I feel that his letter may lull some people into an unjustified and dangerous sense of security. > >Date: Thu, 30 Jan 1997 20:10:36 -0500 > >From: "Paul A. Strassmann" <paul(a)strassmann.com> > >Subject: Further to Goldberg's Cracking Accomplishments > >Gentlemen: > > > >As I suspected (see earlier private comment), the > >highly promoted RSA cracking contest offered > >a number of clues that ordinarly would not be > >volunteered by info-terrorists or info-criminals to > >IW Defense teams. > >These clues made the cracking significantly easier, > >because it made it possible to eliminate an enormous > >range of possible searches. What's the target, and who is doing the encrypting? These "clues" _are_ available to adversaries engaged in industrial and economic espionage; a important part of a covert infowar. It's certainly true that "info-terrorists or info-criminals" will not be so easy to tap, but the absence of these 'clues' is a red herring. They will be secure because they will use good encryption, which is not what US firms can export today. The challenges are realistic models of encrypted Internet protocols, for example IPSEC with ESP data encryption. As such, they accurately display the vulnerability of data on the Internet to espionage. > >The following was extracted verbatim from the > ><The RSA Data Security Secret-Key Challenge> > >posted on <http://www.rsa.com/rsalabs/97challenge/>: > > > >Clue #1: > > > > " ...all the RC5 contests posted as part of the RSA Secret-Key Challenge > >will use 12-round RC5 with a 32-bit word size. " > > > >Clue #2: > > > > " ...The first RC5 contest will consist of some unknown plaintext > >encrypted using a 40-bit key;." Clues #1 and #2 are absolutely reasonable - in an open standard, it is absolutely normal to know the cipher being used, it's mode, and the length of the key. See the SSL specification, or IPSEC's RFCs. > >Clue #3: (a giveway!) > > > > " ... For each contest, the unknown plaintext message is preceded by three > > known blocks of text that contain the 24-character phrase "The > > unknown message is: .....". To those who are unfamiliar with Internet protocols, this would appear to give the cryptanalyst an unrealistic head-start. This is not the case. Most Internet protocols have highly stereotyped packet headers; for example, _every_ normal return packet from a web server starts out with the string "HTTP/1.0" (servers using something other than version 1.0 are rare as hen's teeth at the moment). When you consider that such a packet may contain a firm's confidential earnings predictions or trade secrets (hopefully encrypted), the economic importance of such data is clear. Similar stereotyped headers exist for many other protocols, such as NNTP and SMTP. As such, a known-plaintext attack, as modeled by RSADSI's symmetric key challange, is quite realistic. Even if a full known plaintext for the first block is unavailable, a knowlegable cryptanalyst can usually make some very reasonable assumptions which will greatly speed his or her task. (I'm assuming DES here - which has a 64 bit block, but the argument extends easily to other block sizes). For example, if we know that the data contains only printable ASCII characters (true for the headers of most Internet protocols), then for a 64 bit block, there are 8 bits which we _know_ will be zero in the decrypted block. This lets us dispose of 255 out of every 256 incorrect trial decryptions immediately, and we will have to perform more extensive tests on less then 0.4% of candidate keys. Similar intelligent guesses can be made about the headers of other protocols, for example IPSEC-secured IPv6 packet headers in tunneling mode. Some people have noted that the challenges include the IV, or 'initialization vector' used in CBC (cipher-block-chaining) modes of encryption, and argue that this would not be available to an adversary. Once again, this assertion falls when examined in the light of actual usage. The purpose of an IV is to make dictionary and replay attacks more difficult. It is not intended to prevent brute force attacks, and so is _normally_ included in the clear in communications protocols (for example, see RFC 1827 for it's clear transmission in IPSEC). If it is not included, it is effectively part of the keying material, and thus adds it's bits to the strength of the key. As such, its value would have to be transmitted and protected as carefully as the rest of the key. > >In summary: The claim of exportable cryptography being totally > >insecure, because it can be cracked in 3.5 hours is not > >realistic. The three clues announced in the contest > >would not apply under infowar conditions. As I have shown above, Mr. Strassman's optimism is misplaced in the case of actual, fielded use of encryption on the Internet. It may apply to some classified systems, but they don't use exportable cryptography anyway. A covert inforwar against commercial and private targets is _quite_ plausible. > >What other clues may have been provided to Goldberg > >to support private agendas and gain shrill headlines > >is also a matter of speculation, but I rest my case. What exactly is he hinting at here? > >I certainly cannot assert that a 40 bit key cannot be decyphered. Of course he can't. 40 bits of RC4 encryption (as used in the exportable version of Netscape) was brute-forced not once, but three separate times in the fall of 1995, the fastest effort taking about 28 hours. Today it could be done much more quickly, as Ian demonstrated with RC5 (an algorithm of similar complexity). > >However, I do not think that the RSA unqualified claims > >offer full and appropriate disclosure. I disagree. The RSA challenges accurately model the use of encryption on the unclassified Internet. Ian's decryption of 40-bit RC5 is of considerable importance in demonstrating the insecurity of American citizens caused by Administration efforts to compromise exportable encryption. In my opinon, Mr. Strassman's assertions as to the strength of exportable encryption are too dangerous to be left unchallenged. > >Paul A. Strassmann > >55 Talmadge Hill Road, New Canaan, CT. 06840 > >Telephone: 203-966-5505; Fax: 203-966-5506 > >INTERNET: paul(a)strassmann.com > >WorldwideWeb: http://www.strassmann.com Peter Trei ptrei(a)acm.org Disclaimer: I am speaking as a knowlegable private citizen, not as a representative of my employer. This posting represents my opinon only.

2 1

Re: Waiting for Mac version [was Re: Full strength Email Clients]
by Timothy N. Hill 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 02:19 -0500 97-02-07, Steve Schear wrote: >>... PGPMail 4.5 ... > >Its too bad there isn't a Mac version contemplated. They appear to think >that existing PGP versions, paired with Eudora, are sufficient. I think a >better integrated approach for the Mac would be appreciated as the >available AppleScripts are buggy and awkward. I agree completely about the need. PGP, Inc., does claim to be working on a Mac version, but their promises are beginning to sound a little hollow. They now promise a "1997 release of PGPmail for the Macintosh" and "more specific information on when PGPmail will be available on the Macintosh" "during the second half of February." I bought ViaCrypt PGP for Macintosh 2.7.1 in October. (2.7.1 is nearly identical to the free 2.6.2, with the same abysmal user interface that earned a rare one-star rating from Macworld <http://www.macworld.com/pages/star/starratings.Utilities.html>, but 2.7.1 is licensed for commercial use.) At the time, PGP Inc. promised a free upgrade to version 4.0 for Mac, which was already considerably overdue. (According to <http://www.pgp.com/products/viacrypt-tbr.cgi>, 4.0 is still "To Be Released Soon.") When PGP, Inc., announced PGPmail 4.5 in December <http://www.pgp.com/newsroom/prel8.cgi>, they wrote "PGPmail 4.5 ... supports ... Mac OS." I called and asked if this implied they were bypassing 4.0 for Mac and when 4.5 would be available for Mac. The support person didn't know, said she'd find out and call me back, and never called back. A few days ago, I received this via US mail: >PRETTY GOOD PRIVACY, INC. > >Wednesday, January 22, 1997 > >Dear Valued Customer: > >Thank you for being patient regarding your order for an updated version >of PGP for the Macintosh. The last year has involved many changes for >our company. As a customer, we know the changes have caused delays in >the product you expected sooner. I would like to explain recent events >and extend a special offer in appreciation of your business. > >First, an explanation of recent events. As you may already know, Pretty >Good Privacy, Inc. purchased Lemcom Systems and its wholly owned >subsidiary, ViaCrypt, last year. ViaCrypt had previously announced >ViaCrypt PGP 4.0 for the Macintosh. Pretty Good Privacy is fully >committed to the Macintosh platform, and we have plans to release a >rich set of products for the Macintosh in 1997. We have already doubled >the size of our Macintosh group with engineers who have extensive Apple >experience. > >We are currently working on a new version of PGPmail designed >specifically for the Macintosh, adding new features and revising the >graphical user interface, making it significantly easier to use. > >After much serious consideration, we decided to dedicate the Macintosh >PGPmail team to deliver this new product as quickly as possible, and to >cancel the port of ViaCrypt PGP 4.0 to the Macintosh. We apologize for >any inconvenience this delay may have caused, but we believe that you >will agree that the new version of PGPmail designed specifically for >the Macintosh will meet your needs better than a port from the Windows >platform. > >In recognition of the delay, we would like to offer you the forthcoming >1997 release of PGPmail for the Macintosh free of charge. We hope you >will take advantage of this special offer. When ordering, please >indicate the following code #0811 to process your order, so please >retain this letter. Please check the PGPmail section of our website at >http://www.pgp.com/products/PGPmail-faq.cgi during the second half of >February with more specific information on when PGPmail will be >available on the Macintosh. > >Please accept our sincere apologies for the delay. If you have any >questions, please contact us at fyi(a)pgp.com. > >Sincerely, > >Tom Steding >President & CEO >Pretty Good Privacy, Inc. We shall see. Meanwhile, a beta version of "Pretty Safe Mail" <http://www.highware.com/highware/PSM/safemail.htm> is available from Highware in Belgium. It's PGP compatible, and its user interface is a great leap forward from any Mac PGP front end I've seen. But, it still has some deficiencies, it's very slow (25 seconds to sign this message on a 25 MHz 68040 vs. 4 seconds for ViaCrypt PGP 2.7.1), and (as was recently discussed on a couple of these lists) its source code hasn't been published or externally audited. - Tim -----BEGIN PGP SIGNATURE----- Version: 2.7.1 iQCVAwUBMvtiAi62DQeAyFc9AQG5tAQAigsa5/Ygb9PqHHLA/QD+HSpBWFRpRjGW bWfg8Zq0PCi5AyMPAwYagxYo5/m4Sm3OA6u2urq5IDzxVaYOGFIgKGRxaFgWivFN dYfwFRR9WO7NkoigKsOc3ZHAK2UPPWYsFkjbVkbINyke5NmFkwEI0/oPguoMWdXH WMpnOGDut5Q= =kWrX -----END PGP SIGNATURE----- Timothy N. Hill <tnh(a)acm.org> "We all love to instruct, Wellesley, Massachusetts though we can teach only <http://www.ma.ultranet.com/~tnh/> what is not worth knowing." PGP F058F75D 99C5122F 21C5BEF5 620C1D3C - Elizabeth Bennet

1 0

Re: anonymous remailers
by Andrew Loewenstern 17 Dec '03

17 Dec '03

Charley Musselman writes: > Does anyone know the answer? Specifically, how can we choose > a trusted remailer? The answer is to run your own remailer. Make sure your chain includes your remailer at least once. If you can't trust yourself, who can you trust? andrew

1 0

Project 25 Radio
by John Young 17 Dec '03

17 Dec '03

The National Communications Systems published in the Federal Register of February 6, a notice of FTR1024 covering Land Mobile Radio, Project 25. The recommentation specifies encryption: DES (Type 3) and Type 1 for classified use. The specifications are based on seven public TIA documents and one classified NSA document. "This recommendation is intended to facilitate interoperability among telecommunication facilities and systems of the Federal Government." The official document is available in PDF format at: http://members.aol.com/Project25/1024.pdf We've prepared a hypertext version: http://jya.com/ftr1024.htm

1 0

Re: Cypherpunks FOIA request
by John Pearson 17 Dec '03

17 Dec '03

> On 1/18/97, I sent freedom of information act requests to the FBI (main and > San Francisco offices), CIA, NSA, and Secret Service, asking them for copies > of information in their files relating to or referring to the cypherpunks > list, the cypherpunks meetings, and copies of any messages sent from or to > "cypherpunks(a)toad.com". [...] > I'm not sure what I think about the response from the SF FBI branch - it > seems unlikely that they'd never have paid any attention to the list, given > the media coverage in Wired and other places. On the other hand, maybe the > FBI doesn't read Wired. :) While they're not supposed to be monitoring > noncriminal domestic activity, I figured they'd at least have something about > the Mykotronix stuff. > If you think so, you may wish to consider filing an FOIA request for the Mykotronix stuff, and see if it mentions cypherpunks; it could provide an interesting perspective on their response. John P. john(a)huiac.apana.org.au

1 0

Re: My Departure, Moderation, and "Ownership of the List"
by Mark Grant 17 Dec '03

17 Dec '03

On Mon, 3 Feb 1997, Adam Back wrote: > My vote is for renaming: > `cypherpunks-unedited' -> `cypherpunks' > and `cypherpunks' -> `cypherpunks-edited' I have to agree. I'm only a 'cypherpunk' in the sense of setting up various crypto-related Web sites and writing and giving away thousands of lines of cryptography code rather than regularly posting to the list, but my main concern is that the default for the list has gone from anarchy to moderation. If the users of the list truly believe in anarchistic solutions to problems then the moderated list should exist *in addition* to the unmoderated list, rather than replacing it. In a truly anarchistic society the cypherpunks list would be an unmoderated forum full of spam and opinions related in some way to the list topics and numerous moderators would charge us for their versions of the list in which they simply pass on the messages they like. We could then choose a moderator whose interests are similar to ours and pay them for providing us with apropriate information. IMHO this is the way that mailing lists and Usenet are likely to evolve as they become too large for us to read and react to all posts; we should be in the vanguard of creating appropriate solutions to the problems. Providing a moderated list which saves me from dowloading spam is a worthwhile exercise which is potentially valuable to me (and I'm grateful to Sandy for offering such a service for free), but I do not believe that it should be the default for new subscribers. Mark |-----------------------------------------------------------------------| |Mark Grant M.A., U.L.C. EMAIL: mark(a)unicorn.com | |WWW: http://www.unicorn.com/ MAILBOT: bot(a)unicorn.com | |-----------------------------------------------------------------------|

1 0

Hello, Duncan
by Gr8SClaus＠aol.com 17 Dec '03

17 Dec '03

I saw your listing for accessing senior citizens newsgroups through compuserve. Do you think, by chance, that the same would be possible through america online? I'm a senior citizen of 59 but find myself liking middle age to older and find the only source on line (that i can locate as am anateur) is netpics.com and you have to pay for this service. But I do enjoy looking at older GUYS and find mostly girls--even on netpics. Thanks. Dave

1 0

Re: lead remailer is shut down
by Ed.Falk＠Eng.Sun.COM 17 Dec '03

17 Dec '03

Can't remailers be written with basic spam safeguards? I.e. no mass crossposts, limited # of posts by each individual client per day, etc.?

3 2