From huntting at glarp.com Wed Sep 1 07:54:22 1993 From: huntting at glarp.com (Brad Huntting) Date: Wed, 1 Sep 93 07:54:22 PDT Subject: PGP: question In-Reply-To: <9309010146.AA29652@toad.com> Message-ID: <199309011449.AA00330@misc.glarp.com> > if you ask me, limiting $PGPPATH to length 50 is a bug (albeit > most likely benign). Hardly! Many folks with home directories on AFS will have a hard time with this. I would suggest changing this to something like _POSIX_PATH_MAX (which is 255 on BSD386 systems). brad From jazz at hal.com Wed Sep 1 08:19:54 1993 From: jazz at hal.com (Jason Zions) Date: Wed, 1 Sep 93 08:19:54 PDT Subject: NY TAXES CYBERSPACE, CRAM REACTS In-Reply-To: <261clo$q1@hal.com> Message-ID: <9309011516.AA19211@jazz.hal.com> Y'know, a two-paragraph summary in calm tones, followed by the text of the tax notice, would have been more effecitve; breathless hyperbole turns some people off. In any event, I see no reference to retroactivity. At worst, if someone paid an annual fee, tax is owed only on the prorated portion of services to be rendered after September 1. That is, if someone paid $30 on January 1 for one year's service, tax is owed only on the "unused" $10 covering Sept 1 through December 31. This is relatively clear from the wording regarding "service to be rendered after...". Yes, it's monumentally stupid. You think you got it bad? I can't believe the brokerage houses on Wall Street let this one go; NYSE ticker feeds are covered by this, as are all generic reuseable information feeds, which means transmission of credit reports and the like. This is gonna jack up most things related to the US finance industry, especially NYSE and large arbitrage. I left New York State years ago; seems the state's IQ really *did* get stupider after I left. :-) Jason From jazz at hal.com Wed Sep 1 08:24:22 1993 From: jazz at hal.com (Jason Zions) Date: Wed, 1 Sep 93 08:24:22 PDT Subject: Encryption policies of Fidnet, etc. In-Reply-To: <260ohk$l2e@hal.com> Message-ID: <9309011520.AA19223@jazz.hal.com> JTD> It is illegal to encrypt messages period. JTD> E-mail encryption is illegal >Depends on your network and where you live. >It is illegal to use PGP in the United States due to its use of a >copyrighted algoritm. It is *NOT* illegal to use it anywhere else in >the world. Other encryption methods are legal. Jeez, talk about misinformation. If it were copyright, then a US copyright is indeed restrictive world-wide; that's the point of the Berne Convention. However, it's not copyright; it's pretty tought to copyright an algorithm, all one can do is copyright the exact expression of one implementation of that algorithm. What's involved here is a patent, which is (as you note) not binding outside the US. Finally, is it certain that PGP indeed infringes on a valid patent? >... Get the facts first - you can distort them later! Ah. This explains much. Jason From jazz at hal.com Wed Sep 1 08:49:22 1993 From: jazz at hal.com (Jason Zions) Date: Wed, 1 Sep 93 08:49:22 PDT Subject: (fwd'd) more Clipper inside? In-Reply-To: <260kjq$irr@hal.com> Message-ID: <9309011545.AA19233@jazz.hal.com> Warning: rampant paranoia inside. >Check this out. >Clipper inside the Apple get you bothered? >How about Clipper inside all UNICES ? (all POSICES) Not bloody likely, for several dozen reasons. Most importantly, POSIX does not, indeed cannot, specify implementation. All it does is specify interfaces. That is, POSIX could define a standard API which accepts a clear-text message and some form of secure identification for a user and produces an authentication string which can be used by a recipient of that message to verify that it was sent by that user. The standard cannot state "You must use MD5" or "You must use Clipper". POSIX also produces "Profiles", which are standards that point at other standards. A profile might say "When the message-auth function is provided, it shall use MD5 as its mechanism." Another profile might say "When the message-auth function is provided, it shall use PGP." A customer would tell a vendor "I want to buy a system that conforms to the profile that says use Clipper for authentication." Other customers would tell that same vendor "I want to buy a system that conforms to the profile that says use PGP for authentication." The base POSIX standard is neutral on the issue. Competing profiles take stands on the issue. Customers buy systems that conform to profiles that match their own stand on the issue. The only way Clipper will appear in all POSIX-conforming systems is if one of the following events occur: 1) Only one profile is ever written, one that specified Clipper for message authentication and encryption. 2) Customers tell their vendors they want the Clipper profile and don't tell their vendors they want any other profile. Event (1) is pretty bloody unlikely. POSIX standards groups have substantial international involvement; there are enough people from enough countries where Clipper is recognized as stupid that other profiles will appear. Besides, given a profile that requires Clipper, I can generate a profile that requires PGP in about a day's work that will fly through ballot. Event (2) is the one you have to watch out for. Here, though, it's a case of the sheep going meekly to slaughter, which is what cypherpunks aim to stop anyway. Upshot: POSIX is a weak tool in the hands of the Clipper camp; don't sweat it. ] Cryptographic Services ] ]One proposal has been received, form NIST, which outlines interfaces for ]several areas of cryptographic services: user cryptographic database ]management, secret key cryptography services, and public key cryptography ]services. The secret key services include encryption and data integrity, ]as well as key management. The public key services include encryption ]and digital signatures, as well as key management. The proposal will ]be included in the POSIX mailing and will be discussed at the October meeting. ]Another proposal may be submitted by the October meeting and will also ]be discussed. Any additional proposals for crytpographic services will ]also be entertained. Looks like APIs to me. I suspect there will be substantial opposition to *all* cryptographic API standards from vendors, simply because they know that the f-ing US Government, in the person of the Commerce Department, will then tell them they cannot export those APIs and the mechanisms under them. There's no point in standardizing something when you can't sell it to more than half of your customers. All you have to do is figure out how to use a more positive cryptographic engine (like PGP) with each of the APIs that get defined; we push a profile, and we're done. Jason Zions Chair, IEEE P1003.8 POSIX Transparent File Access Note: I am speaking solely for myself. This is not an official statement of IEEE or any entity thereof. From khijol!erc at apple.com Wed Sep 1 10:14:23 1993 From: khijol!erc at apple.com (Ed Carp) Date: Wed, 1 Sep 93 10:14:23 PDT Subject: Encryption policies of Fidnet, etc. In-Reply-To: <9309011520.AA19223@jazz.hal.com> Message-ID: > > JTD> It is illegal to encrypt messages period. > JTD> E-mail encryption is illegal > > >Depends on your network and where you live. > > >It is illegal to use PGP in the United States due to its use of a > >copyrighted algoritm. It is *NOT* illegal to use it anywhere else in > >the world. Other encryption methods are legal. > > Jeez, talk about misinformation. > > If it were copyright, then a US copyright is indeed restrictive world-wide; > that's the point of the Berne Convention. > > However, it's not copyright; it's pretty tought to copyright an algorithm, > all one can do is copyright the exact expression of one implementation of > that algorithm. What's involved here is a patent, which is (as you note) not > binding outside the US. > > Finally, is it certain that PGP indeed infringes on a valid patent? > > >... Get the facts first - you can distort them later! > > Ah. This explains much. I hate to jump into the fray, but according to Public Key Partners, if you use RSA for educational, (etc.) purposes, you are not infringing on their patent. It has long been held that there is an exemption to 'patent infringment' for educational or other "non-commercial" uses. -- Ed Carp erc at apple.com 510/659-9560 If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From thug at phantom.com Wed Sep 1 10:19:23 1993 From: thug at phantom.com (Murdering Thug) Date: Wed, 1 Sep 93 10:19:23 PDT Subject: NY TAXES CYBERSPACE, CRAM REACTS In-Reply-To: <9309010524.AA11600@longs.lance.colostate.edu> Message-ID: So, what this means is that companies which produce information products printed on paper (Newspapers, Magazines, etc..), and who contribute to pollution (both as paper waste and as emissions into the environment in the manufacturing, printing and transport of paper) and deforrestation pay only a 4% sales tax to the state, while companies which sell information electronically and produce no pollution or deforrestation pay a 9% tax to the state. Now there's a real insentive not to pollute the environment, NOT! Cuomo is a FUCKING IDIOT! There, I've said it... Il Duce must be pulled from his comfy office, hung upside down in a public square in Albany, and repeatedly shot with high caliber weapons, and then beaten to a pulp with baseball bats. Thug p.s. Mario, if you're reading this, repeal the tax now, you fucking bastard! From plmoses at unix.cc.emory.edu Wed Sep 1 10:29:23 1993 From: plmoses at unix.cc.emory.edu (Paul L. Moses) Date: Wed, 1 Sep 93 10:29:23 PDT Subject: NY TAXES CYBERSPACE, CRAM REACTS Message-ID: <9309011724.AA03212@emoryu1.cc.emory.edu> Arguably the NY tax is a violation of the Commerce Clause of the Constitution. Is the state's local interest more compelling than the burden this law places on interstate commerce? Doubtful. Paul From doug at netcom4.netcom.com Wed Sep 1 10:39:23 1993 From: doug at netcom4.netcom.com (Doug Merritt) Date: Wed, 1 Sep 93 10:39:23 PDT Subject: Encryption policies of Fidnet, etc. Message-ID: <9309011736.AA22359@netcom4.netcom.com> khijol!erc at apple.com (Ed Carp) said: >I hate to jump into the fray, but according to Public Key Partners, if you >use RSA for educational, (etc.) purposes, you are not infringing on their >patent. > It has long been held that there is an exemption to 'patent infringment' >for educational or other "non-commercial" uses. Hmm. I would love to interpret this as meaning that I can freely use their technology in freeware software that I write for and release to the net. However there would seem to be reason to doubt this. ;-) Any opinions on how much/how little one could get away with on such things? Would it make a difference if the piece of software were intended for a focused education/research area (say groupware research) rather than being highly general (as a mailer is)? I'm less familiar with patent exemptions than copyright exemptions, so this is all somewhat opaque to me. And there's always the old issue of whether someone will be motivated to sue you, and whether you want to spend time & money on defense, quite aside from the hypothetical legality or illegality that might eventually be established. Urk. Doug From danodom at matt.ksu.ksu.edu Wed Sep 1 10:49:23 1993 From: danodom at matt.ksu.ksu.edu (Dan Odom) Date: Wed, 1 Sep 93 10:49:23 PDT Subject: Encryption policies of Fidnet, etc. In-Reply-To: Message-ID: <9309011744.AA12892@matt.ksu.ksu.edu> Ed Carp Said: > It has long been held that there is an exemption to 'patent infringment' > for educational or other "non-commercial" uses. Is this just for RSA, or for all patents? If PKP wanted to forbid academic use of RSA (or require a license for it), could they legally do so? Assume for now that the patent is valid, which it may not be... I ask all this because I often hear researchers looking for a cure for (insert your favorite aliment here) complain that they have to pay patent royalties on the gentically-modified animals they use in their work, and if, say, two patented rabbits produce offspring, they have to pay royalties on each of the offspring as well. This is academic use (to me anyway; I don't know about legally), but requires royalties. -- Dan Odom danodom at matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS PGP key by finger or request. From paul at poboy.b17c.ingr.com Wed Sep 1 11:29:23 1993 From: paul at poboy.b17c.ingr.com (Paul Robichaux) Date: Wed, 1 Sep 93 11:29:23 PDT Subject: Encryption policies of Fidnet, etc. In-Reply-To: <9309011744.AA12892@matt.ksu.ksu.edu> Message-ID: <199309011818.AA14080@poboy.b17c.ingr.com> -----BEGIN PGP SIGNED MESSAGE----- The exemption is a part of the sections of the US code pertaining to patents. As I understand it, the exemption allows you to build _one_ instance of a patented item for your _own_ _personal_ research. If you as an individual want to keep a patented bunny as a pet, you're probably OK. If you want to use PGP, as an ividual, you're probably OK. If you want to use those patented items for anything else, you're probably not OK, thus the recent interest in a commercial-and-infringement-proof PGP. Witness the just-decided Litton-Honeywell patent infringement case. Litton obtained a $1.2G judgement against Honeywell, which used a method patented by Litton to manufacture its very successful ring laser gyros. Since damages in patent infringement cases are based on actual damages (with a 3x increase possible if the jury decides that the infringement was deliberate), the Litton-Honeywell case might give a manufacturer pause. I bet that PKP would be unable to show that my use of PGP has caused them _any_ actual (or even potential) damages. However, Apple (or Lotus, or any of the other RSA licensees) have obviously decided that they'd rather play {safe,fair} and license the patents directly. - -Paul - -- Paul Robichaux, KD4JZG | "Change the world for a better tomorrow. But perobich at ingr.com | watch your ass today." - aaron at halcyon.com Intergraph Federal Systems | Be a cryptography user- ask me how. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLITm4iA78To+806NAQHUogP6AkrIf7+uyMehKosHi+qdeWz0POs7XHth PejJe3qflnxEUlFaUnJWKemj9iF6gwP6N90LBsY68gWaO5aUNqLM00UE996GutpV o5+AyzKST+cjJkC0p8P3N8K8tGe+llGJW9gSjRLmx61B+cdNQ/STjIMCSUevs8SZ n54glbaC56Y= =hkpg -----END PGP SIGNATURE----- From tk at reagan.ai.mit.edu Wed Sep 1 12:59:58 1993 From: tk at reagan.ai.mit.edu (Tom Knight) Date: Wed, 1 Sep 93 12:59:58 PDT Subject: Fair Use In-Reply-To: <9309011744.AA12892@matt.ksu.ksu.edu> Message-ID: <19930901195515.2.TK@ROCKY.AI.MIT.EDU> Date: Wed, 1 Sep 1993 13:44 EDT From: danodom at matt.ksu.ksu.edu (Dan Odom) Is this just for RSA, or for all patents? If PKP wanted to forbid academic use of RSA (or require a license for it), could they legally do so? Assume for now that the patent is valid, which it may not be... I ask all this because I often hear researchers looking for a cure for (insert your favorite aliment here) complain that they have to pay patent royalties on the gentically-modified animals they use in their work, and if, say, two patented rabbits produce offspring, they have to pay royalties on each of the offspring as well. This is academic use (to me anyway; I don't know about legally), but requires royalties. The exemption from patent protection applies only to research which attempts to improve or extend the patented idea. Thus, if you were breeding patented insulin-dependant rabbits with the intent to produce better ones, this would be acceptable. If, however, you wanted to test your new diabetic drug on the rabbits, then you owe the patent holder a royalty. Using PGP (as opposed to writing a new one, or improving it, or attempting to use it in new ways), even by academics, is probably questionable in the US under patent law. Developing new versions of RSA code or algorithms clearly is legal, even for private commercial firms. Patenting the improvements is legal and encouraged. Selling or using a patented invention, even internally, is prohibited. So it all depends. Are you a user or an improver? Can you make a legitimate claim to be testing new ideas, implementations, or applications, or are you just using someone else's implementation. A paper trail showing that you are thinking about ways to improve or further develop the ideas might be a powerful defense. Like, for example, messages to this forum. From bill at twwells.com Wed Sep 1 13:06:45 1993 From: bill at twwells.com (T. William Wells) Date: Wed, 1 Sep 93 13:06:45 PDT Subject: NY TAXES CYBERSPACE, CRAM REACTS In-Reply-To: <9309011516.AA19211@jazz.hal.com> Message-ID: In article <9309011516.AA19211 at jazz.hal.com>, Jason Zions wrote: : Y'know, a two-paragraph summary in calm tones, followed by the text of the : tax notice, would have been more effecitve; breathless hyperbole turns some : people off. Like me. I stopped reading just as soon as I realized that the primary bit of information I would obtain from the message was that its author needs to adjust his dose of antipsychotics. From warlord at MIT.EDU Wed Sep 1 14:14:27 1993 From: warlord at MIT.EDU (Derek Atkins) Date: Wed, 1 Sep 93 14:14:27 PDT Subject: PGP suggestions (was Re: anonymous mail) In-Reply-To: <199308312052.AA01186@misc.glarp.com> Message-ID: <9309012108.AA03677@toxicwaste.MEDIA.MIT.EDU> > Perhaps it's time we polished the edges, added a few of the features > that are lacking, and wrote up up an RFC for the PGP message format. This is being worked on.... > Some features I'd like to see in PGP are: > > The ability to send an encrypted message to multiple > recipients without duplicating the entire message. The > most logical way to do this would probably be to encrypt > the random IDEA key once for each recipient. This has been in PGP since version 2.2! Read the docs! To use this feature, you just execute: pgp -e filename user1 user2 user3... And it will encrypt the file to all users, using the same IDEA key and RSA-encrypting it to the different recipients. > There needs to be a facility for having multiple signatures > on a single document without making the signers sign each > others signatures. Besides the obvious application of > removing a signature from a document, this would also > facilitate things like petitions where many people could > asynchronously sign a single document, and latter assemble > all the signatures together. This has been discussed. It is possible to do this in the PGP protocol, but it has not been implemented. What this means is that you could write the code to generate the proper packets to do this, since those packets are legal, but this code has not yet been written. It is in the works, but I wouldn't expect to see it in the 2.4 version. > It should be possible (though certainly not mandatory) to > hide the recipient's identity entirely. This, too, is in the works, albeit a little more difficult to accomplish. > The message format needs to allow for alternate forms of > encryption (besides IDEA). Furthermore, the (shared key) > algorithm used to encrypt a message should be hidden in > the RSA encrypted part of the message along with the shared > key. Ideally, a list of algorithms could be given which > would allow the message to be optionally compressed before > being encrypted, or encrypted two or more times with > different algorithms. This is already supported. There is a byte that represents the secret-key algorithm (and there is a byte that represents the message-digest algorithm as well). It would be simple to add, say, triple-DES to PGP as an alternative encryption algorithm. As for hiding the encryption algorithm, this is a possibility but I don't see it happening. The data structures, I don't believe, allow for this currently. (I'd have to go back and double check this one). > If I'm confused and the PGP message format already supports some > of these features, please correct me. Thats why this message was composed. Enjoy! -derek From khijol!erc at apple.com Wed Sep 1 15:24:28 1993 From: khijol!erc at apple.com (Ed Carp) Date: Wed, 1 Sep 93 15:24:28 PDT Subject: Encryption policies of Fidnet, etc. In-Reply-To: <9309011744.AA12892@matt.ksu.ksu.edu> Message-ID: > Ed Carp Said: > > > It has long been held that there is an exemption to 'patent infringment' > > for educational or other "non-commercial" uses. > > Is this just for RSA, or for all patents? If PKP wanted to forbid > academic use of RSA (or require a license for it), could they legally > do so? Assume for now that the patent is valid, which it may not > be... I'm under the impression that it's for any patent, but I'm not a lawyer (I just play one on the net [grin]). > I ask all this because I often hear researchers looking for a cure for > (insert your favorite aliment here) complain that they have to pay > patent royalties on the gentically-modified animals they use in their > work, and if, say, two patented rabbits produce offspring, they > have to pay royalties on each of the offspring as well. This is > academic use (to me anyway; I don't know about legally), but requires > royalties. I think it's because they are using them to make $$$. I think. :) Here's the README from the RSA folks that I got with RSAREF. Hope it answers one or two of your questions. :) --------------------------------- cut here ----------------------------------- RSAREF(TM): A Cryptographic Toolkit for Privacy-Enhanced Mail RSA Laboratories (A division of RSA Data Security, Inc.) April 20, 1992 This document copyright (C) 1992 RSA Laboratories, a division of RSA Data Security, Inc. License is granted to reproduce, copy, post, or distribute in any manner, provided this document is kept intact and no modifications, deletions, or additions are made. WHAT IS IT? RSAREF is a cryptographic toolkit designed to facilitate rapid deployment of Internet Privacy-Enhanced Mail (PEM) implementations. RSAREF represents the fruits of RSA Data Security's commitment to the U.S. Department of Defense's Advanced Research Projects Agency (DARPA) to provide free cryptographic source code in support of a PEM standard. RSA Laboratories offers RSAREF in expectation of PEM's forthcoming publication as an Internet standard. Part of RSA's commitment to DARPA was to authorize Trusted Information Systems of Glenwood, MD, to distribute a full PEM implementation. That implementation will be available this spring. RSAREF supports the following PEM-specified algorithms: o RSA encryption and key generation, as defined by RSA Laboratories' Public-Key Cryptography Standards (PKCS) o MD2 and MD5 message digests o DES (Data Encryption Standard) in cipher-block chaining mode RSAREF is written in the C programming language as a library that can be called from an application program. A simple PEM implementation can be built directly on top of RSAREF, together with message parsing and formatting routines and certificate-management routines. RSAREF is distributed with a demonstration program that shows how one might build such an implementation. The name "RSAREF" means "RSA reference." RSA Laboratories intends RSAREF to serve as a portable, educational, reference implementation of cryptography. WHAT YOU CAN (AND CANNOT) DO WITH RSAREF The license at the end of this note gives legal terms and conditions. Here's the layman's interpretation, for information only and with no legal weight: 1. You can use RSAREF in personal, non-commercial applications, as long as you follow the interface described in the RSAREF documentation. You can't use RSAREF in any commercial (moneymaking) manner of any type, nor can you use it to provide services of any kind to any other party. For information on commercial licenses of RSAREF-compatible products, please contact RSA Data Security. (Special arrangements are available for educational institutions and non-profit organizations.) 2. You can give others RSAREF and programs that interface to RSAREF, under the same terms and conditions as your RSAREF license. 3. You can modify RSAREF as required to port it to other operating systems and compilers, as long as you give a copy of the results to RSA Laboratories. Other changes require written consent. 4. You can't send RSAREF outside the United States or Canada, or give it to anyone who is not a U.S. or Canadian citizen and doesn't have a U.S. "green card." (These are U.S. State and Commerce Department requirements, because RSA and DES are export-controlled technologies. Without the export-control restrictions, RSAREF would be available by anonymous FTP.) HOW TO GET IT To obtain RSAREF, read the license at the end of the note and return a copy of the following paragraph by electronic mail to : I acknowledge that I have read the RSAREF Program License Agreement and understand and agree to be bound by its terms and conditions, including without limitation its restrictions on foreign reshipment of the Program and information related to the Program. The electronic mail address to which I am requesting that the program be transmitted is located in the United States of America or Canada and I am a United States citizen, a Canadian citizen, or a permanent resident of the United States. The RSAREF Program License Agreement is the complete and exclusive agreement between RSA Laboratories and me relating to the Program, and supersedes any proposal or prior agreement, oral or written, and any other communications between RSA Laboratories and me relating to the Program. RSAREF is distributed by electronic mail in UNIX(TM) "uuencoded" TAR format. When you receive it, store the contents of the message in a file, and run your operating system's "uudecode" and TAR programs. For example, suppose you store the contents of your message in the file 'contents'. You would run the commands: uudecode contents # produces rsaref.tar tar xvf rsaref.tar RSAREF includes about 60 files organized into the following subdirectories: doc documentation on RSAREF and RDEMO install makefiles for various operating systems rdemo RDEMO demonstration program source RSAREF source code and include files test test scripts for RDEMO USERS' GROUP RSA Laboratories maintains the electronic-mail users' group for discussion of RSAREF applications, bug fixes, etc. To join the users' group, send electronic mail to . REGISTRATION RSAREF users who register with RSA Laboratories are entitled to free RSAREF upgrades and bug fixes as soon as they become available and a 50% discount on selected RSA Data Security products. To register, send your name, address, and telephone number to . INNOVATION PRIZES RSA Laboratories will award cash prizes for the best applications built on RSAREF. If you'd like to submit an application, want to be on the review panel, or would like more details, please send electronic mail to . Applications are due December 31, 1992, and awards will be announced March 31, 1993. First prize is $5000, second prize is $2000, and there are five prizes of $1000. PUBLIC-KEY CERTIFICATION RSA Data Security offers public-key certification services conforming to forthcoming PEM standards. For more information, please send electronic mail to . PKCS: PUBLIC-KEY CRYPTOGRAPHY STANDARDS To obtain copies of RSA Laboratories' Public-Key Cryptography Standards (PKCS), send electronic mail to . OTHER QUESTIONS If you have questions on RSAREF software, licenses, export restrictions, or other RSA Laboratories offerings, send electronic mail to . AUTHORS RSAREF was written by the staff of RSA Laboratories with assistance from RSA Data Security's software engineers. The DES code is based on an implementation that Justin Reyneri did at Stanford University. Jim Hwang of Stanford wrote parts of the arithmetic code under contract to RSA Laboratories. ABOUT RSA LABORATORIES RSA Laboratories is the research and development division of RSA Data Security, Inc., the company founded by the inventors of the RSA public-key cryptosystem. RSA Laboratories reviews, designs and implements secure and efficient cryptosystems of all kinds. Its clients include government agencies, telecommunications companies, computer manufacturers, software developers, cable TV broadcasters, interactive video manufacturers, and satellite broadcast companies, among others. RSA Laboratories draws upon the talents of the following people: Len Adleman, distinguished associate - Ph.D., University of California, Berkeley; Henry Salvatori professor of computer science at University of Southern California; co-inventor of RSA public-key cryptosystem; co-founder of RSA Data Security, Inc. Taher Elgamal, senior associate - Ph.D., Stanford University; director of engineering at RSA Data Security, Inc.; inventor of Elgamal public-key cryptosystem based on discrete logarithms Martin Hellman, distinguished associate - Ph.D., Stanford University; professor of electrical engineering at Stanford University; co-inventor of public-key cryptography, exponential key exchange; IEEE fellow; IEEE Centennial Medal recipient Burt Kaliski, chief scientist - Ph.D., MIT; former visiting assistant professor at Rochester Institute of Technology; author of Public-Key Cryptography Standards; general chair of CRYPTO '91 Cetin Koc, associate - Ph.D., University of California, Santa Barbara; assistant professor at University of Houston Ron Rivest, distinguished associate - Ph.D., Stanford University; professor of computer science, MIT; co-inventor of RSA public-key cryptosystem; co-founder of RSA Data Security, Inc.; member of National Academy of Engineering; director of International Association for Cryptologic Research; program co-chair of ASIACRYPT '91 RSA Laboratories seeks the talents of other people as well. If you're interested, please write or call. ADDRESSES RSA Laboratories RSA Data Security, Inc. 10 Twin Dolphin Drive 100 Marine Parkway Redwood City, CA 94065 Redwood City, CA 94065 (415) 595-7703 (415) 595-8782 (415) 595-4126 (fax) (415) 595-1873 (fax) PKCS, RSAREF and RSA Laboratories are trademarks of RSA Data Security, Inc. All other company names and trademarks are not. ---------------------------------------------------------------------- RSA LABORATORIES PROGRAM LICENSE AGREEMENT RSA LABORATORIES, A DIVISION OF RSA DATA SECURITY, INC. ("RSA"), IS WILLING TO LICENSE THE "RSAREF" PROGRAM ON THE TERMS AND CONDITIONS SET FORTH BELOW. YOUR ACKNOWLEDGEMENT AND ACCEPTANCE OF THESE TERMS AND CONDITIONS IS REQUIRED PRIOR TO DELIVERY TO YOU OF THE RSAREF PROGRAM. 1. LICENSE. RSA is willing to grant you a non-exclusive, non-transferable license for the "RSAREF" program (the "Program") and its associated documentation, subject to all of the following terms and conditions: a. to use the Program on any computer in your possession; b. to make copies of the Program for back-up purposes; c. to incorporate the Program into other computer programs only through interfaces described in the RSAREF Library Reference (the file "rsaref.txt" which accompanies the Program) (any such incorporated portion of the Program to continue to be subject to the terms and conditions of this license) only for your own personal or internal use or to create Application Programs; d. to modify the Program for the purpose of porting the Program to any other operating systems and compilers, but only on the conditions that: (i) you do not alter any Program interface, except with the prior written consent of RSA; and (ii) you provide RSA with a copy of the ported version of the Program by electronic mail; and e. to distribute the Program without charge to non-commercial users, but only in accordance with the limitations set forth in Section 2. "Application Programs" are programs which either (i) incorporate all or any portion of the Program in any form, or (ii) interface with the Program but do not incorporate all or any portion of the Program in any form. 2. LIMITATIONS ON LICENSE. a. RSA owns the Program and its associated documentation and all copyrights therein. YOU MAY NOT USE, COPY, MODIFY OR TRANSFER THE PROGRAM, IN EITHER SOURCE CODE OR OBJECT CODE FORM, ITS ASSOCIATED DOCUMENTATION, OR ANY COPY, MODIFICATION OR MERGED PORTION THEREOF, IN WHOLE OR IN PART, EXCEPT AS EXPRESSLY PROVIDED IN THIS AGREEMENT OR WITH THE PRIOR WRITTEN CONSENT OF RSA. YOU MUST REPRODUCE AND INCLUDE RSA'S COPYRIGHT NOTICES ON ANY COPY OR MODIFICATION, OR ANY PORTION THEREOF, OF THE PROGRAM AND ITS ASSOCIATED DOCUMENTATION. b. You may not distribute copies of the Program or its associated documentation or any Application Program except as expressly provided in this Agreement. IF YOU TRANSFER POSSESSION OF ANY COPY, MODIFICATION OR MERGED PORTION OF THE PROGRAM, WHETHER IN SOURCE CODE OR OBJECT CODE FORM, OR ITS ASSOCIATED DOCUMENTATION OR ANY APPLICATION PROGRAM, IN SOURCE CODE OR OBJECT CODE FORM, TO ANOTHER PARTY, EXCEPT AS EXPRESSLY PROVIDED FOR IN THIS LICENSE, YOUR LICENSE SHALL BE AUTOMATICALLY TERMINATED. c. The Program and all Application Programs are to be used only for non-commercial purposes. This means that you may not use the Program or any Application Programs in any manner or for any purpose directly related to a product or service that is provided for sale to third parties (either by you or by any person or entity for whom you provide services) or that is provided (with or without compensation) for general use within a business organization or subdivision thereof. In addition, you may not distribute the Program or any Application Program in any manner that will generate any income to you, including without limitation any income on account of license fees, royalties, maintenance fees and upgrade fees. d. You may not translate the Program into any other computer language, except with the prior written consent of RSA. e. You may not incorporate the Program into other programs through interfaces other than the interfaces described in the RSAREF Library Reference, except with the prior written consent of RSA. f. You may distribute the Program only in the following forms: (i) the unmodified Program, in source code or object code form; (ii) the Program as modified only for the purpose of porting it to another operating system or compiler in accordance with Section 1.d., in source code or object code form; and (iii) as part of an Application Program in executable code form. g. You may distribute the Program only pursuant to a Program License Agreement exactly in the form of this Program License Agreement. You may not vary the terms of this Program License Agreement. You may distribute the Program only in compliance with all laws, regulations, orders and other restrictions on the export from the United States of America of the Program or of any information about the Program which are imposed by the government of the United States of America. 3. NO RSA OBLIGATION. You are solely responsible for all of your costs and expenses incurred in connection with the distribution of the Program hereunder, and RSA shall have no liability, obligation or responsibility therefor. RSA shall have no obligation to provide maintenance, support, upgrades or new releases to you or to any distributee of the Program. 4. NO WARRANTY OF PERFORMANCE. THE PROGRAM AND ITS ASSOCIATED DOCUMENTATION ARE LICENSED "AS IS" WITHOUT WARRANTY AS TO THEIR PERFORMANCE, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF THE PROGRAM IS ASSUMED BY YOU AND YOUR DISTRIBUTEES. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU AND YOUR DISTRIBUTEES (AND NOT RSA) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 5. LIMITATION OF LIABILITY. EXCEPT AS EXPRESSLY PROVIDED FOR IN SECTION 6 HEREINUNDER, NEITHER RSA NOR ANY OTHER PERSON WHO HAS BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THE PROGRAM SHALL BE LIABLE TO YOU OR TO ANY OTHER PERSON FOR ANY DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING BUT NOT LIMITED TO ANY DAMAGES FOR LOST DATA, RE-RUN TIME, INACCURATE INPUT, WORK DELAYS OR LOST PROFITS, RESULTING FROM THE USE OF THE PROGRAM OR ITS ASSOCIATED DOCUMENTATION, EVEN IF RSA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 6. PATENT INFRINGEMENT OBLIGATION. Subject to the limitations set forth below, RSA, at its own expense, shall: (i) defend, or at its option settle, any claim, suit or proceeding against you on the basis of infringement of any United States patent in the field of cryptography by the unmodified Program; and (ii) pay any final judgment or settlement entered against you on such issue in any such suit or proceeding defended by RSA; provided, however, that RSA's indemnity obligations hereunder shall not exceed $5000, including the cost to RSA of defending or settling such suit or proceeding. The obligations of RSA under this Section 6 are subject to: (i) RSA's having sole control of the defense of any such claim, suit or proceeding; (ii) your notifying RSA promptly in writing of each such claim, suit or proceeding and giving RSA authority to proceed as stated in this Section 6; and (iii) your giving RSA all information known to you relating to such claim, suit or proceeding and cooperating with RSA to defend any such claim, suit or proceeding. RSA shall have no obligation under this Section 6 with respect to any claim to the extent it is based upon use of the Program in a manner other than that permitted by this Agreement. THIS SECTION 6 SETS FORTH RSA'S ENTIRE OBLIGATION AND YOUR EXCLUSIVE REMEDIES CONCERNING CLAIMS FOR PROPRIETARY RIGHTS INFRINGEMENT. NOTE: Portions of the Program practice methods described in and subject to U.S. Patents Nos. 4,218,582 and 4,405,829, issued to Leland Stanford Jr. University and Massachusetts Institute of Technology, respectively. Such patents are licensed to RSA by Public Key Partners of Sunnyvale, California, the holder of exclusive licensing rights. This Agreement does not grant or convey any interest whatsoever in such patents. 7. RESTRICTIONS ON FOREIGN RESHIPMENT. THIS LICENSE IS EXPRESSLY MADE SUBJECT TO ANY LAWS, REGULATIONS, ORDERS, OR OTHER RESTRICTIONS ON THE EXPORT FROM THE UNITED STATES OF AMERICA OF THE PROGRAM OR OF ANY INFORMATION ABOUT THE PROGRAM WHICH MAY BE IMPOSED FROM TIME TO TIME BY THE GOVERNMENT OF THE UNITED STATES OF AMERICA. YOU MAY NOT EXPORT OR REEXPORT, DIRECTLY OR INDIRECTLY, THE PROGRAM OR INFORMATION PERTAINING THERETO, EXCEPT TO CANADA PURSUANT TO SECTION 126.5 OF THE U.S. INTERNATIONAL TRAFFIC IN ARMS REGULATIONS. 8. TERM. The license granted hereunder is effective until terminated. You may terminate it at any time by destroying the Program and its associated documentation together with all copies, modifications and merged portions thereof in any form known to be in your possession. It will also terminate upon the conditions set forth elsewhere in this Agreement or if you fail to comply with any term or condition of this Agreement. You agree upon such termination to cease making copies of, using or distributing the Program and to destroy the Program and its associated documentation, together with all copies, modifications and merged portions thereof in any form known to be in your possession. 8. GENERAL a. This Agreement shall be governed by the laws of the State of California. b. Address all correspondence regarding this license to RSA's electronic mail address , or to RSA Laboratories ATTN: RSAREF Administrator 10 Twin Dolphin Drive Redwood City, CA 94065 -- Ed Carp erc at apple.com 510/659-9560 If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From collins at newton.apple.com Wed Sep 1 16:14:28 1993 From: collins at newton.apple.com (Scott Collins) Date: Wed, 1 Sep 93 16:14:28 PDT Subject: Non-Cash Schemes -- precedent? Message-ID: <9309012308.AA28734@newton.apple.com> This mornings (1 Sep 93) Wall Street Journal, page B2, Enterprise column: "'Scrip' ATMs Appeal to Growing Number of Retailers". The artical describes retailers who are installing ATM machines that hand out 'scrip', deducted from a clients account, for use in the stores. Less attractive to thieves, cheaper to build and maintain. A physical precedent for digital schemes ? Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From jet at netcom.com Wed Sep 1 18:39:29 1993 From: jet at netcom.com (J. Eric Townsend) Date: Wed, 1 Sep 93 18:39:29 PDT Subject: [EVENTS]: security related Message-ID: <9309020135.AA23537@netcom.netcom.com> [marginal interest to this list. -eric] Last update: 08/31/93 COMPUTER SECURITY EVENTS CALENDAR This file contains a list of upcoming computer security events. The absence or inclusion of any particular event does not imply criticism or endorsement by the National Institute of Standards and Technology or the sysop. Because of the nature of this material and how it is obtained, it is impossible to include every event. If you know of computer security events that are not listed, please send the conference/course literature to the following: Lawrence B. Keys National Institute of Standards and Technology Room A-216, Bldg. 225 Gaithersburg, MD 20899 DATE: 09/09/93 TITLE: 3rd International Virus Bulletin Conference LOCATION: Amsterdam SPONSOR: CONTACT: Editor, Virus Bulletin ADDRESS: 21 The Quadrant, Abingdon Science Park CITY_ST: Abingdon, OX14 3YS, UK PHONE: +44 (0)235 559935 DATE: 09/15/93 TITLE: Information Warfare Conference LOCATION: Montreal, CANADA SPONSOR: National Computer Security Association CONTACT: Michael E. Kabay, Ph.D. ADDRESS: P.O. Box 509 CITY_ST: Westmount, QC/H3Z2T6 CANADA PHONE: 514-931-6187 DATE: 09/20/93 TITLE: 16th National Computer Security Conference LOCATION: Baltimore, MD SPONSOR: NCSC and NIST CONTACT: NCSC, Attn: NCS Conference Secretary, AS11 ADDRESS: National Computer Security Center CITY_ST: Fort George G. Meade, MD 20755-6000 PHONE: (410) 850-0272 DATE: 10/04/93 TITLE: 4th USENIX UNIX Security Symposium LOCATION: Santa Clara, CA SPONSOR: USENIX Association CONTACT: USENIX Conference Office ADDRESS: 22672 Lambert Street, Suite 613 CITY_ST: El Toro, CA 92630 PHONE: (714) 588-8649 DATE: 10/04/93 TITLE: 13th Conference on Control, Audit & Security of Information Sys. LOCATION: Boston, MA SPONSOR: MIS Training Institute CONTACT: MIS Registration ADDRESS: 498 Concord St. CITY_ST: Framingham, MA 01701-2357 PHONE: (508) 879-7999 DATE: 10/04/93 TITLE: 2nd Annual Pacific Conference on Information Systems Auditing LOCATION: Seattle, WA SPONSOR: EDP Auditors Association & CANAUDIT Inc. CONTACT: CANAUDIT Inc. ADDRESS: P.O. Box 4150 CITY_ST: Simi Valley, CA 93093 PHONE: (805) 583-3723 DATE: 10/04/93 TITLE: Information Security Principles and Practices LOCATION: Fairfax, VA SPONSOR: Center for Professional Development (Gerorge Mason University) CONTACT: Catherine M. Hoover ADDRESS: Center for Professional Development (George Mason University) CITY_ST: Fairfax, VA 22030-4444 PHONE: (703) 993-2090 DATE: 10/04/93 TITLE: Recent Developments in Information Security LOCATION: Fairfax, VA SPONSOR: Center for Professional Development (George Mason University) CONTACT: Catherine M. Hoover ADDRESS: Center for Professional Development (George Mason University) CITY_ST: Fairfax, VA 22030-4444 PHONE: (703) 993-2090 DATE: 10/12/93 TITLE: UNIX Security LOCATION: Fairfax, VA SPONSOR: Center for Professional Development (George Mason University) CONTACT: Catherine M. Hoover ADDRESS: Center for Professional Development (George Mason University) CITY_ST: Fairfax, VA 22030-4444 PHONE: (703) 993-2090 DATE: 10/20/93 TITLE: 10th World Conference on Computer Security, Audit & Control LOCATION: Westminster, London, UK SPONSOR: Compsec International CONTACT: Karen Giles ADDRESS: Elsevier Advanced Technology, Mayfield House, 256 Banbury Road CITY_ST: Oxford OX2 7BR, United Kingdom PHONE: +44 (0) 865 512242 DATE: 10/25/93 TITLE: Protecting Networks and Small Systems LOCATION: Gaithersburg, MD SPONSOR: CSI, Hosted by NIST (gov. employees/contractors only) CONTACT: CSI Conference Registration ADDRESS: 600 Harrison St. CITY_ST: San Francisco, CA 94107 PHONE: (415) 905-2626 DATE: 10/28/93 TITLE: Building Information Security Awareness LOCATION: Gaithersburg, MD SPONSOR: CSI, Hosted by NIST (gov. employees/contractors only) CONTACT: CSI Confrence Registration ADDRESS: 600 Harrison St. CITY_ST: San Francisco, CA 94107 PHONE: (415) 905-2626 DATE: 11/01/93 TITLE: 7th USENIX Systems Administration Conference (LISA VII) LOCATION: Monterey, CA SPONSOR: USENIX CONTACT: USENIX Conference Office ADDRESS: 22672 Lambert St., Suite 613 CITY_ST: Lake Forest, CA 92630 PHONE: (714) 588-8649 DATE: 11/03/93 TITLE: 1st ACM Conference on Computer and Communications Security LOCATION: Fairfax, VA SPONSOR: Bell Atlantic & George Mason University CONTACT: Ravi Ganesan ADDRESS: Bell Atlantic, 7th floor, 11720 Beltsville Dr. CITY_ST: Beltsville, MD 20705 PHONE: (301) 595-8439 DATE: 11/08/93 TITLE: 20th Annual Computer Security Conference & Exhibition LOCATION: Anaheim, CA SPONSOR: Computer Security Institute CONTACT: CSI Conference Registration ADDRESS: 600 Harrison St. CITY_ST: San Francisco, CA 94107 PHONE: (415) 905-2626 DATE: 12/01/93 TITLE: 4th Annual EICAR Conference LOCATION: St. Alabans, Hertfordshire, ENGLAND SPONSOR: Eicar CONTACT: Ms. Allison Sweeney ADDRESS: S&S International Ltd., Berkley Ct. Mill St. CITY_ST: Berkhamsted, Herts, HP2 4HW, England PHONE: +44 442 877877 DATE: 12/06/93 TITLE: 9th Annual Computer Security Applications Conference LOCATION: Orlando, FL SPONSOR: Aerospace Computer Security Association CONTACT: Dr. Ronald Gove ADDRESS: Booz-Allen & Hamilton, 8283 Greenboro Drive CITY_ST: McLean, VA 22102 PHONE: (703) 902-5280 DATE: 01/04/94 TITLE: 4th IFIP Working Conference on Dependable Computing for Critical LOCATION: San Diego, CA Applications SPONSOR: IFIP Working Group CONTACT: Dr. Gerard Le Lann, INRIA -Project REFLECS ADDRESS: BP 105 CITY_ST: 78153 Le Chesnay Cedex, FRANCE PHONE: + (33) 1 39 63 53 64 DATE: 02/04/94 TITLE: Internet Society Symposium on Network and Distributed Sys. Sec. LOCATION: San Diego, CA SPONSOR: Internet Society CONTACT: Robert W. Shirey, MS Z202 ADDRESS: Mitre Corp. CITY_ST: McLean, VA 22102-3481 PHONE: (703) 883-5397 DATE: 05/17/94 TITLE: 6th Annual Canadian Computer Security Symposium LOCATION: The Ottawa Congress Centre SPONSOR: The Canadian System Security Centre (Government of Canada) CONTACT: Karen Lowther ADDRESS: Canaian System Security Center, P.O. Box 9703, Terminal CITY_ST: Ottawa, Ontario K1G 3Z4 PHONE: (613) 991-7513 DATE: 06/14/94 TITLE: IEEE Computer Security Foundations Workshop VII LOCATION: Franconia, NH SPONSOR: IEEE Computer Society CONTACT: Ravi S. Sandhu ADDRESS: ISSE Department, George Mason University CITY_ST: Fairfax, VA 22030-4444 PHONE: (703) 993-1659 DATE: 10/04/94 TITLE: 1st European Dependable Computing Conference LOCATION: Berlin, GERMANY SPONSOR: Joint Technical Interest Group CONTACT: Erik Maehle, University of Paderborn/FB14 ADDRESS: Warburgerstr. 100 CITY_ST: D-W-4790 Paderborn GERMANY PHONE: ++49 (5251) 602209 From nowhere at bsu-cs.bsu.edu Wed Sep 1 18:44:30 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Wed, 1 Sep 93 18:44:30 PDT Subject: Info Security News article on Clipper (fwd) Message-ID: <9309020143.AA06952@bsu-cs.bsu.edu> Info Security News Volume 4, Number 5 September/October 1993 page 14 --- D.C. Dateline --- New Crypto Standards in Contention by Charlotte Adams Experts are hotly debating the Clipper initiative, a plan to standardize on a voice-encryption device with built-in law-enforcement access. Although de facto or mandatory acceptance of Clipper or similar hardware now seems remote, the potential cost of such action makes it worth considering. The rationale for Clipper was to maintain the government's information-eavesdropping capability as the use of encryption spreads. The hope was that the market would follow the government's lead, making Clipper the de facto standard. The National Institute of Standards and Technology sees benefits in making Clipper the accepted standard. "If we deny [criminals] the use of the national communications net, [that's a] nontrivial accomplishment," says Ray Kammer, NIST's acting director. If the network standard is Clipper, he reasons, criminals would "have to set up their own [communications] system, an interesting and formidible task." NIST is pushing ahead with a proposed Escrowed Encryption Standard. If all goes well, this Federal Information Processing Standard could be in place by October, an important step toward widespread use by the federal government. The key-escrow mechanism should be in place by autumn, government sources say. A related issue is NIST's Digital Signature Standard, which was developed in secret by the National Security Agency. NIST added a new issue to the DSS debate last summer when the agency announced a proposed settlement with Public Key Partners giving PKP control over commercial use of the standard. Clipper pros and cons. The key-escrow concept, allowing access to law-enforcment agencies, will have to become mandatory because it makes no sense on a voluntary basis, critics say. "It clearly has implications for data transmission, as well," says Phil Karn of Qualcomm, a San Diego maker of cellular telephones. Government contractors, in fact, are already fine-tuning another chip, called Capstone, which will be much more convenient for data-security applications. Capstone will add the NIST's secure hash, digital signature and key-exchange algorithms to Clipper's Skipjack encryption algorithm and escrow support. "Clipper is good for voice, for telephony, but not as a coprocessor inside a PC, selectively encrypting fields," says Richard Ankney, a technical consultant with Fischer International Systems Corp. "Capstone is better in that regard." The trouble with Capstone is that it is big and expensive, a full custom, very-large scale-integration ciruit design, says John Droge, vice president of program development for chip designer, Mykotronx Inc., of Torrance, Calif. VLSI Technology Inc., in San Jose, is actually fabricating the chip. Mykotronx expects the chips initially to sell at $100 apiece in quantities of 10,000. PCMCIA (Personal Computer Memory Card International Association) cards initially will sell in the $300 range, he predicts. That's a far cry from the government's $100 target price for the PCMCIA module. If the hardware becomes mandatory, space would have to be found for the chips inside notebooks and palmtops, as well as in laptop and desktop computers. Estimates on the markup to customers vary from 25 to 200 percent. The cost of retrofitting Clipper or Capstone into existing machines would be tremendous, says Fred Gluck, director of marketing for control products with Datamedia Corp., a Nashua, N.H. security software and token vendor. Simply multiply the $25 to $30 per half-hour you pay for technical people times the 100 million or so PCs out there, he says. But much of the cost may be hidden from the end user, Ankney counters. "You could take the hit and not raise the price at all." The Digital Signature Standard. Although eclipsed by the Clipper controversy, DSS nevertheless remains an issue. Even though its algorithm is not secret, NSA "played a very dominant role" in creating it, says David Sobel, legal counsel for the Computer Professionals for Social Responsibilty. The secrecy surrounding NSA's role in DSS goes beyond the will of Congress in the Computer Security Act of 1987 for the "[standards] development process to be open and accountable," Sobel says. The PKP angle is also a problem, CPSR says. The arrangement by which NIST allows PKP to control commercial use of the Digital Signature Standard "really comes down to ... almost paying them off," says Marc Rotenberg, director of CPSR's Washington office. People shouldn't read too much into the proposal, NIST says. "It means ... the government wants to move on and get this out of the way ... without any acknowledgement of [the validity of the PKP] infringement action," explains F. Lynn McNulty, NIST's associate director for computer security. The "big payoff" of the proposed agreement is that individual citizens communicating with the government won't have to pay royalties, he says. More information needed. Almost everyone agrees that more information is necessary before a policy decision can be made. "Are we talking about completely revamping the communications infrastructure to facilitate 800 wiretaps?" asks Daniel Weitzner, senior counsel for the Electronic Frontier Foundation. EFF coordinates the activities of the Digital Privacy and Security Working Group, a coalition of information security technology companies and non-profit groups that has raised many questions about Clipper. "We want a real, solid understanding of the problems from [the administration's] perspective and a fact-based risk assessment," Weitzner says. NIST's own security and privacy advisory panel refused to rubberstamp the Clipper initiative at first sight and various interest groups have demanded a more thoughtful and open review. The Digital Privacy and Security Working Group has been asked to contribute substantively to the ongoing interagency crypto policy review, EFF's Weitzner says. CPSR, however, is forming its own policy review group. The administration's approach of taking outside imput is still essentially a closed process, CPSR says. "The point we're trying to make [is that] the public has an interest in its privacy and consumers have an interest in what they ultimately might end up paying, " Rotenberg says. ---------------------------------------- Charlotte Adams is a free-lance journalist covering technology issues in the Washington D.C. area for a variety of magazines. Copyright (c) 1993 by MIS Training Institute Press, Inc. Ye olde Spooge Meister spooge /spooj/ 1. Inexplicable or arcane code or random and probably incorrect output from a computer program. From mark at coombs.anu.edu.au Wed Sep 1 20:36:49 1993 From: mark at coombs.anu.edu.au (Mark) Date: Wed, 1 Sep 93 20:36:49 PDT Subject: general purpose telnet bouncer. Message-ID: Several people have expressed interest in a utility such as this. It's existed for several years but Ive recently decided to fix it up into a releasable condition. Share and enjoy. flames to /dev/null Mark mark at cairo.anu.edu.au ---------------------- cut here ---------------------------- /* Name: ts2.c */ /* Author: Hal-9000, Richard Stevens, Xanadude, Avalon, Mark */ /* Distribution: Public */ /* Copyright: Held by the respective contributors */ /* Posted to USENET 1st September '93 by Mark mark at cairo.anu.edu.au */ /* This file was telserv.c, part of the Telnet Server package v. 1.0, written by "Hal-9000". Much of that package was developed by Richard Stephens and his thanks go to "Xanadude" for providing him with that section. Performance fix by Darren Reed. */ /* Reworked to add concurrency, password checking and destination selection on the fly. - Mark 31st Aug 93 Compiled and tested on: HPUX 9.01 9000/700 series NeXTStep 3.1 NeXT 68040 OSx Pyramid 90x BSD universe SunOS 5.2 sun4c Ultrix 4.3 DEC RISC To compile, type "cc -O -s ts2.c -o ts2". MY_PASSWORD and SERV_TCP_PORT are all that is required to be altered. */ #define MY_PASSWORD "pass" #define SERV_TCP_PORT 12345 /* port I'll listen for connections on */ #include #include #include #include #include #include #include #include #include #include #include #include #define QLEN 5 char sbuf[2048], cbuf[2048]; extern int errno; extern char *sys_errlist[]; void reaper(); int main(); void telcli(); int main(argc, argv) int argc; char *argv[]; { int srv_fd, rem_fd, rem_len, opt = 1; struct sockaddr_in rem_addr, srv_addr; bzero((char *) &rem_addr, sizeof(rem_addr)); bzero((char *) &srv_addr, sizeof(srv_addr)); srv_addr.sin_family = AF_INET; srv_addr.sin_addr.s_addr = htonl(INADDR_ANY); srv_addr.sin_port = htons(SERV_TCP_PORT); srv_fd = socket(PF_INET, SOCK_STREAM, 0); if (bind(srv_fd, (struct sockaddr *) &srv_addr, sizeof(srv_addr)) == -1) { perror("bind"); exit(-1); } listen(srv_fd, QLEN); close(0); close(1); close(2); #ifdef TIOCNOTTY if ((rem_fd = open("/dev/tty", O_RDWR)) >= 0) { ioctl(rem_fd, TIOCNOTTY, (char *)0); close(rem_fd); } #endif if (fork()) exit(0); while (1) { rem_len = sizeof(rem_addr); rem_fd=accept(srv_fd, (struct sockaddr *) &rem_addr, &rem_len); if (rem_fd < 0) { if (errno == EINTR) continue; exit(-1); } switch(fork()) { case 0: /* child process */ close(srv_fd); /* close original socket */ telcli(rem_fd); /* process the request */ close(rem_fd); exit(0); break; default: close(rem_fd); /* parent process */ if (fork()) exit(0); /* let init worry about children */ break; case -1: fprintf(stderr, "\n\rfork: %s\n\r", sys_errlist[errno]); break; } } } void telcli(source) int source; { int dest; int found; struct sockaddr_in sa; struct hostent *hp; struct servent *sp; char gethost[100]; char getport[100]; char string[100]; bzero(gethost, 100); sprintf(string, "Password: "); write(source, string, strlen(string)); read(source, gethost, 100); gethost[(strlen(gethost)-2)] = '\0'; /* kludge alert - kill the \r\n */ if (strcmp(gethost, MY_PASSWORD) != 0) { sprintf(string, "Wrong password, got %s.\n", gethost); write(source, string, strlen(string)); close(source); exit(0); } do { found = 0; bzero(gethost,100); sprintf(string, "Host: "); write(source, string, strlen(string)); read(source, gethost, 100); gethost[(strlen(gethost)-2)] = '\0'; hp = gethostbyname(gethost); if (hp) { found++; #if !defined(h_addr) /* In 4.3, this is a #define */ #if defined(hpux) || defined(NeXT) || defined(ultrix) || defined(POSIX) memcpy((caddr_t)&sa.sin_addr, hp->h_addr_list[0], hp->h_length); #else bcopy(hp->h_addr_list[0], &sa.sin_addr, hp->h_length); #endif #else /* defined(h_addr) */ #if defined(hpux) || defined(NeXT) || defined(ultrix) || defined(POSIX) memcpy((caddr_t)&sa.sin_addr, hp->h_addr, hp->h_length); #else bcopy(hp->h_addr, &sa.sin_addr, hp->h_length); #endif #endif /* defined(h_addr) */ sprintf(string, "Found address for %s\n", hp->h_name); write(source, string, strlen(string)); } else { if (inet_addr(gethost) == -1) { found = 0; sprintf(string, "Didnt find address for %s\n", gethost); write(source, string, strlen(string)); } else { found++; sa.sin_addr.s_addr = inet_addr(gethost); } } } while (!found); sa.sin_family = AF_INET; sprintf(string, "Port: "); write(source, string, strlen(string)); read(source, getport, 100); gethost[(strlen(getport)-2)] = '\0'; sa.sin_port = htons((unsigned) atoi(getport)); if (sa.sin_port == 0) { sp = getservbyname(getport, "tcp"); if (sp) sa.sin_port = sp->s_port; else { sprintf(string, "%s: bad port number\n", getport); write(source, string, strlen(string)); return; } } sprintf(string, "Trying %s...\n", (char *) inet_ntoa(sa.sin_addr)); write(source, string, strlen(string)); if ((dest = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("telcli: socket"); exit(1); } connect(dest, (struct sockaddr *) &sa, sizeof(sa)); sprintf(string, "Connected to %s port %d...\n", inet_ntoa(sa.sin_addr), ntohs(sa.sin_port)); write(source, string, strlen(string)); #ifdef FNDELAY fcntl(source,F_SETFL,fcntl(source,F_GETFL,0)|FNDELAY); fcntl(dest,F_SETFL,fcntl(dest,F_GETFL,0)|FNDELAY); #else fcntl(source,F_SETFL,O_NDELAY); fcntl(dest,F_SETFL,O_NDELAY); #endif communicate(dest,source); close(dest); exit(0); } communicate(sfd,cfd) { char *chead, *ctail, *shead, *stail; int num, nfd, spos, cpos; extern int errno; fd_set rd, wr; chead = ctail = cbuf; cpos = 0; shead = stail = sbuf; spos = 0; while (1) { FD_ZERO(&rd); FD_ZERO(&wr); if (spos < sizeof(sbuf)-1) FD_SET(sfd, &rd); if (ctail > chead) FD_SET(sfd, &wr); if (cpos < sizeof(cbuf)-1) FD_SET(cfd, &rd); if (stail > shead) FD_SET(cfd, &wr); nfd = select(256, &rd, &wr, 0, 0); if (nfd <= 0) continue; if (FD_ISSET(sfd, &rd)) { num=read(sfd,stail,sizeof(sbuf)-spos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { spos += num; stail += num; if (!--nfd) continue; } } if (FD_ISSET(cfd, &rd)) { num=read(cfd,ctail,sizeof(cbuf)-cpos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { cpos += num; ctail += num; if (!--nfd) continue; } } if (FD_ISSET(sfd, &wr)) { num=write(sfd,chead,ctail-chead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { chead += num; if (chead == ctail) { chead = ctail = cbuf; cpos = 0; } if (!--nfd) continue; } } if (FD_ISSET(cfd, &wr)) { num=write(cfd,shead,stail-shead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { shead += num; if (shead == stail) { shead = stail = sbuf; spos = 0; } if (!--nfd) continue; } } } } ----------- end of file ------ cut here ------- From ld231782 at longs.lance.colostate.edu Wed Sep 1 22:25:07 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Wed, 1 Sep 93 22:25:07 PDT Subject: NSA response to EFF Clipper Q's Message-ID: <9309020522.AA09539@longs.lance.colostate.edu> An EFF Online newsletter previously reported highlights from a list of questions submitted to the NIST/NSA regarding Clipper. That entire document is now available on ftp.eff.org in pub/EFF/legislation/clipper-answers. It makes reference to attachments on chip specifications that are not present in the text file. Overall, the document has rather numerous typographical errors for a government document, and it's unclear whether this is the result of the EFF scanning or whether they are in the original document. Also, at this point in the swift-moving arena, the responses are fairly dated, coming out long before the close of the expert review of the algorithm and a CSSPAB meeting at the end of July. Items in this review of the Clipper comments: - encryption regulation - constitutionality - Mycotronx, VLSI rationale, history of Clipper - Presidential directive & review procedure - key escrow in software - history of Skipjack - identification information in key escrow databases - notes on wiretap protocol - NSA cryptographic control wish list - Capstone capabilities - policy review - Clipper: a status report Encryption Regulation --- The major revelation in this document as reported here previously is the statement that the Administration has progressed far enough in the `policy review' to determine that `regulating private encryption' would be `imprudent' and `drastic' and that no new legilsation will be proposed to `limituse of encryption technology'. Unfortunately, in the characteristically maddening bureacratic doublespeak of the NSA, the previous statements suggest that this is the case only `because these measures may be sufficient to make key escrow encryption [widespread]'. Nevertheless the statement is extremely significant given various ominous sound bites in the media that suggested very clearly that cryptographic regulation was definitely `on the table' for consideration. Constitutionality --- The other major revelations as reported in the EFF document are the explicit attention to constitutional issues. However, the response is not very meaningful except to deny that any are relevant. In particular, it does not indicate the constitutionality of any enforcement or regulation in the area. >The key escrow technology only ensures that government agencies, will be >able to decrypt intercepted communications when lawfully authorized. It >neither expands nor contracts federal, state or local law enforcement >authority to access and decrypt communications. The key escrow technology >simply assures the continued feasibility of lawful electronic surveillance >under statutes that have long since been determined to be constitutional. Mostly the document is just a reformulation of the following idea in various ways: >it became clear >that a strategy was needed that could accommodate the needs of the private >sector for top notch communications security; of U.S. industry to remain >competitive in the world's secure communications market; and of U.S. law >enforcement to conduct lawfully-authorized electronic surveillance. Clearly, the writers' favorite words are `authorized' and `lawful' and here we are doubly reassured. Mycotronx, VLSI --- Here are a few other significant details in the response. For the first time there is official confirmation that the proposal goes back far previous to the Clinton administration: >The logic design contract for the microcircuit was awarded to MYKOTRONIX, >Inc. of Torrance, California, in late 1991 Mykotronx was chosen because: >This company provided a >unique combination of (i) expertise to quickly design custom cryptographic >chips, (ii) secure facilities, and (iii) the cleared personnel (At the TOP >SECRET level) necessary for the successful execution of the contract >requirements. Which makes me wonder. Has anyone with any serious sway in the NSA noticed the stolen Mycotronx documents yet? I would love to see the response to an FOIA inquiry on this one. Do they care? Did any heads roll at Mycotronx? >VLSI Technology of San Jose, California, was chosen as the chip foundry >based primarily on its technological capabilities to fabricate >microcircuits resistant to reverse engineering Selection of the vendors was >in accordance with U.S. government rules for sole source procurement. >other manufacturers that wish to enter the market and can satisfy the >technology and security requirements will be approved to manufacture these >microcircuits. Here we have the highly implausible suggestion that other companies will be considered to manufacture the microcircuits. Fat chance. Presidential Directive --- The document gives more detail about the Presidential Review Directive and Presidential Decision Directive behind Clipper. >The PRD called for interagency studies examining a number >of issues including, for example, the impact of the key escrow strategy and >the feasibility of implementing the key escrow technique in software. >Another issue to be addressed in the course of the review is the impact of >advanced telecommunications on law enforcement. While analogous in the >sense that both encryption and advanced telecommunications technology can >impede the effectiveness of authorized law enforcement electronic >surveillance, the two technologies present different issues and are being >treated separately. The results of the reviews are expected early this >fall. Hence, the `feasibility of implementing the key escrow technique in software' is `under review.' Later in the document, we have the point: >Because software is easy to change, secure software implementations of the >key escrow technique have been difficult to devise. We would welcome the >participation of the software industry in a cooperative effort to meet this >technical challenge. of course, users may continue to use existing >software encryption products. I don't recommend cooperating with the NSA in trying to devise `secure software' -- first of all, the suggestion that they will even have `security' in chip hardware is a fantasy and illusion; secondly, software is inherently free and unchained and nothing the NSA invents can ever change that; thirdly, cooperating with the NSA can be hazardous to one's economic health; and finally, probably no one in the NSA seriously believes that secure software implementations are possible, and are just throwing this out for cynical effect. Skipjack --- Information on SKIPJACK, confirming suggestions by some (e.g. A. Walker on sci.crypt) that the algorithm is based on earlier defense-oriented schemes in a long line of development: >Was the encryption algorithm specifically designed for the key escrow >initiative? > >No. The algorithm chosen for the key escrow microcircuit was originally >developed by NSA for use in U.S. government communications systems, albeit >not in the management of our nuclear arsenal as some have speculated. >Essentially the same cryptographic technology was under government >development and analysis for more than ten years. Although NSA does not >comment on the details of its design and analysis, the algorithm has >undergone intense expert scrutiny comparable to that used in the analysis >of cryptography intended for classified government systems. While the >algorithm was originally developed for unclassified defense systems, it >will be considered for certain classified applications in the future. Key Escrow Databases --- What about identification associated with keys in the databases? The NSA is in a catch-22 here. If there is nothing but serial numbers in a database, how do the key escrow agencies ensure that key IDs requested for wiretapping are associated with the given entities named in warrants? If they are present, how could such a scheme be maintained in anything other than an Orwellian Totalitarian Dystopia? The following is the first explicit commitment to total lack of identification information in the databases: >Some have expressed concerns that personal information could be contained >in the key escrow databases. The only information held by a key escrow >agent will be the chip serial numbers and the key component associated with >that number. Since the information in the key escrow databases will not be >associated with any particular individual, the database would be of no use >in identifying individuals or otherwise obtaining personal information >about them. Therefore, a key escrow agent will have no information about >the person owning or using equipment containing a microcircuit for which it >holds keys. Requests for a key component will be for a particular chip >identification number. No information regarding the identity of the target >of the authorized electronic surveillance will be provided to the key >escrow agents. Wiretap Protocol --- Interestingly, they say that when a wiretapped device is moved to a new phone number, they don't have the authority to tap it any longer: >If the subject of A surveillance were to move the device to another >location (and another telephone number), law enforcement authorities could >not legally monitor communications at other locations. This is because, as >noted above, electronic surveillance of wire or electronic communications >must be directed at some identifiable telephone, cellular telephone, or >computer facility. Therefore, before law enforcement authorities can >legally monitor any other telephone number in an effort to locate the >subject's encryption device, they must first satisfy a court that there is >probable cause to believe that illegal communications will occur over that >line. Major criticism is based on the fact that once a given key has been released, a phone is forever in the future insecure. For the first time we have the assurance >As added protection, law enforcement will have access to a key only so long >as it has authority to conduct a surveillance. Systems are being designed >to ensure that keys are destroyed when the authority to conduct a >particular electronic surveillance has expired. NSA wish list --- We get a wish list of realms in which the NSA would like to control domestic cryptography: >Concerns have been expressed about use of this key escrow technology and >these chips, in particular, across the panoply of new emerging >technologies, such as ISDN, TDMA, Cellular, CDMA Cellular, ATM, SONET, >SMDS, etc. Don't forget PEM -- D.D. gets really excited about that one. >It impossible to design key escrow encryption techniques that >are almost totally transparent to the system, given the transmission media >together with its propagation characteristics. Optimally, the system >should be designed with the encryption, if possible. The government intends >to work cooperatively with industry toward this end. Yes, just what every cryptography company wants, their personal NSA consultant breathing down their circuits. Capstone Capabilities --- Here's some notes on Capstone. Most capabilities also indicated by D.D. in her writings: >In addition to the key escrow technology contained in the >encryption-only chip, the enhanced chip also includes a Digital Signature >Algorithm proposed by NIST as a FIPS; a Secure Hashing Algorithm (SHA) >recently approved as FIPS 180; a Key Exchange Algorithm based on a public >key exchange, a general purpose exponentiation algorithm; and a general >purpose, random number generator which uses a pure noise source. This chip >is now being considered for installation in PCMCIA electronic cards and for >use in the Defense Messaging System. Personally, I wonder if the NSA intends to phase out Clipper from the beginning. The implementation could encrypt the law enforcement field under that more low-level chip. The Capstone chip will be the NSA's little `black box' miracle in every machine. Policy Review --- Finally, there are the indications that the `policy review' done in the Fall will cover the exportability of key escrow and the future cryptographic export control policy in the country concerning `marketability and foreign competition'. While everyone is desperate for a breakthrough here, the likely announcement will be that `no export restrictions will be placed on Clipper' and since the technology is completely suitable for all cryptographic applications (smirk) no other cryptographic devices will be approved for export. That's my guess, anyway. Clipper: a status report --- Current progress report on Clipper: the most serious hurdles for the NSA right now are imposing the Clipper FIPS standard and the DSA patent arrangement with PKP. The NSA has long demonstrated its complete obliviousness and imperviousness to public opinion no matter how loud or negative (consider early DSS endorsement). However, for the previous two standards, it has reached unprecedentedly screeching levels. The government will find it *extremely* difficult to go ahead with either in the face of almost uniformly hostile reception to both. Doing so is likely to raise a much larger outcry and warrant more desperate approaches on the side of the opposition (ala Zimmermann's `guerilla cryptography'). The future revelations in the DSS, Clipper, and `policy review' topics will be critical in indicating whether the NSA will take a more low-key and unobtrusive stance in regulation of domestic cryptography, with the original Clipper announcment its boldest step ever, or whether it will become even more paranoid and volatile in attempting to control and strangle natural, evolving domestic cryptographic developments. If you value your freedom, pray for the former. From sameer at netcom.com Thu Sep 2 00:46:51 1993 From: sameer at netcom.com (Sameer Parekh) Date: Thu, 2 Sep 93 00:46:51 PDT Subject: REMAIL: Alpha testers for installation script Message-ID: <9309020744.AA03586@netcom.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- At the urging (urging, bah!-- I *wanted* a task-- He could've probably seen it in my eyes) of Eric Hughes, I have been working on a script so that the installation of an anonymous remailer (with PGP) is as easy as typing install_remail. At this point it works *flawlessly* on *my* system, so I'd like to see how it works on other systems. This is still an interim version, however, for it is not idiot proof. A small typo (such as mistyping the pathname of your pgp executable) will mean that you have to start over. That will change, but probably in another version. I want to get this out as quickly as possible so that more remailers can pop up like wildfire, and *then* I'll work on idiot-proofing it, so that *everyone* with a UNIX account and crypto-anarchist leanings (no matter their tech-expertise) can be running a remailer. This script in the non-idiot-proof version needs that ~/.forward and ~/remail both don't exist. If you'd like to help me test this thing, and see if it works on your system, please mail me, with some info about your system and your tech expertise. (So I know what to expect.) (I'm setting Reply-To: to both this account and cs60a-qu at cory.eecs.berkeley.edu, because cs60a-qu is where the install_remail-installed remailer is running there. [It may go down at any moment, so it would be appreciated if people could use it and test it, but at this point it wouldn't be wise to rely on it for anything important.]) Peace, - -- Sameer sameer at netcom.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIWkQwvya0ihLgutAQENqgP+LR6cdm5Wy4jD6Ohl1g5iCR2JweTQRxPP 1AQ5KzW7MbRFhbO9l6wizSkYZE9emDR3YmpWTCZx2tpw+JucBk2C3GwtC4nMkY72 r7hgYwmwb41Fqe1MmfEzwAkvViYyRKSBhTxB869+54DYviHJ87jdxGG1gxxY5gmT uYNwHag7m7o= =IaYF -----END PGP SIGNATURE----- From gg at well.sf.ca.us Thu Sep 2 02:20:09 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 2 Sep 93 02:20:09 PDT Subject: NY TAXES CYBERSPACE, CRAM REACTS Message-ID: <93Sep2.021540pdt.14287-4@well.sf.ca.us> Yeah, I agree the tax is stupid, and I would certainly hope that some of the affected parties get together and start some kind of lawsuit on the basis of the discriminatory preference for paper media... ...but for God's sake, let's not sink to the level of calling for the assassination of elected officials... aside from the obvious legal issues, that puts us on *their* level. -gg From remailer at netcom.com Thu Sep 2 05:46:54 1993 From: remailer at netcom.com (remailer at netcom.com) Date: Thu, 2 Sep 93 05:46:54 PDT Subject: new remailer Message-ID: <9309021239.AA15429@mail.netcom.com> Well not _that_ new. I've been operating it since Sunday. I am operating this remailer out of my personal account. It's interface is identical to the standard cypherpunks remailer as defined by the code I ftp'd from soda.berkeley.edu. I've modified the code to fit it to my particular administrative situation, so you should consider this remailer EXPERIMENTAL. Remailer Address: catalyst at netcom.com Remailer PGP Key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyBTjoAAAEEAMIKpRnqXb82TOQpx/vEDwGPXndXaxtfiZeSLZqullWCEbd4 YkCHG/F1i3Wzq4Pgz6nSbb58vMS5RonY7+ZC6IHI8zBpp9oMW3u+lqbk8Z61x49d xwAKlE7Zsk/pOeGrqbsidm83WUqlSGgyOpvq0A8LzT4+WPra8ZvHue9jwOpJAAUR tChBbm9ueW1vdXMgUmVtYWlsZXIgPGNhdGFseXN0QG5ldGNvbS5jb20+ =MgMa -----END PGP PUBLIC KEY BLOCK----- Any message that has a header line of the form Request-Remailing-To: somebody at somewhere -- either in the header or with the header pasting operator (::) -- will get remailer handling. If a message does _not_ include any remailer commands, then it must actually be a message to catalyst at netcom.com (me). The message will subsequently be delivered to me. Note: badly-formed remailer commands may be equivalent to _no_ commands at all, and thus your message will be delivered to me, instead of getting remailed! I WARNED YOU. Comments, problems, questions > catalyst at netcom.com. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From klbarrus at owlnet.rice.edu Thu Sep 2 05:54:40 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Thu, 2 Sep 93 05:54:40 PDT Subject: MISC: cut & choose Message-ID: <9309021251.AA11969@flammulated.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- Earlier I mentioned cut-and-choose protocols as a way of protecting from signing a message that you really don't want to (ways of forging signatures on documents). The protocols are simple and rest on a probabalistic argument (similar in some ways to the "proof" in a zero-knowledge proof) - you can be certain to any degree you wish that you are not about to sign a harmful document. Essentially, Bob makes multiple copies of the document and appends random bits on the end of each. Then, he blinds each document with a different blinding factor, and presents all the copies of the blinded documents to Alice. But before she signs anything, she demands that all documents are unblinded, except one. Bob complies and produces the unblinding factor for all the documents except one, and unblinds them. Alice looks over the documents to verify their content, and if she is satisfied, she goes ahead and digitally signs the remaining document, which is still blinded. For example, say Alice is a digital bank. Bob wants to get $10 of digital cash, so he prepares a message, blinds it, and goes to the bank. However, Alice, who has read about the notary protocol, is leery of signing random strings, so Bob goes home again and prepares 100 messages, 100 blinding factors, and blinds each message with its own blinding factor. He shows up at the bank and gives Alice all the messages. Alice picks one message and hands back the other 99, demanding that Bob unblind them. So he complies, and Alice verifies that they all are in fact messages for $10. Satisfied, she digitally signs the last message, knowing that there still is a 1% chance that Bob cheated the bank by slipping in a $100 message with the $10 messages. So Alice can feel as comfortable as she likes by just asking for more messages. Say that cash messages look like this (with random bits at the end): This is $10 of digicash legal tender from First Digital. ADF!#$%@^%&gsu$ When Bob blinds this, it becomes unreadable so Alice can't verify that it is in fact a legitimate message (Bob may be trying to get Alice's signature on another document). But Bob does need to blind the message or the bank (Alice) can note the random bits, serial number, or whatever, and thus correlate the cash with him. The solution is the above protocol, which leaves an 1/n chance of fooling the bank, where n is the number of messages. Alice can ask for n messages where n is large, but there will still be a 1/n chance that Alice picks the special message and is tricked into signing it. (Say Bob slips in a message for $1000 into a bunch of $10 messages; he may get really lucky and have Alice pick the $1000 message, demanding he unblind all the rest to reveal $10 messages). However, this can get pretty expensive to implement for high confidence levels. Again, I'm sure a document forgery can't occur with PGP or even RIPEM (in the notary protocol manner) since neither program blinds messages: they calculate hashes, compress, encrypt, digitally sign hashes, but don't obscure messages by a multiplication factor. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIVz4YOA7OpLWtYzAQH0lgQAl3QZ6GFbWntDzuk+CKrkGyealZvHXlu5 stiq3OY+svoQCNRa2TjwJKS6htWsgqeYT4YUFwFV8YtfofavKqUGpuhveC3T5kjH DyKK9Ha1IVjrl5mX4uyz089nU45lQqKJKXCiplDLezRLiB1avVZmIyhdqOyB158W WTjwedeXUVo= =nzAD -----END PGP SIGNATURE----- From klbarrus at owlnet.rice.edu Thu Sep 2 05:56:54 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Thu, 2 Sep 93 05:56:54 PDT Subject: KOH: disassembly Message-ID: <9309021253.AA12012@flammulated.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- About the KOH virus/program: I've receive two disassemblies of the program (but not the original source code yet; I haven't had a chance to try to contact the author). I'm not sure that either person who mailed me the disassembly wants to take credit for it, publically at least :-) so I'll just thank them here for their work, and answer questions in email (although one of the disassemblies includes an email address). One person indicated that KOH really isn't a virus at all, so maybe this can be answered by folks who know more about such matters than I do! Apparently the fast encryption method is indeed an XOR; other than that I haven't had a chance to look over the code. I am interested in the IDEA implementation that KOH includes. So, if you are interested in copies of the disassembly, let me know. I had one report that KOH locked up an 8088 PC from a tester (thanks!). I'd try to post something intelligent about the code but I just haven't looked at it enough to comment. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIV0DYOA7OpLWtYzAQFP0wP+KrWx2hlne9XRdwOi/3uL//6sy7Bus69U ZvBD7OVUTa9NQEjwlSRlUHEQq/WKnPVZwGhqXLMyIXz6A+DaMTt1NgsQ/RnbHNT0 I9tDUYnSOMA84LRYPP14ZFW+1tWdPtLFI3mOumVr/RyEhz7PJnkKdFVPoCZYWZd9 a9n3yF6YKV0= =X0M4 -----END PGP SIGNATURE----- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From klbarrus at owlnet.rice.edu Thu Sep 2 05:58:16 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Thu, 2 Sep 93 05:58:16 PDT Subject: MISC: DH key xchange Message-ID: <9309021252.AA12006@flammulated.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- Earlier somebody (Samuel Pigg?) asked for a D-H key exchange reference. It should be in any modern crypto textbook, and is easy to follow. Alice and Bob want to exchange keys over a hostile channel. They pick a prime p, a random number a, and exchange this information. Alice picks Ra, a random number less than p, and keeps it secret. Bob picks Rb, also a random number less than p. Alice calculates Ya = a^Ra mod p, and sends the result to Bob. Bob calculates Yb = a^Rb mod p, and sends the result to Alice. To recover the common key Alice and Bob will now use with each other, they raise the result the other person sent them to their secret random number, and take the result modulo p. That is, Alice calculates Yb^Ra mod p, and Bob calculates Ya^Rb mod p. Even if an eavesdropper gets a, p, and the intermediate Ya and Yb, the final key cannot be determined (due the difficulty of the discrete logarithm). Example: 1) Alice and Bob pick a = 11, p = 347 2) Alice picks Ra = 240 Bob picks Rb = 39 Alice and Bob keep Ra and Rb secret 3) Alice calculates Ya = a^Ra mod p = 11^240 mod 347 = 49 Bob calculates Yb = a^Rb mod p = 11^39 mod 347 = 285 4) Alice sends Bob Ya = 49 Bob sends Alice Yb = 285 5) Alice calculates Yb^Ra mod p = 285^240 mod 347 = 268 Bob calculates Ya^Rb mod p = 49^39 mod 347 = 268 Now Alice and Bob can communicate using their common key. Even if an enemy intercepts a = 11, p = 347, Ya = 49, and Yb = 285, the common key cannot be calcuated. (Well, they can here since I'm using small numbers, but with large numbers the discrete log problem is intractable). -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIVzxYOA7OpLWtYzAQGzvQQAltkJR3xd/5YJt1pBt2/fWmCrRGqy0RFW ZZEL5ZHUNO9glaYOA39vUlRbZX8IDwHwKSDXJt98NsHH3WT5JJ0i52hy37mcWLOx 7FbsCo8MMjg2xOye3YLLzXa6a99ad5nV7/rk2pL+9mP0lNZdFcWGnfDvz/F5gqCF qMRAYby1KI8= =6ZSd -----END PGP SIGNATURE----- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From astrashe at nyx.cs.du.edu Thu Sep 2 07:50:12 1993 From: astrashe at nyx.cs.du.edu (Alex Strasheim) Date: Thu, 2 Sep 93 07:50:12 PDT Subject: CRM, a new remailer's utility Message-ID: <9309021447.AA16276@nyx.cs.du.edu> I've just written an msdos utility called CRM that I'd like to offer to the public for testing. CRM is supposed to make use of the encrypted cypherpunk remailers as simple as possible. This is how it works: you tell crm the name of the input (plaintext file), and the address of the person you want to send it to, and crm will affix the "Request-Remailing-To:" and "Encrypted: PGP" headers to the document and perform nested encryptions with PGP. It wraps the result in a /bin/sh script that will mail the cypher text to the first remailer on the chain when it's executed. If you did one of these on your msdos computer: crm tfile astrashe at nyx.cs.du.edu You'd end up with a file called tfile.crm that would contain the shell script. Then if you uploaded that to your unix account, and typed: sh < tfile.crm The message would be sent to me through a chain of encrypted remailers. A random list of of of crm's features: You can specifiy the subject line in the original text file, or crm will prompt you for it. You can put the destination address in the command line, or you'll be prompted for that as well. Output (.crm) files can be concatenated to make a single long script that will send more than one letter. The subject-line is embedded in the ciphertext. The number of links in the chains and the list of possible remailers is contained in a text file that can be located anywhere on the path. Crm is writen in turbo pascal 5.5 and the source comes with it. I wrote it all yesterday (except for some recycled code fragments), so it's kind of quick and dirty. If anyone would be willing to take a look at this, I'd be grateful. Once I'm convinced it's reliable (it *seems* reliable now) I'll upload it to soda. If you're interested, email me at astrashe at nyx.cs.du.edu and I'll send you a uuencoded version through the mail. Please put CRM in the subject of your letter so that it doesn't get lost in the shuffle. Thanks. Alex astrashe at nyx.cs.du.edu From felix at hu.se Thu Sep 2 08:26:56 1993 From: felix at hu.se (Felix Ungman) Date: Thu, 2 Sep 93 08:26:56 PDT Subject: ViaCrypt export? Message-ID: <199309021523.AA24790@mail.swip.net> Will ViaCrypt consider exporting pgp? (well, I think I can guess the answer ;-) However, pgp is already widely used outside USA (at least as many as the US users, I suspect). It would be interesting to know what they're going to do about it. There exists no country boundaries in cyberspace, you know! ---------------------------------------------------------------------- - RealName: Felix Ungman InterNet: felix at hu.se AppleLink: SW0358 - - Felix gor det goda godare! - ---------------------------------------------------------------------- From plmoses at unix.cc.emory.edu Thu Sep 2 09:46:58 1993 From: plmoses at unix.cc.emory.edu (Paul L. Moses) Date: Thu, 2 Sep 93 09:46:58 PDT Subject: NY tax on info services (whatever that means) Message-ID: <9309021642.AA22892@emoryu1.cc.emory.edu> I was sloppy in stating the test for a Commerce Clause problem with this law. Hopefully this is a bit more accurate: - First ask, Does this law affect interstate commerce? How and to what extent? - Then ask, Does the law burden interstate commerce in any way? - Next, Does the law have a discrete benefit to State (ie NY State) interests? - Finally, does the benefit to NY interest outweigh the burden on interstate commerce? Is the state interest more significant? Two caveats: - This is not offered for any purpose other than mere speculation and intellectual analysis. - Free legal advice is worth exacty what you pay for it. Paul From nowhere at chaos.bsu.edu Thu Sep 2 10:49:42 1993 From: nowhere at chaos.bsu.edu (Chael Hall) Date: Thu, 2 Sep 93 10:49:42 PDT Subject: Chaos up and running Message-ID: <9309020948.AA00514@chaos.bsu.edu> I know, long time, no post... Well, I have been very busy this summer. The end result is that my machine (chaos) is finally online. I will be running an anonymous remailer (maybe more than one) from this site and intend to run a pseudonymous system like anon.penet.fi here. I have implemented it and need a little help incorporating PGP encryption. The machine is in a secure area and is under the exclusive control of me. At the moment, I am prepared to provide accounts to those who are willing to help improve the system in some way. If you feel that you can contribute, there are several avenues by which you can do so. For example (this is not an exhaustive list): 1. Upload cypherpunks-related files to the anonymous FTP area. 2. Telnet or rlogin to chaos.bsu.edu (147.226.53.28) and login as guest. Follow the instructions to request an account. 3. Write me (nowhere at chaos.bsu.edu or root at chaos.bsu.edu or nowhere at bsu-cs.bsu.edu or chall at bsu.edu or 00CCHALL at bsuvc.bsu.edu) with a request for an account. If you choose either option two or three above, please tell me what you intend to accomplish through having this account and in what positive ways your having an account will impact my system. Odds are, you will be accepted. There is great potential in having this system on the Internet. I am creating a mail server to aid in discussion about the direction that chaos is going to head. Anyone who would like input on this please send a request to be put on the mail server and I will set it up when we get a few brains together. This is just a quick note (it's lunchtime in Indiana) so if I glossed over anything or neglected to mention something, let me know. The following addresses might be of interest to you: remailer at chaos.bsu.edu anon.ping at chaos.bsu.edu and anon.help at chaos.bsu.edu For a list of anon.* addresses for specific functions, finger anon at chaos.bsu.edu We were having some lookup problems since chaos has only been online for two days... Please mail my nowhere at bsu-cs.bsu.edu account if you cannot access the system for any reason. Thanks, Chael Hall -- Chael Hall nowhere at chaos.bsu.edu Chaos Unlimited nowhere at bsu-cs.bsu.edu From julf at penet.FI Thu Sep 2 12:06:58 1993 From: julf at penet.FI (Johan Helsingius) Date: Thu, 2 Sep 93 12:06:58 PDT Subject: ViaCrypt export? In-Reply-To: <199309021523.AA24790@mail.swip.net> Message-ID: <9309022035.aa15531@penet.penet.FI> > Will ViaCrypt consider exporting pgp? O Precisely what I was asking myself. > There exists no country boundaries in cyberspace, you know! Boy, do we know! Julf From frissell at panix.com Thu Sep 2 12:24:42 1993 From: frissell at panix.com (Duncan Frissell) Date: Thu, 2 Sep 93 12:24:42 PDT Subject: Anonymous Credentials Message-ID: <199309021920.AA03784@panix.com> To: cypherpunks at toad.com Another good argument in favor of anonymous credentials... A person of my acquaintance who was long ago "seduced by the dark side of the Force" tells me that there is a lucrative market in ID copies supplied by people working in the personnel departments of companies. When new employees come with their birth certificates, SSN cards, driver's licenses, etc and their completed I-9 forms as required by the '86 Immigration Act, the clerk will take them to the copy machine, hit the button twice, pocket the extra set of copies, sell the ID package to a credit borrower or ID craftsman. All sorts of juicy info is there in one place. It's great. Duncan Frissell Who will fool them all one day (and make the former Prince jealous) by changing his name to ASCII 7 so that bells will ring whenever a database accesses it. --- WinQwk 2.0b#0 From frissell at panix.com Thu Sep 2 12:25:17 1993 From: frissell at panix.com (Duncan Frissell) Date: Thu, 2 Sep 93 12:25:17 PDT Subject: Digital Cash Experiment Message-ID: <199309021920.AA03777@panix.com> To: cypherpunks at toad.com Boy, you give people free money and they don't even use it. Last Saturday, I posted the codes from a $5 Western Union phone card. That is good for 8.3333 minutes of domestic long distance service. Some people told me that they made calls on the card (and one generous soul even sent me the codes from another $5 card in encrypted E-mail). The 8 minutes in calls weren't, however, used up until today when I killed the last minute myself. You can't even give money away. Have all of you been to your local Western Union money transfer agent and bought your phone cards for convenient anonymous (when made from payphones) LD calls. Today's NYT also featured a story about the similar Sprint phone cards (everyone and their uncle is issuing them these days). Sprint cut a deal with Hallmark whereby you will be able to buy $6 greeting cards with a 10 minute Sprint phone card inside so your recipient can call you back. This makes the calls 60 cents/minute which is the going rate for domestic LD calls on these cards. And, yes this is a cypherpunks topic because it represents an anonymous telecommunications account (of sorts). Duncan Frissell The Economist has been tracking the price of a market basket of commodities since it was founded in the 1840s. In the summer of 1991, the (inflation adjusted) price of those commodities fell to the lowest level ever observed. I guess we aren't running out of things. --- WinQwk 2.0b#0 From panzer at drown.slip.andrew.cmu.edu Thu Sep 2 13:26:58 1993 From: panzer at drown.slip.andrew.cmu.edu (Panzer Boy) Date: Thu, 2 Sep 93 13:26:58 PDT Subject: Anon IRC (Anonymous vs. Private) Message-ID: I have been running an Anonymous IRC server for a short time now. This allows a real time conversation, as opposed to the monologue provided via netnews or mail. Currently, when a user logs in, the internal (and external) representation of the user is: NICKNAME!user at anon.host Users have the ability to change their Nickname, and all other people have to identify people is by their Nickname. People who have used IRC for awhile have told me that this would promote anarchy on the channels, because it makes it impossible to ban/ignore certain people from conversations. So my fix is going to be running users Hostname through a one-way hash function. So references to users will be: NICKNAME!user at HASH(Real-Hostname) The question is, what kind of hash do it use? My first idea was to use a hash function that has many collisions, a simple "summing" of the ascii characters. This would make sure that people would have certain ID's, and ban/ignore would work. This would also make it harder to be sure you had the correct host if you were going to try to brute force out a users hostname. A couple other people have suggested using a hash function that is much more complex. So that no collisions will occur, and all users will have unique "ID's" associated with their Nickname. If collisions occur, it is ok. Just the possibility for banning/ignoring people you don't intend goes up. Any suggestions on this one? I was also thinking of allowing users to come on the system as NICK!user at anon.host and then switch between that, and their NICK!user at HASH(Real-Host). This would allow people to be both completely anonymous or, if they wanted, have and identity attached to themselves. This way people could ban/ignore anyone at "anon.host" if they didn't want to deal with "anonymous" people. To connect to my server, load up an IRC client, and change your server to "drown.slip.andrew.cmu.edu". In standard clients, "/server drown.slip.andrew.cmu.edu", is how to do this. For more information about irc, ftp to CSA.BU.EDU. -Matt panzer at drown.slip.andrew.cmu.edu From cs60a-qu at monoceros.EECS.Berkeley.EDU Thu Sep 2 14:04:45 1993 From: cs60a-qu at monoceros.EECS.Berkeley.EDU (Sameer Parekh) Date: Thu, 2 Sep 93 14:04:45 PDT Subject: Two new remailers Message-ID: Here are the keys for the two new remailers I have set up, sameer at netcom.com, and cs60a-qu at cory.eecs.berkeley.edu. Because I'm still working on the installation script, they will probably disappear for short periods of time, but they're semi-permanent now. (I haven't tested the netcom.com one yet, I just ran my script. I'm hoping that it works!) Here are the keys: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQCNAiyGXXoAAAEEAMDtjyzGpLKugc49+Na4GZcUZ1Q1jyZYeofTdNwlTIbs4bGY OaeFCXaQluD4ANsLn9muMVae+q+3gZsIq14klQLO6Xe55pZ0Efx5shfFU24S9+xA RUrDfMMqD5TtaoBXH9aQBV9mVo0h5Pxu6ng9B0A+GPJg/ygdVqW95EIJnjMRAAUT sAEAtCVTYW1lZXIncyBSZW1haWxlciA8c2FtZWVyQG5ldGNvbS5jb20+sAEAmQCN AiyE6CgAAAEEALqDVb9/znhvoG0jMgFv1ezJWNKyC5XbXnO6DvbucHvqFsLHSYuQ txtrKVsuk2yGturMVWFAmnH8xCmpf0wUWIVzydNQbg4IB6/FzJ/ZdwXWmvvUJi2R 6IKJB0PGDhiWpRwfHrLthcuzXwxK0buWGW6BAFAcLV0ipEwhnnhSVnRJAAURtDNT YW1lZXIncyBSZW1haWxlciA8Y3M2MGEtcXVAY29yeS5FRUNTLkJlcmtlbGV5LkVE VT4= =eqRW -----END PGP PUBLIC KEY BLOCK----- From greg at ideath.goldenbear.com Thu Sep 2 16:34:46 1993 From: greg at ideath.goldenbear.com (Greg Broiles) Date: Thu, 2 Sep 93 16:34:46 PDT Subject: Who generates AOCE keys? Message-ID: <5qP09B1w164w@ideath.goldenbear.com> Scott Collins (collins at newton.apple.com) writes: (re AOCE, and who generates users' key pairs) >What I gathered from actually using this software is that you personally >generate a key pair, on your own machine, and then transparently send your >public key to RSADSI. Some time later, you receive a certificate (with an >expiration date) that allows your 'signer' to function. RSADSI does not >make, or even see, your private key. and Mitch Ratcliffe (godsdog at netcom.com) writes, in E-mail: (posted with permission) >While Apple will not cop to this, it is my understanding that users will >get certified keys from RSA. I have Very Good Sources on this. They can >generate a key for use on their network, but as part of the vision of the >paperless, collaborative economy, Apple believes you'll want publically- >certified keys. Well, Apple has failed to guess what I'll want. :) Perhaps the similarity of these two ideas (RSA generates keys & certificates, versus RSA gets public key & generates certificate) has generated confusion internally at Apple; I dunno. -- Greg Broiles greg at goldenbear.com Golden Bear Computer Consulting +1 503 342 7982 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764 From ebrandt at jarthur.Claremont.EDU Thu Sep 2 18:54:47 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Thu, 2 Sep 93 18:54:47 PDT Subject: REMAIL: list In-Reply-To: <9308312011.AA13862@flammulated.owlnet.rice.edu> Message-ID: <9309030152.AA04188@toad.com> After being largely off-line for most of the summer, I came back to find that my remailer had been bit-bucketing most encrypted messages, apparently due to PGP 2.3's lack of backward compatibility. (There'd better be a good reason for that, PGP team.) I'll get around to building 2.3 RSN. There will also be a momentary interruption of encryption service when this old Sequent machine gets swapped out from under the Sequent binary... PGP 2 key by finger or e-mail Eli ebrandt at jarthur.claremont.edu From tcmay at netcom.com Thu Sep 2 20:27:00 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 2 Sep 93 20:27:00 PDT Subject: Remailer Reliability In-Reply-To: <9309030152.AA04188@toad.com> Message-ID: <9309030322.AA20056@netcom5.netcom.com> Eli Brandt writes: > After being largely off-line for most of the summer, I came back to > find that my remailer had been bit-bucketing most encrypted messages, > apparently due to PGP 2.3's lack of backward compatibility. > (There'd better be a good reason for that, PGP team.) I'll get > around to building 2.3 RSN. There will also be a momentary > interruption of encryption service when this old Sequent machine > gets swapped out from under the Sequent binary... Glad to have Eli back! (and we missed you at the Extropaganza last weekend) This underscores one of the persistent problems with remailers: the generally flaky nature! (No insult or criticism intended...the folks who run remailers are to be commended, but the fact is that "multiple hop" remailing routes are are a real gamble these days, what with so many remailers temporarily or permanently disabled or (somehow) not passing messages through.) Karl Barrus's list of functional remailers is a great first step, but we need to somehow establish a better "market system" of remailers (digital postage woud be a boon here) so that the upness or downness of remailers would be more predictable. Like others, I suspect, I have to "ping" the remailers before sending anything, and then hope and pray they aren't taken offline for maintenance (or whatever) between the time I ping them and the time I use them for something important. If Sameer Parekh's "instant remailer" code multiplies the number of remailers by some factor, we will even more urgently need to deal with this issue of remailer reliability. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From barlow at eff.org Thu Sep 2 20:44:49 1993 From: barlow at eff.org (John Perry Barlow) Date: Thu, 2 Sep 93 20:44:49 PDT Subject: Crypto Greetings from Russia Message-ID: <199309030337.AA04757@eff.org> Jerry, I don't know if you saw this on its way through the office, but unless you have some objection, I'm going to invite this organization to join the Digital Privacy Working Group. There might be a lot of leverage gained from working the standards processes in the two countries against/with each other. I'm also interested in hearing if anyone in cypherpunks has heard of these folks or their product. FAX TRANSMISSION Date: 23 August, 1993 To: John P. Barlow Electronic Frontier Foundation Washington, DC, USA From: Anatoly N. Lebedev President LAN Cypto Moscow, Russia Phone/Fax: 095-936-7256 Subject: Digittal privacy working group Dear Mr. Barlow, I enjoyed your brilliant paper "Decrypting the Puzzle Palace" (Comm. ACM, vol.35, No.7, July 1992) very much. The situation with "the Russian NSA" or Federal Agency of the Government Communications and Information (FAGHI) is mostly the same as you describe there. So that I am in accord with the most parts of the paper. The company "LAN Crypto" is interested in becoming part of the digital privacy working group. "LAN Crypto" is the first Russian independent private company, which specializes in the development of information security systems and electronic documents transfer (electronic funds transfer, electronic checks, contracts, etc.) by means of cryptology. We have installed our software and the cryptological technology in more than 100 state and commercial banks in Russia, Belorussia and Kazakhstan. Our digital signature (we call it NOTARY) was recognized in April 1992 by the Suprime Arbitre Court of Russia. The first solution on electronic contract with our digital signature and conflict between the sides was made by the Moscow Arbitre Court 28 July 1993. NOTARY is a package of programs for electronic (digital) signing of PC files, revealing the identity of the author and assuring the integrity of such files. NOTARY employs advanced method of digital signing. The method is based upon the complex Discrete Logarithm Problem. NOTARY takes 0.2 sec for signing and 0.8 sec for checking the signature by AT-286/16MHz (secret key 512 bits). Now the works on national standard of digital signature in Russia also began. We work in this way actively with the other private companies and state organisations. We proposed to make the common standard for Russia and USA. This proposition was supported by the Information Technologies Department of the Russia State Committee of Standards. We've sent this proposal to the presidential team of the US President Mr. W. Clinton in Jan 1993. So I would be very glad to get from you any fresh information on DSS, because the last version we have gotten from our american partners was of Nov. 1992. We as a private company also propose some other packages of programs: VESTA (for encryption), which provides processing speed of 10 KBytes/sec on AT-286 (16MHz), ATHENA (for public-key generation), which takes less than 3 seconds for two users to generate a common secret key of 512 bits (using an AT-286 operating at 16MHz) (6.5 seconds for common key of 1024 bits), DIANA for strong and flexible access regulaton to files of databases. DIANA prevents an unauthorized access to information, contained in server or working station of LAN. It is based on encrypting of files and dynamic decrypting of them while working. All information between the server and the working station goes in an encrypted form. User of the working station uses a compact TSR-program. The key distribution system of DIANA does not have analoges in the world. To get more information on our programs you may connect with "LAN Crypto": 117630, Academician Chelomey St. 10-43, Moscow, Russia, phone/fax 095-936-7254 E-mail: lan at crypto.msk.su or with our representatives in the USA: Severtson and Associates 1901 Prytania, Suite 17 New Orleans, LA 70130 Phone 504/524-2256 or Dmitry Orlov San Francisco, CA 408/988-3832 E-mail: dimon at mcafee.com Regards, Anatoly N. Lebedev President LAN Crypto From mbriceno at aol.com Thu Sep 2 21:54:52 1993 From: mbriceno at aol.com (mbriceno at aol.com) Date: Thu, 2 Sep 93 21:54:52 PDT Subject: Crypto Greetings from Russia Message-ID: <9309030042.tn45384@aol.com> > We proposed to make the common standard for Russia and USA. This > proposition was supported by the Information Technologies Department > of the Russia State Committee of Standards. We've sent this proposal > to the presidential team of the US President Mr. W. Clinton in Jan > 1993. What an opportunity! We Cypherpunks should establish a link with LAN Crypto asap. ---Marc From ld231782 at longs.lance.colostate.edu Thu Sep 2 22:44:51 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 2 Sep 93 22:44:51 PDT Subject: Remailer Reliability In-Reply-To: <9309030322.AA20056@netcom5.netcom.com> Message-ID: <9309030539.AA16419@longs.lance.colostate.edu> tcmay at netcom.com (Timothy C. May) >Like others, I suspect, I have to "ping" the remailers before sending >anything, and then hope and pray they aren't taken offline for >maintenance (or whatever) between the time I ping them and the time I >use them for something important. C'punks, it seems to me that the anonymous pool idea is underutilized by the remailers. I suggest that a remailer variation be developed that posts to an anonymous pool (some appropriate obscure newsgroup) indicating that a message actually was sent from the final hop. The sender can be sure the message made it if they see this posting. If anyone wants to get even more fancy, the final remailer might also post to the pool when the message bounced to the final address back to the remailer. Obviously, without reliability the anonymity is worthless. From ld231782 at longs.lance.colostate.edu Thu Sep 2 23:44:52 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 2 Sep 93 23:44:52 PDT Subject: New Online Organization Message-ID: <9309030641.AA17507@longs.lance.colostate.edu> ===cut=here=== From: elrose at path.net (Lance Rose) Date: Thu, 2 Sep 1993 22:37:24 PDT Subject: New BBS Trade Group Formed NOMA National Online Media Association Contacts: Phill Liggett LIGGETT at delphi.com (203)233-3163 Lance Rose elrose at echonyc.com (201)509-1700 FOR IMMEDIATE RELEASE A new trade association, the National Online Media Association (NOMA), was formed at ONE BBSCON '93 in Colorado Springs on August 27th, 1993. NOMA comprises BBS operators, Internet service providers, and other online media and services. NOMA's mission is to act for the BBS and online service industry on matters of national importance by creating an industry presence in Washington, D.C. and other means; assist its members at the state and local levels; educate the public on the unique social, business and legal roles of BBS's and other online services; establish appropriate industry standards and guidelines; promote business development in the industry; and maintain and provide access to resources and industry information for use by the public and the industry. An 11 person Organizing Committee was elected to develop a proposal for NOMA's charter, bylaws, membership requirements, structure, and form of leadership. The proposal is to be completed and distributed within the BBS and online services industry by November 30th, 1993. Discussion areas are being set up immediately for those interested in participating in NOMA's early development. An Internet mailing list is available to all those interested at natbbs at echonyc.com (subscribe to natbbs-request at echonyc.com). A conference area is also being made available on the Delphi national information service. The members of NOMA's Organizing Committee are: Phill Liggett - Chairperson LIGGETT at delphi.com Joe Balshone BALSHONE at delphi.com Celeste Clark BBS #: (805)520-2300 Pat Clawson 76357.3572 at compuserve.com P. Victor Grambsch - Secretary PVICTOR at delphi.com Tony McClenny BBS#: (703)648-1841 Robert Pataki PUGDOG at delphi.com W. Mark Richmond BBS#: (209)685-8487 Steve Sprague steve.sprague at uboa.org Jim Taylor jim.taylor at F5.N310.Z1.FIDONET.ORG Bill Wilt wilt at aol.com In addition, three advisors agreed to assist NOMA's Organizing Committee: Mike Godwin, Esq. mnemonic at eff.org David Johnson, Esq. djohns06 at reach.com Lance Rose, Esq. elrose at echonyc.com For further information, please contact Phill Liggett, (203)233- 3163 or Lance Rose, Esq., (201)509-1700 Mailing Address: NOMA c/o Phill Liggett Solutions, Inc. 89 Seymour Avenue, West Hartford, CT 06119 ------- End of Forwarded Message From julf at penet.FI Fri Sep 3 00:24:53 1993 From: julf at penet.FI (Johan Helsingius) Date: Fri, 3 Sep 93 00:24:53 PDT Subject: Crypto Greetings from Russia In-Reply-To: <9309030042.tn45384@aol.com> Message-ID: <9309031018.aa18209@penet.penet.FI> > > We proposed to make the common standard for Russia and USA. This > > proposition was supported by the Information Technologies Department > > of the Russia State Committee of Standards. We've sent this proposal > > to the presidential team of the US President Mr. W. Clinton in Jan > > 1993. > > What an opportunity! We Cypherpunks should establish a link with LAN Crypto > asap. Whooaa! Slow.... Please remember that the former SU is full of "companies" that claim to be *the* whatever national initiative of Russia. Mostly they are just a couple of former research scientists with a Grand Plan, and usually they have no clue as to how to make it fly. They just think that with the new market echonomy, simply forming a company and having some Big Words will make them filty rich automatically... I know there are exceptions. But.. Beware. Julf From gg at well.sf.ca.us Fri Sep 3 03:37:03 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 3 Sep 93 03:37:03 PDT Subject: Digital Cash Experiment Message-ID: <93Sep3.033212pdt.14379-2@well.sf.ca.us> 60-cents per minute...? Is that the going rate on debit phone cards? Do you know any place I can call to find out more about these...? -gg From HAHN at lds.loral.com Fri Sep 3 04:55:28 1993 From: HAHN at lds.loral.com (Reply to: hahn@lds.loral.com) Date: Fri, 3 Sep 93 04:55:28 PDT Subject: Gubment Bombmaker's Cookbook Message-ID: <930903075125.42fd@lds.loral.com> Several days ago I made a post in response to the gentleman in Hartford's difficulty with the law. His problems stem from someone's posting to his BBS recipe(s) for bomb making. I mentioned, offhand, that a federal government publication exists containing such recipes. Mike Godwin responded asking for a citation, that it might be useful to the defense. OK, here it is: TM 31-210 Dept. of the Army Technical Manual Improvised Munitions Handbook published 1969 It contains chemical recipes for about a dozen explosive materials (both primary and secondary explosives) from easily obtainable ingredients, along with designs for fusing devices and explosive booby-traps. I have never tried any of these (to paraphrase Shel Silverstein, my eyes still see, my hair's unburned, and my fingers are still on my hands -- and I'd like to keep it that way), but my knowlege of chemistry and engineering convinces me that they all work. The book contains the disclaimer "For official use only" on nearly every page. It is, however, widely available at gun shows, which is where I got mine. I'll not reproduce any recipes here, but if the defence attornies for the gentleman in Hartford contact me and can prove who they are, I will be happy to share any info with them. __ | (V) | "Tiger gotta hunt. Bird gotta fly. | (^ (`> | Man gotta sit and wonder why, why, why. | ((\\__/ ) | Tiger gotta sleep. Bird gotta land. | (\\< ) der Nethahn | Man gotta tell himself he understand." | \< ) | | ( / | Kurt Vonnegut Jr. | | | | ^ | From jazz at hal.com Fri Sep 3 08:17:02 1993 From: jazz at hal.com (Jason Zions) Date: Fri, 3 Sep 93 08:17:02 PDT Subject: NY tax on info services (whatever that means) In-Reply-To: <2658ge$s93@hal.com> Message-ID: <9309031513.AA07974@jazz.hal.com> >I was sloppy in stating the test for a Commerce Clause problem with this >law. Hopefully this is a bit more accurate: > - First ask, Does this law affect interstate commerce? How and > to what extent? > - Then ask, Does the law burden interstate commerce in any way? > - Next, Does the law have a discrete benefit to State (ie NY State) > interests? > - Finally, does the benefit to NY interest outweigh the burden on > interstate commerce? Is the state interest more significant? If you read the text of the tax change, you'll find that it subjects no new services to taxation, it merely changes the tax rate they pay. This particular law does not increase the burden on any businesses other than how much tax they must collect; they already had to collect some, now they have to collect more. The specific tasks they had to perform stay the same, just some numbers get larger. You'd have to find and attack the original tax code changes that imposed taxes of any sort on comm-based info services. Good luck; probably NY just imposed a tax on all commerce where at least one party had nexus in NY, which swallowed up comm-based info services along with everyone else. Jason From karn at qualcomm.com Fri Sep 3 08:20:31 1993 From: karn at qualcomm.com (Phil Karn) Date: Fri, 3 Sep 93 08:20:31 PDT Subject: Gubment Bombmaker's Cookbook In-Reply-To: <930903075125.42fd@lds.loral.com> Message-ID: <9309031517.AA17002@servo> This is ridiculous. Have they never heard of The Anarchist's Cookbook? I've seen it on the shelf of the local large bookstore, though now I'm not sure whether I want to admit to buying a copy. Have they not yet discovered rec.pyrotechnics? Phil From baumbach at atmel.com Fri Sep 3 09:25:02 1993 From: baumbach at atmel.com (Peter Baumbach) Date: Fri, 3 Sep 93 09:25:02 PDT Subject: NY tax on info services (whatever that means) Message-ID: <9309031604.AA10266@octopus.chp.atmel.com> I have been studying the US constitution lately, and an excerpt from Article 1 Section 10 seems appropriate: No State shall, without the Consent of the Congress, lay any Imposts or Duties on Imports or Exports, except what may be absolutely necessary for executing its inspection Laws; and the net Produce of all Duties and Imposts, laid by any State on Imports or Exports, shall be for the Use of the Treasury of the Unites States; and all such Laws shall be subject to the Revision and Control of the Congress. In liberty, Peter Baumbach From mbriceno at aol.com Fri Sep 3 09:35:02 1993 From: mbriceno at aol.com (mbriceno at aol.com) Date: Fri, 3 Sep 93 09:35:02 PDT Subject: Crypto Greetings from Russia Message-ID: <9309031218.tn53668@aol.com> > Whooaa! Slow.... > > Please remember that the former SU is full of "companies" that claim > to be *the* whatever national initiative of Russia. Mostly they are > just a couple of former research scientists with a Grand Plan, and > usually they have no clue as to how to make it fly. They just think > that with the new market echonomy, simply forming a company and > having some Big Words will make them filty rich automatically... > > I know there are exceptions. But.. Beware. Thanks for telling me. I was not aware of that. However, they claim to have equipped quite a number of sites. I haved asked them for more info on their products. Let's see what they got. --Marc From julf at penet.FI Fri Sep 3 09:50:03 1993 From: julf at penet.FI (Johan Helsingius) Date: Fri, 3 Sep 93 09:50:03 PDT Subject: Crypto Greetings from Russia In-Reply-To: <9309031218.tn53668@aol.com> Message-ID: <9309031947.aa00502@penet.penet.FI> > Thanks for telling me. I was not aware of that. However, they claim to have > equipped quite a number of sites. I haved asked them for more info on their > products. Let's see what they got. Also, when talking about "quite a number" with regard to X-SU, remember the scale of things. Relcom/EUnet, the commercial IP network provider out there, has something like 120 POPs and 20,000 registered domains... And they consider themselves still in the start-up phase... Julf From cme at ellisun.sw.stratus.com Fri Sep 3 11:30:34 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Fri, 3 Sep 93 11:30:34 PDT Subject: Remailer Reliability Message-ID: <9309031826.AA09137@ellisun.sw.stratus.com> If you want reliability, you can take a page from the fault tolerance business. Replicate the remailers. (There are many papers on this topic. See, for example, ISIS from Cornell and Manetho from Rice.) Example: I send to r1 and r2. Each of r1 and r2 sends to r3 and r4. r3 and r4 each take the first message to arrive and drop the second. at the end of the chain, you have rm and rn. rm and rn each get the message (drop the second) and then decide between them who gets to post it. The one who gets to, does and tells the other that it's all done -- at which time the other drops its copy. Death detection is by time-out (but only rn and rm need to delay operation until the time-out -- to prevent multiple postings from a split-brain network.) Expensive (4x the message traffic) -- but fault tolerant. - Carl From an23135 at anon.penet.fi Fri Sep 3 12:57:05 1993 From: an23135 at anon.penet.fi (aragorn) Date: Fri, 3 Sep 93 12:57:05 PDT Subject: where can I get the source for BSD mail? Message-ID: <9309031952.AA21881@anon.penet.fi> I am looking for a copy of the source for BSD mail. Can anyone help me? ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From bill at twwells.com Fri Sep 3 13:15:05 1993 From: bill at twwells.com (T. William Wells) Date: Fri, 3 Sep 93 13:15:05 PDT Subject: Remailer Reliability In-Reply-To: <9309031826.AA09137@ellisun.sw.stratus.com> Message-ID: In article <9309031826.AA09137 at ellisun.sw.stratus.com>, Carl Ellison wrote: : If you want reliability, you can take a page from the fault tolerance : business. Replicate the remailers. If you're going to do that, why not go for extra security at the same time? Instead of transmitting the same message to all of the remailers, transmit different pieces to each and then reconstruct the original from whatever pieces you get. Done right, this could also be used to make traffic analysis harder. From edgar at spectrx.Saigon.COM Fri Sep 3 13:15:36 1993 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Fri, 3 Sep 93 13:15:36 PDT Subject: PGP features Message-ID: Brad Huntting recently posted: Perhaps it's time we polished the edges, added a few of the features that are lacking, and wrote up up an RFC for the PGP message format. Some features I'd like to see in PGP are: I've added my comments [with these full margins] as appropriate. The ability to send an encrypted message to multiple recipients without duplicating the entire message. The most logical way to do this would probably be to encrypt the random IDEA key once for each recipient. ??? This has been implemented in PGP since at least release 2.2. (Maybe 2.1, memory fails). Just specify multiple UserID fragments in the command line when encrypting. Note that if you don't specify a UserID in the command line, you -cannot- enter multiple ID's in the resulting prompt. This is in the -h help text: To encrypt a message for any number of multiple recipients: pgp -e textfile userid1 userid2 userid3 There needs to be a facility for having multiple signatures on a single document without making the signers sign each others signatures. Besides the obvious application of removing a signature from a document, this would also facilitate things like petitions where many people could asynchronously sign a single document, and latter assemble all the signatures together. This can be done via detached signature certificates, which can be gathered together and presented with the original document. To create a signature certificate that is detached from the document: pgp -sb textfile [-u your_userid] It should be possible (though certainly not mandatory) to hide the recipient's identity entirely. Not currently implemented, but being discussed. You can acheive much the same effect by using a another key-pair with a pseudonym in the UserID, to be distributed only through remailers or otherwise anonymously. The message format needs to allow for alternate forms of encryption (besides IDEA). Furthermore, the (shared key) algorithm used to encrypt a message should be hidden in the RSA encrypted part of the message along with the shared key. Ideally, a list of algorithms could be given which would allow the message to be optionally compressed before being encrypted, or encrypted two or more times with different algorithms. Not implemented, but has been mentioned. Triple-DES is one possible alternative. You can achieve multiple IDEA encryption by just using current PGP to encrypt twice (or more). Even if you encrypt to the same public key, the IDEA key used will be different. Compression can currently be turned off, if desired, via a CONFIG.TXT option, which can also be specified in the command line. Compression is also automatically turned off if the plaintext is recognized as the output of PKZIP or other popular compressors. If I'm confused and the PGP message format already supports some of these features, please correct me. Consider yourself corrected (:} -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca From jim at tadpole.com Fri Sep 3 13:25:05 1993 From: jim at tadpole.com (Jim Thompson) Date: Fri, 3 Sep 93 13:25:05 PDT Subject: where can I get the source for BSD mail? Message-ID: <9309032014.AA05116@tadpole.Tadpole.COM> Oh, several places. Look for the source to metamail (ask archie, or fish around on bellcore.com), and there is typically a 'tahoe.tar.Z' file around. Jim From nobody at eli-remailer Fri Sep 3 13:25:37 1993 From: nobody at eli-remailer (nobody at eli-remailer) Date: Fri, 3 Sep 93 13:25:37 PDT Subject: WANTED: List of very reliable remailers Message-ID: <9309032021.AA17759@toad.com> -----BEGIN PGP SIGNED MESSAGE----- I've been experimenting with the remailers lately, and I've been trying to put together all the tools I'll need to start sending most of my email through them. Towards this end, I wrote a simple program called CRM that adds forwarding tags, and calls PGP to do multiple encryptions, and then wraps the result in a /bin/sh script that will extract the cyphertext and do the mailing. In what is starting to look to me like a design flaw, I set the program up to pick a random chain of a specified length out of a set of remailers. All of this talk about remailer reliability has got me a little bit spooked, because I don't have any way of knowing if my mail is going through or not. I'd like to configure my remailer's utility so that it only uses a small list of *very* reliable remailers, preferably with each entry on the list being run by a distinct person. Are there any remailers which: o Support PGP encryption? o Have been in reliable operation for a significant period of time (at least a couple of months)? o Are maintained by someone who knows enough about the software to prevent it from crashing? o Don't introduce significant delays in the remailing? (Unless, of course, they are using some sort of scheme to frustrate traffic analysis.) and o Are set up on systems over which the remailer's administrator has enough clout to prevent a summary shutdown without at least giving a couple of days' notice? I'm assuming (for no very good reason) that Hal Finney's sites fit these criterium. If that's true, then strictly speaking, I'd only need one other similar site run by another person, although I'd feel better if I was using a chain through three remailers. Obviously, the more remailers I have on the list, the better off I am. But I'd rather have a small list of highly reliable remailers than a larger list than contains even a single marginal one. The list of remailers that I'm using now came from a list that was posted to this mail-list a few days ago, and I haven't had any problems with it (at least none that I know of -- I'm assuming that all of my mail went through). I just got a little worried about the post reporting dropped mail from the jarthur remailer administrator, which had been mentioned on the list I had been using as a reliable remailer. If anyone can help me out, I'd be grateful. Please post replies to the list, or mail me directly at: astrashe at nyx.cs.du.edu Thanks, Alex -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIejerGKvmrRrQghAQHvMQQA1Ez5Lxo1glHaJhvquvuti1WseFl4Nw5r g0qRfeWQFwSbZZtsFUiGs6f4iibj9lVpBwtmL8k7oTYRfCNLe+noi6TC0PChEeHt BKQmCAGTx5oPu2UtqXUvfFtb2MwqDXxNpX4BOd+klO6qPjBq6H8eG7GCNzSmeLp5 yr3ALw+qANg= =FSf4 -----END PGP SIGNATURE----- From banisar at washofc.cpsr.org Fri Sep 3 14:20:06 1993 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Fri, 3 Sep 93 14:20:06 PDT Subject: UK Privacy International Co Message-ID: <00541.2829920226.5141@washofc.cpsr.org> UK Privacy International Conference ANNOUNCEMENT ONE DAY PUBLIC CONFERENCE INTERNATIONAL DEVELOPMENTS IN PRIVACY AND DATA PROTECTION 30th SEPTEMBER, 1993, MANCHESTER, UK A roundtable hosted jointly by Privacy International and the Law School of the University of Manchester Topics include : Privacy concerns with Caller ID and digital phone services Privacy implications of Electronic Health Care Patient Record Systems and medical smart cards Cryptography, and communications surveillance Implications of the European Commission data protection directive The establishment of guidelines for handling police files in emerging democracies in Central and Eastern Europe Weaknesses in the UK Data Protection Act This programme will include a small number of papers and formal presentations, but will primarily be a forum for general discussion of the issues. A number of key international experts will be present at the meeting. The conference is free for all Privacy International members, independent experts, and privacy and consumer advocates. A fee of 50 (US$75) will apply to representatives of government organisations or companies. 8.30 AM - 2.00 PM, Thursday 30th September 1993 Room 2.22, The Law School, University of Manchester, Oxford Road, Manchester, M13 9PL For more information, please contact : Simon Davies at Privacy International in London on (44) 81 402 0737 or fax (44) 81 313 3726 (email : Davies @privint.demon.co.uk ) or Dave Banisar at Privacy International in Washington on (1) 202 544 9240, fax (1) 202 547 5482 (email : Banisar at washofc.cpsr.org ) From sameer at netcom.com Fri Sep 3 14:35:07 1993 From: sameer at netcom.com (Sameer Parekh) Date: Fri, 3 Sep 93 14:35:07 PDT Subject: Remailer Reliability In-Reply-To: <9309030539.AA16419@longs.lance.colostate.edu> Message-ID: <9309032129.AA02437@netcom.netcom.com> L. Detweiler said: > C'punks, it seems to me that the anonymous pool idea is underutilized > by the remailers. I suggest that a remailer variation be developed that > posts to an anonymous pool (some appropriate obscure newsgroup) > indicating that a message actually was sent from the final hop. The > sender can be sure the message made it if they see this posting. If > anyone wants to get even more fancy, the final remailer might also post > to the pool when the message bounced to the final address back to the remailer. That definitely looks like a wise idea. Maybe if I can figure it out, among the writing of the install-script I can add this little feature. Which newsgroup? Should someone create an alt.remail? How exactly would it be implemented? I'm thinking that simply the user would do: :: Request-Remailing-To: sameer at netcom.com Remail-ID: 572374237 And the remailer would post to alt.remail: Message with Remail-ID: 572374237 was remailed. Does that look good? -- Sameer sameer at netcom.com From ajw at Think.COM Fri Sep 3 14:35:41 1993 From: ajw at Think.COM (Andy Wilson) Date: Fri, 3 Sep 93 14:35:41 PDT Subject: programmer's lot Message-ID: <9309032131.AA10572@custard.think.com> [forwards deleted] >>From New Scientist, 28 august 93, Feedback column: >> >>"The National Westminster Bank admitted last month that it keeps >> personal information about its customers-such as their political >> affiliation-on computer. But now Computer Weekly reveals that a >> financial institution, sadly unnamed, has gone one better and moved >> into the realm of personal abuse. >> The institution decided to mailshot 2000 of its richest customers, >> inviting them to buy extra services. One of its computer programmers >> wrote a program to search through its databases and select its >> customers automatically. He tested the program with an imaginary >> customer called Rich Bastard. >> Unfortunately, an error resulted in all 2000 letters being addressed >> "Dear Rich Bastard". The luckless programmer was subsequently sacked." From eichin at paycheck.cygnus.com Fri Sep 3 15:05:14 1993 From: eichin at paycheck.cygnus.com (Mark W. Eichin) Date: Fri, 3 Sep 93 15:05:14 PDT Subject: Gubment Bombmaker's Cookbook In-Reply-To: <930903075125.42fd@lds.loral.com> Message-ID: <9309032004.AA02837@paycheck.cygnus.com> My copy says: For further information or additional inserts, contact: Commanding Officer Frankford Arsenal ATTN: SMUF A-U3100, Special Products Division Small Caliber Engineering Directorate Philadelphia, PA 19137 A friend got it for me at an Air Force PX, which was apparently open to the public. It's about 250 pages of newsprint in about 4"x5" format. I don't have convenient access to a scanner or I'd scan in a page or two -- there are sketches (improvised handguns, shaped charges, and such) as well as text. Some of the "easily obtainable ingredients" aren't any more, which shows the age of the book (one or two things use silver coins, which haven't been circulated since the early sixties.) Overall, though, the recipes use things that you can find. _Mark_ From miron at extropia.wimsey.com Fri Sep 3 15:05:46 1993 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Fri, 3 Sep 93 15:05:46 PDT Subject: Remailer Reliability In-Reply-To: <9309030322.AA20056@netcom5.netcom.com> Message-ID: <1993Sep3.203107.13987@extropia.wimsey.com> ld231782 at longs.lance.colostate.edu (L. Detweiler) writes: >C'punks, it seems to me that the anonymous pool idea is underutilized >by the remailers. I suggest that a remailer variation be developed that >posts to an anonymous pool (some appropriate obscure newsgroup) No need to change anything. Just add a pool address to the "Request-remailing-to:" line. -- Miron Cuperman | NeXTmail/Mime ok Unix/C++/DSP, consulting/contracting | Public key avail AMIX: MCuperman | From remail at tamsun.tamu.edu Fri Sep 3 15:45:16 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Fri, 3 Sep 93 15:45:16 PDT Subject: PEM vs. PGP formats Message-ID: <9309032237.AA18712@tamsun.tamu.edu> > On the other hand, in terms of anonymity, you can always generate a > self-signed key with TIS/PEM (I forget the exact term they use in the > TIS/PEM docs, but you can just make yourself a certificate which > doesn't really say anything about your identity). Yes, but this doesn't provide the service I desire. I *want* to be able to sign a message, but I *only* want the intended recipient to know who I am. PEM discloses the originator's ID *in the clear* when I send a signed message. PGP hides the signature and all other information that identifies me within the encrypted portion of the message! From nfe at scf.nmsu.edu Fri Sep 3 16:55:17 1993 From: nfe at scf.nmsu.edu (nfe at scf.nmsu.edu) Date: Fri, 3 Sep 93 16:55:17 PDT Subject: Gubment Bombmaker's Cookbook Message-ID: <9309032349.AA13638@NMSU.Edu> Most of the IMH has been typed in and posted on various BBS's - don't know of a FTP site for it though... IMH was originally a gvmt publication, and it's been reprinted by several of the R-wing paramilitary publisers (paladine press, desert publications, etc.) it has a ISBN number, can be found, and ordered via Books in print, however will be confiscated by customs at the canadian border as that sort of thing is contraban in canada - I don't know about england... For the address of some of the paramilitary publishers, and reviews of some of these books get a copy of the rec.pyrotechnics FAQ sheet. This includes pointers to FTP sites that have some online "bomb books"... btw: IMH is considered one of the more acurate, and safer books of this kind. The anarchist cookbook is generaly considered the most dangerous book to the prostective "kitchen chemist" in print... hope that helps ps: rec.pyrotechnics has posts of this type of formula all the time, and ANY decent library will have books on explosives. Older High School chem texts have recipies, and a good encyclopedia wil at least tell you how to make black powder. police bomb disposal, and pyrotechnics books are also good sources, as are theatrical special effect books. This type of info is widely available to anyone, anywhere! this court case is obviously pure harrasment. From M..Stirner at f28.n125.z1.FIDONET.ORG Fri Sep 3 17:05:17 1993 From: M..Stirner at f28.n125.z1.FIDONET.ORG (M. Stirner) Date: Fri, 3 Sep 93 17:05:17 PDT Subject: remailer reliability Message-ID: <2298.2C87C75D@shelter.FIDONET.ORG> Uu> C'punks, it seems to me that the anonymous pool idea is underutilized Uu> by the remailers. I suggest that a remailer variation be developed Uu> that posts to an anonymous pool (some appropriate obscure newsgroup) Uu> indicating that a message actually was sent from the final hop. I'm not absolutely clear on what you are suggesting, but I suspect that alt.test can probably be made to serve your purposes. Before the password mess on penet (which kills automagic replies, unfortunately, as they haven't passwords), I used the autoreplies that come form various US & foreign sites in response to alt.test postings as a good shakedown of penet remailer reliability. I haven't messed with alt.test in a while so have pretty much forgotten the drill, but it was definitely useful at the time. ********************************************************************* * - PGP Key D30909 via servers * * > What country can preserve its liberties if its rulers are not <* * > warned from time to time that their people preserve the spirit <* * > of resistance? Let them take arms!" - Thomas Jefferson, 1787 <* ********************************************************************* ___ Blue Wave/QWK v2.12 -- M. Stirner - via FidoNet node 1:125/1 UUCP: ...!uunet!kumr!shelter!28!M..Stirner INTERNET: M..Stirner at f28.n125.z1.FIDONET.ORG From b44729 at achilles.ctd.anl.gov Fri Sep 3 18:30:31 1993 From: b44729 at achilles.ctd.anl.gov (Samuel Pigg) Date: Fri, 3 Sep 93 18:30:31 PDT Subject: Remailer Reliability In-Reply-To: Message-ID: <9309040125.AA27752@achilles.ctd.anl.gov> >>>>> On Fri, 3 Sep 1993 19:30:10 GMT, bill at twwells.com (T. William Wells) said: bill> If you're going to do that, why not go for extra security at the bill> same time? Instead of transmitting the same message to all of the bill> remailers, transmit different pieces to each and then reconstruct bill> the original from whatever pieces you get. Done right, this could bill> also be used to make traffic analysis harder. By breaking a message into pieces and sending them via different paths to the same destination ("path forking"), this can only make traffic analysis easier, because all the pieces lead to the same destination, and you can follow any of them to get to the anonymous recipient. But there *is* a way this could be useful: implementing a "kill message" remailer command for pieces that have been forked off from the original message. This way, a message could split itself into pieces (or duplicate itself with a different header) and the attacker would have to determine which one to try to follow to the recipient (or follow them all), as only one will arrive there and the rest would die after a number of remailer hops. I really think that non-deterministic "smart messages" are the way to go here. A simple command language for the remailers would allow the header construction software already being worked on by ebrandt at jarthur.Claremont.EDU (CRM) and others to use tricks like this to defend against attacks. The defense complexity would be a function of the users' header construction software and needs. People who need "minimal" anonymity would have simpler anonymous address blocks, as compared to those who require "serious" anonymity, and the remailers themselves would have a lighter load (not having to implement very serious security for *all* messages-- just those that need it). "Smart messaging" would also have the added benefit of not requiring the remailers to be constantly rewritten as new schemes are conceived for foiling remailer attack (well, for the most part.) Sam Pigg dt1acaa at cfraix.cfr.usf.edu samp at renoir.cftnet.com b44729 at achilles.ctd.anl.gov PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C From nowhere at bsu-cs.bsu.edu Fri Sep 3 18:45:32 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Fri, 3 Sep 93 18:45:32 PDT Subject: net.history (flashback) Message-ID: <9309040143.AA26741@bsu-cs.bsu.edu> On Fri, 3 Sep 1993 02:20:00 GMT, Bill Murray writes - > I am reminded of a story, perhaps apocryphal. In the middle > seventies Fortune magazine was working a feature on computer > crime. Most of the experts that they interviewed told them > that the security on most of the nation's commercial time > sharing systems was pretty good. However, they admitted that > one convicted felon and hacker, Jerry Schnieder, would tell > them otherwise. Of course Fortune had to interview him. I remember this story, Bill, and I find this correlation interesting. It's funny how Schneider's name hasn't really surfaced in such a long time. In fact, once I think about the real parallels to Herren Doktor's lip service, I find it even frightening, given the anticipated impact with which her opinions seem to affect governmentalism. For what its worth, there was another interesting item concerning Schneider which appeared in Info Security News this issue, in their "Top Ten Events" article of the top ten info-security events since the inception of computers. I relay the pertinent portion of this article below: "Jerry Schneider was not the first computer crook, which he became at 18; nor was he the first computer security consultant, which he became at age 21. Still, his antics on both sides of the law helped bring computer crime to the awareness of the public in general and business managers in particular. Although still in high school in 1968, Schneider started a company called Creative Systems Enterprises and began selling electronic telecommunications gadgets he invented. Each day as he passed the Pacific Telephone and Telegraph Company office, he scavenged the firm's dumpster for discarded equipment that could be used to build his gadgets. He also collected a wide variety of documents, ranging from invoices to training manuals. Within just a few years, he became an expert on telephone company technology and business, and reportedly knew more about Pacific Telephone's telephone equipment supply procedures than any of its employees. In June, 1971, Schneider set into motion an elaborate plan to steal new telephone equipment from Pacific Telephone and resell it as refurbished equipment through Creative Systems. Eventually the scam would net him hundred of thousands of dollars worth of Pacific Telephone equipment. Scneider accessed Pacific Telephone's computerized ordering system and by using a telephone card dialer succeeded in placing orders for equipment. To complete the scam, he needed to learn the telephone equipment budgets for individual telephone company's sites, equipment inventory levels and other key pieces of information. He gathered the required information by getting access codes to a commercial time-sharing service used by the telephone company for inventory control and parts distribution. In January 1972, acting on information provided to them by one of Schneider's former employees, law enforcers raided Schneider's offices and a warehouse where they found equipment the district attorney said was worth $8,000. They also learned at that time that Schneider had stolen a total of $125,000 worth of equipment. Later, Schneider would admit that he had taken close to $900,000 worth of goods. The day after his arrest on February 8, 1972, newspapers across the country called it one of the most famous computer crimes ever. "How he Folded, Spindled, and Mutilated," one headline said. In a plea bargain, Schneider agreed to plead guilty to one count of grand theft of $5,000 worth of equipment. In July, he was sentenced to two monyhs in a minimum security corrections institution. In all, however, served 40 days and paid a $500 fine. Later that year, Schneider, then only 21 years old, formed a computer consulting firm catering to companies that did not want to get ripped off by cyber-crooks. He stayed in the business until 1977. Today, he owns a firm that sells off-shore banking services. 8<------ Gut Here --------------- Gee, imagine that. Ye olde Spooge Meister spooge /spooj/ 1. Inexplicable or arcane code or random and probably incorrect output from a computer program. From doug at netcom5.netcom.com Fri Sep 3 20:37:15 1993 From: doug at netcom5.netcom.com (Doug Merritt) Date: Fri, 3 Sep 93 20:37:15 PDT Subject: net.history (flashback) In-Reply-To: Message-ID: <9309040334.AA19172@netcom5.netcom.com> > Today, he owns a firm that sells off-shore banking >services. Sounds like he might be interested in cypherpunk topics; there's a connection to off-shore banking that goes further than the obvious. Anyone know anything about Schneider's firm or other such firms? I've always wondered how that works, what's legal and what's not, etc. Doug -- Doug Merritt doug at netcom.com Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow From albertson at attmail.com Fri Sep 3 21:07:17 1993 From: albertson at attmail.com (Todd Albertson ) Date: Fri, 3 Sep 93 21:07:17 PDT Subject: PGP features Message-ID: <9309040406.AA23747@toad.com> My feature list for PGP are simplier. I just want an integration of PGP into a commercial email package (such as Microsoft Mail or Lotus' CC Mail). It can't be that hard to do - can it? ---------- From: Edgar W. Swank To: Cypherpunks Subject: PGP features Date: Fri, Sep 3, 1993 11:46AM Brad Huntting recently posted: Perhaps it's time we polished the edges, added a few of the features that are lacking, and wrote up up an RFC for the PGP message format. Some features I'd like to see in PGP are: I've added my comments [with these full margins] as appropriate. The ability to send an encrypted message to multiple recipients without duplicating the entire message. The most logical way to do this would probably be to encrypt the random IDEA key once for each recipient. ??? This has been implemented in PGP since at least release 2.2. (Maybe 2.1, memory fails). Just specify multiple UserID fragments in the command line when encrypting. Note that if you don't specify a UserID in the command line, you -cannot- enter multiple ID's in the resulting prompt. This is in the -h help text: To encrypt a message for any number of multiple recipients: pgp -e textfile userid1 userid2 userid3 There needs to be a facility for having multiple signatures on a single document without making the signers sign each others signatures. Besides the obvious application of removing a signature from a document, this would also facilitate things like petitions where many people could asynchronously sign a single document, and latter assemble all the signatures together. This can be done via detached signature certificates, which can be gathered together and presented with the original document. To create a signature certificate that is detached from the document: pgp -sb textfile [-u your_userid] It should be possible (though certainly not mandatory) to hide the recipient's identity entirely. Not currently implemented, but being discussed. You can acheive much the same effect by using a another key-pair with a pseudonym in the UserID, to be distributed only through remailers or otherwise anonymously. The message format needs to allow for alternate forms of encryption (besides IDEA). Furthermore, the (shared key) algorithm used to encrypt a message should be hidden in the RSA encrypted part of the message along with the shared key. Ideally, a list of algorithms could be given which would allow the message to be optionally compressed before being encrypted, or encrypted two or more times with different algorithms. Not implemented, but has been mentioned. Triple-DES is one possible alternative. You can achieve multiple IDEA encryption by just using current PGP to encrypt twice (or more). Even if you encrypt to the same public key, the IDEA key used will be different. Compression can currently be turned off, if desired, via a CONFIG.TXT option, which can also be specified in the command line. Compression is also automatically turned off if the plaintext is recognized as the output of PKZIP or other popular compressors. If I'm confused and the PGP message format already supports some of these features, please correct me. Consider yourself corrected (:} -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca From doug at netcom5.netcom.com Fri Sep 3 21:17:15 1993 From: doug at netcom5.netcom.com (Doug Merritt) Date: Fri, 3 Sep 93 21:17:15 PDT Subject: Remailer Reliability Message-ID: <9309040413.AA23647@netcom5.netcom.com> sameer at netcom.com (Sameer Parekh) >install-script I can add this little feature. Which newsgroup? Should >someone create an alt.remail? How exactly would it be implemented? I'm >thinking that simply the user would do: > [...] > And the remailer would post to alt.remail: There are two problems here. One is that the remailer exposes itself and defeats traffic analysis avoidance. The other is a standard transaction processing sort of problem; the posting to alt.remail might fail even though all else worked. Although I've dealt with transaction processing problems, it's a tricky area, and I don't have a good text on the subject. Any recommendations? b44729 at achilles.ctd.anl.gov (Samuel Pigg) said: >By breaking a message into pieces and sending them via different paths >to the same destination ("path forking"), this can only make traffic >analysis easier, because all the pieces lead to the same destination, >and you can follow any of them to get to the anonymous recipient. Depends on how it's done. As stated this analysis implies that traffic analysis is *always* possible, since after all, the message must somehow make it to its destination. In other words, I disagree. Traffic analysers will have access to only some limited subset of information. If a certain kind of blind remailing with multiple pathways is practiced, then traffic analysis can be statistically defeated. The bad guys might sometimes know that X sent a message somewhere. Other times they might know Y received a message. Only improbably (under ideal implementation circumstances) would powerful bad guys own so many machines & networks that they would be able to deduce both sender and recipient, and even then, if traffic were heavy (as it will be in some years), it would be a statistical rather than certain deduction. (This of course raises the (no doubt old-hat) problem that no single remailer can be trusted, since it might be in the hands of the NSA or KGB or something. In fact, since the NSA is famous for doing their job well, this list must have NSA watchers, no question, even without paranoia, and if I were them I'd be experimenting with remailers even now, to keep up with trends. We'll never know how many remailers are trustworthy, so we'll have to use statistical schemes to make compromise unlikely.) This is all standard parallel remailing stuff. Add to this the possibility that the different remailing paths may contain message fragments rather than full messages, and it doesn't really change the security relative to full message parallel remailing...unless it's done badly. Badly would mean that some remailer is the one that finally recombines fragments prior to final delivery. Better is if the recipient's host does the recombination (and I worry about *that*, too). This needs to be done in conjunction with other standard cypherpunk fare, of course. The major design problem I've had is not with security, it's with fault tolerance. Statistical fault tolerance is available, but I prefer leaving that kind to the underlying base systems and networks, and trying to find a top level algorithm that is 100% guaranteed to either work or report failure, so long as the host systems/networks don't fail undetectably. A handshake ACK of receipt would help, except that it might not get back even if the original reached its destination. Which is why I'm starting to think I need to research transaction processing more thoroughly; some years back I'd heard that a centralized server was still state of the art for 100% fail-safe/soft operation. Is this still the case? If so, then we'll have to fall back on probabilistic fault-tolerance, to avoid issues of central authority compromise. >follow them all), as only one will arrive there and the rest would die >after a number of remailer hops. This is actually less safe than an approach which requires multiple pieces to arrive via multiple paths. Bad luck might leave your one path completely in the hands of bad guys (posing as cypherpunks, let's say). >I really think that non-deterministic "smart messages" are the way to >go here. This I agree with; but the way that is done is critical. >A simple command language for the remailers would allow >the header construction software already being worked on by >ebrandt at jarthur.Claremont.EDU (CRM) and others to use tricks >like this to defend against attacks. Cool. More info? > The defense complexity would be a function of the users' >header construction software and needs. People who need "minimal" >anonymity would have simpler anonymous address blocks, as compared to >those who require "serious" anonymity, and the remailers themselves >would have a lighter load (not having to implement very serious >security for *all* messages-- just those that need it). Strongly agree. BTW I consider this emphasis on batch mail to be short sighted. I'm designing for interactive cyberspace. I have a complete algorithm in mind, except I think it still needs some more OLTP wisdom added in. People have been telling me for a long while that I should hook up with cypherpunks; seeing traffic over the last week since I joined shows me why I heard that from so many sources. Tip of the hat to y'all; this is a much juicier forum than I had guessed. I only hope I can continue weathering the storm of heavy traffic, on top of other email lists. :-) Doug From b44729 at achilles.ctd.anl.gov Fri Sep 3 22:15:35 1993 From: b44729 at achilles.ctd.anl.gov (Samuel Pigg) Date: Fri, 3 Sep 93 22:15:35 PDT Subject: Remailer Reliability In-Reply-To: <9309040413.AA23647@netcom5.netcom.com> Message-ID: <9309040511.AA07959@achilles.ctd.anl.gov> >>>>> On Fri, 3 Sep 1993 21:13:47 PDT, doug at netcom5.netcom.com (Doug Merritt) said: Doug> sameer at netcom.com (Sameer Parekh) >install-script I can add this little feature. Which newsgroup? Should >someone create an alt.remail? How exactly would it be implemented? I'm >thinking that simply the user would do: > [...] > And the remailer would post to alt.remail: Doug> There are two problems here. One is that the remailer Doug> exposes itself and defeats traffic analysis avoidance. Not necessarily. If the "post this message to alt.remailer" command for a smart message were executed via splitting off another message with its own encrypted header and path through the remailers to an anonymous posting service. (as suggested by miron at extropia.wimsey.com) Doug> The other is a standard transaction processing sort of Doug> problem; the posting to alt.remail might fail even Doug> though all else worked. I agree this could certainly be a problem (esp. executed as above.) [..] Doug> b44729 at achilles.ctd.anl.gov (Samuel Pigg) said: >By breaking a message into pieces and sending them via different paths >to the same destination ("path forking"), this can only make traffic >analysis easier, because all the pieces lead to the same destination, >and you can follow any of them to get to the anonymous recipient. Doug> Depends on how it's done. As stated this analysis Doug> implies that traffic analysis is *always* possible, Doug> since after all, the message must somehow make it to its Doug> destination. In other words, I disagree. No I'm not implying that. But there really isn't any way doing that could make such an analysis *harder*, as by splitting pieces of the message off, you have multiple parts all going to the same destination. This gives the attacker redundant paths to follow, and if the attacker can trace *any* message, he can discover the identity of the recipient. There would be no "dead-ends" for the attacker. (when I say "follow" I don't necessarily mean follow in a literal sense, but any traffic based statistical analysis.) Doug> This needs to be done in conjunction with other standard Doug> cypherpunk fare, of course. The major design problem Doug> I've had is not with security, it's with fault Doug> tolerance. Statistical fault tolerance is available, but Doug> I prefer leaving that kind to the underlying base Doug> systems and networks, and trying to find a top level Doug> algorithm that is 100% guaranteed to either work or Doug> report failure, so long as the host systems/networks Doug> don't fail undetectably. A handshake ACK of receipt Doug> would help, except that it might not get back even if Doug> the original reached its destination. I agree this is the major problem, with the current state of the remailers, but it may not be a problem with a stable remailer web and an "anonymous address server" (see my long laborious boring posts regarding this from about a week ago.) >follow them all), as only one will arrive there and the rest would die >after a number of remailer hops. Doug> This is actually less safe than an approach which Doug> requires multiple pieces to arrive via multiple paths. Doug> Bad luck might leave your one path completely in the Doug> hands of bad guys (posing as cypherpunks, let's say). I don't think so. This way there is only one (or a few) paths that actually would lead to the recipient, and many "blind alleys" for an attacker to follow. With the multiple-pieces-same-destination scheme *any* one path would be enough to determine the recipient. >I really think that non-deterministic "smart messages" are the way to >go here. Doug> This I agree with; but the way that is done is critical. >A simple command language for the remailers would allow >the header construction software already being worked on by >ebrandt at jarthur.Claremont.EDU (CRM) and others to use tricks >like this to defend against attacks. Doug> Cool. More info? I'm not saying that CRM actually uses a command language (it can't-- nothing has been agreed upon/worked out yet!) but tools like CRM would be able to use a remailer command language to tailor the message's (or anonymous address block's) anonymity protection. See that same long, boring post I made about a few suggestions for what such a language could contain/be useful with. > The defense complexity would be a function of the users' >header construction software and needs. People who need "minimal" >anonymity would have simpler anonymous address blocks, as compared to >those who require "serious" anonymity, and the remailers themselves >would have a lighter load (not having to implement very serious >security for *all* messages-- just those that need it). Doug> Strongly agree. Doug> BTW I consider this emphasis on batch mail to be short Doug> sighted. I'm designing for interactive cyberspace. I Doug> have a complete algorithm in mind, except I think it Doug> still needs some more OLTP wisdom added in. A remailer command language could include instructions to specify how long to hold this message (possibly to be combined with some remailer batching functions.) [..] Sam Pigg dt1acaa at cfraix.cfr.usf.edu samp at renoir.cftnet.com b44729 at achilles.ctd.anl.gov PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C From 72114.1712 at CompuServe.COM Fri Sep 3 22:25:35 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Fri, 3 Sep 93 22:25:35 PDT Subject: JEROME SCHNEIDER Message-ID: <930904051400_72114.1712_FHF52-1@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Punksters, Just a few comments about Jerome Schneider. In addition to the piece in /Fortune/ magazine, there was also a segment done on him by "60 Minutes." During that show he did an impromptu telephone hack for the "60 Minutes" interviewer. At the end of the segment when Schneider asked if he had gone straight, he answered "yes." But when he was asked how we could be sure of that, he replied, "you can't." Such a kidder. Contrary to the mythologized version of his computer crime career, Schneider was not that technically competent. What he was good at was bribing telco employees to get equipment ordering access codes and other inside information. Because he was a juvenile when he committed his computer crimes, he was able to have his record expunged. He gets mad when anyone brings up his criminal record, because, by law, he no longer has a criminal "record." I met Schneider a few years back when he was in the business of selling offshore brass-plate banks. He was in the process of burning his bridges with government after government from the Caribbean to the American Trust Territories. I gave him a call a few months ago to see if he was still selling banks through his company WFI. He said that he was out of that business. He has a new company called American National Securities which is a brokerage firm. If you buy an offshore bank, he will be more than happy to clear your trades through his company. If Doug Merritt, or anyone else is interested in offshore banking with a Cypherpunk twist, contact me. I'm working with several other Cypherpunks on some projects in that area. S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From b44729 at achilles.ctd.anl.gov Fri Sep 3 22:55:35 1993 From: b44729 at achilles.ctd.anl.gov (Samuel Pigg) Date: Fri, 3 Sep 93 22:55:35 PDT Subject: Mistake (CRM's author == Alex Strasheim)! In-Reply-To: <9309040511.AA07959@achilles.ctd.anl.gov> Message-ID: <9309040548.AA09614@achilles.ctd.anl.gov> Oops! >A simple command language for the remailers would allow >the header construction software already being worked on by >ebrandt at jarthur.Claremont.EDU (CRM) and others to use tricks >like this to defend against attacks. ebrandt at jarthur.Claremont.EDU is the return address of the remailer that sent the message from astrashe at nyx.cs.du.edu (Alex Strasheim), who is the author of CRM. My mistake. (thankfully pointed out by Liam David Gray ) Sam Pigg dt1acaa at cfraix.cfr.usf.edu samp at renoir.cftnet.com b44729 at achilles.ctd.anl.gov PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C From anonymous at extropia.wimsey.com Fri Sep 3 23:15:36 1993 From: anonymous at extropia.wimsey.com (anonymous at extropia.wimsey.com) Date: Fri, 3 Sep 93 23:15:36 PDT Subject: No Subject Message-ID: <199309040559.AA18179@xtropia> > ld231782 at longs.lance.colostate.edu (L. Detweiler) writes: >C'punks, it seems to me that the anonymous pool idea is underutilized >by the remailers. I suggest that a remailer variation be developed that >posts to an anonymous pool (some appropriate obscure newsgroup) MC> No need to change anything. Just add a pool address to the MC> "Request-remailing-to:" line. MC> Miron Cuperman Excuse me if I am misunderstanding the "obscure newsgroup" concept, but is not the "Request-Remailing-To:" feature of cypherpunks remailers unable to post to newsgroups, but only to individual or mailing list addresses? I have been told that only Penet's remailer could remail directly to newsgroups, obscure or otherwise. Thanks for any clarification. From b44729 at achilles.ctd.anl.gov Fri Sep 3 23:35:35 1993 From: b44729 at achilles.ctd.anl.gov (Samuel Pigg) Date: Fri, 3 Sep 93 23:35:35 PDT Subject: No Subject In-Reply-To: <199309040559.AA18179@xtropia> Message-ID: <9309040631.AA11668@achilles.ctd.anl.gov> >>>>> On Fri, 3 Sep 1993 22:59:48 -0700, anonymous at extropia.wimsey.com said: > ld231782 at longs.lance.colostate.edu (L. Detweiler) writes: >C'punks, it seems to me that the anonymous pool idea is underutilized >by the remailers. I suggest that a remailer variation be developed that >posts to an anonymous pool (some appropriate obscure newsgroup) MC> No need to change anything. Just add a pool address to the MC> "Request-remailing-to:" line. MC> Miron Cuperman anonymous> Excuse me if I am misunderstanding the "obscure anonymous> newsgroup" concept, but is not the anonymous> "Request-Remailing-To:" feature of cypherpunks anonymous> remailers unable to post to newsgroups, but only to anonymous> individual or mailing list addresses? I have been anonymous> told that only Penet's remailer could remail anonymous> directly to newsgroups, obscure or otherwise. anonymous> Thanks for any clarification. No, I think that julf's remailer is the only *anonymous* posting facility (heck there might be more *now*.) But there are several (last I checked) non-anonymous mail->news gateways on the net, and if used from a remailer, the only address the mail->news gateway would have is the remailer's. Of course, the remailers could be rewritten to allow posting capability also. (probably not a good idea, as I doubt many of the remailer admins would want to suffer throught the controversy that Julf has had to) but it's up to them. Sam Pigg dt1acaa at cfraix.cfr.usf.edu samp at renoir.cftnet.com b44729 at achilles.ctd.anl.gov PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C From julf at penet.FI Sat Sep 4 01:37:17 1993 From: julf at penet.FI (Johan Helsingius) Date: Sat, 4 Sep 93 01:37:17 PDT Subject: remailer reliability In-Reply-To: <2298.2C87C75D@shelter.FIDONET.ORG> Message-ID: <9309041137.aa03413@penet.penet.FI> I still can't reply to M. Stirner because he still uses a illegal user name. Double periods in a user name is a _bad_ idea. But perhaps he doesn't want to receive any mail. > repl: bad addresses: > M..Stirner at f28.n125.z1.fidonet.org (M. Stirner) -- no mailbox in local-part (.) > Before the > password mess on penet (which kills automagic replies, unfortunately, as > they haven't passwords), I used the autoreplies that come form various > US & foreign sites in response to alt.test postings as a good shakedown > of penet remailer reliability. Find out the facts first. You don't need passwords to send to anXXXX users. Autoreplies work perfectly well. It's just that *your* real return address doesn't work! Sorry about sounding irritated, but we have discussed your dysfunctional return address several times, and you haven't fixed it, instead blaiming the problems on everything else... Julf From khijol!erc at apple.com Sat Sep 4 03:30:40 1993 From: khijol!erc at apple.com (Ed Carp) Date: Sat, 4 Sep 93 03:30:40 PDT Subject: Gubment Bombmaker's Cookbook In-Reply-To: <930903075125.42fd@lds.loral.com> Message-ID: > TM 31-210 Dept. of the Army Technical Manual > Improvised Munitions Handbook > published 1969 > > It contains chemical recipes for about a dozen explosive > materials (both primary and secondary explosives) from > easily obtainable ingredients, along with designs for > fusing devices and explosive booby-traps. I also have a copy of this. > I have never tried any of these (to paraphrase Shel Silverstein, > my eyes still see, my hair's unburned, and my fingers are still > on my hands -- and I'd like to keep it that way), but my knowlege > of chemistry and engineering convinces me that they all work. I have. Pretty effective stuff, although I don't think it mentions the old "ammonium nitrate + motor oil" standby. ;) > The book contains the disclaimer "For official use only" on > nearly every page. It is, however, widely available at gun > shows, which is where I got mine. I got mine at the Dallas Gun Show several years ago, along with "Survival, Evasion, and Escape". > I'll not reproduce any recipes here, but if the defence > attornies for the gentleman in Hartford contact me and can > prove who they are, I will be happy to share any info with > them. I don't see why not - after all, alt.pyrotechnics has a lot of discussion of this sort of thing... -- Ed Carp erc at apple.com 510/659-9560 If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From miron at extropia.wimsey.com Sat Sep 4 03:40:40 1993 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Sat, 4 Sep 93 03:40:40 PDT Subject: Remailer Reliability In-Reply-To: <9309030322.AA20056@netcom5.netcom.com> Message-ID: <1993Sep4.070059.18924@extropia.wimsey.com> miron at extropia.wimsey.com (Miron Cuperman) writes: >ld231782 at longs.lance.colostate.edu (L. Detweiler) writes: >>C'punks, it seems to me that the anonymous pool idea is underutilized >>by the remailers. I suggest that a remailer variation be developed that >>posts to an anonymous pool (some appropriate obscure newsgroup) >No need to change anything. Just add a pool address to the >"Request-remailing-to:" line. Actually, an even better idea is to add the header Return-receipt-to: at the final hop. This will send a note to the pool only if the recipient system accepts the messaFrom owner-cypherpunks Sat Sep 4 06:45:41 1993 Received: by toad.com id AA01922; Sat, 4 Sep 93 06:40:44 PDT Received: by toad.com id AA01877; Sat, 4 Sep 93 06:37:26 PDT Return-Path: Received: from panix.com ([198.7.0.2]) by toad.com id AA01872; Sat, 4 Sep 93 06:37:22 PDT Received: by panix.com id AA15005 (5.65c/IDA-1.4.4 for cypherpunks at toad.com); Sat, 4 Sep 1993 09:34:21 -0400 Date: Sat, 4 Sep 1993 09:34:21 -0400 From: Duncan Frissell Message-Id: <199309041334.AA15005 at panix.com> To: cypherpunks at toad.com Subject: Re: Gubment Bombmaker`s To: cypherpunks at toad.com N >it has a ISBN number, can be found, and ordered via Books in print, N >however will be confiscated by customs at the canadian border as that N >sort of thing is contraband in canada - I don't know about england... >From the Loompanics Catalog: "Special Notification Regarding Books Seized by the Authorities Loompanics Unlimited cannot be responsible for any shipment of books seized by any government body. This applies in particular to Canada, where many books are banned, and to prisoners, whose keepers often confiscate books. If you are a prisoner or a Canadian, you are advised to check with your authorities before ordering books. We cannot be responsible for books siezed by ANY government, since neither UPS nor Post Office insurance covers such a situation. Be warned!" Elaine Elansky has set up an account to receive contributions to her son's defense fund (he remains in jail in Hartford, CT for his BBS-related 'crimes'. They need money. Send it to: Michael Elansky Fund 25 Maiden Lane West Hartford, Connecticut 06117 or Michael Elansky Fund Account # 02060573652 Society for Savings 342 North Main Street West Hartford, Connecticut 06117 Thank you, Duncan Frissell --- WinQwk 2.0b#0 From nobody at shell.portal.com Sat Sep 4 07:36:19 1993 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sat, 4 Sep 93 07:36:19 PDT Subject: Denning and the cost of attack against SKIPJACK (fwd) Message-ID: <9309041300.AA27965@jobe.shell.portal.com> (forwarded from sci.crypt) On page 14 of the August 30, 1993 issue of Government Computer News Kevin Power reports that Dorothy Denning told the Computer System Security and Privacy Advisory Board that SKIPJACK would not be compromised by exhaustive attack methods in the next 30 to 40 years. I am reminded of a story, perhaps apocryphal. In the middle seventies Fortune magazine was working a feature on computer crime. Most of the experts that they interviewed told them that the security on most of the nation's commercial time sharing systems was pretty good. However, they admitted that one convicted felon and hacker, Jerry Schnieder, would tell them otherwise. Of course Fortune had to interview him. According to the story, the interview went something like this: Fortune: Mr. Schnieder we understand that you are very critical of the security on the nation's commercial time sharing systems. Jerry: Yes, that is right. Their security is very poor. Fortune: Could you break into one of those systems? Jerry: Yes, certainly. Fortune: Well, could you demonstrate for us? Jerry: Certainly, I'd be happy to. At this point Jerry took the reporters into the room where his "Silent 700" terminal was. He connected to the system that he normally used but deliberately failed the logon. When he deliberately failed again at the retry prompt, the system disconnected. Jerry dialed in again, failed a third time, and this time he broke the connection. He dialed a third time but this time he dialed the number of the operator. Jerry: This is Mr. Schnieder. I seem to have forgotten my password. Can you help me? Operator: Sorry Mr. Schnieder, there is nothing that I can do. You will have to call back during normal business hours and talk to the security people. Jerry: I am sorry too, but you do not seem to understand. I am working on something very important and it is due out at 8am. I have to get on right now. Operator: I am sorry. There is nothing that I can do. Jerry: You still do not understand. Let me see if can clarify it for you. I want you to go look at your billing records. You will see that you bill me about $800- a month. This thing that I am working on; it is why you get your $800-. Now, if you do not get off your a-- and get me my password so that I have this work out at 8am, by 9am there is going to be a process server standing on your front steps waiting to hang paper on the first officer through the door. Do I make myself clear? Apparently he did. Operator: Mr. Schnieder, I will call you right back. At this point he appears to have one or two things right. He changed the password, called Jerry back at the number where his records said that he should be, and gave him the new password. Jerry dumped two files and then turned to the reporters. With a triumphant smile he said "You see!" Fortune (obviously disappointed): No, No, Mr. Schneider! That is not what we wanted to see. What we wanted to see was a sophisticated penetration of the software controls. Jerry: Why would anybody do THAT? __________________________ The cost of an exhaustive attack is an interesting number. It gives us an upper bound for the cost of efficient attacks. However, it is never, itself, an efficient attack. It is almost always orders of magnitude higher than the cost of alternative attacks. The very fact that its cost can be easily calculated ensures that no one will ever encrypt data under it whose value approaches the cost of a brute force attack. History is very clear. "Black Bag" attacks are to be preferred; they are almost always cheaper than the alternatives. After those are attacks aimed against poor key management. These attacks will be very efficient when the keepers of the keys already work for you and where their continued cooperation and silence are assured. William Hugh Murray, Executive Consultant, Information System Security 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL From nobody at shell.portal.com Sat Sep 4 14:20:45 1993 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sat, 4 Sep 93 14:20:45 PDT Subject: CRM (again) Message-ID: <9309042020.AA08831@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- (Note: this was sent through a remailer, and the return address is inaccurate. My address is astrashe at nyx.cs.du.edu.) | I'm not saying that CRM actually uses a command language (it can't-- | nothing has been agreed upon/worked out yet!) but tools like CRM | would be able to use a remailer command language to tailor the | message's (or anonymous address block's) anonymity protection. | See that same long, boring post I made about a few suggestions | for what such a language could contain/be useful with. CRM doesn't do anything grandiose. All it does is pick a random path of a specified length from a list of remailers, and wrap up an input file with remailing requests, encrypted PGP tags, and nested PGP encryptions. For example, if you start out with a file like: - -+---snip----- Subject: Just a test... I'm going to wrap up this file with CRM and make a /bin/sh script that will mail it to myself through a chain of remailers. - -+---snip----- and do one of these: c:\>crm infile astrashe at nyx.cs.du.edu you'll end up (with no further intervention on your part) with the /bin/sh script that's at the end of this post. If you run that script, it will mail the above short note to me through a chain of three remailers. Each of the remailers gets PGP encrypted input. The subject line will show up as the subject on my mailer. (Please don't run the script; my mailbox is full enough already.) The reason I had CRM wrap the final output in a script is that because the chain of remailers is random, the first remailer in the chain varies each time CRM is invoked. This way you don't have to worry about keeping track which one to mail the cyphertext to. This is obviously more of a hassle than using elm to send your mail; but if you're already writing letters offline and uploading them (which you ought to be doing anyway, to take full advantage of PGP's protection), it's only marginally more difficult than mailing stuff without the remailers. And it could be argued that it's *easier* to use CRM and the remailers than standard mailing, because the shell script keeps track of the subject lines and the destination for you. You could write ten letters, wrap them with CRM, keep concatenating the new scripts onto a outgoing mail file, then upload the whole thing at once and mail it in one fell swoop. If you want a copy of CRM, let me know. (Write to astrashe at nyx.cs.du.edu, not the return address on this post). It's an msdos program, written in turbo pascal. - -+---snip----- #!/bin/sh # # This is a shell script produced by CRM. # sed -e '/^BEGINCRM/d' -e '/^ENDCRM/d' << \End_of_File > crm.tmp BEGINCRM :: Encrypted: PGP - -----BEGIN PGP MESSAGE----- Version: 2.3a hIwCPhjICRQCw4kBBACpc6PDQEH8FR03Y1nO1IgMiG/ypCqe9c4oFcZzmx8jQaJ+ hDLpM5VcCHCGEQJUcmd0i3FCOFw1qKsWY612BdYMETPGpfDvK7SOqTmzBESF/NHE VhYgUuk06AYlhpcH5hNZ85DDXJLVLL7EJ/sLWy2mmV0p3CrIHK0aljddQmPbbKYA AAL0GwZ1Z+1XUvIhKpyk2W4l2fbrGdfflox5TQy8MuBkgSAxelm5DNNdYz7IDD5w G1X0G/YETmOs//7u7xL8gPAx2dYUi2raLSCXJ941Y4FtRc2W2Eci4M0uiDIYbTNT 45YBFW+emw6jawLvwKj5jlF2QAqn/6wuT1Px+azZSS39z8jyzcClhEEaEQSGBGcg o1NpSR6Bk9myQG5hEezB7j92s+D6D6APkTtc/LgyX/UG3jkCt86dbrhljoGQcIku NDS2lWHEJEXUJ4I/QwL8gwZLKcVkyxW1h8GB1Y8/LjfhnrjQXjig1jumPqbzOmBu 1u4exeV/kFADW2iDq8trjzkcBI7k/xGljtkaR1I9lVhIimyMz8bUr1WYuUte5u4P 4SxK9lSdS8TnK4pDwaubDL41aZ4eERNxuquerXbH1x3L7eDbUuerSI+vCM4uinWS c/ZDsIGYc0xgNzg4bq9ji04KK/FA6Y5HsnKAkdNV2V65GaNxk8IwAlkSQBygvf0R kdwOkJ+Y1L+k05lkI7N5AXOF+5cZQMw2oZElsF9pvbflzRIkJJBn+//Zx9cDJE6I SaISCg/c/DFeuH21zyv06Xrs8kRvX7183dD6I40RuGx5pg5eOalbBZFTqda5PV6w C6jtv2GxjfNYmOFLo/7uRpscrfAr2APvdR6/cTfb869tR22DcfYUOI5COxU0VH++ Lwq5Z6wVykrYWSZbUePO0MjzzRWCnAYOdlbJN0qFJXceNSKKIjYwZR/M4HlUTwYn 14jIfgvekaKWXL2ydk11S2eCPl9GrbNyptJUSjVteMFO333xjeoPMKST/yybvVsH JTlKy0XfmV3jUzjiOxy2yCLxeTJRjXFK8gKtIPpgfD1TEYdBELDTbQSbqm0f4aWE uHFEMI59IHPS0Dunu+Yn2QNyCw0NJbvclBUyYqrRFMyPT8R4V8qECYwZtcHbtP2z eJxRlQNx43GHfS5GxgQdJGB4Urb0y3AhsuEm+gWYoX6xuJSQ+GRX =42WF - -----END PGP MESSAGE----- ENDCRM End_of_File mail remail at tamsun.tamu.edu < crm.tmp rm crm.tmp - -+---snip----- - -+ Alex Strasheim | astrashe at nyx.cs.du.edu | PGP public key available via finger -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIj1fLGKvmrRrQghAQEniQP7BSeTbv9NtzMFAryrXAH0l6HdQ6dFTgxK AdWGts1zxGhJxoBO+ULwnaApuVgJoFz9iKEJ5GWWjpvs6f4tlG69MiTrb6vTW+0+ H8ceNIC15uyUWQR0fyy28SqgQhQLB2Ys3Y54fPDU5kvZKxa6hi38ZY6hTIg4b8BY 6zWwiGnJI2w= =kQ9/ -----END PGP SIGNATURE----- From sameer at netcom.com Sat Sep 4 18:15:47 1993 From: sameer at netcom.com (Sameer Parekh) Date: Sat, 4 Sep 93 18:15:47 PDT Subject: Remailer Reliability In-Reply-To: <9309040413.AA23647@netcom5.netcom.com> Message-ID: <9309050109.AA13068@netcom5.netcom.com> > I only hope I can continue weathering the storm of heavy traffic, on > top of other email lists. :-) > Doug Good luck.. Didn't someone mention a while back a scheme by which a message can be split up into a bunch of parts and only requires about 50% of them or so to be completely rebuilt? Something like that would be very useful I think to deal with remailer reliability problems. That would require a good deal more user work though. -- Sameer sameer at netcom.com From edgar at spectrx.Saigon.COM Sat Sep 4 19:40:49 1993 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Sat, 4 Sep 93 19:40:49 PDT Subject: Phil Z Comments on ViaCrypt Message-ID: <6gsD0B3w165w@spectrx.saigon.com> I received the following comments on ViaCrypt from Phil Z. Reposting here with permission. I'll try to forward a summary of your comments. ==================================================================== Subject: Re: Your visit To: spectrx!edgar (Edgar W. Swank) *Edgar* Date: Wed, 1 Sep 93 20:40:08 MDT From: Philip Zimmermann Hello Edgar. Thanks for your hospitality. I enjoyed our conversations during my visit. The PKP/Viacrypt contract requires that ViaCrypt use THEIR OWN RSA cryptographic engine, not PKP's or RSADSI's. I will be working closely with them to ensure that they do a good job on that. Actually, RSA calculations are fairly straightforward, and it's hard to screw them up. I will probably try to get them to stick with my own keygen routines, if they are allowed to use them in the PKP contract. The keygen stuff would be the most important place to look for any security holes. My discussions with ViaCrypt's president, Lenny Mikus, and his programming staff, suggest to me that they are genuinely interested in making a very secure product. It's possible, I suppose, that maybe I could talk to ViaCrypt about maybe publishing the source code for the rest of ViaCrypt PGP, minus the RSA engines that the PKP contract won't let them publish. We'll see. The current plans are for them to use the straight PGP source code with no changes except for using their own RSA engines. So publishing the source code would not yield many new insights anyway, since it's the same. Other than as a confidence builder, which is nice to have. You may repost this to cypherpunks if you wish. Phil -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca From ld231782 at longs.lance.colostate.edu Sat Sep 4 20:46:30 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sat, 4 Sep 93 20:46:30 PDT Subject: Denning in Govt Comp News Message-ID: <9309050342.AA07626@longs.lance.colostate.edu> FYI, on sci.crypt W.H. Murray passes along quotes of D. Denning in an article in Government Computer News, p14, Aug. 30, 1993 by Kevin Power. If anyone could scan this for the cypherpunk collection it would be appreciated. ===cut=here=== From: WHMurray at DOCKMASTER.NCSC.MIL Subject: Denning on Skipjack Date: Fri, 3 Sep 1993 00:25:00 GMT In Government Computer News, p14, August 30, 1993, Kevin Power quotes Dorothy Denning as saying "I am 100 percent certain that there are no weak keys." William Hugh Murray, Executive Consultant, Information System Security 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL From: WHMurray at DOCKMASTER.NCSC.MIL Subject: And again, Denning on SKIPJACK Date: Fri, 3 Sep 1993 02:30:00 GMT In the same article kevin Power quotes Denning as having said "The people at NSA have done more to evaluate than the public algorithm in DES. They're way ahead of the game." I hope Dr. Denning never said anything like that for the record. Even if it were true, it would not be knowable. It would be unprofessional to make such an unscientific assertion. William Hugh Murray, Executive Consultant, Information System Security 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL From: WHMurray at DOCKMASTER.NCSC.MIL Subject: Denning and the cost of attack against SKIPJACK Date: Fri, 3 Sep 1993 02:20:00 GMT On page 14 of the August 30, 1993 issue of Government Computer News Kevin Power reports that Dorothy Denning told the Computer System Security and Privacy Advisory Board that SKIPJACK would not be compromised by exhaustive attack methods in the next 30 to 40 years. [...] From klbarrus at owlnet.rice.edu Sat Sep 4 21:05:51 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sat, 4 Sep 93 21:05:51 PDT Subject: REMAIL: RIPEM and PGP remailer Message-ID: <9309050400.AA13534@flammulated.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, I have turned my old account (elee9sf at menudo.uh.edu) into a cypherpunks remailer that supports BOTH pgp and ripem. In addition to the pgp pasting token :: Encrypted: PGP there is also a ripem pasting token :: Encrypted: RIPEM I've just tested the remailer with pgp, ripem, pgp nested inside ripem, and ripem nested inside pgp, and all the messages have come back successfully. The installation went fairly quickly with Sameer's scripts; I essentially added the necessary lines to the maildelivery file, copied the pgpmail.pl file to ripemmail.pl (that's what I indicated in the maildelivery file), altered ripemmail.pl to recognize RIPEM message delimiters, and changed around the string that is built with the $system call. I apologize to those who have asked for a RIPEM remailer for taking so long; I was bogged down trying to get RIPEM compiled on rosebud, an HP/UX (cc, c89, -Aa flags: nothing worked; no gcc or disk space to install gcc, unproto didn't help - I now think the compiler is way broken). The only drawback is that account is due to expire sometime. Plus, if many people decide to support ripem in addition to pgp the scripts are going to need some reworking :-) In order to update the dos batch files I'll need an MSDOS ripem executable - has anyone seen any? (Apparently I don't have a command line compiler to build it myself; I have Turbo C++ for Windows) Here are the public keys: For the pgp half - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyIBzwAAAEEALgRUlovklKVnasbE6qyNB82RL8emHh6+BwRwt49Yqt/YJaP Yl7V6k83/pnTE4w73S6rcWBo9jrSH1u1/Fcz7uUbRmGhteuMBEnB64wPqbxKEIrt vKJAx4xuNkTPGeNBCGOq5RtiEHbEt99hKF2H6lk9iLb8UwQCnV45xNlD3J7pAAUT tCByZW1haWxlciA8ZWxlZTlzZkBtZW51ZG8udWguZWR1PokAlQIFECyICuyDgOzq S1rWMwEBE44D/3Wwl0SLFvcN6BHe3BJhh6m1KBs3pRXsy2SBGN/y3+/NVRHbYhgy Q0MLEAPJ0PZnsJjH1pIyEDnoybcIvFyd5B3e9txawQJvaq238dyuzj5nzaTxe43H KUlh52fJzLCvXNa035p5ApvkaD1PpdAo6Vk3BGuYGOtEtGQLzLFntaqv =kIeo - -----END PGP PUBLIC KEY BLOCK----- and for the ripem half - -----BEGIN PUBLIC KEY----- User: elee9sf at menudo.uh.edu PublicKeyInfo: MFowCgYEVQgBAQICAgkDTAAwSQJCAXLNDW+7UU+XsgEfhDVdhgH0gq68Ss056URr 3VDg7lSUu61anW2wABEeVEzCgQwYR4/hYdV3rojbADx9UOAp+cOzAgMBAAE= MD5OfPublicKey: B6DB0C696304C9092F8A4493326461D3 - -----END PUBLIC KEY----- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIlj+YOA7OpLWtYzAQEx8gP/YejO5r9+dCAQa2jdypuQTQmZOeLvXZLu UKK9sfn6Q2HJu0cp+ll0JVKh4qujLCmCFgFAeXwMbdBibJLByIowKzul6W0dNUEq haLRnhrI/iGiDO9VgD8463TpA7BHxM13t7iJp5TaaYI3KfwIxj7J6H43bjr9Ea6u aniKxu5WrDI= =imPY -----END PGP SIGNATURE----- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From elee9sf at Menudo.UH.EDU Sat Sep 4 22:25:50 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Sat, 4 Sep 93 22:25:50 PDT Subject: REMAIL: sendmail invocation Message-ID: <199309050521.AA13295@Menudo.UH.EDU> I just adjusted the sendmail invocation in the remailer scripts on menudo to include the -oi option ("/usr/lib/sendmail -oi "). This option tells sendmail to not treat a period on a line by itself as the end of input. (I remember having fun posting a message where I showed forging a usenet post - my post had such a line, and the rest of the message kept on getting truncated. Miron brought the -oi option to our attention!) However, it just occured to me that this is a simple, if unplanned, way for people who have signatures automatically appended to messages to use a remailer and have trailing lines cut! No fancy "cut here" marks for the scripts to recognize, let sendmail do the work! On the other hand, I plan to not use sendmail in the long run. I plan to upgrade to an smtp package (hopefully to avoid logging like syslog) sent to me by Peter Honeyman, so I'm going to leave the sendmail invocation with -oi. -- Karl L. Barrus - klbarrus at owlnet.rice.edu From nobody at eli-remailer Sun Sep 5 00:27:29 1993 From: nobody at eli-remailer (nobody at eli-remailer) Date: Sun, 5 Sep 93 00:27:29 PDT Subject: A question about pasting Message-ID: <9309050727.AA15916@toad.com> -----BEGIN PGP SIGNED MESSAGE----- This probably a naive question, but: Is there any way, using a remailer, to paste something into the header that will provide a return address (different from the reamiler's) that can be recognized by a garden variety unix mail program? Because it seems to me that if it is, then it would be possible to set up a mail forwarding site that would work in the following way: 1. A user would send in and register, possibly (preferably) via a remailer chain, a public-key and a remailer return address. A remailer return address would be a PGP encrypted command bundled with a remailer address; the PGP command would cause the remailer to forward the mail to the user through a chain of remailers. 2. These would be stored under an alias, either user-defined or automatically allocated (like anon.penet.fi). 3. Once registered, the server would send encrypted mail back to the user via the chain, and request that the user take some specific action (ie., send mail with the a random ten character string in the subject line, or whatever) to verify the address. This would prevent people from creating anonymous identities that forwarded mail to someone else. 4. Once the identity was registered and confirmed, then whenever mail is sent to that address, the forwarder will encrypt it with the public key and use the remailer chain to forward the mail. The identity of the person sending mail to the alias and the subject line would be buried in the cyhpertext. 5. The server will also make the public key of all identities available via a mail request, so that signatures can be verified by people who want to do that. The whole point of this is that it would then be possible to have mail that's very secure (except for traffic analysis). You could use PGP encrypted outgoing mail to everyone, even people who don't know or care about remailers. Your sysadmin wouldn't know what your outgoing mail contained or who it was to. None of the people operating remailers would know that either, because you're using a chain. If you could paste a line into a header that would allow others to mail to your alias by just pressing 'r' on their mailer, then you wouldn't be asking your correspondents to sacrifice any convenience on their end. The people running the alias server wouldn't know who you really were, and niether would any of the people running the remailers on on the encrypted return chain. The result of all this would be that all of your incoming and outgoing mail would be encrypted, and the identities of your correspondents would be hidden, as would the contents of your letters; and you wouldn't be depending upon any single person to hold your secrets for you, because none of the individual remailers would be able to piece anything together, and the alias server wouldn't know anything about you at all. And all of this would be 100% compatible with the existing email system (you could communicate with non-participants). It's almost an axiom that any simple idea like this can't work, or else it would already be implemented. That suggests to me that you *can't* paste something in the header that will automatically route replies to an alias rather than back to where the letter came from. Is that the case? Alex astrashe at nyx.cs.du.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLImSLbGKvmrRrQghAQGs8QQAsVR4TKqKEda04dYarEuwWgwN5eejQbKP SCdRwEYhl7UhzcVuTCoRezHeqLYWa56a00hBu3qGY+HE/0VPWns7bmNodt4Ykdxl sbpPfwTwS+dPDrQBUAIhYSxT1A1dxhjkI5uKK7zj4PqbUjcp0e9BBuiClQk6Yz3K WXmsJ3byvEw= =xMN5 -----END PGP SIGNATURE----- From gg at well.sf.ca.us Sun Sep 5 01:27:30 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Sun, 5 Sep 93 01:27:30 PDT Subject: Gubment Bombmaker's Cookbook Message-ID: <93Sep5.012213pdt.14278-1@well.sf.ca.us> This case brings up the same larger issue as does privacy in all its forms: the question of whether and to what degree the protection of the Bill of Rights extends into the realm of electronic media. I strongly suggest it's time to start a grassroots campaign for a new constitutional amendment which extends all constitutional protections to include and encompass "any electronic or optical or other means of information storage, processing, and communication." With a relatively liberal, pro-technology administration in the White House, this stands a better chance of passing now than it did a few years ago. A constitutional amendment would put BBSs etc. on the same footing as the spoken word and the printed page. Without this, we're doomed to a future of petty tyrrany and censorship. -gg From nobody at shell.portal.com Sun Sep 5 06:21:38 1993 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sun, 5 Sep 93 06:21:38 PDT Subject: Two digital cash technical papers Message-ID: <9309051250.AA09123@jobe.shell.portal.com> There are two papers at ftp.cwi.nl descibing some of the mathemathics, /pub/CWIreports/CS/CS-R9318.ps.Z and /pub/CWIreports/CS/CS-R9323.ps.Z CS-R9318 N. Ferguson "Single Term Off-Line Coins" CS-R9323 Stefan Brands "An Efficient Off-line Electronic Cash System Based On The Representation Problem" From norm at netcom.com Sun Sep 5 08:46:00 1993 From: norm at netcom.com (Norman Hardy) Date: Sun, 5 Sep 93 08:46:00 PDT Subject: Remailer Reliability Message-ID: <9309051539.AA01918@netcom4.netcom.com> sameer at netcom.com (Sameer Parekh) says: > Didn't someone mention a while back a scheme by which a > message can be split up into a bunch of parts and only requires about > 50% of them or so to be completely rebuilt? Something like that would > be very useful I think to deal with remailer reliability problems. > That would require a good deal more user work though. There was a paper sometime back (10 years I would guess) called "Sharing Secrets". For any j and k such that 0 pairs. The secret was the value of f(x) for yet another public value of x. The paper described how to do this in finite fields. From klbarrus at owlnet.rice.edu Sun Sep 5 09:21:01 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sun, 5 Sep 93 09:21:01 PDT Subject: Remailer Reliability In-Reply-To: <9309040125.AA27752@achilles.ctd.anl.gov> Message-ID: <9309051614.AA27793@flammulated.owlnet.rice.edu> Samuel Pigg wrote: >go here. A simple command language for the remailers would allow >the header construction software already being worked on by >ebrandt at jarthur.Claremont.EDU (CRM) and others to use tricks >like this to defend against attacks. ?? Header construction software for unix and pc's has existed for months and is available at soda.berkeley.edu Granted, I'm waiting to validate three of the remailers so the scripts are a bit out of date, especially the dos batch files... -- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From klbarrus at owlnet.rice.edu Sun Sep 5 09:46:01 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sun, 5 Sep 93 09:46:01 PDT Subject: REMAIL: 9/6/93 Message-ID: <9309051640.AA28953@flammulated.owlnet.rice.edu> With all the new remailers, and more to come soon, I thought I'd post an updated list. Updated public keys and unix scripts should be available soon; hopefully I'll update the dos batch files this weekend as well. NOTE: my new remailer (elee9sf at menudo.uh.edu) is not on this list, partly because I don't expect it to run for any great length of time. It is more of an experiment to support PGP and RIPEM at the same remailer. If you missed the public keys, mail to me and I'll send them. -----BEGIN PGP SIGNED MESSAGE----- Cypherpunk anonymous remailers, 9/6/93 Q1: What are the anonymous remailers? A1: 1: nowhere at bsu-cs.bsu.edu 2: hh at cicada.berkeley.edu 3: hh at pmantis.berkeley.edu 4: hh at soda.berkeley.edu 5: 00x at uclink.berkeley.edu 6: cdodhner at indirect.com 7: hal at alumni.caltech.edu 8: cs60a-qu at cory.eecs.berkeley.edu 9: ebrandt at jarthur.claremont.edu 10: catalyst at netcom.com 11: sameer at netcom.com 12: remailer at rebma.mn.org 13: elee7h5 at rosebud.ee.uh.edu 14: hfinney at shell.portal.com 15: remail at tamsun.tamu.edu 16: remail at tamaix.tamu.edu 17: remailer at utter.dis.org 18: remailer at entropy.linet.org 19: remail at extropia.wimsey.com NOTES: 1-6 no encryption of remailing requests 7-19 support encrypted remailing requests 19 special - header and message must be encrypted together 12,17,18,19 introduce larger than average delay (not direct connect) 12,17,19 running on privately owned machines ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks/remailer directory at soda.berkeley.edu (128.32.149.19). chain.zip - program that helps with using remailers dosbat.zip - MSDOS batch files that help with using remailers hal's.instructions.gz - in depth instruction on how to use hal's.remailer.gz - remailer code pubkeys.tar.gz - public keys of remailers which support encryption pubkeys.zip - MSDOS zip file of public keys scripts.tar.gz - scripts that help with using remailers Mail to me (klbarrus at owlnet.rice.edu) for further help and/or questions. ====================================================================== Q3. Email-to-Usenet gateways? A3. 1: group-name at cs.utexas.edu 2: group.name.usenet at decwrl.dec.com 3: group.name at news.demon.co.uk 4: group.name at news.cs.indiana.edu 5: group-name at pws.bull.com 6: group-name at ucbvax.berkeley.edu NOTES: * This does not include ones that work for single groups, like twwells.com. #1 apparently blocks anonymous remailer posts #6 blocks from non-berkeley sites (so use the berkeley remailers :-) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIoT9IOA7OpLWtYzAQEyNQP/YeinL8uNCiOLDLVr0U+keX2LOkdyftHb FYOc56yGa+GcvqZ0KwqQk3cIAhZjdpNoRv6HcFHUcbD25lh77vyP/F/8OCXtRrG1 6708o0gGPcj2CSuzYygSFlfey4bv9FAsIgwe71oHpe5W0u/XxHUlaBFebi+u0310 lRTAiuBNRhI= =CcA+ -----END PGP SIGNATURE----- From bill at twwells.com Sun Sep 5 14:06:59 1993 From: bill at twwells.com (T. William Wells) Date: Sun, 5 Sep 93 14:06:59 PDT Subject: anonymous routing Message-ID: I've been thinking about the problem of sending anonymous e-mail without using explicit routing. Here's one solution. Each message is comprised of two parts, an encrypted address and the data to be transmitted. The encrypted address has N parts, each encrypted so that it can be decrypted by one remailer. These N parts each contain information such that M of them can be used to reconstitute the destination address. Note that no indication is given of which remailer decrypts which; a remailer is expected to attempt decryption of all of them and to check for success. When a remailer is able to decrypt a piece, it replaces it with its decrypted value. It then remails the results, either to a randomly chosen remailer or to the destination, if it has the M parts. Sounds like the mail will never get delivered? Possibly. N pieces in the message M pieces needed to recover the addresses R remailers If I haven't screwed the math, H = R * (1/N + 1/(N-1) + 1/(N-2)....1/(N-M+1)) That is, the average number of hops to deliver a message will be the product of the size of the remailer pool and a factor that is purely a function of the address information. This number amounts to an appreciable fraction of the remailer pool unless the number of pieces is very large. For example, with just two pieces needed and 20 pieces provided, you'll hit about 10% of the remailers. Combine this with two things: make all messages the same size and create a "background" set of noise messages and I think that just about covers connecting sender to receiver. The only exception I can think of is that, since a message going into the system has the same data going out, if the bad guys see it in both places you're screwed. There's an obvious solution to that that I've overlooked, right? From MIKEINGLE at delphi.com Sun Sep 5 22:51:09 1993 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Sun, 5 Sep 93 22:51:09 PDT Subject: Trusted timestamps Message-ID: <01H2LZYT94GA935IO5@delphi.com> There are a lot of additions being talked about for the remailers, and timestamping is another which could be put in. With commercial PGP coming out, people may soon be doing "real business" using PGP. In this case, timestamps can be a problem. A simple example: you sign an electronic contract with someone. Before signing, you set your date a month ahead. The other person doesn't stop to notice it - many people have trouble translating numeric dates to month names anyway - and accepts the contract. Two weeks later, you revoke your key. He can't enforce the contract because it was made two weeks after your key was revoked. There are plenty of problems which can be caused by modified timestamps. One means of protection would be to have future PGP's detect and warn of postdated timestamps when a signed message is checked. Another would be to use remailers to create trusted timestamps. The remailer would have a key labeled < Remailer xx timestamp >. Timestamped messages would not necessarily be anonymized. There are several ways this could work. You could send a message to a remailer and get back a detached signature certificate. Or the remailer could sign the message and send it on its way. Ideally the remailer would detect a PGP message, de-armor it, sign the .PGP file, re-armor it, and pass it on. This way, PGP would automatically check all the signatures on the received message. You could bounce a message through several remailers and onto its destination, acquiring several timestamps along the way. Or bounce it back to yourself to create a poor-man's copyright. -- MikeIngle at delphi.com From tcmay at netcom.com Sun Sep 5 23:17:07 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 5 Sep 93 23:17:07 PDT Subject: Trusted timestamps In-Reply-To: <01H2LZYT94GA935IO5@delphi.com> Message-ID: <9309060613.AA18943@netcom5.netcom.com> Mike Ingle writes: > There are a lot of additions being talked about for the remailers, and > timestamping is another which could be put in. With commercial PGP coming > out, people may soon be doing "real business" using PGP. In this case, > timestamps can be a problem. A simple example: you sign an electronic New ideas for "Mom and Pop Timestapping Services" are useful to discuss, but be aware that several papers on exactly this kind of digital timestamping have been presented at conferences, mostly by Stu Haber and Scott Stornetta of Bellcore. Their system involves a hash of some document which is then published in an effectively unchangeable place: the pages of the "New York Times," Sunday edition, form a pretty good "widely witnessed event," to use their terminology. A digital contract timestamped (to the "granularity" of the publishing schedule, clearly) could not easily be disavowed. There are some other details. To reduce storage/publishing requirements, a binary tree of other documents can all be hashed together, so that only a single number need be published. Anyone trying to alter a contract, or to claim the given contract was not in fact timestamped when it was, would have to produce the same hash value with a different input...this can be made intractable with a good hash function. The hash function hides the content of course, so privacy is maintained. Bellcore is offering a commercial service to do this. An Internet service might be exciting (the distribution of NetNews to many thousands of sites, for archiving on CD-ROMs, tapes, etc., is a lot like the "widely witnessed event" of publishing in the "New York Times"). Alternatives to Bellcore may run afoul of patents, though. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From remail at tamsun.tamu.edu Mon Sep 6 02:46:15 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Mon, 6 Sep 93 02:46:15 PDT Subject: Anonymous Forwarding Message-ID: <9309060941.AA18958@tamsun.tamu.edu> Do you have spare email accounts laying around? Would you like to have them forward mail to your main account anonymously? These are the questions which led me to hack up an anonymous .forward technique. I figured that I'd use a spare account to receive mail which I normally wouldn't want connected to my main address. Furthermore, mail forwarded to my main email address would be automatically encrypted to prevent the prying eyes of the sysadmin from snooping. Anonymous Forwarding -------------------- My software works like this. The destination address is prepared as a standard remailer header and pgp encrypted for one or more remailers, e.g. ==================================== :: Request-Remailing-To: my_real_address ==================================== becomes =================================== :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.3a hIwCPhjICRQCw4kBBACnRARz+qDK21BXcSUba3WjT4NEjoMtq+PZoJujGN2A/Ati O31UHYpULTP7j8OKBC+4Zuuan2e8CLTG9f3/XgYSuv8YRU5DtKr6bEuDDuojjgfr /ZudUWTej646ZJTqhrXRQldg/x/Wuu3kx8tby0zf+PcqqOssw7S2rgT6yrrdG6YA AABFct7lohDMViS01vOxzWr3RYernaqB9bkQmWlGd32TFrbe9bGf6BFBMvlDT8v+ C6xf1qI24mDslNiGoabjd/nCsE6d4EFT =7jt6 -----END PGP MESSAGE----- =================================== These "anonymous return addresses" are stored in the home directory (e.g. lib/shell.addr, lib/rosebud.addr, etc) on the spare account. When an incoming message is processed through .forward, the body of the message is stored and optionally encrypted with the public key of the main email account. The software then picks a remailer return address at random (e.g. lib/rosebud.addr), and appends it on the front of the encrypted body. This file is then re-encrypted with the public key of the destination anonymous remailer (optional). I did this so no one sees the obvious two-part message (pgp encrypted return address and pgp encrypted body). It probably doesn't add security, but it's optional. There is a configuration variable called "chain". If it is higher than 1, then up to "chain" number of remailers are chosen at random and chained together. Optionally, each new envelope in the chain will use the public key of the next remailer for encryption. So what happens is an incoming message is encrypted, the forwarding address (which is already encrypted for specific remailers) is added to an encrypted body and bounced randomly off a certain number of remailers to the final destination which is the main email account. Now you're all set to subscribe to alt.bomb.building with your other email account without fear of it being connected to your "real" account. ;-) Anonymous Mailing Lists ----------------------- Using my anonymous-forwarding script I have thrown together a kludgy anonymous mailing list program. Not only are the users on this list totally anonymous but the list address itself is secret! (Don't ya just love double-blind mechanisms?) To subscribe, users simply pgp encrypt a "Request-Remailing-To:" block as I detailed above and send it to the list request address. The list software sends out messages using the exact same script as anonymous-forward. At no time does the mailing list software see the real e-mail address. Only by collaborating with the operators of anonymous remailers can the list operator find out the real address of a user. The list address itself is also secret. Ihe true address is embedded in an encrypted "Request-Remailing-To:" block and chained through several remailers. Users post to the mailing list by adding their response to the encrypted return block and sending it to the first anonymous remailer in the chain. (the list software automatically puts the list's return block at the start of every message for easy response. [no cut/pasting needed]) Hopes, Dreams, and Bugs ----------------------- Obviously, with the small number of remailers on the net, and most of them running from multiuser machines and student accounts, security is not high. As the number of remailers increase, the probability of a bunch of remailer operators all collaborating is small. If remailers ever reach the level of popularity of gopher/fsp sites, it would be near impossible to shut down an anonymous mailing list. (there's no postmaster to complain to because you don't know the true address!) Alas, there is currently no way of returning error messages so if something bad happens, you aren't notified. Shutting down a single remailer in the chain would be very harmful. A fault-tolerant mechanism is needed and a robust way of returning error messages. -rjc p.s. If I have reinvented the wheel, ignore this message. I didn't see any anonymous forwarding/anonymous list software on soda so I figured no one had written any. From rjc at gnu.ai.mit.edu Mon Sep 6 03:26:14 1993 From: rjc at gnu.ai.mit.edu (Ray) Date: Mon, 6 Sep 93 03:26:14 PDT Subject: Anonymous Forwarding Message-ID: <9309061019.AA29877@geech.gnu.ai.mit.edu> Do you have spare email accounts laying around? Would you like to have them forward mail to your main account anonymously? These are the questions which led me to hack up an anonymous .forward technique. I figured that I'd use a spare account to receive mail which I normally wouldn't want connected to my main address. Furthermore, mail forwarded to my main email address would be automatically encrypted to prevent the prying eyes of the sysadmin from snooping. Anonymous Forwarding -------------------- My software works like this. The destination address is prepared as a standard remailer header and pgp encrypted for one or more remailers, e.g. ==================================== :: Request-Remailing-To: my_real_address ==================================== becomes =================================== :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.3a hIwCPhjICRQCw4kBBACnRARz+qDK21BXcSUba3WjT4NEjoMtq+PZoJujGN2A/Ati O31UHYpULTP7j8OKBC+4Zuuan2e8CLTG9f3/XgYSuv8YRU5DtKr6bEuDDuojjgfr /ZudUWTej646ZJTqhrXRQldg/x/Wuu3kx8tby0zf+PcqqOssw7S2rgT6yrrdG6YA AABFct7lohDMViS01vOxzWr3RYernaqB9bkQmWlGd32TFrbe9bGf6BFBMvlDT8v+ C6xf1qI24mDslNiGoabjd/nCsE6d4EFT =7jt6 -----END PGP MESSAGE----- =================================== These "anonymous return addresses" are stored in the home directory (e.g. lib/shell.addr, lib/rosebud.addr, etc) on the spare account. When an incoming message is processed through .forward, the body of the message is stored and optionally encrypted with the public key of the main email account. The software then picks a remailer return address at random (e.g. lib/rosebud.addr), and appends it on the front of the encrypted body. This file is then re-encrypted with the public key of the destination anonymous remailer (optional). I did this so no one sees the obvious two-part message (pgp encrypted return address and pgp encrypted body). It probably doesn't add security, but it's optional. There is a configuration variable called "chain". If it is higher than 1, then up to "chain" number of remailers are chosen at random and chained together. Optionally, each new envelope in the chain will use the public key of the next remailer for encryption. So what happens is an incoming message is encrypted, the forwarding address (which is already encrypted for specific remailers) is added to an encrypted body and bounced randomly off a certain number of remailers to the final destination which is the main email account. Now you're all set to subscribe to alt.bomb.building with your other email account without fear of it being connected to your "real" account. ;-) Anonymous Mailing Lists ----------------------- Using my anonymous-forwarding script I have thrown together a kludgy anonymous mailing list program. Not only are the users on this list totally anonymous but the list address itself is secret! (Don't ya just love double-blind mechanisms?) To subscribe, users simply pgp encrypt a "Request-Remailing-To:" block as I detailed above and send it to the list request address. The list software sends out messages using the exact same script as anonymous-forward. At no time does the mailing list software see the real e-mail address. Only by collaborating with the operators of anonymous remailers can the list operator find out the real address of a user. The list address itself is also secret. Ihe true address is embedded in an encrypted "Request-Remailing-To:" block and chained through several remailers. Users post to the mailing list by adding their response to the encrypted return block and sending it to the first anonymous remailer in the chain. (the list software automatically puts the list's return block at the start of every message for easy response. [no cut/pasting needed]) Hopes, Dreams, and Bugs ----------------------- Obviously, with the small number of remailers on the net, and most of them running from multiuser machines and student accounts, security is not high. As the number of remailers increase, the probability of a bunch of remailer operators all collaborating is small. If remailers ever reach the level of popularity of gopher/fsp sites, it would be near impossible to shut down an anonymous mailing list. (there's no postmaster to complain to because you don't know the true address!) Alas, there is currently no way of returning error messages so if something bad happens, you aren't notified. Shutting down a single remailer in the chain would be very harmful. A fault-tolerant mechanism is needed and a robust way of returning error messages. -rjc p.s. If I have reinvented the wheel, ignore this message. I didn't see any anonymous forward/list software on soda so I figured no one had written any. From cdodhner at indirect.com Mon Sep 6 07:16:19 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Mon, 6 Sep 93 07:16:19 PDT Subject: Key signing, authentication Message-ID: <199309061407.AA13849@indirect.com> Recently there was some discussion about when to sign somebody's public key and when not to. Does anybody have a short, to the point set of guidelines on when it is ok to sign? I think minimum requirements to sign would most likely be receiveing that key from the owner both on and off the net. That way somebody on the net who is doing man-in-the-middle type attacks is thwarted, as is somebody who gives you the key off the net with a false net-id. Anyway, I'm sure there's more to it than that, like are phone calls ok? I mean, how did you get the # anyway? And what about meeting the person in the flesh? How do you know they are the same person you talk to on the net? Thinking too much about this could make a person .realy. paranoid! ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner at indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" My opinions are shareware. To register your copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------ From nate at VIS.ColoState.EDU Mon Sep 6 08:01:19 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Mon, 6 Sep 93 08:01:19 PDT Subject: please send me info on the Randy Weaver case.. Message-ID: <9309061455.AA05349@nagel.VIS.ColoState.EDU> A while back there was a bit about a guy named Randy Weaver, I think in the mountains of California. Please send me all the information you may have on that case... what transpired, what was done about it, anything. thanks, -nate nate at vis.colostate.edu From MJMISKI at macc.wisc.edu Mon Sep 6 09:46:21 1993 From: MJMISKI at macc.wisc.edu (Matthew J Miszewski) Date: Mon, 6 Sep 93 09:46:21 PDT Subject: Law Review Articles Message-ID: <23090611381265@vms2.macc.wisc.edu> To answer many of your questions, I am alive. Ive been doing considerable research and thus been unable to reply to much of my mail. I am preparing to write one or several articles for publication on the legal effects of the internet and of course more specifically cryptography. Unfortunately, in the midst of my research i have come along a great deal more i could write about then first thought. So, I come to the list asking for input. For those who do not know, Law Review articles help litigators to support arguments that they need to make. They are not primary authority but often times one article will feed on another and develop into a school of thought. It is important to break into this cycle in order to further legitimize our (several) causes. Among topics already considered: International Data Havens Digitial Cash Algorithmic Patents Electronic Signiture reliability Cryptographic Export Laws First Amendment and the Net Computers, Freedom and Privacy (I wonder if thats a copyright infraction) Fair Use Laws and general Copyright Telecommunication Laws Effects on Competitiveness And a General Overview of the Cryptography Controversy I appeal to the list for further suggestions for topics as well as votes on which topic is most important to establish now. I am not locked in to any particular topic right now but will need to get going soon. Please forward any sources (good technical papers and legal sources), and any ideas or thoughts you may have. To those who care, Im back. To those who dont know me, Im back. To those who have offered help, I have not forgotten or abondoned ship, I will contact you. BTW, glad to see so much activity on the list. Keep up the good work. Matthew J. Miszewski mjmiski at macc.wisc.edu From doug at netcom.com Mon Sep 6 11:51:22 1993 From: doug at netcom.com (Doug Merritt) Date: Mon, 6 Sep 93 11:51:22 PDT Subject: Law Review Articles In-Reply-To: Message-ID: <9309061846.AA08938@netcom.netcom.com> Here's some more: authenticated signatures in regard to digital banking, direct democracy (both net and actual government), contract law, protection of sources in reporting, power of attorney, treaty signatures, anonymity of crime tips to police international bill of rights (some of these mechanisms potentially confer rights that certain governments do not) international law enforcement enforceability of information import/export restrictions evolution of international cooperative inter-government institutions (UN, world courts, world banks, interpol, etc) to match evolution of international net activities jurisdictional issues of international net activities (what does location mean in the net? Can I send an information agent to do things that are legal in the target country but not locally? What if the target country is indeterminate?) future changes in interpretation of sovereignty impact of a hypothetical declaration of a new nation in cyberspace (considering technical ability to vote, trade, "print" currency, tax, implement and enforce contracts, negotiate treaties, etc) U.S. bill of rights and its transferability to net activities U.S. federal versus state jurisdiction over net activities ability of existing legal theory to adequately cover such topics, including strength of current theories of philosophy of law Conceivably it's too early in the state of things to address some of these topics, but they'll all arise at some point, will he nill he. Doug -- Doug Merritt doug at netcom.com Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow Unicode Novis Cypherpunks Gutenberg Wavelets Conlang Logli Alife HC_III Computational linguistics Fundamental physics Cogsci SF GA VR CASE TLAs From mdiehl at triton.unm.edu Mon Sep 6 13:51:26 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Mon, 6 Sep 93 13:51:26 PDT Subject: Key signing, authentication In-Reply-To: <199309061407.AA13849@indirect.com> Message-ID: <9309062046.AA04749@triton.unm.edu> According to Christian D. Odhner: > > Recently there was some discussion about when to sign somebody's public > key and when not to. Does anybody have a short, to the point set of > guidelines on when it is ok to sign? I think minimum requirements to sign > would most likely be receiveing that key from the owner both on and off > the net. That way somebody on the net who is doing man-in-the-middle type > attacks is thwarted, as is somebody who gives you the key off the net with > a false net-id. Anyway, I'm sure there's more to it than that, like are > phone calls ok? I mean, how did you get the # anyway? And what about > meeting the person in the flesh? How do you know they are the same person > you talk to on the net? Thinking too much about this could make a person > .realy. paranoid! Well, I think I started that thread with a query. I got lots of discussion and summarized the (most conservative) concensus in my .plan file. You can read my policy by typing finger mdiehl at triton.unm.edu. Hope this helps. >"The NSA can have my secret key when they pry >it from my cold, dead, hands... But they shall >NEVER have the password it's encrypted with!" I love it! ;^) > J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politicly Incorrect! Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From ebrandt at jarthur.Claremont.EDU Mon Sep 6 14:41:25 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Mon, 6 Sep 93 14:41:25 PDT Subject: Remailer Reliability In-Reply-To: <9309040125.AA27752@achilles.ctd.anl.gov> Message-ID: <9309062138.AA15910@toad.com> > the header construction software already being worked on by > ebrandt at jarthur.Claremont.EDU (CRM) and others to use tricks Urk? Eli From an23135 at anon.penet.fi Mon Sep 6 15:12:19 1993 From: an23135 at anon.penet.fi (aragorn) Date: Mon, 6 Sep 93 15:12:19 PDT Subject: generic source for mail available Message-ID: <9309062207.AA21880@anon.penet.fi> sorry about this, it's a bit off the subject, but it will be very much on the subject if I ever find what I am looking for and do what I plan to do to it. Wanted: generic source code for mail. I just want to find some source that is not dependant on bsd or on SVR4 UNIX. It's for a "patch" I am planning for mail and sendmail. thanks in advance, ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From ld231782 at longs.lance.colostate.edu Mon Sep 6 21:46:31 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Mon, 6 Sep 93 21:46:31 PDT Subject: the Warehouse-Elansky-Ionizer case (fwd from CuD) Message-ID: <9309070441.AA20047@longs.lance.colostate.edu> This is perhaps the first mostly factual & objective account coming out so far on this subject at this very preliminary period, but still plenty of appended bitter ire. Gives more background on Elansky but has a definite speculative undertone. More info in comp.org.eff.talk. It doesn't talk about the rather emotional relation of the bail to other bail rates (e.g., is it true that murder is $100K standard?) There's some mushy academic rationalization on Elansky as a product-of-society-and-environment `rebellious youth': >There is sufficient academic literature on the rebellious subcultures >of youth to support the claim of excessive posturing, attachment to >symbols perceived to be anti-social and shocking, and social rituals >establishing unity and identity among participants in youthful >"deviant" (a sociological, not a moral label) subcultures. oh brother. sounds like something Mr. T.C. May would write :-P >It appears that Mike Elansky may be less than a saintly naif. >It also appears that he is hardly a hardcore villain. Jim Thomas writes on comp.org.eff.talk 8/6/93 that he talked to the defense attorney of Elansky, and `it sounded as if the defense is in disarray' (last Tuesday & Thursday). Attorney D. Brown (203-522-3343) `just returned from vacation', and was unfamiliar with the case initially, the cyberspatial angle, and EFF. Nevertheless `His first concern was to get Elansky released.' Hence, amazingly, it appears that mobilization and publicity of the defendant's corner has engaged far faster in cyberspace than in his local `real world' proximity. Perhaps this signals a turning point for cases of this type. Preliminary signs, such as in the document below, suggest the `raid' was fundamentally ill-considered, and given the sheer nonexistence and paranoia of the prosecution's case so far revealed, and despite what J. Thomas expects, I think this will probably be a major victory for Elansky & BBS operator rights. Of course, in cases like this, for a clear-cut PR victory, the more innocent and upstanding the victim the more powerful the propaganda. Steve Jackson was absolutely classic in both respects, and it is unlikely that any case on computer seizure & constitutionality so momentous will ever return. However, this one could rate high up there. (As J. Thomas writes below, however, the so-far invisible media attention is very frustrating. It is possible there are simply no major sources or reporters aware of it.) Following came to the newsgroup comp.org.eff.talk via C.M. Kadie, himself a modern cyberspatial hero. (Warehouse is the BBS, Ionizer is Elansky's pseudonym.) ===cut=here=== [From Computer underground Digest Sun Sep 5 1993 Volume 5 : Issue 69, ISSN 1004-042X. For a free on-line subscription, send email to tk0jut2 at mvs.cso.niu.edu. -cmk] Date: Sun, 5 Sep 1993 14:43:51 CDT From: Jim thomas Subject: File 1--The Ware House BBS Case Reconsidered Until August 2, Mike Elansky was just another 21 year old student at the University of Hartford majoring in electronics. He also ran a BBS affiliated with the IIRG (International Information Retrieval Guild) called The Ware House, using "Ionizer" as his handle. Today (Sept 5), he remains in jail unable to post his $500,000 bond. His crime? Judging from newspaper accounts, his family, and his attorney, it appears to be for exercising his First Amendment rights. According to the prosecutor's indictment, Elansky's sin involves creating risk of injury to a minor and advocating violence against law enforcement agents. If convicted, he faces up to 10 years in prison. BACKGROUND The following file elaborates on the details, and there seems little substantive disagreement over the essential facts of the case. Elansky was considered by those who knew him as a typically normal youth with a passion for computers and electronics. Some have also noted that he did have an interest in explosives, neither illegal nor odd, and that he had previous run-ins with the law for relatively minor, non-violent offenses. This is not unusual in a society in which up to 25 percent of male colleges students between the ages of 17-22 could say the same thing. However, nothing officially noted in Elansky's past seems to provide any reasonable justification for the current reaction to him. According to media, the indictment, defense attorney Dick Brown, and others close to the case, two "anarchy files" led to the indictment. The files, similar to but not identical with, those found in countless other similar ASCII files or books (especially The Anarchists Cookbook) described pyrotechnics. The vocabulary used in the files might be considered by some to be childish posturing or offensive bad taste. The prosecutor considered them a direct threat to law enforcement officers by claiming that they actively advocated violence against police. Apparently using a minor to aid them, Hartford police allegedly downloaded files from The Ware House's file section, and one in particular drew their attention. According to those who have read the file and seen the BBS logs, either the file's author or the uploader, but *not* Elansky, introduced instructions for making an explosive device with: ! Note to Law-enforcement type people: ! ! This file is intended to promote ! ! general havoc and *ANARCHY*, and ! ! since your going to be the first ! ! assholes up against the wall.. there ! ! isnt a damn thing you can do about ! ! it, pigs! ! Silly? Sure. Immature? You bet. Offensive? Depends on your point of view. In bad taste? Undoubtedly. But, ILLEGAL? Doubtful. Of sufficient import, even when coupled with pyrotechnic instructions, to warrant arrest, indictment, and an insurmountable bond? No way. "Way," says the prosecutor. According to Elaine Elansky, Mike's mother, the bond was initially set at $25,000 by the judge, but the prosecutor intervened and succeeded in raising it. According to some inside sources, Elansky was also denied legal representation at critical points in the initial proceedings. There appears to be no evidence that Elansky himself advocated or himself was involved in any activities that advocated violence. His apparent interest in explosives, which, according to one informant, included a legal demonstration of a harmless pyrotechnic display as part of a licit highschool project, added to the suspicions and "evidence" against him. However, judging from the indictment, the only concrete charges and substantive evidence were the "anarchy files." WHAT ARE ANARCHY FILES? "Anarchy" files have been a common feature of many BBSes since the emergence of the "computer underground" culture. Their common theme emphasizes destructive "trashing" often perceived as a primitive form of social rebellion. The files range from silly pranks (such as "How to fuck-up a MacDonalds," which describes "barfing techniques") to potentially dangerous instructions for making pyrotechnical and similar devices. Many of the files, especially those that describe how to manufacture home-made hallucinogens or how to make "weapons" out of strange combinations of ingredients (make explosives with soap, vinegar, and talcum powder??), are totally ineffective. Other instructions are not. However, even the most destructive instructions that we have seen are simply plagiarized or slightly edited accounts taken from licit over-the-counter literature or from other sources, such as U.S. military manuals or highschool/college chemistry classes. The difference is that creators of anarchy files alter the vocabulary and rhetoric for a young audience. The new discourse tends to reflect the social rebellion of youth rather than any serious prescription for action. And, one is likely to learn more from watching a MacGyver episode than from most anarchy files. There is sufficient academic literature on the rebellious subcultures of youth to support the claim of excessive posturing, attachment to symbols perceived to be anti-social and shocking, and social rituals establishing unity and identity among participants in youthful "deviant" (a sociological, not a moral label) subcultures. This is a common part of the maturation process as youths pass from adolescence to adulthood. Whether in the form of the counter-culture of the 1960s, "punk-rock"/heavy-metal/thrash-metal" of the last 15 years, "rap" lyrics that extol violence and misogyny, or even Satanism and other esoteric and, for some, grossly offensive expressions of rejection of mainstream society, youth find increasingly creative ways to shock their elders in a cyclical game of generational freak-outs. There are, of course, misguided youths unable to distinguish fantasy posturing from reality. The most appropriate responses to troubled youth include non-punitive intervention or, in extreme cases, law enforcement intervention *after* they violate laws. Perhaps Mike Elansky is one for whom intervention is appropriate. Or, perhaps not. Based on the information released to the public so far, there appears to exist no substantial evidence supporting the indictment other than the availability of licit, Constitutionally-protected, youth culture documents symbolizing "wreaking havoc" on the standards of propriety of adults and "straights," rather than a literal advocacy of physical assault on persons or property. ISSUES IN THE ELANSKY CASE Perhaps the prosecutor will find sufficient evidence to try Mike Elansky for something. Perhaps, even if the facts are as they seem and evidence of wrong-doing weak, he will be found guilty. After all, the experiences of Len Rose, Craig Neidorf, Steve Jackson Games, Sun Devil victims, Rich Andrews, and many others remind us that "justice" is not always served by the justice system in computer-related cases. However, the Elansky cases raises broader issues. Just a few include: 1. THE FIRST AMENDMENT: If, as the prosecutor contends, the files in question are illegal and subject to felony prosecution with potential imprisonment, and if, as the next file indicates, the information in these files is readily accessible to the public through licit channels, then what is the basis for targeting a BBS sysop for prosecution while ignoring public libraries and bookstores? Does this mean that the prosecutor rejects First Amendment protections for BBSes? If so, the implications for electronic publishing are staggeringly frightening: It subjects sysops and users to an arbitrary standard of acceptability that apparently may be determined at the discretion of individual prosecutors. Whatever suspicions the prosecutor may have about Elansky's activities, making the anarchy files available is the crux of the indictment, and if successful in his prosecution for making it available, the chilling effect on electronic publishing will be substantial. 2. ELECTRONIC PUBLISHING: The following IIRG file notes the availability of numerous anarchy texts and discussions on the nets and elsewhere. If prosecution of the Elansky case is successful, a precedent could be established that would stifle both publishing and public discussion. If Elansky is found guilty as charged in the indictment, should administrators at the University of Hartford also be held liable for making such information available to minors through its computer facilities? Could other BBS sysops be punished? Would a user who calls a BBS in New York and downloads the file be at risk for a federal crime by transporting "illegal files" across state lines? MEDIA: It appears that Mike Elansky may be less than a saintly naif. It also appears that he is hardly a hardcore villain. Perhaps this is why the media doesn't find his situation worthy of front page news. But, Mike Elansky, depressing as his situation is, and unjust as his situation may seem given the current available facts, IS NOT THE ISSUE. When The Department of Treasury BBS was criticized for having virus source code and "underground files" (that included Cu Digest) available, the story made the front page of the Washington Post, CNN, the AP Wires, and other media (see CuD 5.51, 5.57, 5.58). When a poster on The Well, a public access system in California, was using ASCII to hustle four women, some simultaneously, it made the front page of the Washington Post, and was given prominent play in Time Magazine, The Chicago Tribune, The San Francisco Chronicle, and numerous other papers. On a slow news day, mundane sex and fabricated scandal sells. Substantive stories that are slow, lack a sexy angle, or may require thought rather than momentary titillation, are boring. Yet, the implications of of a kid languishing in jail because he can't post $500,000 bond for running a BBS with "anarchist" files has implications of far more import than cyber-sex. Perhaps Mike Elansky is the next terrorist-from-hell, using his board to plot mayhem, as his prosecutor suggests. Or, perhaps he is just some young kid who is being persecuted for exercising First Amendment rights in a form of persecution that illustrates prosecutorial abuse and trampling of the Constitution. Either way, it is curious that those who cover cyberspace for the major media find "cyber-Lotharios" more worthy of investigation than a story with substance. Something is not right in Hartford, and therein lies the story. A FINAL COMMENT The battle over symbolic boundaries between "good" and "evil" often reflects conflicts of clashing values and cultures. When laws are used creatively as weapons to suppress distasteful, but licit, language and behavior rather than to enforce the law and ensure Constitutionally protected rights, then the government abuses the law. To recast former U.S. Supreme Court Justice Louis Brandeis's 1928 comment, if government abuses law, it breeds contempt for law and invites people to become a law unto themselves--it invites anarchy. Whatever Mike Elansky may or may not have done, the implications of the ostensible indictment for publishing "anarchy files" seem to overstep both the spirit and the letter of the Constitution. Judging from the facts currently available, it appears that the handling of the Elansky case may be another instance of law enforcement excess in attempting to police cyberspace. If so, continued attempts by law enforcement to impose moral standards by excessive use of law cannot be ignored. Dissemination of information, especially information that puts others at risk, also entails responsibilities. It strikes me as far more appropriate to discuss the implications of information made increasingly accessible by expanding information technology rather than attempt to establish moral boundaries by fear of prosecution. -- Carl Kadie -- I do not represent any organization; this is just me. = kadie at cs.uiuc.edu = From ld231782 at longs.lance.colostate.edu Mon Sep 6 23:57:24 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Mon, 6 Sep 93 23:57:24 PDT Subject: correction Message-ID: <9309070653.AA21588@longs.lance.colostate.edu> >Jim Thomas writes on comp.org.eff.talk 8/6/93 that he talked to the 9/6/93 -- Sept. 6. mea culpa. From gnu Tue Sep 7 00:16:34 1993 From: gnu (John Gilmore) Date: Tue, 7 Sep 93 00:16:34 PDT Subject: Four new alt-groups on government agencies we love to hate Message-ID: <9309070713.AA23639@toad.com> ------- Forwarded Messages From: jkp at cs.HUT.FI (Jyrki Kuoppala) Newsgroups: alt.politics.org.batf Subject: cmsg newgroup alt.politics.org.batf Control: newgroup alt.politics.org.batf Date: 6 Sep 1993 20:23:46 GMT Organization: Helsinki University of Technology, Finland Message-ID: <26g68i$bgh at nntp.hut.fi> Reply-To: jkp at cs.HUT.FI (Jyrki Kuoppala) The topic of the group is the discussions and information on the politics and activities of the U.S. Bureau of Alcohol, Tobacco, and Firearms. For your newsgroups file: alt.politics.org.batf Politics of the U.S. firearms (etc.) regulation agency ------- Message 2 From: jkp at cs.HUT.FI (Jyrki Kuoppala) Newsgroups: alt.politics.org.cia Subject: cmsg newgroup alt.politics.org.cia Control: newgroup alt.politics.org.cia Date: 6 Sep 1993 20:46:58 GMT Organization: Helsinki University of Technology, Finland Message-ID: <26g7k2$c9u at nntp.hut.fi> Reply-To: jkp at cs.HUT.FI (Jyrki Kuoppala) The topic of the group is the discussions and information on the politics and activities of the U.S. Central Intelligence Agency. For your newsgroups file: alt.politics.org.cia Politics of the U.S. Central Intelligence Agency ------- Message 3 From: jkp at cs.HUT.FI (Jyrki Kuoppala) Newsgroups: alt.politics.org.nsa Subject: cmsg newgroup alt.politics.org.nsa Control: newgroup alt.politics.org.nsa Date: 6 Sep 1993 20:52:36 GMT Organization: Helsinki University of Technology, Finland Message-ID: <26g7uk$cmo at nntp.hut.fi> Reply-To: jkp at cs.HUT.FI (Jyrki Kuoppala) The topic of the group is the discussions and information on the politics and activities of the U.S. National Security Agency. For your newsgroups file: alt.politics.org.nsa Politics of the U.S. National Security Agency ------- Message 4 From: jkp at cs.HUT.FI (Jyrki Kuoppala) Newsgroups: alt.politics.org.covert Subject: cmsg newgroup alt.politics.org.covert Control: newgroup alt.politics.org.covert Date: 5 Sep 1993 21:46:23 GMT Organization: Helsinki University of Technology, Finland Message-ID: <26dmnf$ksb at nntp.hut.fi> Reply-To: jkp at cs.HUT.FI (Jyrki Kuoppala) As proposed in alt.config 2 Sep 1993. The topic of the group is various organizations around the world engaging in paramilitary action, intelligence, spying, covert operations, ie. the "dark side" of governmental action or action supported by governments but secret to nearly all citizens. What kind of political power do these organizations hold? How do they use it? Are they a threat to governments by the people or a threat to freedom and democracy? Are they "a necessary evil" in an unperfect world? For your newsgroups file: alt.politics.org.covert Covert ("spook") organizations around the world ------- End of Forwarded Messages From b44729 at achilles.ctd.anl.gov Tue Sep 7 05:02:29 1993 From: b44729 at achilles.ctd.anl.gov (Samuel Pigg) Date: Tue, 7 Sep 93 05:02:29 PDT Subject: Remailer Reliability In-Reply-To: <9309051614.AA27793@flammulated.owlnet.rice.edu> Message-ID: <9309071157.AA05471@achilles.ctd.anl.gov> >>>>> On Sun, 5 Sep 1993 11:14:48 -0500 (CDT), Karl Lui Barrus said: Karl> Samuel Pigg wrote: >go here. A simple command language for the remailers would allow >the header construction software already being worked on by >ebrandt at jarthur.Claremont.EDU (CRM) and others to use tricks >like this to defend against attacks. Karl> ?? Karl> Header construction software for unix and pc's has Karl> existed for months and is available at soda.berkeley.edu Karl> Granted, I'm waiting to validate three of the remailers Karl> so the scripts are a bit out of date, especially the dos Karl> batch files... Ok.. I'll rewrite it: >go here. A simple command language for the remailers would allow >the header construction software already around to use tricks >like this to defend against attacks. The point is that header contruction software would be able to use the remailer command language in the header contruction to custom tailer some of the defense against statistical and traffic based remailer attacks. Sam Pigg dt1acaa at cfraix.cfr.usf.edu samp at renoir.cftnet.com b44729 at achilles.ctd.anl.gov PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C From remail at tamsun.tamu.edu Tue Sep 7 05:16:37 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Tue, 7 Sep 93 05:16:37 PDT Subject: New BBS Trade Group Message-ID: <9309071209.AA15958@tamsun.tamu.edu> NOMA National Online Media Association Contacts: Phill Liggett LIGGETT at delphi.com (203)233-3163 Lance Rose elrose at echonyc.com (201)509-1700 FOR IMMEDIATE RELEASE A new trade association, the National Online Media Association (NOMA), was formed at ONE BBSCON '93 in Colorado Springs on August 27th, 1993. NOMA comprises BBS operators, Internet service providers, and other online media and services. NOMA's mission is to act for the BBS and online service industry on matters of national importance by creating an industry presence in Washington, D.C. and other means; assist its members at the state and local levels; educate the public on the unique social, business and legal roles of BBS's and other online services; establish appropriate industry standards and guidelines; promote business development in the industry; and maintain and provide access to resources and industry information for use by the public and the industry. An 11 person Organizing Committee was elected to develop a proposal for NOMA's charter, bylaws, membership requirements, structure, and form of leadership. The proposal is to be completed and distributed within the BBS and online services industry by November 30th, 1993. Discussion areas are being set up immediately for those interested in participating in NOMA's early development. An Internet mailing list is available to all those interested at natbbs at echonyc.com (subscribe to natbbs-request at echonyc.com). A conference area is also being made available on the Delphi national information service. The members of NOMA's Organizing Committee are: Phill Liggett - Chairperson LIGGETT at delphi.com Joe Balshone BALSHONE at delphi.com Celeste Clark BBS #: (805)520-2300 Pat Clawson 76357.3572 at compuserve.com P. Victor Grambsch - Secretary PVICTOR at delphi.com Tony McClenny BBS#: (703)648-1841 Robert Pataki PUGDOG at delphi.com W. Mark Richmond BBS#: (209)685-8487 Steve Sprague steve.sprague at uboa.org Jim Taylor jim.taylor at F5.N310.Z1.FIDONET.ORG Bill Wilt wilt at aol.com In addition, three advisors agreed to assist NOMA's Organizing Committee: Mike Godwin, Esq. mnemonic at eff.org David Johnson, Esq. djohns06 at reach.com Lance Rose, Esq. elrose at echonyc.com For further information, please contact Phill Liggett, (203)233- 3163 or Lance Rose, Esq., (201)509-1700 Mailing Address: NOMA c/o Phill Liggett Solutions, Inc. 89 Seymour Avenue, West Hartford, CT 06119. From cme at ellisun.sw.stratus.com Tue Sep 7 08:06:39 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Tue, 7 Sep 93 08:06:39 PDT Subject: Law Review Articles Message-ID: <9309071500.AA17823@ellisun.sw.stratus.com> I have two pet issues: 1. Who Owns Cryptography? David Kahn's "The Codebreakers" shows that strong cryptography (as strong as that used by the military of the time) has almost always been invented by and used by private individuals, throughout history. The US Gov't (especially the NSA) has been trying to give the impression that it owns cryptography. The case needs to be made that cryptography inventions occur spontaneously in the minds of individuals and that cryptography is used to guard privacy (of both files and conversations) in a way the government: a. could not control if it tried, short of "1984" style room bugging, informants, ... b. should not control because of the 4000 year history of private ownership of cryptography. 2. Export Laws for Cryptography -- There are three classes of cryptography, logically: i. Munitions ii. Commercial iii. Public Domain Munitions cryptography would include systems using government classified algorithms or incorporated in physical hardware which has been hardened for battlefield use. Commercial would include systems which are proprietary to some company and sold by that company. Public domain would include systems which have been fully published (DES, RSA, DH, IDEA, , ...), have been implemented from those publications and which are effectively already in the hands of any interested high school kid. These are often available on public BBSs, worldwide. (PGP, for example) It makes sense to control munitions via ITAR and commercial systems via the commerce department, while leaving public domain systems uncontrolled c/o freedom of speech. What can be done to make these points? If these are not law review issues, what can I do as a private citizen to put these forth? - Carl From visgraph!forrie Tue Sep 7 09:11:41 1993 From: visgraph!forrie (Forrest Aldrich) Date: Tue, 7 Sep 93 09:11:41 PDT Subject: Munitions class encryption Message-ID: <199309071532.AA01937@visgraph.uucp> I am curious about what constitutes "Munitions" class cryptography; is there really anything out there available to "us" that is of this "quality" (being unsure of where pgp stands with this). If there were, would it be feasible to have something like this that is software-only-based? If so, and it originated outside of the USA, I wonder what the officials would think of its use. On that line, I wonder if traffic-analysis isn't being performed right now to determine where the heaviest use of PGP exists. Perhaps to some, the idea of traffic-analysis (on the internet, that is) might sound a bit silly; however, I have been assured that this type of activity is none-the-less a regular one, and is used for many purposes. Anyone have more details? I had a friend who worked in the COMM center at a former air force base. He had a top secret clearance, and said that one of his duties was to separate (and deliver?) classified printouts. He said that the stuff he read in there would 'blow your mind'. He said that (this was only a few years ago) the government used encryption cards (computer cards) which were changed on a daily basis. Which makes me wonder if "Munitions" class cryptography would indeed require hardware support. From sameer at netcom.com Tue Sep 7 09:31:38 1993 From: sameer at netcom.com (Sameer Parekh) Date: Tue, 7 Sep 93 09:31:38 PDT Subject: news.cs.indiana.edu Message-ID: <9309071626.AA13650@netcom.netcom.com> news.cs.indiana.edu oes not appear to be working as an anonymous news posting gateway. A recent post through my remailer to alt-security didn't work. -- Sameer sameer at netcom.com From nobody at Menudo.UH.EDU Tue Sep 7 10:12:34 1993 From: nobody at Menudo.UH.EDU (nobody at Menudo.UH.EDU) Date: Tue, 7 Sep 93 10:12:34 PDT Subject: REMAIL: pasting Message-ID: <199309071705.AA02648@Menudo.UH.EDU> -----BEGIN PGP SIGNED MESSAGE----- Earlier, a question about pasting arose. The cypherpunks remailers to support an outgoing pasting token: the double hash (##). It will paste text into the outgoing mail header. For example, this message was sent through the remailer elee9sf at menudo.uh.edu: - -------------------- :: Request-Remailing-To: cypherpunks at toad.com ## X-Pasted-By: Karl Barrus - -------------------- So there should be an "X-Pasted-By:" in the header somewhere! I'm not sure about pasting in reply fields to override behavrior. That dependes on precedence between "From:" and "Reply-To:", etc. Basically, I'm not real familiar with the appropriate RFC :-) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIy/G4OA7OpLWtYzAQHbGgP/alyO+uY6pkzEr9nPKVzYKiB0DcopcKDJ 3tV937CjldyC48K0g3iJ9San6bk6KGLstALQwMSvWIW5kSq1GRxFAgxBuZ9vnT/X 3gN+vn+8jao/H7H20tRilz5nzIW/AhRhc//46Xr4QafPcXI6BXRvsEY0SkzHEkYV 9D5xakEYhiM= =kf83 -----END PGP SIGNATURE----- From nobody at Menudo.UH.EDU Tue Sep 7 10:32:41 1993 From: nobody at Menudo.UH.EDU (nobody at Menudo.UH.EDU) Date: Tue, 7 Sep 93 10:32:41 PDT Subject: REMAIL: timestamp Message-ID: <199309071728.AA04198@Menudo.UH.EDU> -----BEGIN PGP SIGNED MESSAGE----- With all the talk of timestamps, I decided to implement a simple timestamp on the remailer at elee9sf at menudo.uh.edu. It is by no means a cryptographically secure timestamp. The remailer adds a timestamp header field to outgoing messages. It looks like this: X-Timestamp: hour:min:sec on day:month:year For instance, this message should have one. This nice thing about this is that in the process of stripping mail headers, the remailers will automatically filter the X-Timestamp as well. Thus, if a message is chained through several remailers, only the last remailer's timestamp (if any) will appear in the final message. klbarrus at owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIzEmIOA7OpLWtYzAQFTFwP9F84EDoIh8XmRDuY4463N5U9jAtLeXBnz WtrGuLF10Vngz3GDkGn4BQF4GQfEUgbYFcosZs3bV8/t0SP487PpnvblV7HG3/rO Fs39piJYTVETnBl14Gt8xVic8GxPvKuAatqk+J9rvKpj1eTklxFT2a/bqOCCJ1FK TuhZQHAVR5U= =U47Z -----END PGP SIGNATURE----- From Andrew.Corradini at m.cc.utah.edu Tue Sep 7 10:56:40 1993 From: Andrew.Corradini at m.cc.utah.edu (Andrew Corradini/SBDC) Date: Tue, 7 Sep 93 10:56:40 PDT Subject: Just the faq, jack Message-ID: Hiya, and ad-apologies-vance if this is patently obvious... Just subscribed, and was hoping to find an ftp site associated with the maillist, any faq-like information, whatever... Thanks, Andrew Corradini asc7556 at u.cc.utah.edu From nowhere at bsu-cs.bsu.edu Tue Sep 7 11:41:41 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Tue, 7 Sep 93 11:41:41 PDT Subject: REMAIL: pasting Message-ID: <9309071839.AA26292@bsu-cs.bsu.edu> In-Reply-To: <199309071705.AA02648 at Menudo.UH.EDU>; from "nobody at Menudo.UH.EDU" at Sep 7, 93 12:05 pm > >The cypherpunks remailers to support an outgoing pasting token: the >double hash (##). It will paste text into the outgoing mail header. > >I'm not sure about pasting in reply fields to override behavrior. >That dependes on precedence between "From:" and "Reply-To:", etc. >Basically, I'm not real familiar with the appropriate RFC :-) > My remailer certainly does not support a double hash! If you want to paste something into the header with my remailer, put it in the "::" header block. For example: :: Request-Remailing-To: nowhere at bsu-cs.bsu.edu Subject: blah Reply-To: an1234 at anon.penet.fi X-Pasted-By: nowhere It will ignore the "##" header block and send it as part of the body. By the way, chaos.bsu.edu is currently down... I screwed up my boot sector. I was going to install NetBSD 0.9 anyway, so that's what I'll do this afternoon or Thursday. Chael -- Chael Hall nowhere at bsu-cs.bsu.edu 00CCHALL at BSUVC.BSU.EDU nowhere at chaos.bsu.edu chall at bsu.edu From collins at newton.apple.com Tue Sep 7 12:26:42 1993 From: collins at newton.apple.com (Scott Collins) Date: Tue, 7 Sep 93 12:26:42 PDT Subject: Who generates AOCE keys? Message-ID: <9309071843.AA27927@newton.apple.com> In the software I used (as recently as last Thursday) the keys are _absolutely_, _positively_ generated locally. Subsequently the public key can be mailed automagically to RSADSI to be incorporated into a certificate which is returned to you. The latest version of RIPEM Mac uses the same procedure for the same functionality. >>[...] users will get certified keys from RSA [...] Yes! _After_ sending RSADSI an uncertified key. >>[the user] can generate a key for use on their network This is the uncertified key. >>Apple believes you'll want publically certified keys Thus, they provide a mechanism to get RSADSI to certify your (self generated) key. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From mdiehl at triton.unm.edu Tue Sep 7 13:16:42 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 7 Sep 93 13:16:42 PDT Subject: REMAIL: timestamp In-Reply-To: <199309071728.AA04198@Menudo.UH.EDU> Message-ID: <9309072012.AA27465@triton.unm.edu> According to nobody at Menudo.UH.EDU: > > The remailer adds a timestamp header field to outgoing messages. It > looks like this: > > X-Timestamp: hour:min:sec on day:month:year Ya fergot to mention which TIMEZONE you are in! J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politicly Incorrect! Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From nobody at Menudo.UH.EDU Tue Sep 7 13:36:44 1993 From: nobody at Menudo.UH.EDU (nobody at Menudo.UH.EDU) Date: Tue, 7 Sep 93 13:36:44 PDT Subject: REMAIL: timestamp Message-ID: <199309072028.AA23070@Menudo.UH.EDU> Well, I decided to comment out the timestamping (what a short lived feature! :-) I'm starting to work on a caching remailer, and the timestamping info could be used to map input and output mailing pairs - especially since I was going to change the stamps to read "X-Time-In:" and "X-Time-Out:". That would defeat the entire purpose of caching... From cdodhner at indirect.com Tue Sep 7 14:01:44 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Tue, 7 Sep 93 14:01:44 PDT Subject: Who generates AOCE keys? In-Reply-To: <9309071843.AA27927@newton.apple.com> Message-ID: <199309072054.AA27320@indirect.com> Scott Colins writes: > In the software I used (as recently as last Thursday) the keys are > _absolutely_, _positively_ generated locally. Subsequently the public key > can be mailed automagically to RSADSI to be incorporated into a certificate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > which is returned to you. The latest version of RIPEM Mac uses the same > procedure for the same functionality. Well, what keeps people from makeing keys with somebody else's name/user id on them and sending them in to be certified? Where is the authentication from the key certifier's point of view? Just wondering. Happy Hunting, -Chris. ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner at indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" "If guns are outlawed, only the government will have guns." -E. Abbey My opinions are shareware. For a registered copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------ From collins at newton.apple.com Tue Sep 7 15:47:40 1993 From: collins at newton.apple.com (Scott Collins) Date: Tue, 7 Sep 93 15:47:40 PDT Subject: Who generates AOCE keys? Message-ID: <9309072205.AA05327@newton.apple.com> Christian D. Odhner writes: >what keeps people from [getting certified] keys with somebody else's name The The relation between the preferred signature authority for the installation, and that installation. From the documentation: >Some companies authorized to issue approval files to their employees may >require that you sign a printed request form and have it notarized by a >notary public. (To create a printed request form, choose Print from the File >menu.) Note: If you are going to use your Signer as an individual or in a >small business, look for the insert that came with this package for >instructions on using an outside approval authority. >Print your request and send it, with a copy of the Request file on disk if >necessary, to your approval authority. See the insert that came with your >package for details. Assuming that your request form has been completed >properly, the approval authority will send back your Signer Approval file. ...which would seem to put the lie to (the general application of) my ealier statement: >[the key] can be mailed automagically to RSADSI Which turns out to be true only for the 'low assurance' RSA Persona Certificate Authority (currently handing out certificates for free) which does no verification of the user<-->id link. CAs with more stringent policies have stronger prerequisites for the issuance of a certificate. Hope this helps, Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From lefty at apple.com Tue Sep 7 15:51:44 1993 From: lefty at apple.com (Lefty) Date: Tue, 7 Sep 93 15:51:44 PDT Subject: Who generates AOCE keys? Message-ID: <9309072243.AA09027@internal.apple.com> Christian Odhner wonders: > >Well, what keeps people from makeing keys with somebody else's name/user >id on them and sending them in to be certified? Where is the >authentication from the key certifier's point of view? The pass phrase. -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From frc%bwnmr4 at harvard.harvard.edu Tue Sep 7 16:16:45 1993 From: frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) Date: Tue, 7 Sep 93 16:16:45 PDT Subject: Remailing Message-ID: <9309072309.AA08374@bwnmr4.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- Would it be possible to incorporate a ping into the remailer? Say give it a list of known remailers for the chain and have it pick one at random, then ping it. If the remailer responds then send out the mail, otherwise pick a new remailer, and repeat.... Or this there a flaw in this that I'm just too ignorant to see? FRC -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLI0UtbbAlE4AqlTZAQEtTQP/SZlTdkSn+fwiO13SybCHGArjWPpl+xg8 CnSxgw7coYUWdMUU/kwnCQWuLKVsZigcLQmlm1SUvvf6MADmkENF1A0V1Q7kej7Q CCHEjvKA78oHAFBjw3b/BuBAGIibtuGubrSDp/65fe3jF2obDwK4mJqSlD9dcWLC SzU58NCnl9M= =zmFE -----END PGP SIGNATURE----- From baumbach at atmel.com Tue Sep 7 16:31:45 1993 From: baumbach at atmel.com (Peter Baumbach) Date: Tue, 7 Sep 93 16:31:45 PDT Subject: double-blind vs single-blind Message-ID: <9309072304.AA10914@octopus.chp.atmel.com> > ------------------------------------------------------------------------- > To find out more about the anon service, send mail to help at anon.penet.fi. > Due to the double-blind, any mail replies to this message will be anonymized, > and an anonymous id will be allocated automatically. You have been warned. > Please report any problems, inappropriate use etc. to admin at anon.penet.fi. I have a remailer question. I see a letter posting an offer on the net. The person making the offer is not anonymous. I wish to be anonymous, so I decide to use a remailer to reply. My reply includes a anNNN reply address. If the original poster replies back, an anonymous id will be allocated to him. This isn't any good. When the reply arrives, I will see the new anonymous id of a user whos real username and address I know! My pen-pal would compromise his ability to post anonymously in the future. How can I send an anonymous message that allows a reply that is not anonymous? Keep in mind my pen-pal may not know anything about remailers yet. (I have yet to use them myself :-) Peter Baumbach baumbach at atmel.com From sameer at netcom.com Tue Sep 7 16:51:46 1993 From: sameer at netcom.com (Sameer Parekh) Date: Tue, 7 Sep 93 16:51:46 PDT Subject: news.cs.indiana.edu *does* work Message-ID: <9309072346.AA22332@netcom.netcom.com> The person using my remailer to send news through the posting server incorrectrly used hyphens instead of periods to post news. Sorry about not verifying a simple error like that before posting about it. -- Sameer sameer at netcom.com From marc at Athena.MIT.EDU Tue Sep 7 16:52:41 1993 From: marc at Athena.MIT.EDU (Marc Horowitz) Date: Tue, 7 Sep 93 16:52:41 PDT Subject: Remailing In-Reply-To: <9309072309.AA08374@bwnmr4.harvard.edu> Message-ID: <9309072346.AA23274@hodge.MIT.EDU> >> Or this there a flaw in this that I'm just too ignorant to see? It's fine, if you don't mind making traffic analysis completely trivial. Marc From frc%bwnmr4 at harvard.harvard.edu Tue Sep 7 17:11:46 1993 From: frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) Date: Tue, 7 Sep 93 17:11:46 PDT Subject: Remailing In-Reply-To: <9309072346.AA23274@hodge.MIT.EDU> Message-ID: <9309080005.AA08479@bwnmr4.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- How does this make TA trivial? I am assuming that batch mailings or staggered mailings are occuring. The remailers are known locations so any traffic between mailers is assumed to be observed. The key is making it impossible to correlate arrival and departure time of any particular message. Am I missing something? -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLI0h2bbAlE4AqlTZAQExOAQAs6lLhVMjm5hi9swLgkLFJUSz8SazhlfW 5RDTBxNJs2oxt0oit1oEvKqBR26zKKayrwQf2O1DIxQD/f08qfIRS5dbLiz8c4VE 5XiP5j+HBr9j/mt5EiN8uCukpi1eP4pCq/cl82UDqkA8kkosvNDfSY26ubmf97FH 3uNbJ6vkWv0= =qryI -----END PGP SIGNATURE----- From ld231782 at longs.lance.colostate.edu Tue Sep 7 20:31:47 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 7 Sep 93 20:31:47 PDT Subject: the Pitfalls and the Pendulum of Anonymity In-Reply-To: <9309072304.AA10914@octopus.chp.atmel.com> Message-ID: <9309080324.AA21869@longs.lance.colostate.edu> baumbach at atmel.com (Peter Baumbach) raise the problem with the anon.penet.fi remailer: he sends email to someone who does not have an ID on the server. They reply, causing the server to automatically allocate them an ID. He now knows their anonymous ID. This can also happen if somebody `accidentally' responds to a message directed to their `cleartext identity' (not sent through the server) anonymously through the server. Since no one else has posted on this yet I will. The short answer is that you can tell them to use your address `na[x]' and their anonymous identity won't be revealed, and if they are using the server they might know that (is it stated in the introduction material? it sure should be). The collective list psyche realized this was a problem in an epiphany about 6 months ago (due credit, I recall it was Deadbeat who brought it to everyone's attention). It was a very lively exchange because J. Helsingius was also involved simultaneously. (In fact, I'd call it one of the few great testaments to cypherpunk prowess.) The problem is rooted in two circumstances: (1) the server was mainly intended for posting to newsgroups at its origination, where the automated anonymizing (J. Helsingius' term: `automated double blinding') makes sense. If someone posts to a newsgroup anonymously, it is harmless and perhaps beneficial for replies to that posting to be automatically anonymized. (2) however, a major use of the server is email-to-email mail, so to speak. in this case the scenario raised by Deadbeat in the past & Baumbach recently reveals the pitfalls in the `feature'. the automated anonymizing feature, implemented with the best of intentions, has come back to haunt J. Helsingius rather rudely--it is perhaps the greatest weakness of the server, other than the corrected `forge-without-passwords' aspect (where someone can forge an email message from: address and possibly determine anonymous-to-identity mappings through trial and error if no passwords are used). J. Helsingius has announced grand visions for the amazing, spectacular, and impending Mark II server that will incorporate full encryption (user keys mappings and a server key), along with a new default in which replies to anonymous email will not be automatically anonymized. Arriving `sometime in the fall'. If anyone wants it sooner, donate a hard drive or something to this great living cypherpatriot, who has personally monitored contributed to the list for suggestions and maintenance over many months span. There are multitudes of treacherous pitfalls to anonymity, far more complex than the mere simplicity of keeping a password secret, and it requires almost superhuman attention, precision, and cleverness to avoid them all. It is like juggling multiple identities. In fact, the studies on multiple personality disorder are very fascinating in this light. Under an anonymous identity, one must respond as if certain knowledge is known and other aspects are *not* known. This reminds me of cases of MPD in which one personality can drive a car, and the other cannot, for example. Analogously, if I revealed in some anonymous message that I knew some secret or private aspect of one of my other identities, `the jig is up'. In fact, it would be very useful to try to enumerate all the various pitfalls of maintaining an anonymous identity. One trick might go like this: carry on a conversation with a person anonymously. Then, suppose one has a pretty good guess of the person's identity. Send the next snippet in the dialogue to the cleartext identity of your suspect. If s/he responds as if nothing was different in the conversation, carrying it on further, using the anonymous ID or even the regular one, you have it nailed. If you get the response `what are you talking about?' the test was inconclusive. This shows the absolute importance of looking to *whom* a message you received was addressed to! was it to *you* or to *you* or to ... Ah--anonymity is such a delicate facade, and it is an apt symbolism on multiple levels when the only difference between silent secrecy and horrifying exposure teeters precariously [as if] on the order of the two typed keystrokes `na'! p.s. I would like to know if there is a way to (1) automatically get traffic statuses from anon.penet.fi, and (2) get a list of supported newsgroups. From marc at Athena.MIT.EDU Tue Sep 7 20:56:47 1993 From: marc at Athena.MIT.EDU (Marc Horowitz) Date: Tue, 7 Sep 93 20:56:47 PDT Subject: Remailing In-Reply-To: <9309080005.AA08479@bwnmr4.harvard.edu> Message-ID: <9309080351.AA11068@binkley.MIT.EDU> >> How does this make TA trivial? >> I am assuming that batch mailings or staggered mailings are occuring. That is not currently the case. And even if it were, sending messages to yourself is going to add a significant "known quantity" to the remailer traffic. The more an attacker knows, the less he needs to figure out. Marc From M..Stirner at f28.n125.z1.FIDONET.ORG Tue Sep 7 21:11:47 1993 From: M..Stirner at f28.n125.z1.FIDONET.ORG (M. Stirner) Date: Tue, 7 Sep 93 21:11:47 PDT Subject: News.cs.indiana.edu Message-ID: <2424.2C8D46EF@shelter.FIDONET.ORG> Uu> news.cs.indiana.edu oes not appear to be working as an Uu> anonymous news posting gateway. A recent post through my remailer to Uu> alt-security didn't work. I had a similar experience during testing this week. On the other hand, you should have mailed it to alt.security@ rather than alt-security@, according to the latest FAQ. I did successfully test group-name at pws.bull.com however. . ~ . M. -- M. Stirner - via FidoNet node 1:125/1 UUCP: ...!uunet!kumr!shelter!28!M..Stirner INTERNET: M..Stirner at f28.n125.z1.FIDONET.ORG From clark at metal.psu.edu Tue Sep 7 22:51:51 1993 From: clark at metal.psu.edu (Clark Reynard) Date: Tue, 7 Sep 93 22:51:51 PDT Subject: Super Phones? Message-ID: <9309080603.AA04729@metal.psu.edu> Excerpted from "Wired," August 1993 Playboy (Not THAT Wired) Reprinted without Permission Spread Spectrum technology was developed for the military to allow for high-security communications with crystal-clear reception. Now Cincinatti Microwave has introduced the Escort 9000 ($400), a cordless digital phone with Spread Spectrum that operates on the recently approved 900 MHz radio frequency (that's 20 times higher than the frequency conventional cordless phones use). This marriage of technologies gives the Escort 9000 a remarkable range of about a half maile, superior reception and complete privacy. "Previous attempts to bring Spread Spectrum to the consumer market have been too costly and too bulky for personal use," said Cincinatti Microwave president Jacques Robinson, who sells the phones directly to the public. (Call 800-433-3487 for more information or to order one.) Another company, Cobra, incorporates CM's Spread Spectrum technology into its latest 900 MHz model, and AT & T will introduce a 900 MHz Spread Spectrum phone in the fall. Tropez and Panasonic also offer 900 MHz phones (without Spread Spectrum). It is rumored that the range for some 900 MHz phones could be increased in the future to up to seven miles, which means that one could serve as an around-town alternative to a cellular phone. ---END EXCERPT Now, here's my problem with this nice-sounding product. I called the 800 number to ask for an explanation of this product, which immediately aroused my suspicion. >From my conversation with the receptionist on the other end of the phone, which was somewhat less than informative, the idea of Spread Spectrum technology is that the signal is spread out into individual packets on different wavelengths, then reconstituted at the other end, using some sort of session key generated at the beginning of each transaction. Considering the rather lax security of high-ranking government and military officials with phone technology, recent eavesdropping on Air Force One and the White House most glaringly, I find it difficult to accept as kosher any security scheme created by the government and then offered to private industry. More chillingly, the receptionist told me that no one would be able to perform surveillance on me "except the government." Alerted to this possibility, I immediately asked whether it had the Clipper Chip or the Capstone, or whether there was some sort of key escrow involved. This got me put on hold for a couple minutes. Then the receptionist returned, and told me that the person from the engineering department who took care of the phones had indicated that not even the government had the technology to monitor these phones. Upon asking how and why the government might do this, I received a rather chilly notification that the engineering department, was, of course, unwilling to reveal these secrets. Well, it was worth a try. I gave them my address so that they could send me further information. More reports forthcoming. You can contact Cincinatti Microwave by telephone at: (800) 433-3487 or by snailmail at: Cincinatti Microwave 1 Microwave Plaza Cincinatti, OH 45249 ---- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyKoFQAAAEEAL22Al/Xil0UER1V7AlS4+eJmOQ6ruIojmq1XCSE7mCqLw3Q ILHBGlcCOl9S20N/8gdge2PfMS9BK794P2r/J3GUjwZw/emKuVm9SXDBpXfdgWax 7jdAGfohRthw/q1+x/z5nJ7gP2C7AZSlsa+XCYYRZbTR2fpaLXzs8jiGc9glAAUT tClSb2JlcnQgVy4gRi4gQ2xhcmsgPHJjbGFya0BueXguY3MuZHUuZWR1Pg== =vJ53 -----END PGP PUBLIC KEY BLOCK----- From karn at qualcomm.com Tue Sep 7 23:42:47 1993 From: karn at qualcomm.com (Phil Karn) Date: Tue, 7 Sep 93 23:42:47 PDT Subject: Super Phones? In-Reply-To: <9309080603.AA04729@metal.psu.edu> Message-ID: <9309080637.AA12050@servo> "Spread spectrum" does *not* imply "encrypted". The spreading sequences are quite often just simple linear feedback shift registers, which anyone with basic knowledge of cryptanalysis knows how to crack. Anyone with knowledge of the signal format and the right hardware could easily intercept such a signal. This *definitely* includes the government. The fact that spread spectrum usually thwarts the average scanner enthusiast is actually rather unfortunate in my opinion, because that lessens the demand for truely secure cryptography. Phil From nobody at rebma.rebma.mn.org Wed Sep 8 01:41:51 1993 From: nobody at rebma.rebma.mn.org (nobody at rebma.rebma.mn.org) Date: Wed, 8 Sep 93 01:41:51 PDT Subject: Remailing Message-ID: -----BEGIN PGP SIGNED MESSAGE----- > Would it be possible to incorporate a ping into the remailer? Say > give it a list of known remailers for the chain and have it pick one > at random, then ping it. If the remailer responds then send out the > mail, otherwise pick a new remailer, and repeat.... One possible problem is that the final destination must then be available to every remailer. Say I construct an appropriate header consisting of nested encryptions, and I use it to send a letter from me -> A -> B -> C -> destination where A, B, C are the remailers I chose. Say that there are a total of 10 remailers in the universe that are known. Here, A knows me and B, B knows A and C, and C knows B and destination. However, if A chooses a random remailer from [A-J], then it must somehow make available the final destination to all of the remailers, since there is a chance that the next hop will be destination. Now instead of C knowing the final destination, [A-J] do. Even if I made C the "final" hop (and it will then forward to destination), then I have to make C known to all the remailers, where before only B knew C. Besides, some people may have set up anonymous remailers that aren't public or haven't been announced. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLI1bsIOA7OpLWtYzAQHVaQP/cU7PYUkcM32WqE4oyFc4AzFEHFih/SlU UF4Z0utxAhQU4rKEi9FFW582Hasm7Bq3HYjW8cWOlwCbghWejxWMiw1J+W3u8MBG XvWER2TtDid8FN1fyj8Pf8sx6OeJ59aTkgGCJ3SjHTIVaU5y/Z1Z4mqGm49tIFBi 6OMh2r+lA7g= =C7BC -----END PGP SIGNATURE----- From julf at penet.fi Wed Sep 8 06:41:56 1993 From: julf at penet.fi (Johan Helsingius) Date: Wed, 8 Sep 93 06:41:56 PDT Subject: the Pitfalls and the Pendulum of Anonymity In-Reply-To: <9309080324.AA21869@longs.lance.colostate.edu> Message-ID: <199309081331.AA18760@mail.eunet.fi> > Since no one else has posted on this yet I will. The short answer is > that you can tell them to use your address `na[x]' and their anonymous > identity won't be revealed, and if they are using the server they might > know that (is it stated in the introduction material? it sure should be). It shure should be in the help file. But the whole help file needs to be rewritten. I'm running as fast as I can! > (1) the server was mainly intended for posting to newsgroups at its > origination, where the automated anonymizing (J. Helsingius' term: > `automated double blinding') makes sense. I hate the automatic anonymizing myself, but for historical reasons that had to be done. Can be fixed in the next reincarnation of the server if documented clearly enough. > (2) however, a major use of the server is email-to-email mail, so to > speak. in this case the scenario raised by Deadbeat in the past & > Baumbach recently reveals the pitfalls in the `feature'. Right. There is a solution, but it has to wait for MK II. > the automated anonymizing feature, implemented with the best of > intentions, has come back to haunt J. Helsingius rather rudely--it is > perhaps the greatest weakness of the server, other than the corrected > `forge-without-passwords' aspect (where someone can forge an email > message from: address and possibly determine anonymous-to-identity > mappings through trial and error if no passwords are used). Right. > J. Helsingius has announced grand visions for the amazing, spectacular, > and impending Mark II server that will incorporate full encryption > (user keys mappings and a server key), along with a new default in > which replies to anonymous email will not be automatically anonymized. Right. Amazing, spectacular - maybe, but impending... Sigh... > p.s. I would like to know if there is a way to (1) automatically get > traffic statuses from anon.penet.fi, stats at anon.penet.fi. > and (2) get a list of supported newsgroups. No. Simply to reduce bandwith - the list is something like 4000 groups (200K). Julf From pat at tstc.edu Wed Sep 8 06:51:57 1993 From: pat at tstc.edu (Patrick E. Hykkonen) Date: Wed, 8 Sep 93 06:51:57 PDT Subject: Super Phones? In-Reply-To: <9309080603.AA04729@metal.psu.edu> Message-ID: <9309081345.AA09213@tstc.edu> > Now, here's my problem with this nice-sounding product. I called > the 800 number to ask for an explanation of this product, which > immediately aroused my suspicion. > > >From my conversation with the receptionist on the other end > of the phone, which was somewhat less than informative, the > idea of Spread Spectrum technology is that the signal is > spread out into individual packets on different wavelengths, > then reconstituted at the other end, using some sort of session > key generated at the beginning of each transaction. Essentially this is correct, but as Phil Karn already pointed out... spread spectrum is easy to de-spread. However, Motorola has a cordless phone called the Secure Clear phone that operates at 46 to 50 MHz (standard cordless phone freqs.) that has "encryption" between the handset and the base. After calling motorola I am not impressed... they use frequency inversion. Their support person stated that the goal is to "stop casual eavesdroppers that might use baby-monitors or police scanners." Which is fine and good. I know, from personal experience, the problems that can arise from cordless telephones being monitored and the information used against a person. The Motorola and Cincinatti Microwave phones can help with the casual listeners that are out there (and there are quite a few of them!), but neither will stop an interested party with resources to spare. :) -- "I'm not being irrational, I just know to much." - Tim Allen -- Pat Hykkonen, N5NPL Texas State Technical College at Waco Internet: {pat,postmaster,root}@tstc.edu Instructional Network Services Packet: N5NPL at WD5KAL.#CENTX.TX.USA.NA 3801 Campus Dr. Waco, Tx 76705 Public keys available! ** 1984 + 10 ** V:(817) 867-4830 F:(817) 799-2843 From yerazunis at aidev.enet.dec.com Wed Sep 8 07:16:57 1993 From: yerazunis at aidev.enet.dec.com (You cannot conquer a free man, a man whose mind is free. The most you can do is kill him. 08-Sep-1993 1013) Date: Wed, 8 Sep 93 07:16:57 PDT Subject: Spread Spectrum- how it works Message-ID: <9309081410.AA00883@enet-gw.pa.dec.com> From: US3RMC::"clark at metal.psu.edu" "Clark Reynard" 8-SEP-1993 01:59:18.22 >Then the receptionist returned, and told me that the person from >the engineering department who took care of the phones had indicated >that not even the government had the technology to monitor these >phones. > >Upon asking how and why the government might do this, I received >a rather chilly notification that the engineering department, >was, of course, unwilling to reveal these secrets. Well, it was >worth a try. Actually, they aren't telling you, but SS techniques are published widely in the technical literature. For a relatively accessible and understandable introduction, try the ARRL's book "Spread Spectrum Sourcebook", which describes not only the theory but also the results of the ARRL's experimentation with spread-spectrum technology for radio communications. It's about $30 from any reputable ham radio supply house, and you can mail-order it. [very succintly, SS works by adding a pseudorandom modulation to the transmitter carrier that modulates the signal far far MORE than the actual informational modulation. For example, a 16-bit CRC register feeding back on itself can be used. The output of the CRC register (or any other pseudo-random-number-generator (PRNG) can be used as a modulator in two ways: 1) Frequency hopping: the bits in the CRC or PRNG determine (via a lookup table ("hop set") the new center frequency that the transmitter will send on. This freqency may hop a hundred times or more per second. a) ease of detection: easy- you hear a "click" whenever the transmitter hops onto the freqency you're monitoring b) ease of interception: very hard- if there are a few thousand such signals around, you have to splice together 10 millisecond slices from a thousand different sources- and that's a combinatorially prohibitive problem. You need to know the "hop set" and the particular polynomial or psuedorandom sequence to easily recover the signal. 2) Direct Sequence: the single low-order bit in the CRC or PRNG determines whether the output signal from the transmitter's primary oscillator (already modulated with the user's voice) is inverted or not. This translates to massive phase modulation. If the CRC is clocked at a reasonable rate (say, 1 MHz) then the output signal ends up with a bandwidth of about twice the clocking freqency. a) ease of detection: difficult- the SS signal shows up in a conventional reciever as broadband noise- easy to not notice. b) ease of interception: very difficult- I haven't the foggiest about how to go about it. In either case, to demodulate the signal, one recieves the entire bandwidth, then either hops their first-stage local oscillator (for frequency hopping) or phase-inverts (for direct sequence) the incoming signal. The result is a second-stage signal that can be demodulated by conventional means. The only big trick is to synchronize the PRNG on the reciever to the PRNG on the transmitter. Another advantage to SS is that it tends to "ignore" strong signals in the band- any signal that does not correllate against the PRNG modulation is "spread out" over the entire band by the demodulation operation, while the correct signal energy is concentrated into a small channel. This gives what's called "process gain" and allows a weak spread-spectrum signal to work even in channels that may be dominated by strong conventionally-modulated signals. The ARRL did find that if they knew the bandwidth of the signal they were looking for they _could_ direction-find on it, using wideband recievers and notch filters to remove known conventionally-modulated signals from the signal; once they were close enough to be in the "near field" of the transmitter standard direction-finding techniques were adequate to DF, even if they couldn't understand what was being transmitted, they could find the source. (this was the basis for the FCC's OKing of the use of SS modulation by hams on the 440 and higher bands- that some form of accountability was being preserved). ----- Note that if the PRNG in a direct-sequence SS is replaced by a true random number source, we have the equivalent of a one-time pad and (I believe) complete security. However, since the typical demands of a direct-sequence system for phase information are in the megabits per second, the logistics of "key management" may be utterly impractical. ----- So, if CM was using either modulation method, and used some reasonable PRNG (i.e. one with remappings and hopsets determined by user-genned random numbers) then it is quite possible that the government does not have the technology _deployed_ in the field to intercept them. But if they need it, I'm sure they will figure out how to do it. -Bill From ccat at netcom.com Wed Sep 8 08:11:58 1993 From: ccat at netcom.com (Chris Beaumont) Date: Wed, 8 Sep 93 08:11:58 PDT Subject: The origin of spread spectrum (a true story) Message-ID: <9309081504.AA05033@netcom5.netcom.com> I have an interesting perspective on spread spectrum encryption, because one of the inventors of this interesting technology was my father. My father,George Antheil,was an avant garde composer living in Hollywood in the late 30's and early 40's. One of his best friends was Hedy Lamarr, the movie actress.One of the facts about Ms. Lamarr that many people were unaware of,was that she was also very intelligent.(She had also just been married and divorced from a Czeck arms magnate,and had spent much time listening to her ex-husbands and friends 'shop talk'.) Anyway, she and my father were very concerned about the Nazi's rise to power,and their U-boat harassment of international shipping.My father, a composer who was fascinated by machines (his composition,"Ballet Mechanique" was one of the very first uses of machines in music.) was working on a composition for several player pianos at the time...This led them to the idea of using two rolls of randomly punched tape to synchronize a receiver and transmitter in a radio controlled torpedo.Using this technology (frequency hopping) their torpedo would be able to be remotely controlled,with virtually no risk of enemy jamming or detection.And there you have it.I have the patent drawings..which were done by both of them.. Theyre simply marvelous.. Several years ago, a guy who was writing a book on the history of encryption called my half-brother to ask him about this story..Correct me if I'm wrong,but I think this was the absolutely first use of spread spectrum encryption... The patent was issued in 1940, and expired in 1957. In 1960 Sylvania, (I think) started manufacturing a radio controlled torpedo ... Hedy Lamarr is still alive and living in Florida, my father died in early 1959. Neither of them ever saw a penny from their pioneering patent. Chris Beaumont (Nutrient Cafe wholesale) - Chris Beaumont ccat at netcom.com ccat at casa.stanford.edu public key available via finger From cdodhner at indirect.com Wed Sep 8 08:16:58 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Wed, 8 Sep 93 08:16:58 PDT Subject: Who generates AOCE keys? In-Reply-To: <9309072243.AA09027@internal.apple.com> Message-ID: <199309081511.AA09223@indirect.com> > Christian Odhner wonders: > > > >Well, what keeps people from makeing keys with somebody else's name/user > >id on them and sending them in to be certified? Where is the > >authentication from the key certifier's point of view? > > The pass phrase. > > > -- > Lefty (lefty at apple.com) > C:.M:.C:., D:.O:.D:. And who chooses the pass phrase, and how is it transmited between parties, and how is it linked to the keypair/user (is the key encrypted with it like pgp?) ? Just thinking some more... ;) Happy Hunting, -Chris ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner at indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" "If guns are outlawed, only the government will have guns." -E. Abbey My opinions are shareware. For a registered copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------ Ps, Why is the sky blue? From cdodhner at indirect.com Wed Sep 8 08:22:54 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Wed, 8 Sep 93 08:22:54 PDT Subject: Who generates AOCE keys? In-Reply-To: <9309072205.AA05327@newton.apple.com> Message-ID: <199309081517.AA09544@indirect.com> > Christian D. Odhner writes: > > >what keeps people from [getting certified] keys with somebody else's name > > The The relation between the preferred signature authority for the > installation, and that installation. From the documentation: > [good stuff from docs deleted] > > Hope this helps, > > > Scott Collins Oh, ok :> I realy get it now! Thanks. Sorry about the previous post, everybody... ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner at indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" "If guns are outlawed, only the government will have guns." -E. Abbey My opinions are shareware. For a registered copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------ From hughes at ah.com Wed Sep 8 11:17:57 1993 From: hughes at ah.com (Eric Hughes) Date: Wed, 8 Sep 93 11:17:57 PDT Subject: REMAIL: pasting In-Reply-To: <199309071705.AA02648@Menudo.UH.EDU> Message-ID: <9309081810.AA00635@ah.com> >I'm not sure about pasting in reply fields to override behavrior. >That dependes on precedence between "From:" and "Reply-To:", etc. >Basically, I'm not real familiar with the appropriate RFC :-) In short, if there's a Reply-To: field present, the mailer is supposed to reply to that address. Some mailers don't, unfortunately. Some reply to the From: line in the mail, and some reply to the out of band sender information, usually seen in the "From " line at the top of the mail. Let's face it, header pasting is a hack. A very nice hack, in certain ways, but still a hack. As currently implemented, header pasting, be it incoming (::) or outgoing (##), is a syntactic operator, not a semantic one. The relevant RFC is 822, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES". This RFC has several holes in it, however. The syntactic structure of the header fields indicates that the only fields which may appear multiple times are receiver fields (To, cc, bcc, and the Resent-* version of these), Received, and the optional fields. (I avoid a too-long discussion of the Resent-* fields, whose description seems to contradict this definition.) Therefore, it is possible to make syntactically counter-spec mail using header pasting. It is also possible to make such counter-spec mail in emacs mail mode, for example, but it doesn't seem to bother anybody much. Yet RFC-822 is followed as much in the breach as in the observance. In particular, 822 seems to specify that the recipient of the mail be contained in one of the destination fields. Yet sendmail takes parameters on the command line for the destination and ignores the To: field inside the message. Now there is a flag for sendmail to parse the mail and determine addresses, but this is not the default, much less required. I think this behavior of sendmail is good, but it does appear to be counter to the semantic interpretation of the destination fields as specified in 822. My own philosophy on this is that one should never flagrantly violate 822 syntactically, and to take it semantically with a grain of salt. What are the implications for header pasting? I think it ought to remain only syntactic, since the semantics that would need to be defined do not have a solid base in specification, much less in implementation. Yet this pasting does not allow 'overriding' of an existing header field. One could write an operator that removes header fields in the context of header pasting. In the current remailer situation, this operator would allow one to remove the "From:" field and substitute another--instant in-band forgery. Whether the operators of remailers want to do this is left for discussion. Eric From hughes at ah.com Wed Sep 8 12:37:02 1993 From: hughes at ah.com (Eric Hughes) Date: Wed, 8 Sep 93 12:37:02 PDT Subject: Second Annual Cypherpunks Conference Message-ID: <9309081916.AA00730@ah.com> ANNOUNCEMENT ============ Second Annual Cypherpunks Conference Saturday, September 11, 1993 12:00 noon Cygnus Support, Mt. View, California, USA One hear ago this month, the first cypherpunks meeting was held in Oakland, CA. Therefore, the September Bay Area meeting is megalomaniacally named The Second Annual Cypherpunks Conference and Banquet (but really, we'll just go out to dinner afterwards like normal.) The theme this year is Where are my turnips? Visions of cypherpunk futures and Paths to implementation Agenda ------ In no particular order -- Tim May, "We are in a cryptographic arms race." -- Other visionary statements from other attendees -- Inspirational reading from _Temporary Autonomous Zone_ written by Hakim Bey. -- An as-yet unverified presentation on patent law. I encourage people to prepare short position statements to be read aloud at the meeting. Topics should center around what you want out of a cypherpunk future and how you'd go about getting there. Tim has already explicitly scheduled his time; others may do so as well by sending me mail (hughes at ah.com). Eric Hughes DIRECTIONS ========== [Directions to Cygnus provided by John Gilmore. -- EH] Cygnus Support 1937 Landings Drive Mt. View, CA 94043 +1 415 903 1400 switchboard +1 415 903 1418 John Gilmore Take US 101 toward Mt. View. From San Francisco, it's about a 40-minute drive. Get off at the Rengstorff Ave/Amphitheatre Parkway exit. If you were heading south on 101, you curve around to the right, cross over the freeway, and get to a stoplight. If you were heading north on 101, you just come right off the exit to the stoplight. The light is the intersection of Amphitheatre and Charleston Rd. Take a right on Charleston; there's a right-turn-only lane. Follow Charleston for a short distance. You'll pass the Metaphor/Kaleida buildings on the right. At a clump of palm trees and a "Landmark Deli" sign, take a right into Landings Drive. At the end of the road, turn left into the complex with the big concrete "Landmark" sign. Follow the road past the deli til you are in front of the clock tower that rises out of one of the buildings, facing you. Enter through the doors immediately under the clock tower. They'll be open between noon and 1PM at least. (See below if you're late.) Once inside, take the stairs up, immediately to your right. At the top of the stairs, turn right past the treetops, and we'll be in 1937 on your left. The door is marked "Cygnus". If you are late and the door under the clock tower is locked, you can walk to the deli (which will be around the building on your left, as you face the door). Go through the gate in the fence to the right of the deli, and into the back lawns between the complex and the farm behind it. Walk forward and right around the buildings until you see a satellite dish in the lawn. Go up the stairs next to the dish, which are the back stairs into the Cygnus office space. We'll prop the door (or you can bang on it if we forget). Or, you can find the guard who's wandering around the complex, who knows there's a meeting happening and will let you in. They can be beeped at 965 5250, though you'll have trouble finding a phone. Don't forget to eat first, or bring food at noon! I recommend hitting the burrito place on Rengstorff (La Costen~a) at about 11:45. To get there, when you get off 101, take Rengstorff (toward the hills) rather than Amphitheatre (toward the bay). Follow it about ten blocks until the major intersection at Middlefield Road. La Costen~a is the store on your left at the corner. You can turn left into the narrow lane behind the store, which leads to a parking lot, and enter by the front door, which faces the intersection. To get to the meeting from there, just retrace your route on Rengstorff, go straight over the freeway, and turn right at the stoplight onto Charleston; see above. See you there! John Gilmore From gnu Wed Sep 8 12:47:59 1993 From: gnu (John Gilmore) Date: Wed, 8 Sep 93 12:47:59 PDT Subject: Privacy Advocate Position, Madison, Wisconsin Message-ID: <9309081947.AA23392@toad.com> Job postings for cypherpunks, yet! John From: oravec at cs.wisc.edu (Jo Ann Oravec) Subject: Privacy Advocate Position, Madison, Wisconsin Date: Mon, 6 Sep 93 09:48:43 -0500 To the Electronic Frontier Association: The following job opening announcement will appear as an ad in September 12 Wisconsin newspapers and in various other vehicles. It may be of interest to many people who have ties to the EFF. (Wisconsin residency is NOT a requirement for the position!) Please disseminate the announcement as broadly as possible: Privacy Advocate... Madison, Wisconsin The State of Wisconsin is seeking a person responsible for support and advocacy in development and implementation of state and local government policies that protect personal privacy. This position reports to the Privacy Council. Background in business and government application of information technology. Salary $33,000 per year plus excellent benefits. Applicants should submit a detailed resume and a statement outlining their perspectives and approaches to privacy concerns to Mary Becker (608-266-0058, FAX 608-264-9500), Department of Administration, 9th Floor, 101 E. Wilson, P.O. Box 7869, Madison, WI 53707-7869. Materials must be received before 4:30 PM on September 27, 1993. thanks-- Jo Ann Oravec Chair, State of Wisconsin Privacy Council From 72114.1712 at CompuServe.COM Wed Sep 8 14:02:04 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Wed, 8 Sep 93 14:02:04 PDT Subject: CHAUM CHIMES IN Message-ID: <930908203054_72114.1712_FHF95-2@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Punksters, For those of you who live in darkness (i.e., don't read THE ECONOMIST), here is a letter to the editor from David Chaum, in the most recent issue: SIR--Your leader, "No hiding place", and article, "Big brother is clocking you" (August 7th), are to be commended for focusing attention on the exploding threat to privacy being created by piece-meal adoption of intrusive systems, such as automated road tolling. Proposing systems designed around pre-paid smart cards as the solution is, however, somewhat misleading. In French pay phones, Danish vending machines, and in fact all large-scale uses today, such cards must identify themselves during each transaction. Even though your name is not on the card, it represents an erosion of privacy over the coins it replaces. If you are once identified by even a single transaction, such as when you reload the card from your bank account, all your transaction details are linked to your identity. A rare few systems, however, truly do protect privacy. They need not cost more, weaken security, or be harder to use. The technology is described in my article in /Scientific American/, "Achieving Electronic Privacy" (August 1992). A smart card version has already been demonstrated for road tolls by the Dutch government. And CAFE, a project sponsored by the EC, is designing an electronic wallet that literally will, as you recommend, "leave as much control as possible in the hands of individuals." /Amsterdam/ DAVID CHAUM Of course, the next letter to the editor calls for the adoption of systems to track every vehicle at all times. The genius who wrote the letter, thinks it would be a good way to prevent nuclear, biological or chemical terrorism. Geeeeez. S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Andrew.Corradini at m.cc.utah.edu Wed Sep 8 14:52:04 1993 From: Andrew.Corradini at m.cc.utah.edu (Andrew Corradini/SBDC) Date: Wed, 8 Sep 93 14:52:04 PDT Subject: Interested in setting up (or joining!) local group in Utah. Message-ID: Having been recently acquainted with cypherpunkography, I have been rolling around the idea of setting up a local group rather like the original in Cal. Lest ye laugh, Utah happens to be a heckuva place to worry about privacy, intrusion, et al...although it comes from both having a fairly silly state government (they're finally trying to strike down a law which automatically invalidates any marriage in which one of the partners has AIDS..., fer example), and the fact that many here feel that the aura of the Mormon church is somewhat weighty -- no comment either way, just pointing it out... ANYWAY, if there are any other cypherUtahns on the list interested in getting together monthly or so for an evening of pizza, beer, Jolt, milk, potentially subversive activity, and cookies (wonder if the NSA monolith dropped a flag on that one ;-) ... drop me a line. I know of at least 4 very talented and potentially committable persons who'd also be highly interested. My girlfriend, OTOH, will most likely roll her eyes, call me a geek, and head for the shoe department at Nordstrom. Also of potential interest, my BBS has a couple of areas on cryptography, other "Sneakers"-type issues, as well as VR, cyberspace, and programming. Drop by sometime: SENSE/NET (801) 364-6227 2400-9600 Andrew asc7556 at u.cc.utah.edu NOTE: my opinions are too silly to be shared by my employer. From wcs at anchor.ho.att.com Wed Sep 8 18:12:08 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Wed, 8 Sep 93 18:12:08 PDT Subject: ViaCrypt export? Message-ID: <9309090055.AA17129@anchor.ho.att.com> Felix Ungman felix at hu.se asks? > Will ViaCrypt consider exporting pgp? (well, I think I can guess the answer ;-) > However, pgp is already widely used outside USA (at least as many as > the US users, I suspect). It would be interesting to know what they're going > to do about it. There exists no country boundaries in cyberspace, you know! I would guess that they're not willing to put up with the export law nonsense required to export the product. (If they do, more power to them!) If the offensive export-prevention laws weren't there, and if other governments didn't have offensive import-harassment and crypto-harassment laws, then they'd probably decide whether they could make enough money by providing a supported product and pretty manuals to people who can get the net-version free, just as companies like Cygnus are providing commercial support for free GNUware. However, governments have not yet realized that they're obsolete, so you folks won't have that option. :-( Bill Stewart, wcs at anchor.att.com Physical-Address: North America, right hand coast, near the middle. From wcs at anchor.ho.att.com Wed Sep 8 18:22:08 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Wed, 8 Sep 93 18:22:08 PDT Subject: Gubment Bombmaker's Cookbook Message-ID: <9309090109.AA17198@anchor.ho.att.com> > This is ridiculous. Have they never heard of The Anarchist's Cookbook? > I've seen it on the shelf of the local large bookstore, though now I'm > not sure whether I want to admit to buying a copy. A friend of a friend has it on the kitchen shelf along with her other cookbooks :-) Unfortunately, cops don't seem to have figured out that Anarchy isn't against the law, it's just opposed to it. > Have they not yet discovered rec.pyrotechnics? (Shhhh! They've only discovered child-porn and rec.humor so far; next they'll figure out the pyros and pagans are there, and then they'll decide some nonsense about talk.religion violating separation of church and state and go after Phil Karn for creating it :-) From astrashe at nyx.cs.du.edu Wed Sep 8 18:37:08 1993 From: astrashe at nyx.cs.du.edu (Alex Strasheim) Date: Wed, 8 Sep 93 18:37:08 PDT Subject: Viacrypt export? Message-ID: <9309090132.AA12404@nyx.cs.du.edu> Why would people in Europe want to buy an exported Viacrypt when it's completely legal for them to use PGP, which is free and which is built from published source code? From frc%bwnmr4 at harvard.harvard.edu Wed Sep 8 19:08:04 1993 From: frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) Date: Wed, 8 Sep 93 19:08:04 PDT Subject: Remailing In-Reply-To: <9309080351.AA11068@binkley.MIT.EDU> Message-ID: <9309090203.AA12499@bwnmr4.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- > And even if it were, sending messages to yourself is going to add a > significant "known quantity" to the remailer traffic. The more an > attacker knows, the less he needs to figure out. How is pinging a known address considered sending messages to yourself? FRC -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLI6O3bbAlE4AqlTZAQE2qAP7ByAj4hf0IMYBqBhTQDuLY0mSIDGrYSdn ahpDILrnvdPDcz6Lh72lAdT5QIXa8e+2hi/4PLXXPtQpmuW52uSSZjhN4w2FaLUl /Y6ZccEWbbau4Okyw+RUUjJYZbWT4EUjv2vLiN06NjJaPztJJXwFKKWeLnJNixci 2xjZOa3iMKw= =oUif -----END PGP SIGNATURE----- From b44729 at achilles.ctd.anl.gov Wed Sep 8 19:22:09 1993 From: b44729 at achilles.ctd.anl.gov (Samuel Pigg) Date: Wed, 8 Sep 93 19:22:09 PDT Subject: Viacrypt export? In-Reply-To: <9309090132.AA12404@nyx.cs.du.edu> Message-ID: <9309090216.AA29489@achilles.ctd.anl.gov> >>>>> On Wed, 8 Sep 93 19:32:42 MDT, astrashe at nyx.cs.du.edu (Alex Strasheim) said: Alex> Why would people in Europe want to buy an exported Alex> Viacrypt when it's completely legal for them to use PGP, Alex> which is free and which is built from published source Alex> code? I wouldn't, but most corporations don't like purchasing software without the safety blanket of commercial support. (At least in the states. I assume it's the same in europe.) Sam Pigg dt1acaa at cfraix.cfr.usf.edu samp at renoir.cftnet.com b44729 at achilles.ctd.anl.gov PGP Key Fingerprint: ED A7 49 33 65 90 9A BD A4 E4 C5 92 5A 00 BC 6C From frc%bwnmr4 at harvard.harvard.edu Wed Sep 8 19:23:07 1993 From: frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) Date: Wed, 8 Sep 93 19:23:07 PDT Subject: Remailing In-Reply-To: Message-ID: <9309090215.AA12523@bwnmr4.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- > One possible problem is that the final destination must then be > available to every remailer. [explanation removed] ok, this one I can understand to be a problem. Can anyone beat this? > Besides, some people may have set up anonymous remailers that aren't > public or haven't been announced. Well, if the mailer hasn't been announced or made public, then it obviously won't be on the list of mailers that Remailer is choosing it's ping targets from. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLI6RirbAlE4AqlTZAQGmzQP8CdOdShWx9SWcjeID/rdaBeStPmmfs4sW o44Mccp1zKcHRicrr7ELWyEQ28zu7mBGjAuVFKjMDrta8i17sRYvsDchissH+mgw w0qKMge9kYaHvfgrP2K8XMoE79tu3EATBPp32HTF3bBNtrUVV2OPpRSocbtcX4Vc 4VULcmUI4hk= =1YCi -----END PGP SIGNATURE----- From tcmay at netcom.com Wed Sep 8 19:27:10 1993 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 8 Sep 93 19:27:10 PDT Subject: Opportunities in Cyberspace Message-ID: <9309090219.AA13375@netcom5.netcom.com> Crypto Rebels, Here's a piece I wrote for another mailing list, the Extropians list, which about 20 of you are already on (a guess). I make some points about the importance of strong crypto for the "colonization of cyberspace." I start out by commenting on a thread about the Libertarian Party, which I know many of you have no interest in (not that I have much interest, either). Forwarded message: To: Extropians at extropy.org From: tcmay at netcom.com (Timothy C. May) Message-Id: <9309090128.AA05763 at netcom5.netcom.com> Subject: Opportunities in Cyberspace Date: Wed, 8 Sep 93 18:28:16 PDT I agree with everything Nick Szabo says here. A few comments: > These kinds of groups, also ISIL, even LP in its saner moments, > serve an important role in "spreading the meme" -- giving us > the political knowledge that the media and high school Civics classes I don't discount the value of these groups in spreading the memes, providing the support for unpopular beliefs ("You mean others think this way, too?"), and maybe even in providing some alternatives in local elections. The focus of the LP on electoral politics these past 20 years, with little or nothing to show for it, has been misguided, in my opinion. Especially when alternatives exist. > they hate the War on Drugs, etc. Even for the libertarians influential > writers like Rand, Heinlein, etc. may have played a larger role > than activist groups. Also, implementing crypto-anarchy requires the > activists have speific real-world skills (computer programming, > mathemetics, legal, banking, etc.), so many libertarians might > not be able to contribute without a very large amount of effort. I hate to say it, but I will anyway! Many libertarians I have met over the years are ill-suited to making money in conventional jobs. Many are underemployed, with vague dreams about starting companies or otherwise making it big. Nothing wrong with high hopes and great plans, of course. As Nick says, there are huge opportunities in cyberspace and crypto anarchy. I mean these terms in the loose sense that covers networking, software generation, offshore movements of data and capital, and even things like games. (Sidenote on games: anybody with a lot of time on their hands might want to catch the wave that "3DO" will be. If you don't know what I'm talking about, never mind.) > Many libertarians have limited resources to devote to the idealistic, > altruistic efforts of political activism. These legions should > note that that crypto-anarchy if successful opens up > not only political freedoms but also huge business opportunities. > Governments worldwide confiscate over $3 trillion > every year, and most of those property owners would, given sufficient > marketing, pay a significant fraction of that to avoid said > confiscation. This dwarfs the potential markets from, for > example, ocean colonization by several orders of magnitude. And with "persistent institutions" (investment funds/accounts that can be moved around the world, in pieces that are secure against seizure, crytographically protected), we may see the development of private fortunes that are enormous. If a wealthy person believes he can hide his assets and have them grow even after his death, with some of the proceeds funding things he now has interest in (and thinks may help him to be reanimated....nanotech, cryonics, more crypto, etc.), then some very large fortunes may flow into such channels. Such large pools/accounts can take "the long view," funding very risky, high-payoff projects. Sort of like the "rich old men" so common in Heinlein's world. As Nick noted--and as Duncan Frisell and others have noted--the stakes in avoiding taxes are enormous...trillions of dollars a year. The colonization of cyberspace--the real next frontier--is well underway. Within 10 years, graphics computers and Net bandwidths will be high enough to support a much better illusion of a "real space" (virtual reality, "True Names"-type spatial methaphors, more abstract spatial metaphors, etc.). And the Nets will be the cutting edge for debate about the nature of "government"....many of us believe governing such nets by governments will be impossible. But the groundwork is being laid...and the whole Libertarian Party debate is increasingly irrelevant. One real world intrusion could be the outright banning of strong crypto, with government-approved ciphers mandated. At the Worldcon I mentioned recently, Whit Diffie, the principal inventor of public key cryptography, outlined his scenario for a government ban on strong crypto: the government offers the Clipper/Skipjack key escrow system, they they argue that criminals and terrorists are using crypto, and they then make it a crime to use unapproved crypto. The principle enforcement mechanism is the fear of losing one's home, car, and business through the civil forfeiture process, as with the drug laws. Anyone with assets, and any business or corporation, will be scared shitless to use unapproved crypto, and so alternatives will dry up (they'll never go away completely, but will be confined to purely criminal use). Such a ban will have a chilling, devastating effect on our privacy, on our ability to set up the cyberspace worlds I have described, and on computer-mediated markets in general. Our immediate goal must be to make sure the "genie is out of the bottle," that enough crypto tools and knowledge are widely disseminated so that such a government ban is futile. Education and lobbying, to kill off the Clipper/Skipjack, is also important. > Yet the startup costs for crypto-anarchy are much smaller, mostly > mastering obscure mathematics, programming skills, computer security, > and legal/business protocols. What skills can you learn now that > will look good on your "BlackNet" resume? Did the BlackNet piece get posted (anonymously, one would hope) to the Extropians list? It's a good demonstration, I think, of the immanency of this crypto anarchy world. In a sense, it reveals that fully anonymous 2-way markets (as in selling Stealth bomber secrets, or arranging hits, or trading financial data...all kinds of strange stuff, of varying degrees of respectability) are already a reality. > I should also take this opportunity to plug the cypherpunks mailing > list (cypherpunks-request at toad.com) and the cypherpunks meeting > computing up at Cygnus Support on Saturday, September 11th, 12 noon. > Crypto-anarchy is an area where libertarian hackers, lawyers, businessmen, > etc. can make a vast difference in the future of our political landscape. Yes, try to make this meeting if you live in the High Beyond (aka Bay Area). I'll be speaking on this "crypto arms race" that I see coming. Others will speak on goals, plans, new software, etc. > prohibitive, and (3) we are a small minority so we almost always lose. > Many people can have a vastly larger effect on politics by > starting businesses (where is a libertarian-freindly news service > or cable TV channel?), volunteering to help implement crypto-anarchy, > writing the next _Atlas Shrugged_, operating mailing lists, and > posting good libertarian essays to the net. Don't discount the latter -- > talk.politics.misc will likely have over 50,000 readers this > fall, a larger readership than the number of subscribers to _Liberty_ > and _Reason_ combined. Well, I'm doing my best on at least a couple of these points. Crypto anarchy is of course my special interest, and the novel I am still working on (sigh!) is/was ostensibly a "better 'Atlas Shrugged'", or so I am hoping (but please don't ask me for progress reports...I get very grumpy indeed when the first thing people ask is "How's the novel going?"). And, like most of you, I write essays to various lists and groups. One thing I haven't done is to fund a start-up company, or invest in one, but I am getting the itch to do something along these lines. A lot of billionaires will come out of the developments of the next decade or two; in many ways, there are more opportunities with the globabilization of information flows than there were with personal computers. Several Extropians/Cypherpunks I know of have some potentially exciting business ideas brewing. Don't change the channel, you might miss something exciting. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From smb at research.att.com Wed Sep 8 19:42:10 1993 From: smb at research.att.com (smb at research.att.com) Date: Wed, 8 Sep 93 19:42:10 PDT Subject: Viacrypt export? Message-ID: <9309090240.AA29022@toad.com> Alex> Why would people in Europe want to buy an exported Alex> Viacrypt when it's completely legal for them to use PGP, Alex> which is free and which is built from published source Alex> code? I wouldn't, but most corporations don't like purchasing software without the safety blanket of commercial support. (At least in the states. I assume it's the same in europe.) It's not a matter of a safety blanket, it's where you choose to spend your time and effort. A well-supported application can easily pay for itself in decreased staff time. From cs60a-qu at po.EECS.Berkeley.EDU Wed Sep 8 21:07:12 1993 From: cs60a-qu at po.EECS.Berkeley.EDU (Sameer Parekh) Date: Wed, 8 Sep 93 21:07:12 PDT Subject: REMAIL: Perl/problems Message-ID: I'm not good at perl, so I can't solve this problem on my own. (I hardly know anything about perl, actually.) Upon repeated tests of my remailers, I noticed that if there's more than one blank line between the header and the header-pasting, then the pasting doesn't take place. Does this happen with other people's remailers? How is your script different from mine? How can this be fixed? From doug at netcom5.netcom.com Wed Sep 8 22:02:11 1993 From: doug at netcom5.netcom.com (Doug Merritt) Date: Wed, 8 Sep 93 22:02:11 PDT Subject: REMAIL: pasting Message-ID: <9309090454.AA02474@netcom5.netcom.com> hughes at ah.com (Eric Hughes) said: >Yet RFC-822 is followed as much in the breach as in the observance. Not only that, but it is woefully shortsighted. For instance, when I reply to messages from email lists, sometimes I want to reply to the list, and sometimes to the originator. The variations in RFC-822 *compliant* email list headers are staggering; I have yet to see any mail software that understands the variety of syntactically- parseable signals that show that something is from a list, and allows me to easily reply to either the list or the sender. This is a technically trivial wish. It could be done, at least to the 95% mark, even as things stand. But NOOOOOoooo. :-) Similar comments apply to saving things interactively. I'm about to try procmail for non-interactive uses, but I still haven't seen a mailer that lets me say e.g. "(save (from cypherpunks | to cypherpunks | cc cypherpunks | Bcc cypherpunks | "From " cypherpunks) > savefile) & delete Maybe I'm just email-challenged. Suggestions? Doug From jim at tadpole.com Wed Sep 8 23:08:06 1993 From: jim at tadpole.com (Jim Thompson) Date: Wed, 8 Sep 93 23:08:06 PDT Subject: DES is dead Message-ID: <9309090603.AA00304@tadpole.Tadpole.COM> Forwarded, 'cause I've not seen it on cypherpunks as yet. Note that the NIST has approved DES for another couple years. Jim Date: Wed, 8 Sep 1993 14:13:13 -0400 (EDT) From: Matt Lawrence Subject: Re: [prz at columbine.cgd.ucar.EDU: Re: DES Key Search Paper (fwd)] (fwd) To: eff-austin-directors at tic.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII With the crypto conference coming up, I figured y'all ought to see this. -- Matt ---------- Forwarded message ---------- Date: Wed, 8 Sep 93 09:57:27 EDT From: Stainless Steel Rat To: The Elboid Nation Subject: Re: [prz at columbine.cgd.ucar.EDU: Re: DES Key Search Paper (fwd)] This came to me via one of the crypto lists I'm on. I'm certain some of you crypto-weenies out there will be interested: From: Philip Zimmermann To: ratinox at ccs.neu.edu Subject: Re: DES Key Search Paper (fwd) Michael Weiner presented a paper at Crypto93 that describes a fast DES key search engine that uses a special inside-out DES chip that he designed. This chip takes a single plaintext/ciphertext pair and quickly tries DES keys until it finds one that produces the given ciphertext from the given plaintext. Weiner can get these chips made for $10.50 each in quantity, and can build a special machine with 57000 of these chips for $1 million. This machine can exhaust the DES key space in 7 hours, finding a key in 3.5 hours on the average. He works for Bell Northern Research in Ottawa, and says they have not actually built this machine, but he has the chip fully designed and ready for fabrication. This is a stunning breakthrough in the realization of practical DES cracking. BTW-- note that PEM uses straight 56-bit DES. -prz Forwarded message: >From prz Wed Sep 1 14:11:48 1993 >Message-Id: <9309012010.AA10083 at columbine.cgd.ucar.EDU> >Subject: Re: DES Key Search Paper >To: wiener at bnr.ca (Michael) >Date: Wed, 1 Sep 93 14:10:18 MDT >From: Philip Zimmermann >Cc: prz (Philip Zimmermann) >In-Reply-To: <"15836 Wed Sep 1 12:14:00 1993"@bnr.ca>; from "Michael" at Aug 31, 93 11:32 am >X-Mailer: ELM [version 2.3 PL0] > >Thanks, Michael. Your paper was the most important paper presented >at Crypto93, in my opinion. It drove a wooden stake thru DES's heart. > >$1 million - 3.5 hours >$10 miliion - 20 minutes >$100 million - 2 minutes > >It is not plausible to me that NSA's budget for examining DES-encrypted >traffic is less than $100 million. Two minutes. Damn. Two fucking >minutes. DES is dead, dead, dead. > >Regards, >Philip > > Rat Northeastern's Stainless Steel Rat PGP Public Key Block available upon request Ask about rat-pgp.el v1.61 ||||| | | | | | | | | | | | | | | | | | | | | | | ||||| An it harm none, Do what thou wilt shall be the whole of the Law. From julf at penet.fi Wed Sep 8 23:47:12 1993 From: julf at penet.fi (Johan Helsingius) Date: Wed, 8 Sep 93 23:47:12 PDT Subject: REMAIL: pasting In-Reply-To: <9309090454.AA02474@netcom5.netcom.com> Message-ID: <199309090641.AA24013@mail.eunet.fi> > Not only that, but it is woefully shortsighted. For instance, when > I reply to messages from email lists, sometimes I want to reply to > the list, and sometimes to the originator. The variations in > RFC-822 *compliant* email list headers are staggering; I have yet > to see any mail software that understands the variety of syntactically- > parseable signals that show that something is from a list, and allows > me to easily reply to either the list or the sender. Yeah. I am amazed that people don't get it right. My server sends out messages looking like this: From: anXXXXX at anon.penet.fi Reply-To: anXXXXX at anon.penet.fi Sender: anon at anon.penet.fi And there are _lots_ of systems out there that send te reply to "anon at anon.penet.fi"! Elm and VMSMail are the most obvious ones. > Similar comments apply to saving things interactively. I'm about to > try procmail for non-interactive uses, but I still haven't seen a mailer > that lets me say e.g. "(save (from cypherpunks | to cypherpunks | > cc cypherpunks | Bcc cypherpunks | "From " cypherpunks) > savefile) & delete > > Maybe I'm just email-challenged. Suggestions? Try mh. It does all that. Julf From ld231782 at longs.lance.colostate.edu Thu Sep 9 00:42:12 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 9 Sep 93 00:42:12 PDT Subject: BBS operator rights -- a paper Message-ID: <9309090736.AA00686@longs.lance.colostate.edu> >From Current Underground Digest Volume 5 : Issue 70. CuD FTP sites appended below. A paper by jmbell at DARMOK.WIN.NET(Jonathan Bell) on BBS operator & user rights. Somewhat speculative: points out existing legal framework is woefully inadequate to deal with this `fundamentally new category' combining `the mass communications functions of publisher, distributor, broadcaster, advertiser and utility rolled into one'. (imagine the revolutions of the telephone, television, printing press combined -- that's one of my analogies) >It may seem shocking for [BBS] users today to learn that more than ever they >are responsible for what they write and what they distribute. he has it backwards -- now, *less* than ever (with things like cyberspatial anonymity). I guess he's got a point though. >The media lessons of copyright, privacy and >defamation still are being taught on the networks today. They will >continue as more people log on to the networks at hand, spreading >their personage electronically. actually, I think societal attitudes on `libel' `slander' and `defamation' and `sedition' (wink wink) are going to be radically transformed over the next few decades. 1) a mere posting alone is meaningless, and people will begin to understand that offense is in the eye of the beholder. if there is no tracable author there can be no `responsibility' and no one should overreact as if there is. 2) overreaction will decrease. in fact I see networks as sort of a automatic PC (policitically correct) countering device. People that are incredibly sensitive about sexist language or whatever the current fashionable academic term is will tend to get flamed into oblivion. Likewise people that overreact to anonymous spew. Likewise, however, people that are prejudiced get nailed into a more moderate consensus too. Rough humans will get to be increasingly polished by the torrential downpour of cyberspace. also, concepts of `copyright' will be radically transformed. the situation will be such that the `netiquette' will evolve where authors are required to include hypertext *pointers* to actual works, rather than copying the work itself. In this way many diverse problems (such as automatic updating, handling fee charging, etc.) are localized to the correct location (the author himself). However, I also foresee a great deal of future turmoil and turbulence on all these topics. We will probably reach a crescendo of outcry about the time the first unrestricted commercial networks appear, say, mid-to-late 90s. ===cut=here== Date: Sat, 28 Aug 1993 18:28:32 From: jmbell at DARMOK.WIN.NET(Jonathan Bell) Subject: File 3--Re: A Class Like None Other [revised] ((MODERATORS' NOTE: For parsimony, we reproduce here only the first and last two paragraphs of Johnathan Bell's paper, which summarize his central themes. His points are well-argued, and the copious footnotes should be of value to scholars. The entire paper can be obtained from the CuD ftp archives. We recommend it)). A CLASS LIKE NONE OTHER: HOW THE TRADITIONAL MEDIA CLASSIFICATIONS FAIL TO PROTECT IN THE ELECTRONIC FRONTIER by Jonathan Bell August 4, 1993 Mass Communications Law and Ethics Dwight Teeter - Summer 1993 Imagine the mass communications functions of publisher, distributor, broadcaster, advertiser and utility rolled into one and you might find that the beast before you is being operated out of your own home -- or at least that of a friend or neighbor. The computer bulletin board (BBS) offers a variety of services to its users: shopping, electronic mail, public discussion of hot topics, free software, free advice, news. All that may sound idealistic but it is here. The only thing endangering BBS' and their system operators' (sysops') ability to run them is a legal system unclear and uneducated about the First Amendment held dearly by those who keep them going, whether they are the users or the operators. Exactly where BBS' stand in the legal structure has not been definitively decided by anyone. Getting sysops to agree has yet to be accomplished, users see things differently and lawyers and government often have views widely divergent from the thoughts of the other two. The simple fact that the proper status of bulletin boards has yet to be answered reasonably opens up the dire need for a new media classification system. No one sees eye to eye, and assurances that the right thing will always be done do not work. ************************* It may seem shocking for users today to learn that more than ever they are responsible for what they write and what they distribute. The ability to have your voice heard is unprecedented but so is the capability to harm. The media lessons of copyright, privacy and defamation still are being taught on the networks today. They will continue as more people log on to the networks at hand, spreading their personage electronically. Education can answer many of the problems facing the electronic world today. But no puzzles are solvable until computer information systems and bulletin boards are granted the highest degree of First Amendment rights and freedom from liability necessary to keep the waves of public exchange coming throughout the future. ------------------------------ ANONYMOUS FTP SITES: UNITED STATES: ftp.eff.org (192.88.144.4) in /pub/cud etext.archive.umich.edu (141.211.164.18) in /pub/CuD/cud halcyon.com( 202.135.191.2) in /pub/mirror/cud aql.gatech.edu (128.61.10.53) in /pub/eff/cud AUSTRALIA: ftp.ee.mu.oz.au (128.250.77.2) in /pub/text/CuD. EUROPE: nic.funet.fi in pub/doc/cud. (Finland) ftp.warwick.ac.uk in pub/cud (United Kingdom) From ld231782 at longs.lance.colostate.edu Thu Sep 9 01:02:12 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 9 Sep 93 01:02:12 PDT Subject: Government access: satire (from CuD) Message-ID: <9309090756.AA00900@longs.lance.colostate.edu> Also from CuD Wed Sep 8 1993 Volume 5 : Issue 70, a brilliant and scalding satirization by john at ZYGOT.ATI.COM(John Higdon) of points that J. Warren raises in favor of the `government online database access bill' in California, AB1624. J. Warren provided a boilerplate letter, very persuasive in many ways from a *citizen* point of view, for anyone to fax to a specific obstinate legislator on the matter (copies included in many forums). I've been tracking this controversy with great interest, and have forwarded various developments to the cypherpunk list. This last conquest is a fantastic, dazzling example of cyberspatial democracy in action. In this case, J. Warren has done, and continues to do, a totally inspired job of coordinating resources, targeting critical legislators and aspects of the law-making process, building consensus, coordination, and tightly focused organization. More than ever, this effort suggests that Legislators are very high up on the list of Endangered Bureacrats and Future Obsolescence. J. Warren gets my vote as Cypherpunk of the Month. From: Jim Warren >Today, AB1624 passed the Assembly 78-to-0 on the consent agenda, thus >concurring with the amendments that had been made in the Senate after >the Assembly passed it the first time. > >Unless Gov. Pete Wilson vetos it within 12 days, it will become law, >taking effect Jan. 1, 1993. 78-to-0? my *gosh*. Warren appears to have greater diplomatic and lobbying tenacity, and of course, fundamental splendor in his proposals, than our esteemed President and Vice President (the latter just appearing on David Letterman to plug the latest `streamlining government' plan with all the juicy catchwords like `empowering workers' and `corporation reformation'). This California Database Access bill will help pave the way for future success in Federal ones. Note that there is a lot of bickering going on at that level between groups Taxpayer Assets Project (rep. Jamie Love) and EFF (rep. Shari Steele) in support of two different congressional bills, one the Owens bill. We have to get our houses in order to succeed at the national level so spectacularly, but we have a *major* victory under the belt that will aid the Cyberspatial Reality Advancement Movement tremendously. ===cut=here=== Date: Mon, 6 Sep 93 03:04 PDT From: john at ZYGOT.ATI.COM(John Higdon) Subject: File 4--Imaginary Government Reply to Jim Warren's Model Letter ((MODERATORS' NOTE: While we often share John's cynicism, which he expresses satirically below, it appears that Jim Warren's idealism and belief in collective action were *not* misplaced. A few minutes ago, CuD learned that Jim Warren's (and others') efforts to pass the California electronic access bill that would increase availability of public documents to the public were rewarded. Warren's model letters and other strategies were instrumental in today's final passage of the legislation. See File #11, below)). +++++++ Jim Warren presented a substantial argument in his "Model Letter" to John Burton. But it is entirely based upon the premise that anyone in the California state government gives two hoots or a holler about the citizenry. Therefore I appoint myself official (tongue-in-cheek) spokesperson for our state legislature and answer each of Mr. Warren's arguments against the charging of fees for on-line access to state documents. (My apologies for anything that seems true enough to be mistaken for seriousness.) Mr. Warren writes: > I ask that you reconsider your demand for fees, for at least ten reasons: > > 1. BAD PRECEDENT -- FREE FOR OLD-FASHIONED PAPER VS. FEES FOR MODERN ACCESS Mr. Warren, you obviously think that any of us here in Sacramento give a damn about how much anything in government costs. The money comes out of your pocket, not ours. We collect it from you in taxes. We even will track you down after you retire in another state to make sure we get our pound of flesh. I hope that answers your concern regarding costs. > 2. CREATES TWO CLASSES OF PUBLIC ACCESS BASED ON WEALTH AND POSITION Mr. Warren, where on earth have you been all of your life. Of course people with money and position have the power. We have campaign contributions to work off here. Actually, there are several issues at work. Newspapers are our friends. They give us mindless, unquestioning access to the public with our press hand-outs and print what we make convenient. On the other hand, people who are too poor to pay fees for on-line document access are probably radical trouble makers. We don't need that kind of riff-raff examining what we do here in Sacramento. > 3. YOU WOULD EXCLUDE SCHOOLS, COLLEGES, STUDENTS, LIBRARIES, HOMELESS, ETC. Naturally. Students have always been a pain in our rear. Thankfully, as a group, their voting record stinks. The last thing we want to do is incite these children into recklessly exercising their rights. And for heaven's sake, why on earth would we want a bunch of homeless bums to know what is going on in Sacrmento? And the beard and glasses types that frequent libraries--well, need I say more? > 4. BUREAUCRACY AND FEES WOULD DETER MOST LOW-COST PUBLIC ACCESS No shit Sherlock! Did someone lead you to think that we had some desire to make our silly shenanigans public? > 5. IMPOSSIBLE TO ENFORCE; WOULD INCITE WIDESPREAD VIOLATION OF YOUR LAW Did you ever consider that maybe money is not the issue here, but rather denial of access? Give us some credit. But a nice bonus in having fees built into the system is the fact that we know perfectly well that people will ignore the law. This gives us carte blanche to "round up all the usual suspects" should we decide that someone has spoken the wrong thing at the wrong time. When we want to "put someone away", it is most useful to have some trumped up charge. Not paying fees is made to order. > 6. A TECHNICAL NIGHTMARE -- WHO PAYS? HOW MUCH SURVEILLANCE OF USERS? Mr. Warren, we KNOW that. In addition to the above, we are provided with a great excuse to monitor and search and seize to our hearts' content. > 7. SUPPORT -- DON'T SUPPRESS -- DEVELOPMENT OF HIGH-TECH SMALL BUSINESS Don't get us wrong--we support high-tech. But only in big corporations. These garage operations, "loose cannons" if you will, scare the bloody crap out of us. The idea that ordinary people can, unsupervised and in private, create, develop, and manipulate data seen and read by other ordinary people--using high-tech means, no less--strikes at the very core of our benevolent purpose. That purpose is to protect you and other citizens from unnecessary contact with data and devices that you need not know anything about. We, and our corporate contributors--er, I mean the corporations who are under our thumb--oops, rather the high tech industry will handle everything and take care of you. > 8. FREE LAND-FILL PAPER VS. FEES FOR RECYCLABLE ELECTRONS Green stuff is only for serving our agenda. Do not try to use that "green" nonsense on us. We invented the hype so we could raise your taxes. We are pleased that it has been effective. But do not attempt to con your government. We invented the practice. > 9. PRECEDENTS FOR ELECTRONIC SPEECH, ELECTRONIC ASSEMBLY, ELECTRONIC PRESS > I understand you plan to exclude subscription newspapers from your fee-for- > fee mandate. Mr. Warren, as I explained earlier, the mindless newspapers are our friends. Your rabble-rousing "electronic publishers" say things we don't like, and have a "readership" that we would just as soon not see the material. Remember the key word "access". Access is something that all of us in government would just as soon you and all the other bozo constituents NOT have. > 10. YOUR PRECEDENT FOR THE PEOPLE'S RIGHT TO PETITION THEIR GOVERNMENT Hey, if we had our druthers, we would turn that off in a minute. All we have between us and you clowns is a mountain of paperwork and procedures. Are you seriously asking us to strip that away? You think we WANT to hear from you between elections? Get real, son. (End of comments as tongue-in-cheek government spokesperson.) While the above may be pulling at the corners just a little, it is my personal opinion that there is contained more truth than fiction. There are two things to always remember about government bureaucrats: cost is never an issue; and none wants you to know what really goes on in government. After all, you pay the bill and what you don't know won't hurt you. ------------------------------ From ld231782 at longs.lance.colostate.edu Thu Sep 9 01:17:12 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 9 Sep 93 01:17:12 PDT Subject: PRZ: ``is DES dead? '' Message-ID: <9309090812.AA01090@longs.lance.colostate.edu> seen on info.pem-dev, headers deleted ===cut=here=== From: Philip Zimmermann To: ratinox at ccs.neu.edu Subject: Re: DES Key Search Paper (fwd) Michael Weiner presented a paper at Crypto93 that describes a fast DES key search engine that uses a special inside-out DES chip that he designed. This chip takes a single plaintext/ciphertext pair and quickly tries DES keys until it finds one that produces the given ciphertext from the given plaintext. Weiner can get these chips made for $10.50 each in quantity, and can build a special machine with 57000 of these chips for $1 million. This machine can exhaust the DES key space in 7 hours, finding a key in 3.5 hours on the average. He works for Bell Northern Research in Ottawa, and says they have not actually built this machine, but he has the chip fully designed and ready for fabrication. This is a stunning breakthrough in the realization of practical DES cracking. BTW-- note that PEM uses straight 56-bit DES. -prz Forwarded message: >From prz Wed Sep 1 14:11:48 1993 >Message-Id: <9309012010.AA10083 at columbine.cgd.ucar.EDU> >Subject: Re: DES Key Search Paper >To: wiener at bnr.ca (Michael) >Date: Wed, 1 Sep 93 14:10:18 MDT >From: Philip Zimmermann >Cc: prz (Philip Zimmermann) >In-Reply-To: <"15836 Wed Sep 1 12:14:00 1993"@bnr.ca>; from "Michael" at Aug 31, 93 11:32 am >X-Mailer: ELM [version 2.3 PL0] > >Thanks, Michael. Your paper was the most important paper presented >at Crypto93, in my opinion. It drove a wooden stake thru DES's heart. > >$1 million - 3.5 hours >$10 miliion - 20 minutes >$100 million - 2 minutes > >It is not plausible to me that NSA's budget for examining DES-encrypted >traffic is less than $100 million. Two minutes. Damn. Two fucking >minutes. DES is dead, dead, dead. > >Regards, >Philip > From ld231782 at longs.lance.colostate.edu Thu Sep 9 01:32:12 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 9 Sep 93 01:32:12 PDT Subject: priorities for cyberspatial infrastructure from Roundtable Message-ID: <9309090824.AA01206@longs.lance.colostate.edu> Communications Roundtable (CPSR, EFF, TAP, etc.) has established these items as priorities in the Information Infrastructure. Cypherpunks: it occured to me that we could gain a lot of valuable knowledge with how to commence with this `infrastructure building' by looking at historical analogues. While the advent of cyberspace is clearly straight out of the 21st century, we have many parallels to large government building programs throughout the whole American history. What policies were beneficial in colonizing the frontier? which ones were detrimental? Railroads? Highway system? What should we have done differently? In some cases the government provided subsidies to private companies to develop segments and to promote widespread public access. How can we prevent abuse of these funds? Was this generally a successful approach? Is this the best way to go about it? There's a *tremendous* need for informed, thorough, impartial papers on this subject, and not just policy statements from groups that say `this is how it should be' with the words `because it would benefit *us* the most' in between the lines... (Not suggesting that the below is anything of this type, though. In fact, the roundtable represents an excellent diversity of views in computer rights areas, IMHO--dunno about commercial interests though.) This document identifies as priorities: 1. UNIVERSAL ACCESS 2. FREEDOM TO COMMUNICATE 3. VITAL CIVIC SECTOR 4. DIVERSE AND COMPETITIVE MARKETPLACE 5. EQUITABLE WORKPLACE 6. PRIVACY 7. DEMOCRATIC POLICYMAKING Roundtable contacts appended. ============================================================== RENEWING THE COMMITMENT TO A PUBLIC INTEREST TELECOMMUNICATIONS POLICY Telecommunications Policy Roundtable September 1, 1993 A communications revolution is underway as profound as the introduction of the printing press. A new "National Information Infrastructure" is rapidly moving into place -- which will carry video, audio, and data information into homes and offices across the country. Its emergence will produce fundamental shifts in American life, transforming everything from work to education to government to culture. Because the health of our democracy is inextricably linked to the nature of our communications system, this new information infrastructure raises far-reaching questions about our country and its transition into the next century: Who will own these networks? Who will have access to them? What steps will be taken to preserve public institutions? Policy decisions made during the next few years will shape the communications system for decades to come. Enlightened policies could harness the power of these new technologies to ameliorate many of our nation's most critical problems by revitalizing civic institutions, expanding educational opportunities, enhancing access to health care services, and improving job training. However, without a clear commitment to public goals, this promise will never be fulfilled.Instead, many of the shortcomings of our present telecommunications system will be intensified and a host of more serious problems created. There is already a growing disparity between the technologically affluent and the technologically disenfranchised that endangers our social fabric. Policy makers must ensure that the development of the information infrastructure reflects the public interest spirit that has long guided our country's communications policies: our commitment to a national telephone system available to all gave rise to the concept of "universal service," enabling those in the most remote parts of the nation to have access to the means of communication; our commitment to making noncommercial educational, arts, and public affairs programming available to all Americans led to the creation of a public broadcasting system. Our government has the responsibility as public trustee to ensure that new communications technologies serve the democratic and social needs of our country. The rise of new technologies and new businesses has increased the importance of this responsibility. The convergence of once separate industries requires a new policy framework for the information infrastructure, rooted in the shared values of our country and dedicated to the common good. We call on the President and the Congress to pursue a broad and public interest vision for the National Information Infrastructure. We must move beyond narrow and short-term interests and embrace a view that reflects the great diversity and richness of our country. Our policies should reflect the values of a democratic government -- openness, participation, and discussion. They must be inclusive and generous in spirit, ensuring that all segments of our pluralistic society have meaningful access to the telecommunications system. These are the principles on which a great nation has been built. As representatives of many nonprofit and public interest organizations, we believe that the following principles must guide policy making in order to ensure that future generations inherit an information infrastructure which enhances the quality of life for everyone. PUBLIC INTEREST PRINCIPLES 1. UNIVERSAL ACCESS All people should have affordable access to the information infrastructure. Fundamental to life, liberty, and the pursuit of happiness in the Information Age is access to video, audio, and data networks that provide a broad range of news, public affairs, education, health, and government information and services. Such services should be provided in a user-friendly format, widely available to everyone, including persons with disabilities. Information that is essential in order to fully participate in a democratic society should be provided free. 2. FREEDOM TO COMMUNICATE The information infrastructure should enable all people to effectively exercise their fundamental right to communicate. Freedom of speech should be protected and fostered by the new information infrastructure, guaranteeing the right of every person to communicate easily, affordably, and effectively. The design of the infrastructure should facilitate two-way, audio and video communication from anyone to any individual, group, or network. The rights of creators must be protected, while accommodating the needs of users and libraries. Telecommunication carriers should not be permitted to constrain the free flow of information protected by the First Amendment. 3. VITAL CIVIC SECTOR The information infrastructure must have a vital civic sector at its core. For our democracy to flourish in the 21st Century, there must be a vital civic sector which enables the meaningful participation of all segments of our pluralistic society. Just as we have established public libraries and public highways, we must create public arenas or "electronic commons" in the media landscape. This will require the active involvement of a broad range of civic institutions -- schools, universities, and libraries, not-for-profit groups, and governmental organizations. It will also require vibrant public telecommunications networks at the national, regional, and state level. 4. DIVERSE AND COMPETITIVE MARKETPLACE The information infrastructure should ensure competition among ideas and information providers. The information infrastructure must be designed to foster a healthy marketplace of ideas, where a full range of viewpoints is expressed and robust debate is stimulated. Individuals, nonprofits, and for-profit information providers need ready access to this marketplace if it is to thrive. To ensure competition among information providers, policies should be developed to lower barriers to entry (particularly for small and independent services); telecommunications carriers should not be permitted to control programming; and antitrust policies should be vigorously enforced to prevent market dominance by vertically-integrated media monopolies. 5. EQUITABLE WORKPLACE New technologies should be used to enhance the quality of work and to promote equity in the workplace. Because the information infrastructure will transform the content and conduct of work, policies should be developed to ensure that electronic technologies are utilized to improve the work environment rather than dehumanize it. Workers should share the benefits of the increased productivity that those technologies make possible. The rights and protections that workers now enjoy should be preserved and enhanced. To encourage nondiscriminatory practices throughout the information marketplace, public policy should promote greater representation of women, people of color, and persons with disabilities at all levels of management. 6. PRIVACY Privacy should be carefully protected and extended. A comprehensive set of policies should be developed to ensure that the privacy of all people is adequately protected. The collection of personal data should be strictly limited to the minimum necessary to provide specific services. Sharing data collected from individuals should only be permitted with their informed consent, freely given without coercion. Individuals should have the right to inspect and correct data files about them. Innovative billing practices should be developed that increase individual privacy. 7. DEMOCRATIC POLICYMAKING The public should be fully involved in policy making for the information infrastructure. The public must be fully involved in all stages of the development and ongoing regulation of the information infrastructure. The issues are not narrow technical matters which will only affect us as consumers; they are fundamental questions that will have profound effects on us as citizens and could reshape our democracy. Extensive efforts should be made to fully inform the public about what is at stake, and to encourage broad discussion and debate. The policy process should be conducted in an open manner with full press scrutiny. Effective mechanisms should be established to ensure continued public participation in telecommunications policymaking. Persons wanting more information about the Roundtable are urged to contact: Jeff Chester, Center for Media Education, 202/628-2620; cme at access.digex.net Marc Rotenberg, CPSR, 202/544-9240; rotenberg at washofc.cpsr.org Prue Adler, Association of Research Libraries, 202/296-8656, prue at cni.org From cdodhner at indirect.com Thu Sep 9 05:28:09 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Thu, 9 Sep 93 05:28:09 PDT Subject: REMAIL: Perl/problems In-Reply-To: Message-ID: <199309091221.AA03869@indirect.com> > > I'm not good at perl, so I can't solve this problem on my own. (I > hardly know anything about perl, actually.) > > Upon repeated tests of my remailers, I noticed that if there's > more than one blank line between the header and the header-pasting, then > the pasting doesn't take place. Does this happen with other people's > remailers? How is your script different from mine? How can this be fixed? > Now that you mention it... I never had that problem before, I've sent messages with up to three blank lines before the :: with no prob, I don't know about more than three. But a few days ago somebody tried to remail through mine and the message ended up in my mailbox, I looked at the message content and did everything I could to figure out what happened, but the only thing I could come up with was that maybe the :: was not on the first line like it should be and that screwed it up. (clarification: The :: was on the second or third line for sure, if that was the cause of the problem or not I don't know.) Happy Hunting, -Chris ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner at indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" "If guns are outlawed, only the government will have guns." -E. Abbey My opinions are shareware. For a registered copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------ From szabo at netcom.com Thu Sep 9 07:12:18 1993 From: szabo at netcom.com (Nick Szabo) Date: Thu, 9 Sep 93 07:12:18 PDT Subject: Crypto Visions Message-ID: <9309091404.AA19359@netcom4.netcom.com> In the spirit of the Second Annual Cypherpunks Conference in the Bay Area this Saturday, here are a variety of visions for future crypto-anarchy: * GUIs for X, Mac, & Windows that make PGP mail encryption & key handling, anon remailer envelope-stuffing, etc. seamless * mobile.com: pirate crypto ham and shortwave on the Internet * How much computing power and radio gear can be crammed into a van? An RV? A yacht? * Fiber or hi-bandwidth satellite hookup for RV parks and yacht berths * Itinerant hackers, indigent anarchists, and perpetual tourists. Physical crypto-raves for cyberspace biz & social partners * Discovering, debugging, and implementing true software digicash (upon which the following visions depend!) * Distributed digicash banking, offshore, virtually & physically mobile * International digicash telecommuter contracting: programming, publishing, typing pools, etc. Crypto-anarchy for the middle class; pirate CD-ROM libraries for the 3rd World masses. * Internet Casino: why travel to Las Vegas or Monte Carlo when you can play the finest games in the privacy of your own home? * Integration of BBS businesses (already >$1 billion per year) into the digicash economy * Effective law enforcement approaches terrorism: random hits against fixed, centralized physical targets to generate intimidating publicity * Millions of jobs for college grads and military-industrial complex workers: future digicash-related markets in the $trillions per year Nick Szabo szabo at netcom.com From huntting at glarp.com Thu Sep 9 08:42:19 1993 From: huntting at glarp.com (Brad Huntting) Date: Thu, 9 Sep 93 08:42:19 PDT Subject: Viacrypt export? In-Reply-To: <9309090132.AA12404@nyx.cs.du.edu> Message-ID: <199309091534.AA05201@misc.glarp.com> > Why would people in Europe want to buy an exported Viacrypt when it's > completely legal for them to use PGP, which is free and which is built > from published source code? If the're like companies in the states, they may be concerned about proper support. brad From huntting at glarp.com Thu Sep 9 08:43:17 1993 From: huntting at glarp.com (Brad Huntting) Date: Thu, 9 Sep 93 08:43:17 PDT Subject: Gubment Bombmaker's Cookbook In-Reply-To: <9309090109.AA17198@anchor.ho.att.com> Message-ID: <199309091534.AA05189@misc.glarp.com> > Unfortunately, cops don't seem to have figured out that Anarchy isn't > against the law, it's just opposed to it. A few years back a freind of mine was busted for putting up anarchistic grafiti on some public buildings. He told the judge he was voicing his political opionions which was protected by the 1st amendment. Rather than retort with "then keep it to newspapers and kiosks", the judge actually told him that he was free to advocate any government system he wanted, but advocating no government was not protected. Granted, boulder county's is not nessesarily the most authoritive court in the country, but it is interesting that a judge would actually say this. brad From cme at ellisun.sw.stratus.com Thu Sep 9 08:57:19 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Thu, 9 Sep 93 08:57:19 PDT Subject: CHAUM CHIMES IN Message-ID: <9309091550.AA23383@ellisun.sw.stratus.com> >Date: 08 Sep 93 16:30:55 EDT >From: Sandy <72114.1712 at CompuServe.COM> >Subject: CHAUM CHIMES IN >Message-Id: <930908203054_72114.1712_FHF95-2 at CompuServe.COM> ..From: > SANDY SANDFORT Reply to: ssandfort at attmail.com [ . . . ] >Of course, the next letter to the editor calls for the adoption >of systems to track every vehicle at all times. The genius who >wrote the letter, thinks it would be a good way to prevent >nuclear, biological or chemical terrorism. Geeeeez. It was signed by Dorothy Denning, right? Actually, they should take that to its full conclusion. We need implants in every individual, broadcasting to the local surveillance agency, giving not only location but also every word spoken in the vicinity. It could also do a chemical analysis of the air in the neighborhood. It should also have a radiation counter. It should also monitor the host body, looking for signs of anger or sexual arousal? How else will we be guaranteed safe from mad bombers, rapists and child molesters? How else will our big budget LE agencies be able to protect us? I know. When it's finally adopted, worldwide, they'll call it the Ellison Plan. :-( - Carl From 96mbatik at ultrix.uor.edu Thu Sep 9 10:27:21 1993 From: 96mbatik at ultrix.uor.edu (Mark Batik) Date: Thu, 9 Sep 93 10:27:21 PDT Subject: No Subject Message-ID: subscribe me again please Mark Batik | AT&T: Phones with big brother | University of Redlands | built in. | 96mbatik at ultrix.uor.edu "The man who does not value himself, cannot value anything or anyone" -Ayn Rand the opinions expressed are obviously too intelligent and thoughtful to be those of the University of Redlands From desilets at sj.ate.slb.com Thu Sep 9 10:28:18 1993 From: desilets at sj.ate.slb.com (Mark Desilets) Date: Thu, 9 Sep 93 10:28:18 PDT Subject: Subscribe Message-ID: <9309091723.AA10557@eris.sj.ATE.SLB.COM> Please subscribe desilets at sj.ate.slb.com (Mark DeSilets) Thanks Mark From hughes at ah.com Thu Sep 9 11:18:12 1993 From: hughes at ah.com (Eric Hughes) Date: Thu, 9 Sep 93 11:18:12 PDT Subject: Subscribe In-Reply-To: <9309091723.AA10557@eris.sj.ATE.SLB.COM> Message-ID: <9309091807.AA02516@ah.com> [Thanks for your hospitality last weekend. The following is a form letter--EH] The cypherpunks list is for discussions on implementing cryptography. To mail to the whole list, send mail to cypherpunks at toad.com Every mail message sent to this address will be forwarded to everyone on the list. Make sure that the message you wish to send is appropriate for such a broad delivery. If you want to be added or removed from the cypherpunks list, or have any other questions which pertain to list management, send mail to cypherpunks-request at toad.com I don't manage the list from my regular account, so such mail which ends up in my ah.com account will just get you another copy of this file. Eric Hughes maintainer of the lists cypherpunks at toad.com and cypherpunks-announce at toad.com From hughes at ah.com Thu Sep 9 11:37:22 1993 From: hughes at ah.com (Eric Hughes) Date: Thu, 9 Sep 93 11:37:22 PDT Subject: REMAIL: pasting In-Reply-To: <199309090641.AA24013@mail.eunet.fi> Message-ID: <9309091827.AA02544@ah.com> >Yeah. I am amazed that people don't get it right. My server sends out >messages looking like this: > From: anXXXXX at anon.penet.fi > Reply-To: anXXXXX at anon.penet.fi > Sender: anon at anon.penet.fi >And there are _lots_ of systems out there that send te reply to >"anon at anon.penet.fi"! Elm and VMSMail are the most obvious ones. Even worse, there are mailers that respond to the out-of-band sender information that appears in the first line (not in the header!) as the "From " information. Bounce message (almost) always go back to the out-of-band sender, so we changed the cypherpunks list alias on toad.com to generate that as the out-of-band sender. Now bounce message return to a different mailbox and my inbox at toad.com is clear for regular list maintenance. Nonetheless, I still get a number of attempted posts to the mailing list at large _and_ requests for list maintenance (?!) to the owner-cypherpunks alias. If only mail software were consistent, ... Eric From prz at columbine.cgd.ucar.EDU Thu Sep 9 11:48:12 1993 From: prz at columbine.cgd.ucar.EDU (Philip Zimmermann) Date: Thu, 9 Sep 93 11:48:12 PDT Subject: DES is Dead Message-ID: <9309091843.AA18068@columbine.cgd.ucar.EDU> Forwarded message: >Date: Thu, 09 Sep 1993 10:23:00 +0000 >From: "Michael (M.J.) Wiener" >Subject: re:fw:DES is Dead >To: prz at acm.org > >Philip, > >I'm pleased that my paper is getting some attention. However, there >were a few things in your note below that concerned me. > >The first is minor. My last name is spelt "Wiener" - I've always been >a little touchy about that. > >The second is that not only have we not built this machine, but we >have no intention of doing so. To say that the chip is ready for >fabrication may mislead people about our intentions. This is >strictly a detailed paper design. > >Finally, I don't think that DES is dead. After about 15 years of >public scrutiny, we can conclude that DES is a well designed cipher >with a well understood limitation (56-bit keys). A natural >replacement for it is triple-DES. Proclaiming the death of DES >may lead to its being replaced with an entirely new cryptosystem >(e.g. Skipjack). > >I'd appreciate it if you would send a clarification (particularly on >the second point) to the audience that received the message below. > >Thanks, > >Mike Wiener > > >>From: Philip Zimmermann >>Subject: Re: DES Key Search Paper (fwd) >> >>Michael Weiner presented a paper at Crypto93 that describes a fast DES >>key search engine that uses a special inside-out DES chip that he designed. >>This chip takes a single plaintext/ciphertext pair and quickly tries >>DES keys until it finds one that produces the given ciphertext from the >>given plaintext. Weiner can get these chips made for $10.50 each in quantity, >>and can build a special machine with 57000 of these chips for $1 million. >>This machine can exhaust the DES key space in 7 hours, finding a key >>in 3.5 hours on the average. He works for Bell Northern Research in >>Ottawa, and says they have not actually built this machine, but he has >>the chip fully designed and ready for fabrication. >> >>This is a stunning breakthrough in the realization of practical DES >>cracking. BTW-- note that PEM uses straight 56-bit DES. >> >>$1 million - 3.5 hours >>$10 miliion - 21 minutes >>$100 million - 2 minutes >> >>It is not plausible to me that NSA's budget for examining DES-encrypted >>traffic is less than $100 million. Two minutes. DES is dead, dead, dead. >> >> -prz >> From klbarrus at owlnet.rice.edu Thu Sep 9 12:12:23 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Thu, 9 Sep 93 12:12:23 PDT Subject: REMAIL: Perl/problems In-Reply-To: Message-ID: <9309091905.AA02437@flammulated.owlnet.rice.edu> Sameer Parekh wrote: > Upon repeated tests of my remailers, I noticed that if there's >more than one blank line between the header and the header-pasting, then >the pasting doesn't take place. Does this happen with other people's >remailers? How is your script different from mine? How can this be fixed? Could you give an example? I tried a message like the following (between the cut marks) which I sent to elee7h5 at rosebud.ee.uh.edu: ------------8<--cut-->8------------ :: Anon-To: klbarrus at owlnet.rice.edu testing ------------8<--cut-->8------------ and it came back OK, with the blanks squeezed out. So I'm probably misunderstanding what you said. -- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From collins at newton.apple.com Thu Sep 9 13:52:26 1993 From: collins at newton.apple.com (Scott Collins) Date: Thu, 9 Sep 93 13:52:26 PDT Subject: blank lines v. the remailer Message-ID: <9309092017.AA13959@newton.apple.com> > Upon repeated tests of my remailers, I noticed that if there's >more than one blank line between the header and the header-pasting, then >the pasting doesn't take place. Does this happen with other people's >remailers? How is your script different from mine? How can this be fixed? What follows is some of the text of the recurse.pl script, a component of the remailer system. I imagine that there are different versions of this script floating around, but this is the version I got from soda.berkeley.com when I set up my remailer. I have commented it (and noted my comments with 'SC:') to explain the relevent behavior, and deleted non-relevent sections: ----------cut here---------- # SC:read the header, looking for relevent lines while (<>) { # SC:get the next line (from where ever) into $_ s/[ \t\r]*$// ; # SC:remove trailing white space from $_ last if /^$/ ; # SC:get out if this line ($_) is otherwise blank ...code deleted here... } # SC:at this point $_ contains the blank line that followed the header # unless there was no blank line or message following the header (bad message) # We have just read the last line in the header. # Now we check to see if there is a pasting operator. if ( ( $_ = <> ) && /^::[ \t\r]*$/ ) { # SC:get the next line (from where ever) into $_ ('if' can't use 'while' # magic form), and if that next line is the pasting token then... # SC:append all the folling lines (up to, but not including, # the next blank one) to the header while (<>) { ...code deleted here... } } ...code deleted here... ----------cut here---------- You can see (from the condition of the 'if') that this code only finds the pasting token if it is separated from the header by exactly one blank line. This is easy enough to fix, if it is not the desired behavior, by inserting while (<>) { last unless /^[ \t\r]*$/ ; } before the 'if' and removing the '($_=<>) &&' from the if condition. Hope this helps, Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From DOUGHTYD at Citadel.edu Thu Sep 9 14:02:26 1993 From: DOUGHTYD at Citadel.edu (Cdt Pvt Dan Doughty) Date: Thu, 9 Sep 93 14:02:26 PDT Subject: encryption Message-ID: <01H2R2NU55LE8Y5X35@Citadel.edu> sub cypherpunks Daniel J. doughty From nobody at Menudo.UH.EDU Thu Sep 9 16:07:27 1993 From: nobody at Menudo.UH.EDU (nobody at Menudo.UH.EDU) Date: Thu, 9 Sep 93 16:07:27 PDT Subject: REMAIL: cache Message-ID: <199309092301.AA29183@Menudo.UH.EDU> -----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, This is a test message of the caching implementation I've added to the remailer elee9sf at menudo.uh.edu. If you are reading this, it should be working :-) I implemented caching with three extra scripts: filer.pl, mailout.at, and mailout.pl. filer.pl accepts incoming messages and files them into a queue directory, appending the time in seconds, minutes, hours, and the process id number to the file. Hopefully, this will store the file in a random order with respect to the actual order they arrived in. Instead of piping incoming mail to slocal.pl, which is what the typical cypherpunks remailer does, it is piped to filer.pl which just files the messages. mailout.at is a script for the at command. It invokes the mailout.pl command, which mails out the queued messages, and reschedules itself for midnight the next day. Today, I scheduled for 18:00 CDT, so this message should leave for cypherpunks at toad.com then. I forgot to check to see if I'm in cron.allow; if so I'll change from the at command to a crontab. For the time being the remailer "flushes" its queue every night at midnight. After a while I'll make it less often, perhaps every other day or every three days. A week is probably too long :-) mailout.pl is a script which opens the queue directory and gets a list of files. Every file in the directory is opened, piped to slocal.pl, and unlinked. Well, that's it in a nutshell. Next up: padding messages, and an smtp package instead of sendmail. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLI+wM4OA7OpLWtYzAQGM2wQAulXlIz50z6fVPdWeHstdyFA5GgeCPUaO XRWooj0PNPPRrAcfUQqFhhgTZibBDHP6qmOXGU4GWfYL6dqPJhCHTi6iBUOGWQ+2 K1+YHinz7h6vNTf1R9fCRElvH0tn5iwq3uR4ZWLqJhhxtD6Mv01qidOsUQIUfQ9G oN2lT+JrkeU= =RdzB -----END PGP SIGNATURE----- From gnu Thu Sep 9 16:17:27 1993 From: gnu (John Gilmore) Date: Thu, 9 Sep 93 16:17:27 PDT Subject: Crack DES in 3.5 hours for only $1,500,000! Message-ID: <9309092314.AA15000@toad.com> Be the first on your block! Michael Wiener produced a complete design for a DES key search machine, which he presented in the "rump session" at Crypto '93 last month. He designed a single custom chip which can do 50 million test encryptions per second, and the boards and racks and frames into which it fits. The full design has about 60,000 copies of the chip, solves DES in 3.5 hours, and is fully described in the paper. Here is an excerpt from his conclusions: It is possible to build a $1 million machine that can attack DES and recover a key in an average time of 3.5 hours. The machine uses a known plaintext to exhaustively search through the DES key space and could be developed for $500000 in about 10 months. Because a great deal of detail has gone into the design of the key search machine, we can have high confidence in the assessment of its cost and speed. The key search design presented here is one to two orders of magnitude faster than other recently proposed designs. Even cryptosystems with 64-bit keys may be vulnerable. If DES were modified to use 64-bit keys, there would be 2**8 times as many keys to search through, and a $10 million machine would take an average of 3.7 days to find a key. It is possible to build a key search machine that can support a range of modes of DES with little penalty in run-time. A $1 million machine would take 8 hours on average to find a key used in 1-bit CFB mode and 4 hours on average for any of ECB, CBC, 64-bit OFB, 64-bit CFB, or 8-bit CFB mode. This work shows that exhaustive DES key search is alarmingly economical. If it ever was true that attacking DES was only within the reach of large governments, it is clearly no longer true. A fairly painless way to improve security dramatically is to switch to triple-DES. The paper was written as a warning to DES users (bankers) and their customers (depositors). DES is used to protect electronic money transfers among banks all over the world. Several billion dollars per day are moved in this way. Within a day of finishing the machine, a criminal could easily pay back the $1.5M in capital. In the second day, they'd have the capital required to build a second machine, and in the third day a positive cash flow would begin. Banks can do nothing to stop this -- if they shut down their comm links, they go out of business; if they keep moving money over them, intruders suck money out at will. I recommend not keeping your money in banks... Most organizations who would build such a machine (national governments and other forms of organized crime) have probably already constructed many similar machines. This paper will not help them. It is intended to help people who thought that DES was secure. The full paper is available in PostScript via ftp from: ftp.eff.org:/pub/crypto/des_key_search.ps cpsr.org:/cpsr/crypto/des/des_key_search.ps cpsr.org also makes it available via their Gopher service. CPSR.org is on a slow link; use the ftp.eff.org archive if possible. (The file will appear there shortly; apologies for any delay.) John Gilmore Electronic Frontier Foundation Feel free to hack this up and send me back revised copy... John From nobody at pmantis.berkeley.edu Thu Sep 9 16:27:27 1993 From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu) Date: Thu, 9 Sep 93 16:27:27 PDT Subject: Crypto Visions Message-ID: <9309092321.AA16275@pmantis.berkeley.edu> Hey Nick, visionary stuff in general, but . . . szabo>* Internet Casino: why travel to Las Vegas or Monte Carlo when szabo>you can play the finest games in the privacy of your own home? Maybe it's time you stopped working on the CRT tan, and checked out the showgirls :-). There is *virtually* nothing like it. From tcmay at netcom.com Thu Sep 9 18:02:29 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 9 Sep 93 18:02:29 PDT Subject: "Code Warriors" Article in "Metro" Newspaper Message-ID: <9309100058.AA18920@netcom5.netcom.com> Bay Area Cypherpunks and Extropians, Julian Dibbell's excellent article that appeared in the "Village Voice" (August 3rd, cover story) is the *cover story* as well in the latest "Metro" newspaper, the free San Jose area paper (but we get it down here in Santa Cruz as well). I have picked up a handful of these free papers, which I'll take to the Cypherpunks meeting this Saturday. But you all ought to do the same. And those not in the Bay Area may want to be on the lookout for versions of this appearing in your own community newspapers. If it was sold to "Metro," it'll probably be in other major markets as well. Plastered across the cover is this: "CODE WARRIORS New encryption software cripples the government's power to monitor our activities, eavesdrop on our conversations or read our e-mail. Soon the state may be unable to regulate business, collect taxes, spy on foreign enemies, or police criminal activity. It will be the end of government as we know it." And in the table of contents is this description of the article: "COVER STORY How will the Feds be able to control us when they won't know what the hell's going on? Simple encryption software now gives ordinary citizens the ability to keep their secrets secret--and conduct underground transactions safe from the prying eyes of government spooks and IRS agents." And the "Metro" version also differs from the "VV" version by having such paragraphs like this in 24-point type: "Untraceable digital cash transactions and a brisk commerce in trade secrets could spell doom for the corporation as we know it. Hopelessly untaxable, such crypto-markets could also sap the strength of governments." Wow! And "Gulp." I may have to get my European Community passport sooner than I had planned. Does Martinique have a Net connection? -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From khijol!erc at apple.com Thu Sep 9 19:12:30 1993 From: khijol!erc at apple.com (Ed Carp) Date: Thu, 9 Sep 93 19:12:30 PDT Subject: "Code Warriors" Article in "Metro" Newspaper In-Reply-To: <9309100058.AA18920@netcom5.netcom.com> Message-ID: > "Untraceable digital cash transactions and a brisk commerce in trade > secrets could spell doom for the corporation as we know it. Hopelessly > untaxable, such crypto-markets could also sap the strength of > governments." I can see it now - electronic governments based on reputation. With global communications possible, how would it be possible for *any* government to lie to its citizens? Of course, you always run the risk of drowning in information - but that's what filter programs are for, I suppose... -- Ed Carp erc at apple.com 510/659-9560 If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From ld231782 at longs.lance.colostate.edu Thu Sep 9 22:47:33 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 9 Sep 93 22:47:33 PDT Subject: IETF + PEM = Internet Commerce Message-ID: <9309100539.AA02295@longs.lance.colostate.edu> Report: the IETF (Internet Engineering Task Force) is very pro-commerce and recently met in Amsterdam for a session to discuss Internet Mercantile Protocols (IMP). It would allow consumers & companies on the Internet to combine PEM and MIME to complete and automate commercial transactions. J. C. Davin, previously of Bellcore helped initiate the IMP project. He envisions a standard that would allow companies to sell data such as image files or software. Another approach being considered would allow a sort of `home shopping network' approach. Meeting m Amsterdam minutes can be found at thumper.bellcore.com. Directory path: pub/devetzis/imp. Get: imp-archive. Mail me for more information. - - - On a related note, Bob Metcalf of IETF and columnist for InfoWorld was on NPR recently and talked about the `pampered elite' of people with Unix machines that are currently using the internet. The comment was clarified to mean that a vast audience of people with PCs and Macs and other low-end computers are mostly unconnected. IETF membership info appended. He shows a strong commitment to: 1) increasing address space for participants of the next century - `upgrading in one of the biggest cutovers since Great Britain decided to drive on the right side of the road' 2) exploiting ATM with ``cell-based protocols, operating systems, and applications. Otherwise, the Internet stays stuck in its current 20-year-old ASCII-bound applications -- TELNET, FTP, and E-mail.'' 3) strong support for *individual* subscribers vs. the current institutional monopoly, with ISDN playing a central role 4) he's in favor of usage billing as a critical aspect of commercial development. ``Internet carriers must be able, as are telephone companies, to settle with one another for traffic carried on behalf of each other's customers.'' From: "Bob Metcalfe" >if you want to join the Internet Society, as I just did, >to keep in touch with how the third generation is coming along, it costs $70 >per year and gets you the quarterly /Internet Society News/. Call >703-620-8990. From zeek at bongo.cc.utexas.edu Thu Sep 9 23:57:34 1993 From: zeek at bongo.cc.utexas.edu (Zeek) Date: Thu, 9 Sep 93 23:57:34 PDT Subject: Cryptography Conference (Austin, Tx) Message-ID: <199309100652.AA26841@bongo.cc.utexas.edu> ----------------------------------------------------------- Please forward this announcement to appropriate mailing lists, newsgroups, bbs, and individuals. Sincere apologies to those who have seen this announcement too many times. ----------------------------------------------------------- EFF / EFF-Austin Cryptography Conference Wednesday, September 22, 1993 Ramada Inn North, Austin 9220 N. IH-35 at Rundberg Admission is free. Please arrive at 12:3o p.m. to find seating. 1:oo - 1:3o p.m. *INTRODUCTORY REMARKS* Steve Jackson - WELCOME [5 minutes] Bruce Sterling - KEYNOTE [20 minutes] PANEL #1 [1:45 - 3:oo] *POLICY* Mitch Kapor Jerry Berman Dave Farber PANEL #2 [3:15 - 4:3o] *LAW ENFORCEMENT* Esther Dyson Mike Godwin PANEL #3 [4:45 to 6:oo] *CYPHERPUNKS* John Perry Barlow Eric Hughes John Gilmore DINNER [6:oo to 8:oo] No dinner arrangements have been made. However, a buffet dinner will be offered by the Ramada or you may order from their menu. Good dining is also available within the area. RECEPTION [8:oo to 10:oo] A cash bar will be available and everyone is invited. Hopefully those of you unable to make the daytime events can attend the reception. ------------------------------------------------------------------ For more information please contact zeek at bongo.cc.utexas.edu, jonl at wixer.bga.com, or call (512) 453-4483 [leave a message for zeek]. From ld231782 at longs.lance.colostate.edu Thu Sep 9 23:58:16 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 9 Sep 93 23:58:16 PDT Subject: ViaCrypt PGP Announcement clarifications Message-ID: <9309100652.AA03509@longs.lance.colostate.edu> - using their own cryptographic routines DigiSig+ (by necessity) - first release scheduled early Nov. 1993 - Windows & Mac versions in 1994 - source code *not* released - no indication of `reviews' or QA by PRZ etc. ------- Forwarded Message Date: Thu, 09 Sep 93 13:59:41 -0700 From: "Tom Jones" Subject: ViaCrypt PGP Announcement Internet messages pertaining to ViaCrypt(tm) PGP(tm) have been very positive but somewhat overwhelming. With dozens of messages received by Phil and passed on to ViaCrypt, this general response will have to suffice until we can get back with more personalized messages. First, ViaCrypt (a division of 17-year-old Lemcom Systems, Inc.) presently has a PKP patent sublicense for its line of DigiSig+(tm) software and hardware cryptographic engines. By using ViaCrypt's licensed DigiSig+ software cryptographic engine for the RSA technology, and marrying it to most of the PGP code, we will produce a totally compatible and legal commercial product which is called ViaCrypt PGP. Second, there is a little work required before we can start shipping. Most significantly, PGP is being modified to substitute the DigiSig+ cryptographic engine in the ViaCrypt PGP product. With the more generalized interface of the DigiSig+ cryptographic engine, ViaCrypt PGP may run slightly slower than PGP but otherwise you won't notice any difference. ViaCrypt will attempt to minimize any performance differences in future releases. ViaCrypt's patent sublicense from PKP only permits object code to be distributed. That may create uneasiness for some people, but is necessary to market ViaCrypt PGP. Following are excerpts from the press release for ViaCrypt PGP dated 3 September 1993: "ViaCrypt PGP will be available in object code for the DOS environment in early November, 1993. ViaCrypt intends to make the program available on a wide range of additional platforms. UNIX versions will soon follow. To provide a high degree of interoperability, the company expects to announce a Windows version, Macintosh version, and ports to several other platforms in 1994. ViaCrypt PGP for DOS prices are $199.95 for a single user license, $599.95 for a five user license, and $1,649.95 for a 20 user license. Shipping and handling are extra. As an introductory promotional offer, these prices are discounted 50% for orders received through the end of 1993. Multiple-user licenses for 50 or more are also available from ViaCrypt. Prices for ViaCrypt PGP on other platforms may vary and will be established at announcement time." ------- End of Forwarded Message From ld231782 at longs.lance.colostate.edu Fri Sep 10 00:03:31 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Fri, 10 Sep 93 00:03:31 PDT Subject: Waco Raid: Justice Dept. requests FOIA IMMUNITY! Message-ID: <9309100658.AA03565@longs.lance.colostate.edu> Just what we need -- a whole new field day for the disconsolate Kennedy conspiracy theorist industry! Maybe they'll let us see *these* documents in 2050 or so! (Disclaimer: of course, this has only tangential relevance to the list, but it has formed one of the hottest, most recurring, and emotional topics on the list, and hopefully everyone who would flame me for posting it here has already deleted the message based on the subject line! so NYAAHH!) ------- Forwarded Message From: Richard Ginn Subject: Waco, Texas [Branch Davidians] Raid and the Freedom of Information Act Exemption Request by Justice Dept. of the US. Date: Thu, 9 Sep 1993 18:21:21 -0400 By Richard Ginn , Ithaca, New York, USA - 9 Sept. 1993 - The United States Justice Department has requested that all files relating to the Waco, Texas [Branch Davidian - David Koresh and friends] raid by U.S. Government forces and the resulting deaths be exempted from all Freedom of Information Act (FOIA) inquiries and that the files be sealed so that no one may make any further inquiries into the Waco incident. The full text of the request can be found in the United States Federal Register, Volume 58, Number 156, on Monday August 16, 1993, page 43312. The period for comment on this action expires on September 15, 1993 (six days from the date of this message), after which the files will be sealed if there is no opposing comment by the public. - - 30 - ------- End of Forwarded Message From ld231782 at longs.lance.colostate.edu Fri Sep 10 01:08:16 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Fri, 10 Sep 93 01:08:16 PDT Subject: WACO: commentary, addresses to write Message-ID: <9309100803.AA04444@longs.lance.colostate.edu> wow, I guess this has been known in cyberspace since last friday. just goes to show you I don't read all the conspiracy newsgroups, eh? :) ===cut=here=== Newsgroups: talk.politics.guns,talk.politics.misc,alt.individualism,alt.activism,misc.legal From: lvc at cbnews.cb.att.com (Larry Cipriani) Subject: BATF GOES FOR COVER-UP OF WACO FIASCO, Organization: Ideology Busters, Inc. Date: Fri, 3 Sep 1993 17:35:28 GMT BATF GOES FOR COVER-UP OF WACO FIASCO, WRITE TO TREASURY NOW TO PROTEST!!! The people who launched the disastrous raid on the Branch Dividian compound in Waco, Texas, have now mounted an attack on the American people's right to know facts behind the tragedy. The Tresury Department is seeking to deny public access to invesitgative reports probing the government's actions leading to the Waco conflagration You have until September 15 to protest against this cover-up. Comments (preferably in triplicate) should be sent to the Dept. of the Tresaury, Office of Enforcemnet, Room 4312, 1500 Pennslyvania Ave., N.W., Washington, D.C. 20220. WRITE NOW! It has been reported that the Treasury wants to lockup many of the findings of the Waco investigation to "protect investigative techniques and procedures." What they are really doing is hiding the truth from the American people and preventing the people from making an accurate judgment on the BATF actions in Waco. This action is being taken at teh same time critizism of the raid is mounting. The affidavit used to justify the search warrant used in Waco has come under intense criticism, with stories in a number of major papers, the Washington Times the latest (Sept. 2). Experts who have researched the warrant have stated that it never should have been granted because the affidavit did not meet legal requirements. Specifically cited were: a quote attributed to Koresh regarding the LA riots, said to have been spoken three weeks before the riots happened; no probable cause based on information included in the warrant; inaccurate description of the firearms in possession of Koresh; and only technical, if any, violations of firearms laws. As a result of this intense pressure, there has been speculation in the press that Stephen Higgins, BATF Director and other top BATF officials may be forced out. However, to counter the growing outcry, the Treasury is now taking steps to seal away information from the investigation of the tragedy. That is, they are trying to cover it all up. Below is the text of a proposed rule change that would lock up the files of the "Waco Administrative Review Group Investigation", the panel assigned to investigate the assault on the Branch Davidian Compound. This means that Freedom of Information Act requests for information will be denied, and the public will not have access to this information. This is a blatant effort to cover-up the blunders in Waco. It can only be stopped if people cry-out in protest. DEPARTMENT OF THE TREASURY Departmental Offices (DEPO) 31 CFR Part 1 Proposed rule: Privacy Act of 1974, as Amended; Exemption of System of Records From Certain Provisions Contact: Nichole L. Jenkins, 202-622-0450 Comment Date: 09/15/93 (FEDREGISTER 58 FR 43312 08/16/93; 538 lines.) *Proposed Rules* --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- DEPARTMENT OF THE TREASURY Departmental Offices 31 CFR Part 1 Privacy Act of 1974, as Amended; Exemption of System of Records From Certain Provisions AGENCY: Departmental Offices, Department of the Treasury. ACTION: Proposed rule. SUMMARY: In accordance with the requirements of the Privacy Act of 1974, as amended, Departmental Offices, Office of Enforcement is proposing to exempt a system of records, the Waco Administrative Review Group Investigation (DO/.207) from certain provisions of the Privacy Act. The exemptions are intended to increase the value of the system of records for law enforcement and investigative purposes, to comply with legal prohibitions against the disclosure of certain kinds of information, and to protect the privacy of individuals identified in the system of records. The exemptions are intended to increase the value of the system of records for the factfinding investigation and administrative review performed by the Waco Administrative Review Group so as not to reveal local, state or Federal law enforcement techniques, sources and methods or affect the ability of law enforcement agencies to prosecute people for criminal wrongdoing. DATES: Comments must be received no later than September 15, 1993. ADDRESSES: Comments (preferably in triplicate) must be submitted to the Department of the Treasury, Office of Enforcement, room 4312, 1500 Pennsylvania Ave., NW., Washington, DC 20220. FOR FURTHER INFORMATION CONTACT: Nichole L. Jenkins, Attorney, Office of the Assistant General Counsel (Administrative & General Law), (202) 622- 0450, room 1410, 1500 Pennsylvania Ave., NW., Washington, DC 20220. Downloaded from GUN-TALK (703-719-6406) A service of the National Rifle Association Institute for Legislative Action Washington, DC 20036 -- Larry Cipriani -- l.v.cipriani at att.com or attmail!lcipriani From remail at tamsun.tamu.edu Fri Sep 10 01:37:35 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Fri, 10 Sep 93 01:37:35 PDT Subject: WACO: commentary, addresses to write Message-ID: <9309100832.AA16682@tamsun.tamu.edu> Is there any ethical person inside Treasury with a digitizer and net access (or a freind with net access)? A great opportunity for use of alt.whistleblowers. From gnu Fri Sep 10 02:13:41 1993 From: gnu (John Gilmore) Date: Fri, 10 Sep 93 02:13:41 PDT Subject: Crack DES in 3.5 hours for only $1,500,000! In-Reply-To: <9309092314.AA15000@toad.com> Message-ID: <9309100913.AA23487@toad.com> I will have printed copies of the paper at the Cypherpunks meeting this weekend. Folks in other locations, please print the PostScript version from ftp.eff.org:/pub/crypto/des_key_search.ps, rather than asking me to mail printed copies. Kudos to Michael Wiener for doing the work, and for making the paper freely available online! By the way, with 60,000 chips, it takes 3.5 hours to brute-force a 56 bit key. If you lop 16 bits off, you lose a factor of ~60,000: it takes ONE chip a few hours to brute-force it -- or a third of a second if you use the whole machine. I wondered where those ``40-bit keys'' came from... Oho! I now suspect why RC2 and RC4 must remain trade-secret...NSA doesn't want people to know what particular internal algorithm features their brute-force chips are capable of handling! I recall the discussion of how RC2/4 were invented; NSA told the designer (since identified as Ron Rivest): "No, this is too big; weaken this over here; do fewer rounds here; etc..." What resulted was suitable for NSA brute-force using chips they had readily available. It's possible that simple changes to the algorithm would render it much less penetrable by NSA's current hardware. Ron even knows *which* changes, and I encourage him to tell us. John From David.D.L.LANDGREN at PUB.oecd.fr Fri Sep 10 03:37:38 1993 From: David.D.L.LANDGREN at PUB.oecd.fr (David LANDGREN, PUB ) Date: Fri, 10 Sep 93 03:37:38 PDT Subject: ... long live DES (sic) Message-ID: <"21031101903991/16267 OECDX400*"@MHS> >>>This chip takes a single plaintext/ciphertext pair and quickly tries >>>DES keys until it finds one that produces the given ciphertext from the >>>given plaintext. It's all very well to be able to crack DES in 3.5 hours, but I don't know of too many people who obligingly send out the plaintext and cyphertext of a message together, or in some other way combinable. If U can get the plaintext of a DES-encrypted msg then U don't need to dick around with DES anyway. No-one ever said it was bulletproof; a direct consequence is that DES users change their keys awful frequently. David Landgren [standard disclaimer: this is my personal point of view] A B O L I S H F E A R -- E S T A B L I S H T R U S T From smb at research.att.com Fri Sep 10 06:42:43 1993 From: smb at research.att.com (smb at research.att.com) Date: Fri, 10 Sep 93 06:42:43 PDT Subject: Crack DES in 3.5 hours for only $1,500,000! Message-ID: <9309101339.AA26739@toad.com> Oho! I now suspect why RC2 and RC4 must remain trade-secret...NSA doesn't want people to know what particular internal algorithm features their brute-force chips are capable of handling! I recall the discussion of how RC2/4 were invented; NSA told the designer (since identified as Ron Rivest): "No, this is too big; weaken this over here; do fewer rounds here; etc..." What resulted was suitable for NSA brute-force using chips they had readily available. It's possible that simple changes to the algorithm would render it much less penetrable by NSA's current hardware. Ron even knows *which* changes, and I encourage him to tell us. I'll let Rivest speak for himself about NSA's influence -- but I've spoken to cryptographers who've seen the algorithm (under non-disclosure agreements), and they say that RC2 and RC4 are quite strong *if* you use a long enough key. They're algorithms with variable-length keys, and their strength -- and not just their resistance to exhaustive search -- is related to the key size used. The gotcha is that only the 40-bit version is exportable. But we don't need stories about weakened algorithms to know that NSA can crack 40-bit RC2/4; they'd never have granted a license otherwise. (And what does that tell us about 512-bit RSA?) One more point -- it's been claimed that RC2 and RC4 have an inherently- slow key setup mechanism. That can slow down brute-force attacks tremendously, since it then takes a long time to try each case. But it's fine for point-to-point encryptions, where you can amortize that overhead over many messages. --Steve Bellovin From doug at netcom5.netcom.com Fri Sep 10 08:22:46 1993 From: doug at netcom5.netcom.com (Doug Merritt) Date: Fri, 10 Sep 93 08:22:46 PDT Subject: "Code Warriors" Article in "Metro" Newspaper Message-ID: <9309101515.AA29004@netcom5.netcom.com> tcmay at netcom.com (Timothy C. May) said: >Julian Dibbell's excellent article that appeared in the "Village >Voice" (August 3rd, cover story) is the *cover story* as well in the >latest "Metro" newspaper, the free San Jose area paper (but we get it >down here in Santa Cruz as well). Over lunch yesterday I was telling a friend (who had previously exhorted me to find folks on the net more appropriate than sci.crypt to discuss crypto schemes with) about discovering cypherpunks, and on our way out he noticed this Metro issue, commenting "Zeitgeist." Quite. :-) It quotes Tim, btw: You can get further away in cyberspace than you could in going to Alpha Centauri", says Tim May, and he should know. Before he retired seven years agao, a wealthy man at age 34, May was a reasonably illustrious corporate physicist. Now he's a Cypherpunk, part of a loose-knit band of scrappy, libertarian-leaning computer jockeys who have dedicated themselves to perfecting and promoting the art of disappearing into the virtual hinterlands. Concentrated in Silicon Valley but spread out across the country and as far away as Finland, the Cypherpunks maintain daily e-mail contact, collaboratively creating and distributing practical software answers to modern cryptography's central question: How to wrap a piece of digital information in mathematical complexity so dense that only literally astronomical expenditures of computer time can breach it? "Some of these things sound like just a bunch of fucking numbers," May explains. "But what they really are is they're things which in computability space take more energy to get to than to drive a car to Andromeda. I'm not kidding. I mean, you can work the math out yourself." Well, no, you probably can't, but even those unversed in rocket science can appreciate the social value of such calculations... And Eric: "Cryptography is a greater equalizer than the Colt .45," says Eric Hughes, the long-haired, cowboy-hatted and not entirely lapsed Mormon who, along with May, conceived the Cypherpunks just seven months before the Clipper hit the fan. "These are power-leveling techniques," he adds, pointing out that the hermetically sealed voice-and-data channels that could arm every citizen against state wire-surveillance are just the simplest of the crypto toys the Cypherpunks are playing with. Nicely provocative article. Doug -- Doug Merritt doug at netcom.com Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow Unicode Novis Cypherpunks Gutenberg Wavelets Conlang Logli Alife HC_III Computational linguistics Fundamental physics Cogsci SF GA VR CASE TLAs From ferguson at fiber.sprintlink.net Fri Sep 10 08:23:47 1993 From: ferguson at fiber.sprintlink.net (Paul Ferguson x2044) Date: Fri, 10 Sep 93 08:23:47 PDT Subject: Cracking DES - A practical implimentation? Message-ID: <9309101617.AA09158@fiber.sprintlink.net> On Thu, 09 Sep 93 16:14:56 -0700, John Gilmore wrote - > Be the first on your block! No kidding. I just ftp'd the des_key_search.ps file from ftp.eff.org and browsed through the first few pages (hats off to Michael for a fine piece of work). This is indeed an important milestone and will have an impact on the cryptographic implementations used by banks, etc. in the very near future. It should be interesting to see what the future holds .... > The paper was written as a warning to DES users (bankers) and their > customers (depositors). DES is used to protect electronic money > transfers among banks all over the world. Several billion dollars per > day are moved in this way. Within a day of finishing the machine, a > criminal could easily pay back the $1.5M in capital. In the second > day, they'd have the capital required to build a second machine, and > in the third day a positive cash flow would begin. Banks can do > nothing to stop this -- if they shut down their comm links, they go > out of business; if they keep moving money over them, intruders suck > money out at will. I recommend not keeping your money in banks... ...and in another communique - > Oho! I now suspect why RC2 and RC4 must remain trade-secret...NSA > doesn't want people to know what particular internal algorithm > features their brute-force chips are capable of handling! I recall > the discussion of how RC2/4 were invented; NSA told the designer > (since identified as Ron Rivest): "No, this is too big; weaken this > over here; do fewer rounds here; etc..." What resulted was suitable > for NSA brute-force using chips they had readily available. It's > possible that simple changes to the algorithm would render it much > less penetrable by NSA's current hardware. Ron even knows *which* > changes, and I encourage him to tell us. That would be an interesting revelation, wouldn't it? ,-) _____________________________________________________________________________ Paul Ferguson Mindbank Consulting Group fergp at sytex.com Fairfax, Virginia USA ferguson at icp.net From smb at research.att.com Fri Sep 10 08:27:45 1993 From: smb at research.att.com (smb at research.att.com) Date: Fri, 10 Sep 93 08:27:45 PDT Subject: ... long live DES (sic) Message-ID: <9309101526.AA28428@toad.com> It's all very well to be able to crack DES in 3.5 hours, but I don't know of too many people who obligingly send out the plaintext and cyphertext of a message together, or in some other way combinable. If U can get the plaintext of a DES-encrypted msg then U don't need to dick around with DES anyway. No-one ever said it was bulletproof; a direct consequence is that DES users change their keys awful frequently. It's not that simple; Wiener's design is indeed a major breakthrough (for the open literature, of course). First of all, one can often guess probable plaintext for some of the message. Here's the first line of your note as it (apparently) left your machine: Date: 10 Sep 93 10:30:12 GMT If I've ever received mail from you, and hence know that format, I know at least the first 6 bytes, and the format of the next two. If I know the date of the intercept, I have even more. Poof -- a crib. I can do even better. Look at the $10,000,000 machine -- the one with a 21-minute solution. I can afford to try several guesses for where the string `Date: ' occurs. It doesn't take that much more complex a chip to look for obvious variants, such as that string occuring shifted over one or two bytes in either direction. You may get some false positives, but a second-order search machine can then apply more complex heuristics to possible keys returned by Wiener's design. And historically, enemies have been able to get probable plaintext -- or even some chosen plaintext -- for at least a few messages. Read ``The Codebreakers'' or ``Seizing the Enigma'' for many such examples. There's one more step here, described in detail in Garon and Outerbridge's ``DES Watch'' paper. If the DES session key is transmitted encrypted by DES using a 56-bit master key, you're dead meat. I can crunch for weeks to recover one session key, using many possibilities for the plaintext and its location in the ciphertext. But once I recover that long-gone session key, I can use it as the known plaintext to recover your master key. And after that, the jig is up. No, there should be no mistake about it. Single DES is *dead*, for any application where recovery of a single session key is bad. If you want to stick with single DES, you need to change session keys very often (every few seconds against an enemy who can build a $10M machine), and you need to distribute session keys by some other mechanism (i.e., RSA, Diffie-Hellman, triple DES). --Steve Bellovin From koontzd at lrcs.loral.com Fri Sep 10 09:03:48 1993 From: koontzd at lrcs.loral.com (David Koontz ) Date: Fri, 10 Sep 93 09:03:48 PDT Subject: No Subject Message-ID: <9309101558.AA19871@nebula.lrcs.loral.com> >From: "David LANDGREN, PUB " >To: cypherpunks at toad.com >Subject: ... long live DES (sic) >Importance: Normal >Status: R > >>>>This chip takes a single plaintext/ciphertext pair and quickly tries >>>>DES keys until it finds one that produces the given ciphertext from the >>>>given plaintext. > >It's all very well to be able to crack DES in 3.5 hours, but I don't know >of too many people who obligingly send out the plaintext and cyphertext of >a message together, or in some other way combinable. If U can get the >plaintext of a DES-encrypted msg then U don't need to dick around with DES >anyway. No-one ever said it was bulletproof; a direct consequence is that DES users change their keys awful frequently. The way to get plaintext is through what is known as revealed-plaintext, where you can with a high degree of accuracy 'guess' part of the plaintext of a message, such as "From: Col. Dimwitt" in a message format, or the title of a paper or document, which is usally unclassified and knowable from another source. Fearing such, our illustrious 3 letter governmental organization implemented with the advent of electronic crypto gear (set your way back machine, sherman) something called traffic flow security, where on a radio net or dedicated line a cryptographic stream continously runs. The idea is to make it hard to distinguish boundaries of messages, and thus revealed-plaintext. This also allows the use of the caveat - EFTO (Encrypted For Transmission Only) seen on unclassified messages, hey the line was otherwise idle, waiting for classified traffic, right? Modern communications are swinging toward the use of packets, which beside allowing traffic analysis unless the transmission medium is denied (Such as using link encryption as a super encryption, or dedicated lines, etc.). The way to offset to offset the vulnerability to revealed-plaintext attacks is to use filling where some random data followed by a sync or start of message symbol preceeds the the actual message. All message traffic should be encrypted in general, making it hard to separate the wheat from the chaff. Ideally the only unencrypted data should be that required for operating the communications protocol, including denial of packet ordering if possible. There's a paper found on the NIST anonymous ftp site entitled 'Security in ISDN' by William E. Burr that can be informative. Its available in PostScript and is around 70 pages long. From gtoal at an-teallach.com Fri Sep 10 12:47:49 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Fri, 10 Sep 93 12:47:49 PDT Subject: Mailer hooks for PGP Message-ID: <8778@an-teallach.com> In article <9308271722.AA11690 at ah.com> hughes at ah.com writes: > >check your public ring and automatically sign/encode outgoing mail to > >eligible users > > As a general rule, mere presence of a key on a keyring should not > indicate that this person wishes to receive encrypted mail. There > should be a separate installation for that, either by an enhanced > alias file or similar. There are many for whom reading encrypted mail > is not always desirable, because the effort required to download it > and decrypt it is more time than the content is worth. I myself fall > into this category, unfortunately. This is very true. I hacked my mailer to encrypt when possible, and it drove Phil Zimmerman batty every time I mailed him and forgot to override it. G -- Personal mail to gtoal at gtoal.com (I read it in the evenings) Business mail to gtoal at an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212 From gtoal at an-teallach.com Fri Sep 10 12:48:42 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Fri, 10 Sep 93 12:48:42 PDT Subject: Further PGP Security Doubts Message-ID: <8782@an-teallach.com> In article <199308261827.AA25477 at xtropia> an31144 at anon.penet.fi writes: > I have been seeing yet more criticisms of PGP, this time from some > character calling himself "Raymond Paquin." He claims to be a > professor of mathematics who has been working at an unnamed university > exclusively on cryptographics for the past twelve years. He implies > that he is working for some government in a classified capacity and is > thus unable to either publish or discuss the matter openly. I missed that one (had matters to attend to ;-) ) - could someone repost it please? I'd quite like to see if my text style analysis skills are still working :) G -- Personal mail to gtoal at gtoal.com (I read it in the evenings) Business mail to gtoal at an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212 From newsham at wiliki.eng.hawaii.edu Fri Sep 10 13:12:50 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Fri, 10 Sep 93 13:12:50 PDT Subject: DES, key scheduler Message-ID: <9309102010.AA01292@toad.com> Does anyone here have a list of the scheduled bits for each subkey in each round of DES? (ie. if input key is {0,1,...64} (or 56) then k1 = { 15, 2, 35, ... } etc.) Alternatively (next best thing) does anyone have a list of which key bits arent used in each round? Tim N. From MJMISKI at macc.wisc.edu Fri Sep 10 13:27:50 1993 From: MJMISKI at macc.wisc.edu (Matthew J Miszewski) Date: Fri, 10 Sep 93 13:27:50 PDT Subject: Object Code Release Message-ID: <23091013192867@vms2.macc.wisc.edu> Just a qwik note on the release of ViaCrypt only in object code. Ill dig up the cite later but recent appelate decisions show two circuits leaning toward allowing fair use decompiling for academic purposes. Actually, they have gone as far to say that deprogramming an EEPROM and printing out the resultant Source (after decompiled) *might* be considered a fair use of sorts. So, release VC in object and have the folks that decompiled the KOH decompile this too and whallah! A more robust encryption scheme (not security thru obscurity). Matt (not --Matt) mjmiski at macc.wisc.edu (I hate .sig space) From cme at ellisun.sw.stratus.com Fri Sep 10 14:02:51 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Fri, 10 Sep 93 14:02:51 PDT Subject: Crack DES in 3.5 hours for only $1,500,000! Message-ID: <9309102054.AA26212@ellisun.sw.stratus.com> >From: gnu at toad.com (John Gilmore) >Message-Id: <9309100913.AA23487 at toad.com> >Subject: Re: Crack DES in 3.5 hours for only $1,500,000! >Date: Fri, 10 Sep 93 02:13:32 -0700 It feels like you're jumping to conclusions, John. At 40 bits of key, I don't care how strong an algorithm is. I can have my network of SPARCstations try all keys. NSA chip technology doesn't enter into that analysis. Meanwhile, on the death of DES -- what we know is that there's a known plaintext attack, given the right hardware. What I've recently heard called a pre-whitening (XOR with PRNG before the DES) wipes out the known plaintext. The PRNG doesn't need to be that strong. It's protected by DES and vice versa -- Chinese-puzzle style. Of course, my personal favorite DES variant remains: compress|des|tran|des|tran|des but if you're really paranoid, you could change it to: compress|xor|tran|des|tran|des|tran|des since xor and tran are so cheap. [des in any mode you prefer -- eg., cbc or cfb -- IVs kept secret, of course.] [For those not reading sci.crypt, tran is an (up to) 8KB transposition with PRNG keyed from the histogram of the first block of bytes -- code posted to sci.crypt, mailed by me or avbl by ftp from scss3.cl.msu.edu.] - Carl From mdiehl at triton.unm.edu Fri Sep 10 14:12:51 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 10 Sep 93 14:12:51 PDT Subject: "Code Warriors" Article in "Metro" Newspaper In-Reply-To: Message-ID: <9309102106.AA26303@triton.unm.edu> According to Ed Carp: > I can see it now - electronic governments based on reputation. With global Well, we already have a government based on reputation. The very currency with which we pay our rent is "backed by the full faith and promise of the American Government." Pfffft! Ya right. Just think what would happen if the Banks started refusing to loan Big Brother any more money to play with. Our country would fall within 1 year. > communications possible, how would it be possible for *any* government to lie It's becomming more difficult every day for our Big Brother to lie to us. This is happening, for the most part, due to the availability of electronic communications. > to its citizens? Of course, you always run the risk of drowning in > information - but that's what filter programs are for, I suppose... Have you ever played with gopher for 4 hours..... Nuff said.. ;^) Good post, Ed. My only point is that the things you speak of are already happening. Take care. Lagers, J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politicly Incorrect! Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From tcmay at netcom.com Fri Sep 10 14:42:52 1993 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 10 Sep 93 14:42:52 PDT Subject: Armed gangs stealing chips from warehouses Message-ID: <9309102135.AA25794@netcom5.netcom.com> I saw on "Clarinet," the news service, a couple of A.P. reports on armed attacks on chip warehouses. The latest was yesterday when a van pulled up to the loading dock at Wyle, a distributor in Santa Clara (across from Intel). Two armed men forced everyone in the area to the floor, while they went straight for the Intel microprocessors and filled a large bag. An investigator called this type of crime the wave of the future, and said something to the effect that "chips will be the coke of the 90s." Also talk of black markets and how computer networks are being used to coordinate things. So, if you see folks using BlackNet for advertising Intel chips.... (I regret that I cannot post the Clarinet article, as Clarinet has fairly draconian policies about reposting its articles--even though I never signed a contract. Still, Cypherunks should be aware of this....I've seen at least one Clarinet article reposted here on this list, and this could expose the list to actions.) --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From ferguson at fiber.sprintlink.net Fri Sep 10 16:47:53 1993 From: ferguson at fiber.sprintlink.net (Paul Ferguson x2044) Date: Fri, 10 Sep 93 16:47:53 PDT Subject: Digital warfare Message-ID: <9309110040.AA09675@fiber.sprintlink.net> On Fri, 10 Sep 93 14:35:02 PDT, Timothy C. May wrote - > An investigator called this type of crime the wave of the > future, and said something to the effect that "chips will > be the coke of the 90s." Also talk of black markets and > how computer networks are being used to coordinate things. > So, if you see folks using BlackNet for advertising Intel > chips.... That's an interesting point (images of "Wild Palms" conjured). This _is_ the wave of the future, as Tim implies, and it's unfortunate that instances such as this (segway) tarnishes what it is that I think many of us are trying to espouse in the cypherpunk movement. Paul Ferguson | privacy \'pri-va-see\ n, pl, -cies; Mindbank Consulting Group | 1: the quality or state of being apart Fairfax, Virginia USA | from others 2: secrecy fergp at sytex.com | ferguson at icp.net | Privacy -- Use it or lose it. From cme at ellisun.sw.stratus.com Fri Sep 10 18:02:55 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Fri, 10 Sep 93 18:02:55 PDT Subject: Digital warfare Message-ID: <9309110057.AA26559@ellisun.sw.stratus.com> >Date: Fri, 10 Sep 93 19:40:37 -0500 >From: ferguson at fiber.sprintlink.net (Paul Ferguson x2044) >Message-Id: <9309110040.AA09675 at fiber.sprintlink.net> >Subject: Digital warfare >> So, if you see folks using BlackNet for advertising Intel >> chips.... > > That's an interesting point (images of "Wild Palms" conjured). > This _is_ the wave of the future, as Tim implies, and it's > unfortunate that instances such as this (segway) tarnishes what > it is that I think many of us are trying to espouse in the > cypherpunk movement. > >ferguson at icp.net | Privacy -- Use it or lose it. I have heard cypherpunks described as two groups under one label: 1. those of us who advocate privacy in private hands 2. those who advocate anarchy I'm in the privacy camp and worry that enough talk from the anarchists will cause the privacy to be attacked. I fully expect total retaliation by the governments of the world against any effective anarchy. The wilder the threats (even if they're not real), the stronger the retaliation. We could lose all privacy as a result. It's important not to give the government any excuse which would make the populace side with them against us. This is a political battle and we need the people on our side. For example, crypto-anarchic banks -- cute idea -- but if you ever want a cop to make your banker give you the money, the banker can't be anonymous and neither can you account be. ..so you have to *really* trust this banker. Maybe some people will trust such a banker enough. But, meanwhile, talk of total tax evasion by the more excited of our crypto-anarchy brethren might give the government the political ammunition it needs. In fact, if the FBI has planted agents on this list, I wouldn't be surprised to discover someday that they were among the vocal anarchists. - Carl From pmetzger at lehman.com Fri Sep 10 18:32:55 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Fri, 10 Sep 93 18:32:55 PDT Subject: Digital warfare In-Reply-To: <9309110057.AA26559@ellisun.sw.stratus.com> Message-ID: <9309110127.AA10043@snark.lehman.com> Carl Ellison says: > For example, crypto-anarchic banks -- cute idea -- but if you ever want a > cop to make your banker give you the money, the banker can't be anonymous > and neither can you account be. Perhaps the banker can't be anonymous, but the account certainly can be. Many countries have centuries of experience with this. Hell, the Austrians have 100% anonymous accounts to this day. Works just fine, and no trust is involved. > In fact, if the FBI has planted agents on this list, I wouldn't be > surprised to discover someday that they were among the vocal anarchists. Feel free to check my credentials. I assure you I earn more than enough money at my job that it wouldn't be worth the FBI's money to make the bribe big enough -- it would also have to cover the risk to me that being an anarchist presents vis a vis my job -- someday I might lose it for having strange political ideas, and salaries like mine are hard to come by in other professions. Its entirely possible that there are FBI agents on this list -- I proceed on that assumption every day. Its also possible that there are agents provocateur. However, I fully assure you that many of us are legitimate anarchists of long standing, most of us being of the capitalist anarchist persuasion. I'll fully agree that arguing for anarchy with the general public won't work at the current time -- and I agree that our image is important. However, at this point the battle is being fought by folks like EFF and CPSR. I for one don't see any reason to hide my politics, although I try not to make an issue of it. Perry From ferguson at fiber.sprintlink.net Fri Sep 10 19:33:47 1993 From: ferguson at fiber.sprintlink.net (Paul Ferguson x2044) Date: Fri, 10 Sep 93 19:33:47 PDT Subject: Digital warfare Message-ID: <9309110326.AA09763@fiber.sprintlink.net> On Fri, 10 Sep 93 20:57:16 EDT, Carl Ellison wrote - >> That's an interesting point (images of "Wild Palms" conjured). >> This _is_ the wave of the future, as Tim implies, and it's >> unfortunate that instances such as this (segway) tarnishes what >> it is that I think many of us are trying to espouse in the >> cypherpunk movement. >> > >> ferguson at icp.net | Privacy -- Use it or lose it. > > I have heard cypherpunks described as two groups under one label: > > 1. those of us who advocate privacy in private hands > > 2. those who advocate anarchy I find myself straddling the line most of the time, but I have to come down solidly on the side of privacy-advocate, if push came to shove. However, push isn't shoving, so we (cypher-punk-advocates) should all be able to heterogeneously work our goals -- soild, secure and unmolested crypto for the masses. Let's be realistic -- and effective. > It's important not to give the government any excuse which would > make the populace side with them against us. This is a political > battle and we need the people on our side. Anyone who thinks that this battle can be won purely on the grounds of technology is dead wrong. Political leverage is a factor which we must, absolutely be striving for. We're getting there, slowly (very slowly) through education, but digital realization is something that is not going to happen overnight. The impact has yet to hit home in the public sector. - -- On Fri, 10 Sep 1993 21:27:37 -0400, Perry E. Metzger wrote - > Feel free to check my credentials. I assure you I earn more than > enough money at my job that it wouldn't be worth the FBI's money to > make the bribe big enough -- it would also have to cover the risk to > me that being an anarchist presents vis a vis my job -- someday I > might lose it for having strange political ideas, and salaries like > mine are hard to come by in other professions. Oh, come now, Perry. Let's be practical. I (on just one side of this multi-faceted topic), on the other hand, maintain more conventional idealisms; much more geared towards maintaining privacy (at all costs) and fighting the big brother machinations of a government out of control. In my own hairy opinion, anarchy is a losing strategy, but that is merely a matter of semantics, not something we should hash out on this list. I believe in the growth of the world-wide matrix; the growth of the internet -- access for the masses. In fact, that's just what I do to earn my pay. Filter this, Filter that, BGP this, EGP that, OSPF (oh, no!). I believe in strong cryptography. I believe in your power (and mine) to actually endorse and shape the world of digital communications. Let's just agree that we hold the same views on the matter of cryptography: it's a powerful tool. In the hands of the masses, it allows privacy unhindered. Compromised or crippled by the oppressive forces of a government, it is a weapon against privacy. > I'll fully agree that arguing for anarchy with the general public > won't work at the current time -- and I agree that our image is > important. However, at this point the battle is being fought by folks > like EFF and CPSR. I for one don't see any reason to hide my politics, > although I try not to make an issue of it. A wise summation. I would like to think that others are as aware of the political battlefields that must be crossed. I despise the political machine, but I understand the importance in influencing it in order to achieve the ideal "space." Government has no damned business in networking. We do. Paul Ferguson | privacy \'pri-va-see\ n, pl, -cies; Mindbank Consulting Group | 1: the quality or state of being apart Fairfax, Virginia USA | from others 2: secrecy fergp at sytex.com | ferguson at icp.net | Privacy -- Use it or lose it. From karn at qualcomm.com Fri Sep 10 21:17:58 1993 From: karn at qualcomm.com (Phil Karn) Date: Fri, 10 Sep 93 21:17:58 PDT Subject: Digital warfare In-Reply-To: <9309110057.AA26559@ellisun.sw.stratus.com> Message-ID: <9309110410.AA06849@servo> I want to echo Carl's sentiments. I do find talk about cryptographically enforced underground economies to be interesting, but scary as well precisely because I'm afraid of what the backlash might do to the cryptographically enforced personal privacy that I'm primarily interested in. Phil From smb at research.att.com Fri Sep 10 21:27:58 1993 From: smb at research.att.com (smb at research.att.com) Date: Fri, 10 Sep 93 21:27:58 PDT Subject: misc.legal.computing #4107 - Korea now accepts secret US patent applications Message-ID: <9309110426.AA07913@toad.com> This was posted to misc.legal.computing and misc.int-property. It's forwarded to this list with permission. --Steve Bellovin In article , srctran at world.std.com (Gregory Aharonian) writes: > On July 29, 1993, the republic of South Korea became the 17th country > to sign an agreement with the United States to protect patent rights of > patent applications fild in the United States for which the government > has classified secret and indefinitely delay the prosecution of the patent. > Existing countries, mostly COCOM members, are: Australia, Belgium, Canada, > Denmark, France, Germany, Greece, Italy, Japan, Luxembourg, Netherlands, > Norway, Portugal, Sweden, Turkey and United Kingdom. > > For more information on secrecy aspects of US patents, contact Robert > Garrett at the Patent Office, 703-308-0753. > -- > ************************************************************************** > Greg Aharonian srctran at world.std.com > Source Translation & Optimization 617-489-3727 > P.O. Box 404, Belmont, MA 02178 From ld231782 at longs.lance.colostate.edu Fri Sep 10 21:48:28 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Fri, 10 Sep 93 21:48:28 PDT Subject: Usenet on CDs - info Message-ID: <9309110442.AA05350@longs.lance.colostate.edu> Hello cypherpunks. I've been trying to track down the Internet legend of `Usenet on CD' haphazardly for some time, and finally got lucky by accident. The first service was apparently started by Kent Landfield, a FAQ editor and entrepreneur who worked with 3 others and `quickly became overwhelmed' by the response and demand. This was under the company Sterling Software. They handed it off to CD Publishing Corporation, Vancouver, British Columbia, CA who is at this moment distributing Usenet on CDs! Each disk has about 600 megabytes of news. Shipped within 30 days after the last date on the disk. Uses standard ISO 9660 CD format, Rock Ridge extension planned. They have Mac and Unix software on the disk, DOS software planned, with other software acceptable if it is ISO 9660 compliant. Prices range from $40 + 5 s/h per disk down to $24 per disk for 24 disks. The legal aspects of this are interesting. K. Landfield is probably one of the best experts on dealing with laywers on internet topics, and on copyright law & redistribution rights as they apply to Usenet. Interestingly, notably the highest traffic Usenet groups are purposely *omitted* from the disks based on copyright quagmires: >The following newsgroups are not supported due to legal reasons: > > alt.binaries.*, alt.sex.*, alt.toon-pics, alt.tasteless, > de.alt.binaries.*, fj.binaries.*, rec.arts.erotica BTW, the fact that semi- and wholly-pornographic material comprises a very large portion of Usenet traffic (see news.lists) makes the whole Usenet medium somewhat vulnerable to future legislative and public assaults. Remember that new NY Tax increase on telecommunications services I posted? The `conventional wisdom' is that it isn't very threatening, just a `sin tax' on the `phone sex' numbers. Now, look at how much of Usenet traffic is in lewd digitized pictures, and decide if smugness and complacency are maintainable! ===cut=here=== For orders, inquiries, and technical support, please contact : NetNews on CD's CD Publishing Corporation 4824 Fraser Street Vancouver, British Columbia Canada V5V 4H4 604-874-1430 800-333-7565 (USA) 604-874-1431 (FAX) Note: E-mail orders currently cannot be accepted. From ld231782 at longs.lance.colostate.edu Fri Sep 10 22:07:59 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Fri, 10 Sep 93 22:07:59 PDT Subject: offshore data havens, from RISKs Message-ID: <9309110500.AA05482@longs.lance.colostate.edu> OK, here's an *excellent* opportunity to get some cypherpunk exposure on RISKS. Amazingly, we haven't really been seen there before. I move that T.C. May or some other prominent cypherpunk write a letter representative of group interest and ideas on the subject. But anyone who feels they have something to say on the subject should pass on a letter to increase our chances of `getting published'. I would, but offshore data havens are not my niche. Everyone, *don't* argue about the specifics of the letter on the list -- we will never get it sent that way -- but suggestions are OK). then, in a segue (that's the *correct* spelling, Mr. P. `segway' Ferguson :) In the letter, consider talking about the Cypherpunks media exposure in NYT, Village Voice, Whole Earth, etc. However, if the c'punk mailing list is advertised, be *sure* to point out that its up to ~30 messages a day -- I think this helps alleviate spurious newcomers. I would recommend that the more anarchic aspects of the issue of Data Havens be glossed over, such as tax evasion, and just emphasize the non-threatening aspects such as digital cash, etc. so as not to startle all the fuddy duddies. I'm sure they will figure out the implications without any help from us. We do *not* want to come off as a cyberspatial terrorist organization (however close we may actually be :) Definitely, include a pointer to Chaum. Strike while the iron is hot! this is a mainstream opportunity for increased press exposure and attention to the cypherpunk cause. You'll notice the person inquiring is a reporter. chances are the articles he is referring to were cypherpunk-based. I wonder. Also, he *may* be writing an article and purposely not mentioning to avoid competition. ===cut=here== Date: Sun, 5 Sep 93 16:00:59 PDT From: John_R_Bruni at cup.portal.com Subject: Offshore Data Havens As a reader of RISKS who combines his vocation, journalism, with his avocation, computers, I'm writing in with a request. In the course of working on an assignment for one of the TV networks, I came across references to "offshore data havens." These are data networks, alleged to be in the formative process, which will glean data by means fair and foul from the world's legitimate data bases. The implication is that formerly confidential information, be it about individuals, corporations or governments, would seep across networks. The information would then be available, at a price, to anyone who wanted it. My questions are: * Are "offshore data havens" actually being formed, and if so, where? * What are the inherent problems that come to mind? Don't be afraid to state the obvious; television audiences aren't experts in this area. I'd love to see this become a topic for discussion on RISKS, but would also appreciate (with thanks in advance) any responses sent to me directly. john_bruni at cup.portal.com ------- End of Forwarded Message From mccoy at ccwf.cc.utexas.edu Fri Sep 10 22:13:50 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Fri, 10 Sep 93 22:13:50 PDT Subject: Digital warfare In-Reply-To: <9309110410.AA06849@servo> Message-ID: <199309110508.AA18091@tramp.cc.utexas.edu> Phile Karn writes: > I want to echo Carl's sentiments. I do find talk about cryptographically > enforced underground economies to be interesting, but scary as well > precisely because I'm afraid of what the backlash might do to the > cryptographically enforced personal privacy that I'm primarily > interested in. Unfortunately (or fortunately, depending on your position) the two are really inseperable; it is this fact above all others that I really think gives the people inside the beltway the willies when it comes to cryptography. Information has no morality and is subject to no rules save its own. It is kinda like money in that way... >:) If you have the ability to send message that is private there is nothing to prevent that message from being a digital cheque for payment of services. The "underground economy" is probably a lot larger than you would imagine, and given the current political climate you might be able to get a lot farther with the masses by telling them that digital money will give them the ability to tell the IRS where to stick thier noses than pretending it would never happen in the "crypto-enlightened age" and have an opponent bring it up as a point against strong crypto. The two are really inseperable and it seems to be of little value to pretend that they are not. jim From ld231782 at longs.lance.colostate.edu Fri Sep 10 22:53:50 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Fri, 10 Sep 93 22:53:50 PDT Subject: Digital warfare In-Reply-To: <199309110508.AA18091@tramp.cc.utexas.edu> Message-ID: <9309110548.AA06074@longs.lance.colostate.edu> Mr. McCoy of `strong cryptography' and `anarchy': >The two are really inseperable and it seems to be of little value to >pretend that they are not. that is, >If you have the ability to send message that is private there is nothing to >prevent that message from being a digital cheque for payment of services. >The "underground economy" is probably a lot larger than you would imagine, >and given the current political climate you might be able to get a lot >farther with the masses by telling them that digital money will give them >the ability to tell the IRS where to stick thier noses than pretending it >would never happen in the "crypto-enlightened age" and have an opponent >bring it up as a point against strong crypto. I think this is absolutely baseless. Cash is just as untraceable as a cryptographically encoded message. Have governments collapsed on the existence of cash? (well, there's this thing called inflation, but that's something else...) Do we really think that criminals will flourish if only they could get their hands on digital cash? don't criminals make a pretty ingenious use of all the rudimentary tools in use today? is lack of strong cryptography or digital cash preventing all kinds of sordid mischief, criminality, and terrorism? is the fate of the world teetering on the use of the RSA algorithm for [x] size keys or the ability to generate primes and factor numbers? Definitely, these new technologies will give rise to new *forms* of criminality, but the delicate ratio between `lawful citizens' and `evil violators' will assuredly always stay the same. Actually, truly powerful new technology, despite all the rampant and paranoid fears of the populace, has always inherently favored virtue and order in the long run. While I also find the anarchic talk on the list someone disconcerting and misguided, I find it ridiculous to claim that cryptography is a technology that is inherently conducive to anarchy or the deterioration of social order. It *is* conducive, however, to a new kind of government and order unlike any we've ever seen before, and unfortunately it will be so unlike anything in historical experience -- so unlike any `order' we've ever imagined -- that perhaps the crude term `anarchy' is the most apropos of all in our vocabulary. Bush was right on only one count in his characterization of `The New World Order' -- in supposing it exists. Otherwise, the cypherpunks take over the true vision. I *do* believe that we will see entirely new `taxation' systems with the advent of digital cash. It will just be exercised (or `excised') in different ways. We are likely to see mechanisms at the digital bank point for collecting a `transaction tax' (what a sales tax is today). We may also see the creation of `virtual governments' in which the geographical location of an individual is irrelevant to his choice of government, and perhaps for the first time in history the individual can choose freely among all those that exist, to that which best suits his preferences, and the so-called `social contract' between the citizen and his government is actually made *explicit* for the first time. This will all happen on some levels. But only the silly, pale bureacrats in the NSA attribute the Collapse of the World and the Plague of the BoogieMen to the advent and proliferation of strong cryptography. Cryptography is not synonymous with tax evasion, terrorism, or utter chaos. It is simply as neutral, powerful, and liberating as communication itself. In fact, for the first time we are beginning to realize what `communication' truly entails. From cme at ellisun.sw.stratus.com Sat Sep 11 00:18:51 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Sat, 11 Sep 93 00:18:51 PDT Subject: Digital warfare Message-ID: <9309110713.AA27885@ellisun.sw.stratus.com> >Message-Id: <199309110508.AA18091 at tramp.cc.utexas.edu> >Subject: Re: Digital warfare >To: karn at qualcomm.com (Phil Karn) >Date: Sat, 11 Sep 1993 00:08:37 -0500 (CDT) >From: Jim McCoy >The two are really inseperable and it seems to be of little value to >pretend that they are not. IMNSHO, whether they're inseperable or not, harping on anarchy is like advocating strong crypto so that terrorists can use it, ignoring all legitimate uses. It's the talk which plays into FBI hands, not the reality. The reality is here and can not be avoided but reality can't be cited in PR campaigns the way talk can. I know that drug dealers, terrorists and child molestors will use strong crypto. That doesn't mean that I cite such uses when I write letters to Congress or to magazine editors. I cite legitimate uses which the general public will applaud -- not the abberant uses which can not be avoided, no matter how draconian the legislation against crypto. It might be satisfying to point out to the government that they can't stop anarchists and criminals from using crypto but IMHO that would merely (1) anger them and (2) give them ammo for denying ligitimate users access to crypto. It might even be that that's what they want all along -- let the criminals have it and deny it to you and me. That way criminals identify themselves by passing random-looking bits between them. Have a nice day. - Carl From praveen at carina.unm.edu Sat Sep 11 08:24:07 1993 From: praveen at carina.unm.edu (Da Mystic Homeboy) Date: Sat, 11 Sep 93 08:24:07 PDT Subject: Digital warfare In-Reply-To: <9309110548.AA06074@longs.lance.colostate.edu> Message-ID: <9309111519.AA04072@carina.unm.edu> According to L. Detweiler: > >Mr. McCoy of `strong cryptography' and `anarchy': > >>the ability to tell the IRS where to stick thier noses than pretending it >>would never happen in the "crypto-enlightened age" and have an opponent >>bring it up as a point against strong crypto. > >I think this is absolutely baseless. Cash is just as untraceable as a >cryptographically encoded message. Have governments collapsed on the >existence of cash? (well, there's this thing called inflation, but >that's something else...) Actually, yes. Like it or not, most major transactions ever since probably the fifties, are not at all done in "real money". Its all existed as checks, credits, assets, etc. on some bank note somewhere, and now as ones and zeroes in the international info markets. Cash has become a *big* worry for governments nowadays because of the "shadow economy" thats developed with cash. Its completely untraceable, mostly unrecorded, and so the IRS (or any other government agency for that matter) has NO way to know whats Happening. The U.S. gova'ment is losing billions of dollars because of these transactions, and many people have seriously considered outlawing cash. What would happen if all our transactions become untraceable? How is the government supposed to prove anything, except by becoming fascist corporate fanatics (which is what is trying to happen right now). Better yet, if all our communications are in private, how are the information companies going to get their money? Whos going to have established credit- the very basis of our modern kapitalism? >Do we really think that criminals will >flourish if only they could get their hands on digital cash? don't >criminals make a pretty ingenious use of all the rudimentary tools in >use today? is lack of strong cryptography or digital cash preventing Up until about the 70s it was damn near impossible to enforce what the modern day fascists call the "drug war". This was because the world had not become superbly networked as it is, and so, any strange transactions or series of transactions could go virtually unnoticed. It was only in the eighties, with the microcomputer and increased interconnectivity, was it possible to catch, for example, money laundering. Yet, at the same time, for "criminals" it was pretty damn hard to communicate. So, what happens when you have all the freedom of privacy, and all the power of communication? The crash of the drug war and the governments spellbinding and gestapo-like control of the public. >powerful new technology, despite all the rampant and paranoid fears of >the populace, has always inherently favored virtue and order in the long run. Bzzzzt. Wrong again. All major technologies have only *increased* freedom, not the opposite. Technology has always caused more opportunity to think and to do, something that holders of power have never wanted you to do. Of course, it also depends on what you consider being virtue. Being a discordian/anarchist, I consider the chaos and freedom the virtue. >unfortunately it will be so unlike anything in historical experience -- >so unlike any `order' we've ever imagined -- that perhaps the crude >term `anarchy' is the most apropos of all in our vocabulary. Bush was Agreed, but cryptography IMNSHO, is a very strong step toward the natural progression towards true anarchy. >proliferation of strong cryptography. Cryptography is not synonymous >with tax evasion, terrorism, or utter chaos. It is simply as neutral, >powerful, and liberating as communication itself. In fact, for the >first time we are beginning to realize what `communication' truly entails. > Again, agreed. But, as you pointed out, the effects of communication is more often liberating than not. Such the same with crypto. The reason crypto is getting so much hype is because its the safety protection for communication- the true weapon against the powermongrels. From pmetzger at lehman.com Sat Sep 11 08:28:07 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sat, 11 Sep 93 08:28:07 PDT Subject: Digital warfare In-Reply-To: <9309110410.AA06849@servo> Message-ID: <9309111519.AA15630@snark.lehman.com> Phil Karn says: > I want to echo Carl's sentiments. I do find talk about cryptographically > enforced underground economies to be interesting, but scary as well > precisely because I'm afraid of what the backlash might do to the > cryptographically enforced personal privacy that I'm primarily > interested in. You have to accept that the tools for the one are the same as the tools for the other. Its reasonable to not want to emphasize both, but its unreasonable to assume that the enemy doesn't already know that both are done with the same algorithms. If this worries you, come up with your arguments now -- you will need them later. Perry From pmetzger at lehman.com Sat Sep 11 08:38:06 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sat, 11 Sep 93 08:38:06 PDT Subject: Digital warfare In-Reply-To: <199309110508.AA18091@tramp.cc.utexas.edu> Message-ID: <9309111532.AA15648@snark.lehman.com> Jim McCoy says: > If you have the ability to send message that is private there is nothing to > prevent that message from being a digital cheque for payment of services. > The "underground economy" is probably a lot larger than you would imagine, It is currently estimated that at least 10 MILLION people a year fail to file income tax returns, and that another 10 MILLION file returns that are partially or wholely fraudulent. The government would like you to believe that this is rare, so they don't make much of it, but the fact remains that your odds of being prosecuted for tax fraud or failing to file are miniscule. They pick famous people every year to go after like Leona Helmsley to get publicity, but they really don't have the resources to go after more than a couple thousand people a year. A large fraction of the economy in our country is completely underground already. > and given the current political climate you might be able to get a lot > farther with the masses by telling them that digital money will give them > the ability to tell the IRS where to stick thier noses than pretending it > would never happen in the "crypto-enlightened age" and have an opponent > bring it up as a point against strong crypto. This I disagree with. Even people who commit tax fraud every day are horrified by the notion of other people committing it. Its strange, but its a product of our "sanction of the victim" culture. The result of this is that even people who would in the back of their mind love to be able to commit tax fraud with no chance of being caught will not support infrastructure that makes it possible. This is not to say, though, that their support is needed. Countries around the world have turned tax evasion and secret banking into national industries. Look at the Swiss, for example. Computer networks will make private electronic funds transfer systems, and the capacity to take advantage of offshore banks, ubiquitous. The only way to stop it, even if it were to become illegal, would be massive tapping of all data transactions on a scale that could literally not be sustained without bankrupting the government. Imagine trying to hire a staff to monitor all binary data crossing international lines even at todays data rates -- then imagine if those rates went up by three orders of magnitude. Quite simply, whether governments like it or not, income taxation is pretty much doomed. Either they have to move to operating entirely on the level of tangible property and tangible consumption taxation, or they will starve. Perry From 72114.1712 at CompuServe.COM Sat Sep 11 09:13:07 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Sat, 11 Sep 93 09:13:07 PDT Subject: DIGITAL WARFARE Message-ID: <930911160347_72114.1712_FHF27-1@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cypherpunks, Yes, strong crypto can be used for "good or evil." That's true of any tool. And yes, dwelling on the darker applications may be politically counter-productive. But do any of you think that curtailing such discussions will slow up the enemies of privacy for one second? Strong crypto is a threat to the powers that be. Period. We know that, and so do they. The will find reasons to try and stop it. If necessary, they will *manufacture* reasons. They don't care about kiddie porn or terrorism; they care about their power base. And their power base depends on their ability to extract tribute. Strong crypto and international diversification undermine their ability to collect taxes. They are going to fight it no matter how innocuously we present ourselves. I do think we should emphasize *attributes*, not particular *applications*. People who need strong crypto will understand its potential. We don't have to draw pictures. As for the "negative" uses, don't worry, our enemies will gladly describe them. S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bill at twwells.com Sat Sep 11 10:13:07 1993 From: bill at twwells.com (T. William Wells) Date: Sat, 11 Sep 93 10:13:07 PDT Subject: Digital warfare In-Reply-To: <9309111519.AA04072@carina.unm.edu> Message-ID: I'm really glad I gateway this mailing list into a newsgroup. That way, I can killfile discussions such as this one. However, for those not so blessed.... From greg at ideath.goldenbear.com Sat Sep 11 10:39:02 1993 From: greg at ideath.goldenbear.com (Greg Broiles) Date: Sat, 11 Sep 93 10:39:02 PDT Subject: offshore data havens, from RISKs In-Reply-To: <9309110500.AA05482@longs.lance.colostate.edu> Message-ID: "L. Detweiler" writes: > OK, here's an *excellent* opportunity to get some cypherpunk exposure > on RISKS. Amazingly, we haven't really been seen there before. I move > that T.C. May or some other prominent cypherpunk write a letter > representative of group interest and ideas on the subject. But anyone If someone does write this letter, please don't represent the Cypherpunks list as being entirely composed of libertarians or (in Perry's words) "capitalist anarchists", whatever those might be. It seems counterproductive to me to enter into extended political debates here on the list, so I don't - but it's a mistake to assume that silence, in this case, constitutes agreement or consensus about deeper political issues. I think it'd be more accurate to represent the C-punks list as a group of folks with divergent political viewpoints who agree on the importance of personal privacy and see technology as a potential vehicle for acheiving or maintaining it. -- Greg Broiles greg at goldenbear.com Golden Bear Computer Consulting +1 503 342 7982 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764 From bill at twwells.com Sat Sep 11 12:08:09 1993 From: bill at twwells.com (T. William Wells) Date: Sat, 11 Sep 93 12:08:09 PDT Subject: Digital warfare In-Reply-To: <9309111519.AA04072@carina.unm.edu> Message-ID: In article , T. William Wells wrote: : I'm really glad I gateway this mailing list into a newsgroup. : That way, I can killfile discussions such as this one. However, : for those not so blessed.... Whoops. At least one person is imagining that I gateway this into some global newsgroup somewhere... What I'm using is a set of home-grown scripts to gateway the list into a local newsgroup. There's a mail to news gateway package out there that is probably a better solution. If you can't find it or would prefer my home grown scripts, let me know. I can send you that other software (though I haven't looked at it) or I can send you my scripts. There are also things like procmail and deliver that can be used to do this sort of thing. From nobody at soda.berkeley.edu Sat Sep 11 14:23:12 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Sat, 11 Sep 93 14:23:12 PDT Subject: Spooks reading the list Message-ID: <9309112115.AA04714@soda.berkeley.edu> pmetzger at lehman.com writes: >Its entirely possible that there are FBI agents on this list -- I >proceed on that assumption every day. Its also possible that there are >agents provocateur. However, I fully assure you that many of us are >legitimate anarchists of long standing, most of us being of the >capitalist anarchist persuasion. > >I'll fully agree that arguing for anarchy with the general public >won't work at the current time -- and I agree that our image is >like EFF and CPSR. I for one don't see any reason to hide my politics, >although I try not to make an issue of it. > >Perry In fact, there is at least one NSA agent on this list. Whether he/she is on our side or not, who knows? This message, a defense of the NSA, was posted here not long ago. I don't know if anyone else noticed this at the time, but take a look: *From: IN%"remail at tamsun.tamu.edu" 28-AUG-1993 06:02:47.29 *To: IN%"cypherpunks at toad.com" *CC: *Subj: NSA & the Crypto-Zionist Myth of "Public Key"! *>I'm rather surprised that the most significant piece of evidence in favor of *>the "NSA has cracked PGP" theory is that no one's put a bullet through Phil *>Zimmerman's head. * *Excuse me, but I'm getting tired of this silly paranoia. NSA *is not Evil Incarnate Central, and we are not fighting a Valiant War == We? WE! Do you suppose that was a Freudian slip, or did he mean to say it like that? Whoever he is, he works for the NSA. Did anyone else notice this at the time? So, tell us. Have they cracked PGP? *We Are Fated to Lose. The NSA are a bunch of Americans who went *to school & college with the rest of us, and share our communities *with us. Most of them joined NSA to fight totalitarian Communism, and *most of them are sympathetic with values most Americans share when they *bother to think about them, like freedom, privacy, etc. Sure, NSA has *been caught up in the Cold War habits of secrecy, bureaucracy, and *an ingrained habit to control information. It's also almost surely *caught up in the same kind of bureaucratic incompetence we see *in the rest of the U.S. Federal government (most of the DoD, the space *programs, the BATF, the FBI, etc.) Does a $40+ crypto-voice-chip with *an obvious trap door look like Malicious Plot to Destroy All Strong *Crypto and Take Over The World, or does it look like an *a half-competent, half-hearted attempt to retain Cold War era *capabilities they had gotten used to? * *NSA is going through the same crisis of goals as the rest of *the Cold War establishment. Their mission, if they have any left at *all, has changed radically, and they know it. While it *may be "in the best interest of NSA" to maintain control over *NSA employees are also Americans, community members, family *members, etc. They don't typically go around murdering hackers *they don't like. Nor would that accomplish anything for them -- *RSA was published internationally long ago, and PGP is now *scattered at sites all over the world, with new versions being *hacked on in nearly a dozen countries. * *The biggest problem I've encountered talking to various *people about implementing encryption is that they think *cypherpunks are a bunch of paranoid nuts, so only paranoids *would want to do things like use digital cash for their *semi-legal barter schemes. Your expression of surprise that *the NSA hasn't offed Phil Zimmerman just confirms their suspicions. *How can I convince them that cryptography is not just for paranoids? *The rest of us are concerned about things like protecting and *enhancing our privacy and freedom, and there's nothing silly *or paranoid about that. * *But now that you mention it -- Shamir does operate out of Tel *Aviv. Obviously he built RSA with a hole in it, and NSA is the *main arm of the Crypto-Zionist conspiracy of Jewish Planetary Hegemony! *And he didn't publish "Differential Cryptanalysis of the DES" until *non-Zionist bankers got ahold of DES. It's all clear now! * *> I think that, personally, the public-key stuff's gotta have some sort *> of a hole in it that nobody's thought of yet outside of spook central. * *I think your head has to have some sort of a hole in it. Perhaps the *NSA's work? >From the sound of this, the NSA is just a little bit testy! What's the matter, spook biz gone to hell in the post-cold-war era? We must be winning... :-) From lg2g+ at andrew.cmu.edu Sat Sep 11 18:18:13 1993 From: lg2g+ at andrew.cmu.edu (Liam David Gray) Date: Sat, 11 Sep 93 18:18:13 PDT Subject: Spooks reading the list In-Reply-To: <9309112115.AA04714@soda.berkeley.edu> Message-ID: [Here I quote nobody at soda who quotes remail at tamsun:] > *Excuse me, but I'm getting tired of this silly paranoia. NSA > *is not Evil Incarnate Central, and we are not fighting a Valiant War > == > > We? WE! Do you suppose that was a Freudian slip, or did he mean to > say it like that? Whoever he is, he works for the NSA. Did anyone else > notice this at the time? Nobody, when I read the original post I assumed the "we" you're talking about was 'we, the Cypherpunks.' I.e., if NSA were truly Evil Incarnate Central, the Cypherpunks would be fighting "a Valiant War ["We Are Fated to Lose"]". For a moment there, nobody, you nearly had me believing you. But read the rest of the post, and the above 'slip' becomes much less interesting: [Me quoting nobody at soda quoting remail at tamsun, again:] >*We Are Fated to Lose. The NSA are a bunch of Americans who went >*to school & college with the rest of us, and share our communities >*with us. Most of them joined NSA to fight totalitarian Communism, and >*most of them are sympathetic with values most Americans share when they >*bother to think about them, like freedom, privacy, etc. Sure, NSA has >*been caught up in the Cold War habits of secrecy, bureaucracy, and >*an ingrained habit to control information. It's also almost surely >*caught up in the same kind of bureaucratic incompetence we see ^^^^^^^^^^^^ ^^^^^^^^^^^^ The NSA is caught up in bureaucracy, so the Cypherpunks need not lose. >*in the rest of the U.S. Federal government (most of the DoD, the space >*programs, the BATF, the FBI, etc.) Does a $40+ crypto-voice-chip with >*an obvious trap door look like Malicious Plot to Destroy All Strong >*Crypto and Take Over The World, or does it look like an >*a half-competent, half-hearted attempt to retain Cold War era ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Cypherpunks are not fated to lose, because the NSA's attempts are fated to fail. >*capabilities they had gotten used to? [rest deleted] If you give me some time, I can contact the author of the original post -- remail at tamsun.tamu.edu -- and have him post a confirmation of my interpretation of his original post. /* for (i=0 ; i<2**64 ; i++) printf(":>"); */ Liam Gray - lg2g+ at andrew.cmu.edu From ferguson at fiber.sprintlink.net Sat Sep 11 18:38:13 1993 From: ferguson at fiber.sprintlink.net (Paul Ferguson x2044) Date: Sat, 11 Sep 93 18:38:13 PDT Subject: Proper context? Message-ID: <9309120229.AA10732@fiber.sprintlink.net> On Sat, 11 Sep 93 14:15:46 -0700, wrote - > In fact, there is at least one NSA agent on this list. Whether > he/she is on our side or not, who knows? This message, a defense of > the NSA, was posted here not long ago. I don't know if anyone else > noticed this at the time, but take a look: > > *From: IN%"remail at tamsun.tamu.edu" 28-AUG-1993 06:02:47.29 > *To: IN%"cypherpunks at toad.com" > *CC: > *Subj: NSA & the Crypto-Zionist Myth of "Public Key"! > *>I'm rather surprised that the most significant piece of evidence > *>in favor of the "NSA has cracked PGP" theory is that no one's put > *>a bullet through Phil Zimmerman's head. > * > *Excuse me, but I'm getting tired of this silly paranoia. NSA > *is not Evil Incarnate Central, and we are not fighting a Valiant War > == > > We? WE! Do you suppose that was a Freudian slip, or did he mean to > say it like that? Whoever he is, he works for the NSA. Did anyone else > notice this at the time? I went back through my archives and read this message; actually the context in which it was written could be construed that "we" is either party (NSA or Cypherpunks). After re- reading the remainder of his (or her) post, I think he's right for the most part. Messages containing hype (like yours, that I told myself I wasn't going to respond to) consist of much more paranoia than substance. Paul Ferguson | privacy \'pri-va-see\ n, pl, -cies; Mindbank Consulting Group | 1: the quality or state of being apart Fairfax, Virginia USA | from others 2: secrecy fergp at sytex.com | ferguson at icp.net | Privacy -- Use it or lose it. From doug at netcom5.netcom.com Sat Sep 11 18:53:13 1993 From: doug at netcom5.netcom.com (Doug Merritt) Date: Sat, 11 Sep 93 18:53:13 PDT Subject: Spooks reading the list In-Reply-To: Message-ID: <9309120147.AA02481@netcom5.netcom.com> Liam David Gray said: >Nobody, when I read the original post I assumed the "we" you're talking >about was 'we, the Cypherpunks.' I.e., if NSA were truly Evil Incarnate >Central, the Cypherpunks would be fighting "a Valiant War ["We Are Fated >to Lose"]". Righto. If you're going to be paranoid, you may as well read more carefully. The message in question was unambiguous; there were no Freudian slips in it. Like I said recently, the NSA wouldn't be doing their job if they weren't following an obvious list like this. But you can trust them not to be completely moronic. Information gatherers are likely to be complete lurkers, and if they go for agent provocateurs, they'll likely be selected and trained well enough to avoid IQ 80 slipups. I've known NSA employees and contractors in the past and present. Nothing regarding ultra secret work, else I'm sure I'd never have known about it, nor gotten involved, etc. But still, it's just another government agency, with a big budget, fingers in many pies, and with perhaps a higher than average individual and collective intelligence (no pun intended) from what I've seen. The NSA even goes to some open technical conferences; sometimes they even host one (on more mundane computer matters, of course). There's every reason to think that they're merely watching the situation to see what happens. I doubt if they've even seen reason to put other agencies like the FBI on alert. But if anything, if you want to be paranoid, be paranoid about folks like the FBI and SS and Justice Department. They'd be the ones to move in for the kill, you know, if anyone thought there was reason to do so. If you *must* be paranoid, just assume *I'm* from the NSA. I'll even claim to speak for them. (I'm fairly sure I won't be contradicted. ;-) Ok, here goes: "play nice, kids." There, a pronouncement from the heart of Evil Incarnate Central. :-) Doug From remail at tamsun.tamu.edu Sat Sep 11 22:28:16 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Sat, 11 Sep 93 22:28:16 PDT Subject: EC isn't great for privacy either... Message-ID: <9309120522.AA22336@tamsun.tamu.edu> > Wow! And "Gulp." I may have to get my European Community passport > sooner than I had planned. Does Martinique have a Net connection? Don't rush out to get your EC passport yet. Below I have included some exerpts from the EC Information Technology Security Document (ITSEC, aka Green Book). The referenced sections are from the "Confidentiality" section. I have put "..."'s where I have skipped over material and all upper case words are emphasis that I have added. For those who don't want to read it all, the gist of it is that the EC folks are also interested in maintaining the government's ability to intercept private communications. There is also talk about licensing businesses to use good confidentiality services. Btw. There is also a mention of PGP which I have left. Its the paragraph right before the one that mentions Clipper! --Begin Enclosure \subsection{Privacy enhancement issues} \subsubsection{Perception of requirements for privacy enhancement} \SeiLa{Issue} Confidentiality is, at times, essential for the good functioning of administrations, business and human relations. ... Most business and private users of communication systems are aware of the conflict between their confidentiality requirements and national security issues which require the possibility to intercept the communication in a way regulated by national laws. They accept the national authorities ability for this interception provided there are adequate safeguards to prevent unauthorised interception even by government employees. ... {\bf Service provision} The extent to which confidentiality services are provided for a specific business or citizen could depend on a system of LICENSES or certificates. A particular business might qualify for a CONFIDENTIALITY LICENSE depending on its internal procedures and activities. A general (minimum) level of confidentiality could be provided to all users. It should be possible for certain user groups or businesses to use other confidential services (egproprietary) than the standard ones provided. There are strong indications of emerging ``bottom up'' solutions for these needs (eg the Pretty Good Privacy offering on Internet, beginning 1993). Other initiatives (eg the announcement of the ``Clipper Chip'', 16 April 1993) illustrate the growing awareness of governments of the needs of their citizens for confidentiality services. ... If a public confidentiality scheme is offered, organised crime could also subscribe to such a scheme, but as it would include provisions for legal intercept, it would hardly be attractive. One would expect that such users would continue to find their own solutions as will the classified domain. An open and public service offering a credible level of confidentiality would therefore provide for the honest user, while not worsening the situation with respect to public order or national security. The combination of international communication and national security regulations require a common framework for confidentiality services, which on the one hand interoperate within all Community Member States as well as with countries outside the Community which themselves may establish their confidentiality services. This requires either an overlay approach or gateways which link the different national or regional services. These gateways are only required where multinational agreements for co-operation on national security concerns is not yet established. In this case these gateways may provide at least an interim solution. --End Enclosure From gnu Sat Sep 11 22:53:16 1993 From: gnu (John Gilmore) Date: Sat, 11 Sep 93 22:53:16 PDT Subject: RC2/RC4 were uninfluenced by NSA, says Ron Rivest Message-ID: <9309120550.AA26406@toad.com> I claimed that RC2 and RC4 were derived in a process that involved NSA asking that it be weakened in various ways. This was a deduction based on some apparently false information of mine. Ron has set me straight. Please forget what I told you about RC2 and RC4...mea culpa. John ------- Forwarded Message From: rivest at theory.lcs.mit.edu (Ron Rivest) Date: Fri, 10 Sep 93 16:52:35 EDT Message-Id: <199309102052.AA02268 at swan.lcs.mit.edu> To: gnu at toad.com Subject: Crack DES in 3.5 hours for only $1,500,000! Hi John -- Glad to see you're high-lighting Wiener's work; I think it is very important that people see it... Re RC2 and RC4: NSA had absolutely no influence on the design of either algorithm; they are entirely of my own creation. I'll take the credit for their strengths, or the blame for their faults. Please take the trouble to correct any misimpressions you may have given people. (I don't know who you sent your mail to...) I have no information on what sort of brute-force attack machines NSA has in its basement, but it is certainly the case that, as I said before, nothing in either design was affected by NSA or its capabilities. These algorithms are designed to be very good algorithms, but with a variable key-size, so that you could try to get out of NSA the biggest key size you could for export. I really don't like your spreading false information about my work, and wish you would take the simple step of talking to me first; I'll be happy to talk to you. (Feel free to repost this, in its entirety...) Cheers, Ron Rivest ------- End of Forwarded Message From ld231782 at longs.lance.colostate.edu Sat Sep 11 23:04:11 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sat, 11 Sep 93 23:04:11 PDT Subject: EC proposes PRIVACY LICENSES In-Reply-To: <9309120522.AA22336@tamsun.tamu.edu> Message-ID: <9309120558.AA09019@longs.lance.colostate.edu> [anonymously quoted EC policy proposal] >A particular business might qualify for a CONFIDENTIALITY LICENSE >depending on its internal procedures and activities. A general >(minimum) level of confidentiality could be provided to all users. THE HORROR! *this* is Orwellian. *this* is how to outlaw cryptography. we need some ECypherpunk infiltrators ASAP! Whoever posted this -- can you post more information on where it was contained to sci.crypt or alt.privacy.clipper, so that we can get a wider audience? there are probably plenty of Europeans who don't know about this but should! We need a contact to report to the list! I speculated on the list some time ago the efforts by NSA to get Clipper to be an *international* standard. I suggested that the Britain GCHQ would be the first to endorse it publicly. Sounds like the EC may beat them to the punch. Was NSA lobbying involved here, or did they just pick up on this great idea ? Also, where was it [Norway?] that lady posted from saying that their national secret service was pushing a proposal for cryptographic use similar to Clipper? In one word, YIKES From remail at tamsun.tamu.edu Sat Sep 11 23:08:16 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Sat, 11 Sep 93 23:08:16 PDT Subject: warez Message-ID: <9309120601.AA24357@tamsun.tamu.edu> Some recent "warez" posts from alt.security.... Newsgroups: alt.security Path: netcom.com!netcomsv!decwrl!olivea!sgigate!sgi!wdl1!mail!klaus From: klaus at lds.loral.com (Christopher Klaus) Subject: software piracy lists (correction) Message-ID: <1993Aug16.201509.24808 at lds.loral.com> Organization: Loral Data Systems Date: Mon, 16 Aug 1993 20:15:09 GMT Lines: 41 Okay, I got some email flaming me for making accusations about these 'warez' lists. Apparently, not all the sites in the lists contained actual warez due to the list being outdated and as the list said it contained some sites that were beneficial to software pirates but didnt contain any warez. I guess if someone wants to stress that because some of the sites werent infact a warez site, that the lists I published werent actual warez lists. Thats fine. So next time, Ill say this list MAY contain sites that support warez, but these are not actual warez lists. I hope that helps someone. If you are the one complaining about not going through the list and emailing each of the sites about the possibility of a warez site, write a script for me. :) I am not going to work overtime to track down the evils of the net. I dont have time to check 400 sites if they are valid for warez. Apparently quite a few sites must have had actual warez, otherwise Anti-track and other pirates would not have been irate about such lists if it didn't contain any 'warez sites'. I find it ironic that many of the admins complained the lists were outdated and useless (maybe they have access to better lists than me) while the pirates complained it was one of the best lists ever produced. In publishing those lists, my point was that there is an organized crime on Internet that maybe some admins should be aware of. I do not believe by publishing those lists that much piracy has been crushed on Internet. As far as the guys saying how insecure fsp and ftp is because it is so easy for an admin to look at network statistics and notice the large amounts of traffic for software piracy, I find it funny those so much pirating is done without admins ever noticing. And it usually gets noticed because of lack of hard drive space, not amount of network traffic. And when 200 users are using some LAN, I really doubt you would notice an enmormous jump in network traffic anyways, due to people ftp'ing all the time as it is. Not to mention it would be rather hard to find out what kind of network traffic is going through all the ports, without violating the privacy of the users. -- Christopher Klaus klaus at mail.lds.loral.com cklaus at hotsun.nersc.gov Newsgroups: alt.security Path: netcom.com!csus.edu!decwrl!decwrl!olivea!charnel!rat!usc!sdd.hp.com!nigel.msen.com!yale.edu!yale!mintaka.lcs.mit.edu!coup From: coup at gnu.ai.mit.edu (Christopher Klaus) Subject: warez list2 Message-ID: <1993Aug11.200800.20903 at mintaka.lcs.mit.edu> Sender: news at mintaka.lcs.mit.edu Organization: Free Software Foundation Date: Wed, 11 Aug 1993 20:08:00 GMT Lines: 247 Here's another list found in some /tmp of warez dood sites.. Please Inform me if U have sites/info not on this list And Any Updates To: an874 at anon.penet.fi (irc: semi) (Please use same format in msg as I use on list so it s easy to update.) So If there is not you anonymous mail address on this list get one and tell it to me.. Also I allways love to receive sites info and also I like to get info about realiable users as well as "antipirates". Soon I start working with WarBot and #site in irc but I tell 'bout that later -semi FSP:**Address***********Port****Extra****************************************** FSP: 128.113.75.10 6611 FSP: 128.153.16.175 7777 FSP: 128.174.240.63 21 Vampyr Central magnus.cs.uiuc.edu FSP: 128.174.80.13 900 FSP: 128.178.79.121 6969 Corvin FSP: 128.183.8.31 21 FSP: 128.192.7.51 21 ada.stat.uga.edu FSP: 128.2.206.138 30 seismo.soar.cs.cmu.edu FSP: 128.252.135.4 21 wuarchive.wustl.edu FSP: 128.3.252.177 9030 Lankhmar Extension FSP: 128.32.155.3 9999 FSP: 128.55.128.90 11111 FSP: 128.95.48.32 2468 byron.u.washington.edu FSP: 128.96.32.20 21 flash.bellcore.com FSP: 129.10.50.137 2121 vlsi37.coe.northeastern.edu FSP: 129.125.6.206 6669 shapley.astro.rug.nl cray/amiga FSP: 129.186.10.20 5200 naf1.zool.iastate.edu Was on 42 FSP: 129.186.123.140 1992 pv7b8c.vincent.iastate.edu FSP: 129.186.141.241 1992 marge.ecss.iastate.edu FSP: 129.186.141.242 1992 marge.ecss.iastate.edu FSP: 129.186.4.31 2992 pv041f.vincent.iastate.edu FSP: 129.186.8.27 6969 The Ninth Level FSP: 129.215.64.60 7000 FSP: 129.240.21.38 8080 FSP: 129.79.1.15 3000 FSP: 130.179.25.31 6611 newton.amath.umanitoba.ca Slow IBM FSP: 130.225.51.19 11111 FSP: 130.49.4.17 21 Good IBM FSP: 130.84.144.190 7373 FSP: 131.151.1.57 4321 cetus.cc.umr.edu FSP: 131.155.2.49 6669 and on 1200 FSP: 131.170.24.42 6669 yallara.cs.rmit.oz.au FSP: 131.174.224.37 6669 FSP: 131.215.131.148 21 FSP: 131.215.131.148 21 mosaic.cs.caltech.edu FSP: 131.215.131.97 21 ipsc2.caltech.edu and on 5200 \? FSP: 131.229.64.1 2112 Shifty FSP: 132.205.9.100 2711 FSP: 132.235.1.242 21 brandx.cs.ohiou.edu FSP: 132.254.90.4 4444 IBM part closed FSP: 134.148.96.105 21 pleiades.newcastle.edu.au FSP: 134.154.1.10 1756 Aladdin FSP: 134.225.11.1 5190 FSP: 134.225.11.1 5431 FSP: 134.225.11.1 5432 FSP: 134.225.11.1 7351 FSP: 134.225.11.1 8814 FSP: 134.225.4.2 4389 swsscsc2.rdg.ac.uk FSP: 134.225.5.1 4321 scsscsc1.rdg.ac.uk FSP: 134.29.41.1 1121 hobbes.ESCI.StCloud.MSUS.EDU FSP: 134.48.17.13 666 Jims Site FSP: 134.68.6.2 2911 Ethome FSP: 134.68.6.2 3911 FSP: 134.68.7.60 911 FSP: 134.68.7.90 911 FSP: 137.122.6.17 2001 The Bat Cave FSP: 138.23.106.203 6666 FSP: 140.114.26.90 199 Good IBM FSP: 140.114.78.214 21 sunc14.cs.nthu.edu.tw Good IBM FSP: 141.215.69.5 21 FSP: 143.53.240.1 6996 muser.brad.ac.uk FSP: 146.232.108.2 4999 Amiga FSP: 146.232.128.2 6969 cs.sun.ac.za FSP: 150.203.43.50 3333 mehta.anu.edu.au FSP: 150.203.5.31 4455 caesar.anu.edu.au FSP: 152.17.30.2 2766 Slow one FSP: 158.38.60.202 3000 FSP: 158.39.30.24 21 hannibal.hsn.no FSP: 18.172.1.2 21 tsx-11.mit.edu FSP: 192.131.107.5 8564 bart.meiko.com FSP: 192.48.98.1 6669 poly.polytechnique.fr FSP: 192.70.34.205 6678 eurecom5.cica.fr FSP: 192.76.134.1 11111 mcshh.Hanse.de FSP: 192.76.144.75 2001 ftp.germany.EU.net FSP: 192.87.1.150 9999 The Adventure Pit FSP: 193.78.33.42 7549 FTP:**Address*******************Type****Directory************************** FTP: 128.193.124.2 Warez /pub/submit/"..." FTP: 128.36.13.1 DEAD /pub/haskell/library/incoming/" " FTP: 129.43.1.11 Warez /pub/incoming/. unreadable FTP: 129.6.32.54 Warez /upload/".. " FTP: 141.138.2.2 DEAD /pub/uploads/for.gross/".. " FTP: 141.212.32.53 DEAD /pub/../". unreadable"/.bi.n FTP: 147.26.103.14 DEAD /pub/incoming FTP: 179.259.37.10 DEAD /warez/". ,"/pc FTP: 36.10.0.4 Warez /pub/... (e) FTP: Sun.soe.clarkson.edu DEAD /pub/incoming/"..."/.f FTP: W20-575-67.mit.edu Warez /pub/".. " (Dos6.0, Os2 Site) FTP: a.cs.uiuc.edu DEAD /tmp/reddy/papers/".. "/.bin FTP: apollo.di.unipi.ti DEAD /pub/".. "/.bin FTP: athena.erc.msstate.edu DEAD /pub/seger/".. " FTP: athena.erc.msstate.edu DEAD /pup/off-theses-ps/".. "/.bin FTP: aun.uninett.no DEAD /gopherfiles/tmp/gftpC+/"..." FTP: cs.ep.utexas.edu DEAD /pub/reports/xfer/incoming FTP: cs.tut.fi DEAD /pub/tut/testing/confocal/.bin/.zip FTP: delphi.cs.ucla.edu /incoming/" "/". bin" FTP: dix.gps.caltech.edu /pub/... FTP: doppler.ncsc.org /pub/siggraph/uploads/... FTP: elof.iit.edu /.NeXT/... FTP: elof.iit.edu DEAD /pub/drum/incoming/".. "/b.i.n FTP: emil.ma.utexas.edu /gif/.../ FTP: emil.ma.utexas.edu /incoming/.../ FTP: faui80.informatik.uni-erlangen.de /pub/asl/".. " FTP: faui80.informatik.uni-erlangen.de /pub/asl/.. FTP: faui80.informatik.uni-erlangen.de /pub/scheme/yorku/new/... FTP: fcs280s.ncifcrf.gov Warez /pub/incoming/". unreadable" FTP: fourcroy.chem.wayne.edu SCOUnix /pub/unix/sco FTP: fourcroy.chem.wayne.edu Warez /pub/incoming/".message "/.bin FTP: ftp.brad.ac.uk WAREZ /incoming/msdos/".. " FTP: ftp.cayman.com DEAD /pub/users/john/ibmpc FTP: ftp.cs.umn.edu GIF /users/grante/incoming/... FTP: ftp.psi.com DEAD /tmp/".. "/". unreadable"/..f FTP: ftp.uu.net /library FTP: ftp.uu.net /published/usenix/faces FTP: gatekeeper.dec.com /.2/micro/sysv-386/uportlaCk FTP: geom.umn.edu Warez /incoming/". unreadable"/ (visual c++) FTP: guardian.cs.psu.edu /pub/mosis/ugrain/... FTP: gumby.cc.wmich.edu DEAD /pub/incoming/". unreadable"/". "/ FTP: hub.cs.jmu.edu DEAD /incoming/".. "/". unreadable" FTP: huron.scd.ucar.edu Warez /weather/CO_ski.obs/... FTP: hydra.helsinki.fi Warez /incoming/". unreadable" FTP: j.cc.purdue.edu /pub/deTex/.../ FTP: kanaha.idbsu.edu /incoming/... FTP: kanaha.idbsu.edu /pub/NOBS/flip/... FTP: lamont.ldgo.columbia.edu /nceer/data/".. " FTP: lamont.ldgo.columbia.edu /nceer/data/... FTP: louie.udel.edu /incoming/.../ FTP: mango.rsmas.miami.edu DEAD /incoming/.../.../ibm/.zip FTP: math.princeton.edu Warez /pub/deTex/".. " FTP: math.utexas.edu /incoming/djgpp/... FTP: math.utexas.edu /pub/mp_arc/... FTP: math.utexas.edu /pub/mp_arc/abstracts/... FTP: math.utexas.edu /pub/mp_arc/doc/... FTP: math.utexas.edu /pub/mp_arc/papers/... FTP: math.utexas.edu Warez /incoming/".. " FTP: math.utexas.edu Warez /incoming/klaus/haken3/... FTP: mcnc.mcnc.org /pub/4kk/... FTP: ncar.ucar.edu /pc/virus/".. " FTP: nexus.yorku.ca /pub/scheme/new/... FTP: nic.stolaf.edu /pub/sci/... FTP: nic.stolaf.edu /pub/tmp/... FTP: omnigate.clarkson.edu DEAD /pub/gw/dump/.../.f FTP: osceola.cs.ucf.edu DEAD /amar/.../I/f FTP: park.bu.edu DEAD /pub/incoming/" "/.b.in FTP: park.bu.edu DEAD /pub/incoming/dt.bak/.b.in FTP: phoenix.oulu.fi /pub/incoming/"misc.zip "/"... " FTP: phoenix.oulu.fi DEAD /pub/incoming/"misc.zip " FTP: picard.uakron.edu /NetInfo/NeXT/" "/".. "/ FTP: potemkin.cs.pdx.edu Warez /pub/ileaf/incoming/".. " FTP: psuvax1.cs.psu.edu /pub/mosis/ugrain/... FTP: quayle.mu.wvnet.edu DEAD /pub/pc/uploads/.../.zip (no anon.) FTP: rascal.ics.utexas.edu /misc/... FTP: rascal.ics.utexas.edu /misc/av/safety-folder/... FTP: rascal.ics.utexas.edu /misc/mac/... FTP: raven.alaska.edu Warez /pub/".. " FTP: sachiko.acc.stolaf.edu /pub/tmp/... FTP: sesqui.net /pub/incomming/".. " FTP: sifon.cc.mcgill.ca DEAD /pub/in.coming/_..___/__________ FTP: solar.stanford.edu DEAD /pub/"..."/.f FTP: solbourne.solbourne.com /pub/uploads/for.gross/incoming/... FTP: sonata.cc.purdue.edu /pub/next/submissions/multi-media FTP: sonate.cc.purdue.edu Warez /pub/next/multi-media^A FTP: sperm.ocean.washington.edu /pub/matter/" "/" " FTP: sperm.ocean.washington.edu DEAD /pub/matter/" " FTP: sun.soe.clarkson.edu /pub/incoming/... FTP: sun.soe.clarkson.edu /pub/src/flex/.." " FTP: sunbcd.weizmann.ac.il DEAD /pub/incoming/".. " FTP: suntan.tandem.com /pub/... FTP: thor.cs.wayne.edu DEAD /pub/.warez FTP: transit.ai.mit.edu /incoming/... FTP: uhunix2.uhcc.hawaii.edu /mirrors/gnu FTP: unmvax.cs.unm.edu /pub/jensen/.bin/.zip FTP: uvaarpa.virginia.edu /public_access/aa/.find/". " FTP: venera.isi.edu /pub/wuu/tmp/".. " FTP: wlv.iipo.gtegsc.com /pub/... FTP: zaphod.lanl.gov /pub/clim/incoming/ USER:**Irc Nick*********Email********************************************** USER:+ (not in irc) an31 at anon.penet.fi USER:+ Amp (No Email) USER:+ Ap0ll0 an19159 at anon.penet.fi USER:+ Bin ap.9416 at cupid.sai.com USER:+ BloodSlop csc226117 at husky1.stmarys.ca USER:+ BosStone an19426 at anon.penet.fi USER:+ DDay (Not Yet) USER:+ Darion an18877 at anon.penet.fi USER:+ Dekion an18796 at anon.penet.fi USER:+ Eddie (Not Yet) USER:+ Fidelio an19045 at anon.penet.fi USER:+ Flognat an14231 at anon.penet.fi USER:+ GreenDay an18894 at anon.penet.fi USER:+ Ignotus an17295 at anon.penet.fi USER:+ JizMak (Not Yet) USER:+ MasNinja (Not Yet) USER:+ PurpCon (Not Yet) USER:+ Q_Silver an19169 at anon.penet.fi USER:+ RalfiBoy an19218 at anon.penet.fi USER:+ RedOne (Not Yet) USER:+ Robinn (Not Yet) USER:+ S-Lord an19288 at anon.penet.fi USER:+ Slick (Not Yet) USER:+ Snarf snarf at oulubox.tolsun.oulu.fi USER:+ Sp0t (Not Yet) USER:+ TBoard an19155 at anon.penet.fi USER:+ TI_Master an15612 at anon.penet.fi USER:+ TWC an19455 at anon.penet.fi USER:+ TWicked an19576 at anon.penet.fi USER:+ Zip (Not Yet) USER:+ semi an874 at anon.penet.fi XTRA:*Id**User*Description**************************************************** XTRA: + - User is Real (Pirate) XTRA: - - User Is Antipirate *BEWARE* XTRA: ? - Unknow user ps. If U have idea how to make this list look better or any idea at all about this "thing" just send me mail.. I just love to receive mail ;) Pss. If Someone wants his name on this list and also want to receive this my list regualy every time it get chanced, PLEASE don't tell me that in irc, just send me e-mail with: irc nick, anonymous mail address and real mail address. (and if U would tell in same message that where U get this list, you will be in my list very soon). Newsgroups: alt.security Path: netcom.com!csus.edu!decwrl!decwrl!olivea!charnel!rat!usc!sdd.hp.com!nigel.msen.com!yale.edu!yale!mintaka.lcs.mit.edu!coup From: coup at gnu.ai.mit.edu (Christopher Klaus) Subject: warez list Message-ID: <1993Aug11.200142.20536 at mintaka.lcs.mit.edu> Sender: news at mintaka.lcs.mit.edu Organization: Free Software Foundation Date: Wed, 11 Aug 1993 20:01:42 GMT Lines: 259 Hello. I happened to look at /tmp in some major ftp site and found some interesting files. Anyways, I know CERT has sent out a advisory already on FTP abuse. But they didnt really address the FSP sites either. I dont know much about the IBM scene nor care, but I figure maybe some of the admins would like to investigate this list and maybe clean up their sites if they are on it and it hasnt been cleaned up. Maybe the SPA can get involved if someone so desires. Here's the list. __/__/__/__/__/ __/ __/ __/ __/ __/ __/__/ __/__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/__/ __/__/__/ __/__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/__/ __/__/ The Little Tikes Software Co proudly presents the most comprehensive and complete Warez Information available on the Internet Last revision: 930721 =========== WARNING!!!! =========== THIS LIST SHOULD BE KEPT AMONG SITE OPERATORS ONLY!!! If you wish to make a more public version of this file, be sure to remove all information about site operators, IRC bots & servers. Please direct any update information or comments to Tikes and send flames to 127.0.0.1 ---- NOTE ---- >From now on, you'll have to request me the list, I won't automatically dcc it to U when it is updated... Information =========== This file contains many sections: FTP Sites List of all sites that has been or are warez active FSP Sites List of all sites that has been or are warez active Legal Sites List of usefull sites... other than warez IRC Alternate servers used primarly for Warez "hiding" IRC Robots IRC robots Operators List of all has been or actually involved in warez FTP Sites ========= Notes: C)losed, P)password changed, D)irectory changed ?) Status unknown anonymous/@ indicates "normal", lamer, dumb anonymous login user/pass@ indicates a normal user login account... anonymous/[ip] indicates only specific ip's can connnect anonymous/[nick] indicates only nick at ip can connect (developed by Tikes for is modified/enhanced FTP server) C anonymouys/@thyme.lcs.mit.edu 18.26.0.115 930717 /pub/jrd/". "/binary ------------------------------------------------------------------------------- C anonymous/@ 36.10.0.4 930715 Empty ------------------------------------------------------------------------------- C anonymous/[nick]@henry 128.95.42.28 Lawn 930609 ------------------------------------------------------------------------------- C daniel/herschel at rayleigh.ee.washington.edu 128.95.31.245 Ano/Pengo 930712 Gateway 2000 "/rayleigh/home/daniel/.. / /.w" ------------------------------------------------------------------------------- C anonymous/@geom.umn.edu 128.101.25.35 930715 incoming/".. "/.b.in ------------------------------------------------------------------------------- C alien/delete1 at salmon.micro.umn.edu 128.101.193.121 930715 SunOS 4.1 Warez ------------------------------------------------------------------------------- C anonymous/@math.princeton.edu 128.112.128.157 930715 /pub/fycfung/baezpapers/". . ."/.bin ------------------------------------------------------------------------------- C anonymous/@bruno.cs.colorado.edu 128.138.243.151 930715 /pub/cs/doc/.NextTrash/"^L"/progs ------------------------------------------------------------------------------- P dhb/stratton at leach.cs.rit.edu 129.21.41.7 930715 ------------------------------------------------------------------------------- C anonymous/[nick]@ 129.22.64.1 Rocks 921330 ------------------------------------------------------------------------------- C anonymous/[nick]@ 129.22.64.6 Rocks 930609 ------------------------------------------------------------------------------- anonymous/@ub.es (arrima) 130.206.15.53 an16480 at ub.es 930721 /incoming/".bin. " ------------------------------------------------------------------------------- P m90-scj/lingonris at trisse 130.241.220.2 Leinad 930330 ------------------------------------------------------------------------------- P m92-axb/ljulklapp at trisse 130.241.220.2 Leinad 930318 NetWare v3.11 /tcs/swap ------------------------------------------------------------------------------- softsite/quandry at vtan 131.104.136.26 930720 IBM OS/2 TCP/IP FTP ../[IBM|AMIGA|DOCS|NEW] ------------------------------------------------------------------------------- C anonymous/[ip]@mirage.unipv.it 131.175.45.34 Clint 930420 Private /incoming/" "/is ------------------------------------------------------------------------------- anonymous/[ip]@roxette.mty.itesm.mx 131.178.15.100 NetShadow 930721 Empty... setting things up, don't ask for access ------------------------------------------------------------------------------- C anonymous/[nick]@tdsb-s.mais.hydro.qc.ca 131.195.163.5 TheCamel 930715 ./private ------------------------------------------------------------------------------- anonymous/[nick]@tdsb-s.mais.hydro.qc.ca 131.195.163.5 Tikes 930718 On invitation only, don't ask ./private Site operators only, validate nick at host, so don't bother trying to log ------------------------------------------------------------------------------- C anonymous/@hobiecat.pcmp.caltech.edu 131.215.131.167 930715 pub/dropoff/tar.Z/".. "/.bin ------------------------------------------------------------------------------- ftp/warez at gena 132.68.64.49 Gena/Freezer 930721 This site will close soon ./[incoming,warez] Replaced by 132.74.3.50 ------------------------------------------------------------------------------- proba/epson@ 132.74.3.50 Gena/Freezer 930721 ./warez ------------------------------------------------------------------------------- C anonymous/@plains.nodak.edu 134.129.111.64 930721 No space! /pub/tandy/incoming/".. "/.b.in Permission denied in dir /pub/tandy/incoming ------------------------------------------------------------------------------- anonymous/@fsa.cpsc.ucalgary.ca 136.159.2.1 930721 pub/sschurch/[.b...in,.r...eq] ------------------------------------------------------------------------------- C slucas/richmond at powhatan.cc.cnc.edu 137.155.10.10 930712 ". " ------------------------------------------------------------------------------- P c880148/kurilin at asterix.fi.upm.es 138.100.8.6 930330 Slow link... ------------------------------------------------------------------------------- C wizard/hhhew@ 140.113.215.192 930330 ------------------------------------------------------------------------------- C ftp/ylin@ 140.114.26.90 marfada9 930330 /pub ------------------------------------------------------------------------------- C ftp/maolong4 at cobra 140.114.76.203 babuu 930609 ------------------------------------------------------------------------------- P Ether/amadeus@ 140.117.73.1 930719 ------------------------------------------------------------------------------- P abc/trantor at cca.pue.udlap.mx 140.148.3.18 930712 ------------------------------------------------------------------------------- P adela/avatar!@goren.u.washington.edu 140.142.63.1 Ano/Pengo 930709 /". "/". " ------------------------------------------------------------------------------- georgias/fuk!it at honeydew.cc.wwu.edu 140.160.240.29 A-Flat/blazer 930721 ".^t./^t^l.^l^t"/.real ------------------------------------------------------------------------------- ? anonymous/@ 141.201.1.16 930720 Always connection time-out... pub/local/peter/upload/.bin ------------------------------------------------------------------------------- C ftp/@apache.telebit.com 143.191.3.1 930712 /tmp/".. "/.bin ------------------------------------------------------------------------------- Scum/sux2bu@ 152.94.21.8[15] Croc 930720 Running on a PC, often down... Biggest site! ------------------------------------------------------------------------------- C stress/waterloo at unix1.mrih.no 158.38.66.44 berol 930527 Closed while Berol is in the army... Heard some1 else is supposed to take the flame... ------------------------------------------------------------------------------- C zip/merlin at uropax 192.109.39.2 930718 Empty tmp/[unknown dir] ------------------------------------------------------------------------------- anonymous/@netcom4.netcom.com 192.100.81.107 930721 Still empty... asking 4 uploads! /pub/tal/.warez Loggin message says everything is logged... be carefull... README message says it's run by sysadmin... Would sure like to know who run this site! ------------------------------------------------------------------------------- FSP SITES ========= ? Mirage 132.68.48.173 3000 Outrun 930712 ------------------------------------------------------------------------------- ? NetShadow 131.178.15.100 5555 NetShadow 930712 Registration required ------------------------------------------------------------------------------- Legal Sites =========== ? vendor/microsoft@ 137.39.1.9 930712 Host unreachable ------------------------------------------------------------------------------- IRC Servers =========== C mecca.epri.com 144.58.65.48 7777 930712 ------------------------------------------------------------------------------- C picard.cc.umanitoba.ca 130.179.25.28 7777 930712 ------------------------------------------------------------------------------- ? roxette.mty.itesm.mx 131.178.15.100 7777 NetShadow 930720 ------------------------------------------------------------------------------- IRC Robots ========== WarezCat TommydCat 930718 [de]op/ban/kick/invite/dcc... mirror fsp site titan.ucc.umass.edu 2112 ------------------------------------------------------------------------------- C Shadow Elminster 930720 Initializing... not ready for use Due to the way Elminster is actying in #warez... he won't be "trusted" anymore (mass deop/mass kick/lame acting etc...) ------------------------------------------------------------------------------- Operators ========= A-Flat Ano Babuu Blazer Clint Croc Freezer Gena Lawn Leinad marfada9 NetShadow Outrun Pengo Rocks TheCamel Tikes TommydCat ---- thats it. Newsgroups: alt.security Path: netcom.com!netcomsv!decwrl!concert!news-feed-1.peachnet.edu!umn.edu!gold1.tc.umn.edu!werm0004 From: werm0004 at gold1.tc.umn.edu (Angela M Wermager-1) Subject: Pirate FSP Sites Message-ID: Sender: news at news.cis.umn.edu (Usenet News Administration) Nntp-Posting-Host: gold1.tc.umn.edu Organization: University of Minnesota Date: Mon, 16 Aug 1993 03:47:58 GMT Lines: 58 The following is a list of pirate FSP sites that I found in a user's account. I'm tired of having good bandwidth wasted by these software pirates. Would the appropriate agencies please take action against these scumbags? 180.212.61.199 31960 222.140.22.199 29351 112.251.164.94 30509 178.46.139.97 29452 122.94.93.72 11147 115.70.211.71 25732 135.85.44.229 16748 208.53.116.129 6858 163.189.180.38 3968 220.38.200.43 18558 208.7.218.73 23081 215.56.205.245 16858 186.252.0.138 7897 150.87.225.114 25469 116.82.74.146 19782 163.156.183.73 9784 202.28.148.90 12403 163.75.35.150 2098 103.110.27.119 30571 159.126.64.33 14246 169.163.3.17 8828 108.160.185.177 25120 248.175.119.118 8108 155.166.204.122 30757 191.24.223.240 31054 158.249.125.72 3576 180.85.59.93 31163 227.182.122.244 24240 135.41.109.38 5353 130.38.161.96 26739 200.32.35.177 27379 154.115.43.187 4720 250.155.87.134 20768 129.6.188.140 31107 152.52.224.120 11424 109.117.244.14 2852 181.72.235.229 22946 238.200.217.234 17017 135.27.77.38 6735 214.48.7.180 28877 211.119.138.107 30907 237.226.117.171 1081 194.185.133.12 10177 237.146.147.156 1673 223.28.192.163 15270 132.5.71.19 22793 203.154.231.9 5531 174.48.89.148 6950 119.0.50.44 5948 162.224.220.95 22302 185.243.66.69 15931 104.173.5.70 30427 From ld231782 at longs.lance.colostate.edu Sat Sep 11 23:43:17 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sat, 11 Sep 93 23:43:17 PDT Subject: fwds from RISKs Message-ID: <9309120637.AA09563@longs.lance.colostate.edu> - Clinton administration eases Cold war era controls on export of supercomputers to Soviet bloc countries - mainstream article on digital signatures in The Sciences - European secure phone & network advertisement there's a pointer to Islands in the Net by B. Sterling for `offshore data havens' and some other notes there, not included. points: - remember that DEC machine that was taken off the net because of problems with the state department restricting computer access to `foreign nationals'? will anything like this ever happen again? - public comprehension of digital signatures is definitely a necessary stepping stone to digital cash in the collective psyche. A positive sign. - secure phones: was the EC policy recently quoted here affected by this? anyone in Europe threatened by that proposal should look into this. ===cut=here=== RISKS-FORUM Digest 15.03 Date: 27 Aug 93 15:05:53 EDT From: "Mich Kabay / JINBU Corp." <75300.3232 at compuserve.com> Subject: Technology export curbs >From Washington Post newswire 08/27 U.S. Acts to Ease Export Controls On Computers; Industry Officials Say Proposed Standard Falls Far Short of Need By Peter Behr, Washington Post Staff Writer "The Clinton administration moved yesterday to ease Cold War-era controls on exports of high-powered U.S. computers to the former Soviet Bloc and other countries, fulfilling a campaign promise President Clinton made to the Silicon Valley executives who supported him last year." The article continues with comments on the lost sales caused by Cold War restrictions on computer exports. The new Commerce Decision rules allow export of microprocessors rated at 67 Mops (million operations per second), a big boost from the previous limit of 12 Mops. However, multiprocessor units are still on the forbidden list. Sales to the former Soviet Union are still subject to approval by COCOM, the Coordinating Committe for Multilateral Export Controls. Apparently some members of COCOM--Germany, in particular--are trying to link relaxation of computer export restrictions with relaxation of telecommunications gear. *** It will be interesting to see if the long-standing assumption that export restrictions prevent the distribution of technology to the interdicted nations. My reading of the DES-restriction debacle is that export controls on high tech are a farce. The U.S. restrictions hurt U.S. manufacturers and are a boon for everyone else. Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn RISKS-FORUM Digest 15.02 Date: 03 Sep 93 07:52:52 EDT From: "Mich Kabay / JINBU Corp." <75300.3232 at compuserve.com> Subject: Electronic documents A recent article deals with several RISKS of depending on electronic documents: Hayes, B. (1993). The electronic palimpsest; Digital documents for all occasions: erasable, correctable, reproducible, forgeable. _The Sciences_ (NY Academy of Sciences) 33(5):10.(Sept/Oct 1993) I enjoyed reading Brian Hayes article in the new issue of this fine magazine. It is not only informative and up to date, but also elegant, amusing and beautifully illustrated with various paintings. Summary follows: "As a writing instrument, the computer is not su much a better pencil as a better eraser." You can eliminate all traces of your early versions at the stroke of a key. This easy erasability leads to difficulties of authentication. How can one prove who wrote an electronic document? Digitized signatures make the problem worse, since anyone can scan a real signature and then print in on any document. However, digital signatures are a good method of authentication. The public key cryptosystem allows you to encrypt a document with your private (secret) key; only the corresponding public key decrypts the message. The encrypted version is as big as the original, though: a nuisance. A refinement, the digital signature, encrypts a digest of only 160 bits and provides the same confidence of authentication. Another problem is forgery. If we pay the rent with an electronic cheque, what stops a crook from using copy after copy of the same cheque? We will need unique serial numbers on electronic cheques. What about proving _when_ a document was created? Here we have to rely on a time-stamping service. Scientists at BELLCORE have invented the time-stamp equivalent of the digital signature. You submit a digest of the document that needs to be time-stamped to a trusted time-stamping computer; it generates a cryptographically-sound certificate which includes the time of receipt. To prevent fraud at the time-stamping computer (where someone might change the system clock long enough to produce fake time-stamps for a specific crime), every certificate is merged mathematically with all the others issued during the same weekly period. The summary time-stamp is then published in _The New York Times_. The legal system will have to adapt to the increasing use of electronic documents. Historians will also have more trouble piecing together the creative process if only the final version is published or physically available. And what about the rapid changes in computing technology and storage devices? Who will be able to read today's diskettes a hundred years from now? Or even ten? Archivists must think about these issues. <> Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn RISKS-FORUM Digest 15.04 Date: Thu, 9 Sep 1993 18:10:41 +0100 From: Brian.Randell at newcastle.ac.uk Subject: EuroDigital The attached article about a new digital phone service, about to be launched in the UK, is from the Monday, Sept 6, 1993, issue of The Independent. Also in this issue was a two page advertisement for the new service - the text of this is also attached. My understanding is that the new equipment produces emissions that have characteristics that were not considered when the regulations and guidelines (under which existing devices such as hearing aids were designed) were laid down. If this is right, then the statement by the providers of the new service that the problems are the responsibility of the manufacturers of such devices would seem to be highly questionable. I await with interest RISKs readers' reactions to the article (and the advertisement). Brian Randell, Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne, NE1 7RU, UK Brian.Randell at newcastle.ac.uk PHONE = +44 91 222 7923 [...] (Advt.) LIBERTE' The Freedom to make a call in total security We have given you freedom. We have created a secure tomorrow for businessmen and travellers both here and in Europe. New frontiers beckon. Vodafone proudly announces EuroDigital. The most advanced and most secure mobile phone network. So sophisticated that it can even be used to make and receive calls in Europe in total security. EuroDigital represents a revolution in mobile phone technology. A superior digital system that provides a top quality service. A quality that doesn't falter, that doesn't break up. Line rental is 21.50 per month. UK call charges 25p per minute peak, 10p off peak. Only Vodafone can offer this. Liberate yourself. Enjoy freedom of speech and security. Rise above the rest. Call free, 0500 123 123 and ask for more information. All prices are recommended and are exclusive of V.A.T. VODAFONE EuroDigital From gnu Sun Sep 12 00:28:37 1993 From: gnu (John Gilmore) Date: Sun, 12 Sep 93 00:28:37 PDT Subject: `supercomputer' export control In-Reply-To: <9309120637.AA09563@longs.lance.colostate.edu> Message-ID: <9309120728.AA28062@toad.com> > >From Washington Post newswire 08/27 Note the date; this is old news. > U.S. Acts to Ease Export Controls On Computers; Industry Officials > Say Proposed Standard Falls Far Short of Need They're right. > The new Commerce Decision rules allow > export of microprocessors rated at 67 Mops (million operations per second), > a big boost from the previous limit of 12 Mops. However, multiprocessor > units are still on the forbidden list. 67 NOPS [-) is a single SuperSPARC chip or a fast Pentium. Nothing faster than that can be exported without being considered a "supercomputer", requiring armed guards around it in the foreign country, etc. Like, a SPARCstation-10 containing TWO SuperSPARC chips... The amusing thing is that the chips themselves are not export-controlled. Foreign clone-makers buy the chips and sell to the rest of the world, while U.S. companies are fried by endless red tape. If you can get delivery next week or in six months, which supplier do you pick? The whole concept of export controls on computers and communications gear (including cryptography) has got to be demolished. Smashed to the ground like the Berlin Wall, a mere memory of decades of totalitarian bureacracy that ruined real lives and real products. John From nobody at alumni.cco.caltech.edu Sun Sep 12 01:03:17 1993 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Sun, 12 Sep 93 01:03:17 PDT Subject: nada Message-ID: <9309120754.AA18108@alumni.cco.caltech.edu> Some comments on the relationship between anarchy and privacy: 1. There have been some recent posts suggesting that privacy is not fundamentally subversive of government, and that cypherpunks should emphasize the privacy and keep quite about the anarchy. I find these arguments disingenuous in the extreme, and strategically unsound as well. 2. Cypherpunks believe that privacy is fundamentally subversive. Come on, folks, whom do you want privacy FROM, if not your own government? Otherwise there's no logical objection to the key-escrow, trust-big-brother schemes. 3. The government has shown by its behavior that it believes that privacy is fundamentally subversive. 4. I personally find privacy, in itself, only mildly interesting. As a tool to undermine the government, I find it VERY EXCITING INDEED. 5. Cypherpunks' mission is to evangelize the use of privacy. Sell the sizzle, not the steak! Privacy is the steak. The sizzle is the possibility of GETTING AWAY WITH SOMETHING.  From gg at well.sf.ca.us Sun Sep 12 01:28:17 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Sun, 12 Sep 93 01:28:17 PDT Subject: EC isn't great for privacy either... Message-ID: <93Sep12.011829pdt.14002-1@well.sf.ca.us> Right, "most people accept" the need for Big Brother to snoop..... In the UK, during the 1970s, the govt routinely tapped the phones of labor union organisers and members of opposing political parties. This got out in a series of articles in _New Statesman_. Presumably it was easy for dissident telephone engineers to detect evidence of the taps, because the exchanges were electromechanical in those days & taps were hard-wired. Nowadays, it's all System X or other digital, no evidence to detect, no dissident engineers popping out of the woodwork.... There are plenty of other examples of politically-motivated tapping; opposition political parties ought to be making much hay over this right now. During Nazi occupation, Dutch telephone engineers were particularly adept at creating non-tappable direct-dial long distance routes for special use by the resistance. After the war was over, they unveiled it for public use as direct distance dialing. Anyway, if any of these veterans are around, they would probably have interesting things to say about the current issues... -gg From newsham at wiliki.eng.hawaii.edu Sun Sep 12 01:39:14 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Sun, 12 Sep 93 01:39:14 PDT Subject: warez Message-ID: <9309120838.AA28789@toad.com> > > Some recent "warez" posts from alt.security.... Why was this posted to the cypherpunks list? What is the point? [..post deleted..] From nate at VIS.ColoState.EDU Sun Sep 12 02:39:14 1993 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Sun, 12 Sep 93 02:39:14 PDT Subject: PGPcompose (pgpc) 2.0 *just* finished. Message-ID: <9309120933.AA13977@vangogh.VIS.ColoState.EDU> -----BEGIN PGP SIGNED MESSAGE----- PGPcompose 2.0 is available for ftp from 129.82.156.104 (the macintosh in my dorm room... ;-) in /pub/pgpc it's all of 11K, so don't sweat the bandwidth! PGPcompose 2.0 has the following features: -can send mail through anon.penet.fi -keeps your anon.penet.fi password in a PGP'd file in your home directory -mails through 15 of the cypherpunks remailers (unlimited remailings, actually, but there's only 15 servers in it now (tell me of more!)) -can encrypt and sign mail -pumps output directly to sendmail (once you find out where sendmail is... read the README for more info) -will keep you fron doing stupid things, like mailing though anon.penet.fi and then through the remailers, or signing a message and then sending it through the remailers or through anon.penet.fi, etc... If you use it, send me some email. I would like to expand it's abilities, but I'm lazy... and tired. - -nate nate at vis.colostate.edu -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLJLs4NTgi1fmrpxlAQEm+wP5AXyo6iBre/iffpMoDrwGLHbLgqwqeCUa Dn1bI3AeYqj6kwyI7BdkZ4JFTgU6o6mPldDHHwtO1VNi+P/Hnkku+H+xa9YhmxDN b5MouM7By7mEEpgWJS9Bu2+aYXdKa9ZxB6YuI4khBxSJID07mPUer2g35swiRayw y+A2KB537/o= =HhPi -----END PGP SIGNATURE----- From P.V.McMahon at rea0803.wins.icl.co.uk Sun Sep 12 07:08:21 1993 From: P.V.McMahon at rea0803.wins.icl.co.uk (P.V.McMahon at rea0803.wins.icl.co.uk) Date: Sun, 12 Sep 93 07:08:21 PDT Subject: EC proposes PRIVACY LICENSES In-Reply-To: <9309120558.AA09019@longs.lance.colostate.edu> Message-ID: <"7088*/I=PV/S=McMahon/OU=rea0803/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> > [anonymously quoted EC policy proposal] > >A particular business might qualify for a CONFIDENTIALITY LICENSE > >depending on its internal procedures and activities. A general > >(minimum) level of confidentiality could be provided to all users. > > THE HORROR! > > *this* is Orwellian. *this* is how to outlaw cryptography. > > we need some ECypherpunk infiltrators ASAP! I would be interested in knowing which EC document is being referred to. You may perhaps be interested to know that the 14JUL93 Draft 3.6 of the "Green Book on the Security of Information Systems" (from CEC DGXIIIB) addresses the issue that "strong information privacy may also be used to escape investigation by law enforcement". It identifies some related requirements: "an effective, internationally agreed, economic, ethical, and usable solution to meet business, administration, and personal needs including mechanisms for authorised interception and reporting the incidents and crimes adjusted to the conditions of the Internal Market, and to include the necessary equipment and software, but also an infrastructure of Trusted Third Parties. This will discourage "home made" or other solutions." As its name suggests, the Green Book isn't an agreed policy, but is an intermediate step in the process of constructing and Action Plan for EC information security. As such, the current text might be interpreted as a recommendation for EC adoption of a Clipper-style solution, but this is by no means the only (or even the best) way to meet these requirements. Personally I would favour a framework which encouraged strong cryptography, and assumed that criminals will tend to ignore the law, so therefore didn't burden the law-abiding 99% with pointless constraints. This would require an adjustment to the current Green Book requirements, which I, at least, will be suggesting. From jdblair at nextsrv.cas.muohio.edu Sun Sep 12 08:28:22 1993 From: jdblair at nextsrv.cas.muohio.edu (John Blair) Date: Sun, 12 Sep 93 08:28:22 PDT Subject: is the list still going? Message-ID: <9309121540.AA13298@ nextsrv.cas.muohio.EDU > I haven't gotten a mailing for quite a few days. Is something wrong? -john From ccat at netcom.com Sun Sep 12 09:14:18 1993 From: ccat at netcom.com (Chris Beaumont) Date: Sun, 12 Sep 93 09:14:18 PDT Subject: encryption key switching,would it work? Message-ID: <9309121608.AA08172@netcom5.netcom.com> I'm wondering if there is any particular reason why an encrypted message might not be encrypted with several different keys,within the same message, divided by time.Perhaps synchronized clocks or time stamping might be used to toggle the encryption parameters.This technology might be able to defeat the brute force decryption technologies described in the paper mentioned yesterday. The only way that one might decrypt the message is to know the _exact_ time at wich the algorhythm was switched.In other words, what to prevent people from using _numerous_ keys during _one_ session,with the _times_ of switching remaining secret? Combined with a robust "one time pad" method,like triple DES,this technology might be particularly resistant to casual decryption attempts based on knowledge of the algorhythm? I know little about different encryption methods.. is there any reason this wouldnt work,besides the necessary complexity of the information contained in the key? -Chris - Chris Beaumont nutrient cafe wholesale ccat at netcom.com MIME mail graciously accepted ccat at casa.stanford.edu public key available via finger From loki at convex1.TCS.Tulane.EDU Sun Sep 12 09:53:22 1993 From: loki at convex1.TCS.Tulane.EDU (the mischeivious god) Date: Sun, 12 Sep 93 09:53:22 PDT Subject: nada against the gubbamess... In-Reply-To: <9309120754.AA18108@alumni.cco.caltech.edu> Message-ID: <9309121646.AA04893@convex1.tcs.tulane.edu> > 1. There have been some recent posts suggesting that > privacy is not fundamentally subversive of > government, and that cypherpunks should emphasize > the privacy and keep quite about the anarchy. I > find these arguments disingenuous in the extreme, > and strategically unsound as well. no doubt....I have a question for everyone though. How does anarchy deal with justice and who would be the ones to provide this service. Because lets face it we all have days some more that others where we need recourse..be it a dispute on your VISA b/c some @#T$#@$ warezhouse mailed you some crappy stuff and still won't give you back your money... For me the decline of West. Civ. started when Blanche was raped by Stanley in _Streetcar_named_DESIRE_ by Tn. Williams...but to get back to my point ...hmmm what was it...oh!!! The last vestiges of our gubbamess will be the judicial system ...beacuse we all have those days... Also is society outside of our Ivory tower cases with twin cooling fans ready for an anarchical harmony??? > > 2. Cypherpunks believe that privacy is fundamentally > subversive. Come on, folks, whom do you want > privacy FROM, if not your own government? > Otherwise there's no logical objection to the > key-escrow, trust-big-brother schemes. Bzzztt.. the internet is becoming a great place for commerce and trade concerns to get up wit' each other...Trade Secrets and financial records need to be protected from reverse-engineers who cannot think up a creative idea for them- selves so they will steal it. Granted the IRS will soon be peeing in its empty pants pockets to keep them full...but trade is another reason for crypts. And not this reconstituted clipper shit the E.C. is toying with right now. > > 3. The government has shown by its behavior that it > believes that privacy is fundamentally subversive. It is isn't it? see #1 ...vi sucks...kk > > 4. I personally find privacy, in itself, only mildly > interesting. As a tool to undermine the government, > I find it VERY EXCITING INDEED. > > 5. Cypherpunks' mission is to evangelize the use of > privacy. Sell the sizzle, not the steak! Privacy > is the steak. The sizzle is the possibility of > GETTING AWAY WITH SOMETHING. >  > kudos... Loki on a mosquito ridden convex mired in a swamp never to be salvaged...except by da cajuns.... From doug at netcom4.netcom.com Sun Sep 12 10:28:23 1993 From: doug at netcom4.netcom.com (Doug Merritt) Date: Sun, 12 Sep 93 10:28:23 PDT Subject: nada against the gubbamess... Message-ID: <9309121720.AA17362@netcom4.netcom.com> loki at convex1.TCS.Tulane.EDU (the mischeivious god) said: >nobody at alumni.cco.caltech.edu (I think) said: >> 1. There have been some recent posts suggesting that >> privacy is not fundamentally subversive of >> government, and that cypherpunks should emphasize >> the privacy and keep quite about the anarchy. I >> find these arguments disingenuous in the extreme, >> and strategically unsound as well. > >no doubt....I have a question for everyone though. How does anarchy >deal with justice and who would be the ones to provide this service. That's one of the problems with absolute anarchy; it's unstable. Most "anarchists" believe in relative anarchy rather than absolute; some would call that simply "libertarian", but others dislike that label because a lot of libertarians are less extreme in their views. Regardless of fine distinctions in labelling, it is possible to come up with schemes for things like justice that do not involve centralized monolithic government, anyway. As I recall, Ursula LeGuin had justice provided by ad hoc peer review committees, for instance. Snow Crash had it provided by franchised companies that were called "governments", but that sure didn't resemble today's governments in most details. One scheme for future cyberspace would involve digital voting by established reputable personas (anonymous or not) and enforcement via stakes involving digital cash and/or digital reputation. Although building and establishing reputation would require some kind of investment of time and energy, it's difficult to maintain a "one physical body one vote" scheme. Randomized selection of juries might assist in that in a statistical sense. (I arrived late at the cypherpunk meeting Saturday, but from the printed agenda it looks like some aspects of that had been discussed?) As for the original point about whether cypherpunks should be quiet about anarchy or not, this is a question of PR and of politics (of course). If you're talking to a person with libertarian or anarchist leanings, then that would be a selling point. If you're talking to the press, who will in turn be talking to everyone including Peoria, the game is to be more moderate while still offering the sizzle. For instance, even mainstream Republicans and Democrats from the bible belt may distrust the IRS and the CIA enough to want some protection from *them*. But they may not sympathize with people who say that we need protection from the government overall. It's a selling game. It's also worth keeping in mind that there are a variety of political views among cypherpunks, and it would be dishonest to paint all cypherpunks as being in absolute agreement about all aspects of politics. >Also is society outside of our Ivory tower cases with twin cooling fans ready >for an anarchical harmony??? Not a chance. But the sizzle might sell anyway, if it's packaged right. Doug -- Doug Merritt doug at netcom.com Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow Unicode Novis Cypherpunks Gutenberg Wavelets Conlang Logli Alife HC_III Computational linguistics Fundamental physics Cogsci SF GA VR CASE TLAs From pmetzger at lehman.com Sun Sep 12 10:33:23 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 12 Sep 93 10:33:23 PDT Subject: nada against the gubbamess... In-Reply-To: <9309121646.AA04893@convex1.tcs.tulane.edu> Message-ID: <9309121725.AA23425@snark.lehman.com> loki at convex1.tcs.tulane.edu asks: > no doubt....I have a question for everyone though. How does anarchy > deal with justice and who would be the ones to provide this service. This is completely beyond the scope of Cypherpunks -- this isn't a list about anarchism, its a list about cryptographic privacy. I'll gladly suggest a few books for you, though... "The Machinery of Freedom" by David Friedman (yes, THAT Friedman's son). "The Enterprise of Law: Justice without the State" by Bruce Benson Both are likely available from Laissez Faire books, at 800-326-0996. They have a free catalog. Benson's book is a thick, detailed and scholarly work that concentrates solely on legal and judicial systems. Friedman's work is a light survey of all sorts of libertarian and anarchist topics, from monetary systems to a discussion of private judicial practice in medieval Iceland. Having presented some references, I suggest we now abandon the topic of anarchism -- it isn't the purpose of this list. I think its appropriate that people like me not hide our positions, but thats very different from discussing them in an inappropriate place. There are lots of discussion groups on the net for propertarian anarchists to chat in -- and this is a list for cryptography. Perry From nowhere at bsu-cs.bsu.edu Sun Sep 12 10:53:23 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Sun, 12 Sep 93 10:53:23 PDT Subject: The "Cypherpunk Melting Pot" Message-ID: <9309121749.AA00279@bsu-cs.bsu.edu> On Sun, 12 Sep 93 00:54:18 PDT, wrote - > Some comments on the relationship between anarchy and > privacy: > > 1. There have been some recent posts suggesting that > privacy is not fundamentally subversive of > government, and that cypherpunks should emphasize > the privacy and keep quite about the anarchy. I > find these arguments disingenuous in the extreme, > and strategically unsound as well. Bullshit. Privacy is not inherently subversive at all. If you take the time to browse back through the Bill of Rights, you might recognize this paragraph - ARTICLE IV The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized. > 3. The government has shown by its behavior that it > believes that privacy is fundamentally subversive. This is not necessarily true. I agree that Big Brother has gone to the extreme to violate individual privacy in the modern day, but just how does this tie into anarchy? To solely entwine these two idealisms is, in my opinion, a bankrupt strategy. I believe in strong crypto, I believe in privacy. Pinch-hitting for anarchy will damage work for privacy causes. > 4. I personally find privacy, in itself, only mildly > interesting. As a tool to undermine the government, > I find it VERY EXCITING INDEED. Excitement does not define the deed or the end result. Get your cheap thrills at someone else's expense. > 5. Cypherpunks' mission is to evangelize the use of > privacy. Sell the sizzle, not the steak! Privacy > is the steak. The sizzle is the possibility of > GETTING AWAY WITH SOMETHING. "Getting away" with privacy is an oxymoron in itself. Privacy should be something that we all have and enjoy as individuals, not simply as guaranteed under the Constitution, but as a human right that is owed each of us globally. I'll stand by you in a fight for privacy, but I won't be party to anarchic idealisms that I believe will do more damage to the privacy cause in the long run. From doug at netcom4.netcom.com Sun Sep 12 11:04:21 1993 From: doug at netcom4.netcom.com (Doug Merritt) Date: Sun, 12 Sep 93 11:04:21 PDT Subject: nada against the gubbamess... Message-ID: <9309121759.AA21048@netcom4.netcom.com> loki at convex1.TCS.Tulane.EDU (the mischeivious god) said: >Any way question to that point about about elections... > >Who would be ble to be candidates...just anybody ???that would be >almost as bad as our present system...which has people with no relevant >experience except in bullshit and fait de con. Sorry to say that you're a bit confused. The question was how to provide justice under anarchy. I said something about voting. You jumped to the assumption that I was talking about voting for government elections. This is not the case. I was talking about voting on issues of justice, as in a jury. You may want to reread my post with this in mind. As for voting for government in cyberspace, it all depends on the other assumptions. Should there be a virtual government? Should voting for physical-world governments take place on the net? Etc, etc. There is currently no active discussion going on about any of this, so there is no framework for commenting on voting for such things. Doug From Andrew.Corradini at m.cc.utah.edu Sun Sep 12 11:58:23 1993 From: Andrew.Corradini at m.cc.utah.edu (Andrew Corradini/SBDC) Date: Sun, 12 Sep 93 11:58:23 PDT Subject: Let's stick to the topic, folks... Message-ID: For purely practical reasons, could we all please try to limit stuff that'd end up on soda.berkeley.edu in the "rants" directory? ;-) This is a MAILING LIST, not a newsgroup, and some of us have pretty limited space available. Debating constitutional issues, splitting hairs over the difference between libertarianism and anarchism (let ALONE "strong" vs. "weak" anarchy!) is best done in an alt.politics-type setting, no? I didn't subscribe to the list to see 7-level-deep nested quotes arguing over whether anarchy is fundamentally unstable; I suspect most others on the list didn't either. As I understood, and understand, the thrust of the group deals with the TECHNOLOGY and TECHNIQUES involved in the application of cryptography to privacy-related issues and the free distribution of "information", whether dirty pictures, money, or a poem you just wrote to your loved one. NOT the philosophy. Please, for bandwidth's sake, would people please take their back-n-forth's.... *private*?! ;-) (pun fully intended) (deep breath, relax shoulder tension, stepping down from soapbox) Thanks, y'all. I feel much better now. Andrew From composer at Beyond.Dreams.ORG Sun Sep 12 12:39:21 1993 From: composer at Beyond.Dreams.ORG (Jeff Kellem) Date: Sun, 12 Sep 93 12:39:21 PDT Subject: Armed gangs stealing chips from warehouses In-Reply-To: <9309102135.AA25794@netcom5.netcom.com> Message-ID: <9309121937.AA24265@Beyond.Dreams.ORG> On the cypherpunks mailing list, Tim May wrote... > (I regret that I cannot post the Clarinet article, as Clarinet has > fairly draconian policies about reposting its articles--even though I > never signed a contract. Still, Cypherunks should be aware of > this....I've seen at least one Clarinet article reposted here on this > list, and this could expose the list to actions.) Send a note to Brad [Templeton] at Clarinet. He has, in the past, allowed _occasional_ repostings to mailing lists, as long as it is understood that those postings should not be reposted. FYI... -jeff Jeff Kellem Internet: composer at Beyond.Dreams.ORG From lefty at apple.com Sun Sep 12 13:08:41 1993 From: lefty at apple.com (Lefty) Date: Sun, 12 Sep 93 13:08:41 PDT Subject: Spooks reading the list Message-ID: <9309122000.AA00806@internal.apple.com> An anonymous "contributor" writes > >In fact, there is at least one NSA agent on this list. Whether >he/she is on our side or not, who knows? This message, a defense of >the NSA, was posted here not long ago. I don't know if anyone else >noticed this at the time, but take a look: > >*From: IN%"remail at tamsun.tamu.edu" 28-AUG-1993 06:02:47.29 >*To: IN%"cypherpunks at toad.com" >*CC: >*Subj: NSA & the Crypto-Zionist Myth of "Public Key"! > >* {Deletia} >* >*Excuse me, but I'm getting tired of this silly paranoia. NSA >*is not Evil Incarnate Central, and we are not fighting a Valiant War > == > >We? WE! Do you suppose that was a Freudian slip, or did he mean to >say it like that? Whoever he is, he works for the NSA. Did anyone else >notice this at the time? In this context, "we" clearly refers to the Cypherpunks, fighting a "Valiant War" _against_ the NSA. I think you sound like a paranoid loon. -- Lefty [gYon-Pa] (lefty at apple.com) C:.M:.C:., D:.O:.D:. From newsham at wiliki.eng.hawaii.edu Sun Sep 12 13:19:35 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Sun, 12 Sep 93 13:19:35 PDT Subject: encryption key switching,would it work? In-Reply-To: <9309121608.AA08172@netcom5.netcom.com> Message-ID: <9309122019.AA06312@toad.com> > > I'm wondering if there is any particular reason why an encrypted message > might not be encrypted with several different keys,within the same message, > divided by time.Perhaps synchronized clocks or time stamping might be used > to toggle the encryption parameters.This technology might be able to defeat > the brute force decryption technologies described in the paper mentioned > yesterday. If you have a system with key exchange you can change the keys on demand in the middle of a stream (provided the protocol you use allows this). This may be done as many times and as often as you please up to the limitations of the (usually) slower key exchange protocol. > Chris Beaumont nutrient cafe wholesale > ccat at netcom.com MIME mail graciously accepted > ccat at casa.stanford.edu public key available via finger From nowhere at bsu-cs.bsu.edu Sun Sep 12 13:48:24 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Sun, 12 Sep 93 13:48:24 PDT Subject: The "Cypherpunk Melting Pot" Message-ID: <9309122044.AA07882@bsu-cs.bsu.edu> On Sun, 12 Sep 93 00:54:18 PDT, wrote - > Some comments on the relationship between anarchy and > privacy: > > 1. There have been some recent posts suggesting that > privacy is not fundamentally subversive of > government, and that cypherpunks should emphasize > the privacy and keep quite about the anarchy. I > find these arguments disingenuous in the extreme, > and strategically unsound as well. Bullshit. Privacy is not inherently subversive at all. If you take the time to browse back through the Bill of Rights, you might recognize this paragraph - ARTICLE IV The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized. > 3. The government has shown by its behavior that it > believes that privacy is fundamentally subversive. This is not necessarily true. I agree that Big Brother has gone to the extreme to violate individual privacy in the modern day, but just how does this tie into anarchy? To solely entwine these two idealisms is, in my opinion, a bankrupt strategy. I believe in strong crypto, I believe in privacy. Pinch-hitting for anarchy will damage work for privacy causes. > 4. I personally find privacy, in itself, only mildly > interesting. As a tool to undermine the government, > I find it VERY EXCITING INDEED. Excitement does not define the deed or the end result. Get your cheap thrills at someone else's expense. > 5. Cypherpunks' mission is to evangelize the use of > privacy. Sell the sizzle, not the steak! Privacy > is the steak. The sizzle is the possibility of > GETTING AWAY WITH SOMETHING. "Getting away" with privacy is an oxymoron in itself. Privacy should be something that we all have and enjoy as individuals, not simply as guaranteed under the Constitution, but as a human right that is owed each of us globally. I'll stand by you in a fight for privacy, but I won't be party to anarchic idealisms that I believe will do more damage to the privacy cause in the long run. - From nowhere at chaos.bsu.edu Sun Sep 12 14:53:24 1993 From: nowhere at chaos.bsu.edu (Chael Hall) Date: Sun, 12 Sep 93 14:53:24 PDT Subject: Correction Message-ID: <199309122347.QAA17514@chaos.bsu.edu> Correction, that's plans-request at chaos.bsu.edu Chael From nowhere at chaos.bsu.edu Sun Sep 12 14:54:23 1993 From: nowhere at chaos.bsu.edu (Chael Hall) Date: Sun, 12 Sep 93 14:54:23 PDT Subject: chaos.bsu.edu online (again) Message-ID: <199309122346.QAA17487@chaos.bsu.edu> Sorry about that... I will remember not to disklabel my swap partition again like that. Unfortunately, a lot of data was lost last week when I killed my 386BSD partition. One thing that I lost was the pseudonymous contact service that I had written. The remailer, however, has been enhanced a little bit (nothing noticeable) and is now running on chaos. The remailer address is . This is *not* a user account, so if you mess up a message to the remailer, your message will bounce with an appropriate error code. Please try it out and let me know if you have any problems with it. Accounts are available, the same restrictions apply as in my previous message. Telnet to chaos.bsu.edu and login as "guest" to apply for an account. There is a mail server named "plans" on here too. I created it with the intention of getting others' input on the direction that chaos should go. So, if you would like to help give some constructive criticizm, please send a subscription request to "plans-admin at chaos.bsu.edu" now! Chael Hall {nowhere|root}@chaos.bsu.edu nowhere at bsu-cs.bsu.edu 00CCHALL at bsuvc.bsu.edu chall at bsu.edu From jaxelrad at crl.com Sun Sep 12 15:24:24 1993 From: jaxelrad at crl.com (Jonathan Axelrad) Date: Sun, 12 Sep 93 15:24:24 PDT Subject: Digital warfare In-Reply-To: <9309111519.AA04072@carina.unm.edu> Message-ID: On Sat, 11 Sep 1993, Da Mystic Homeboy wrote: > What would happen if all our transactions become untraceable? > How is the government supposed to prove anything, except by becoming fascist > corporate fanatics (which is what is trying to happen right now). Better > yet, if all our communications are in private, how are the information > companies going to get their money? Whos going to have established credit- > the very basis of our modern kapitalism? While I'm very much in favor of digital cash & strong encryption and excited by their potential uses, it seems to me that you're leaving out an awful lot when you paint your vision of the "private" future. Neither is likely to dramatically reduce the amount of general-purpose information available on people and businesses. With the ATM always around the corner, there's almost no reason for me to use a credit card, yet I do (frequent flyer mile credits aside) because it's convenient. The same for giving my unlisted telephone number to the plumber (who, in the years to come, undoubtedly will maintain it in a database and may even sell it) because I want him to call if he's going to be three hours late to fix the leaky pipe. As far as who's going to have established credit, the answer is darn near everyone who can get it. Credit is a powerful tool in a market economy -- to get an idea of how important it is even to average people, just look at the number of articles published by feminists on the plight of recently divorced women who had previously relied on their husband's credit rating. Rather than using the new tools for anonymity, I'll bet that most people, most of the time, want to use them to more securely establish *identity* (i.e., I don't want that jerk down the street with a Radio Shack scanner using my credit for his own purposes). In the end, I would suggest that a digital cash/strong encryption future will include a delicate balance in which each of us is constantly broadcasting personal information in the clear for purposes of convenience (even though we will quickly lose control over how that information is used) while simultaneously using privacy tools to permit more secure transactions and communications. This is not to suggest that there won't be a continued underground economy, but I don't see it taking over the world. From pmetzger at lehman.com Sun Sep 12 17:28:28 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 12 Sep 93 17:28:28 PDT Subject: The "Cypherpunk Melting Pot" Message-ID: <9309130022.AA21166@kublai.lehman.com> Anonymous says: > Bullshit. Privacy is not inherently subversive at all. If you > take the time to browse back through the Bill of Rights, you might > recognize this paragraph - > > ARTICLE IV > > The right of the people to be secure in their persons, > houses, papers, and effects, against unreasonable searches and > seizures, shall not be violated, and no Warrants shall issue, but > upon probable cause, supported by Oath or affirmation, and > particularly describing the place to be searched, and the persons or > things to be seized. I'll point out something about the history of that line most people forget. Our fine nation was founded by drug smugglers. The drug in question was Rum, admittedly, but none the less, the point remains -- the revolutionary war was financed by big time criminals like John Hancock who made their money in smuggling contraband and other similar acts. They made sure that the constitution they got was supportive of their particular business interests. History teachers don't like pointing this sort of thing out, but its none the less true. Our founders wanted a government that is very close in size to what minarchist libertarians think of as being the "right size" -- there was a scandal early on when the white house staff was expanded to four people -- so it shouldn't be suprising that a correct reading of the constitution leads to certain unpleasant conclusions for statists. Perry PS Thomas Jefferson once fretted heavily over whether a constitutional amendment was needed to make the Louisiana Purchase. Think of that image in your mind the next time you hear a congressman propose some new program that is plainly not authorized in the enumerated powers section of the constitution. (By the way, if your history teacher fed you the bull that the "escape clause" means congress can pass any law it likes, I suggest looking up the legal doctrine that the "exception proves the rule", and check out the history of FDRs administration, paying special attention to the early constutional battles like the so called Scheckter "Sick Chicken" case and to the phrase "Court Packing".) From nowhere at bsu-cs.bsu.edu Sun Sep 12 17:33:27 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Sun, 12 Sep 93 17:33:27 PDT Subject: The "Cypherpunk Melting Pot" Message-ID: <9309130027.AA24351@bsu-cs.bsu.edu> Okay. I've gotten my collective thought processes back on track, how 'bout the rest of you? Can we move forward -together- on the front for strong crypto? Seeing as how Mr. P. (segway) Ferguson and Mr. Spooge(y) like to use dictionary entries, I suggest this one as an "end-all" for our current purposes - team - \teem\ 2 : a number of persons associated in work or activity; esp: a group on one side in a match. We should be working as a team and not vetting petty on issues outside of strong crypto. From frissell at panix.com Sun Sep 12 19:23:29 1993 From: frissell at panix.com (Duncan Frissell) Date: Sun, 12 Sep 93 19:23:29 PDT Subject: DIGITAL WARFARE Message-ID: <199309130215.AA07503@panix.com> To: cypherpunks at toad.com ************* Original From: FRISSELL * FORWARDED * To: CYPHERPUNKS at TOAD.COM * MESSAGE * Date/Number: 09/12/93 - Not Yet Posted ************* On: PANIX - 0000 - Email ----------------------------------------------------------------------- To: cme at ellisun.sw.stratus.com Here I innocently go away for the weekend and miss a hot thread on my favorite topic. Appropriate for the list because it's about what this list is about and what the results of its activities might be. Better late than never... CC> I have heard cypherpunks described as two groups under one label: CC> 1. those of us who advocate privacy in private hands CC> CC> 2. those who advocate anarchy CC> CC> I'm in the privacy camp and worry that CC> enough talk from the anarchists will cause the privacy to be CC> attacked. I fully expect total retaliation by the governments of CC> the world against any effective anarchy. The wilder the threats CC> (even if they're not real), the stronger the retaliation. We could CC> lose all privacy as a result. I try not to advocate anarchy but rather to observe it. It is difficult for large institutions to exercise control over ever more powerful individuals. Even though I like crypto, it is neither necessary nor sufficient for what I'll call "governmental downsizing" to avoid controversy. IBM didn't "rightsize" because sweet reason convinced it to. It righsized (and is still rightsizing) because markets convinced it to. We already see signs of governments becoming mere market actors particularly in the currency markets. The nets themselves are the most powerful technology which will reduce the role nation states have to play on the world stage. Crackdowns against strong crypto are not relevant. Since the nation state is bound to the nation and individuals are not, telecoms tends to liberate individuals from states. If I can live anywhere and work anywhere else, I am hard to find much less control. People need not have to even be aware of what they are doing to participate in this process. If they are hired as contingent workers over the nets because that's where the work is, they will be outside of the control mechanism and have to choose to bring themselves back in. Some will do so many will not. For years, those who became expats or invested money overseas have had to make an affirmative choice to file US tax returns or report their overseas income on their returns. Some did so. Many did not. 61% of US expats don't file US returns even though most have income. Everyone on the nets is effectively an expat. According to IRS studies, only *48%* of the income of small businesses is reported. Those are businesses physically located in the US. Since computers will be converting most of us into small business operators (selling ourselves as permanent temps at least) and since the nets encourage locational ambiguity, we will have to choose to cooperate with our rulers. What do we call a "voluntary government"? A church, a social club, a corporation, or a family but not (according to *my* poli sci profs) a government. "An institution that claims a monopoly on the legitimate use of physical force in a given geographic area." Note that by the end of this year, some Continental Cable subscribers will have 100 mbs connections to Internet. Once more people do and they find that they can buy/obtain almost anything digitizable (including "free" international telephone calls) over this link, they will do so. They will have expanded their area of freedom by downloading porno from Zimbabwae (or whatever from wherever). A few more expansions of liberty and the state is reduced to just another club. CC> For example, crypto-anarchic banks -- cute idea -- but if CC> you ever want a cop to make your banker give you the money, the CC> banker can't be anonymous and neither can you account be. Bankers don't give you your money because of fear of cops but because of the desire for future business. Duncan Frissell What is the world's most toxic hazardous waste dump? -- Watch this signature line for the surprising answer. * RM 1.2 * Eval Day 1 * X From pcw at access.digex.net Sun Sep 12 19:29:27 1993 From: pcw at access.digex.net (Peter Wayner) Date: Sun, 12 Sep 93 19:29:27 PDT Subject: Digital warfare Message-ID: <199309130223.AA24415@access.digex.net> People who are skeptical about Perry Metzeger's claim about tax avoidance might want to look at the files of Dave Dinkins, the mayor of New York. I believe that he failed to file for something like 12 years. Yet, the machine runs on in that city.... -Peter From ld231782 at longs.lance.colostate.edu Sun Sep 12 19:43:29 1993 From: ld231782 at longs.lance.colostate.edu (ld231782 at longs.lance.colostate.edu) Date: Sun, 12 Sep 93 19:43:29 PDT Subject: NY cyberspace tax analyses Message-ID: <9309130236.AA25457@longs.lance.colostate.edu> These msgs were taken from miscellaneous mailing lists. Most importantly, this tax does *not* simply affect `phone sex' 900 lines, as a sort of `sin tax' as supposed by some. To the contrary, BBSes, online services, even *shareware* is affected by the tax. Authors below report - BBSes *are* subject if computer & users are in NY - CompuServe, Prodigy, America Online *subject* to tax (Newsday 9/6) - SHAREWARE is *taxed* under the rate if downloaded from NY board - relevant court cases that struck down similar taxes based on 1st amendment - one person complains of `poor wording' in law -- no kidding. I propose that a mailing list dedicated to the topics of cyberspatial regulation and taxation be created ASAP. ===cut=here=== Date: Sat, 11 Sep 1993 23:01:40 -0400 (EDT) From: Jean Armour Polly Subject: Re: NY tax on information services [...] I called the NYS Tax and Finance folks on Friday and they faxed me info on this bill. Briefly (though I am not a lawyer, pun intended), based on a phone conversation with them: There is a tax if -- the "bbs operator" charges a membership fee AND -- the host computer is in NYS AND -- the operator sells to NYS residents. If the host computer is out of state it does not apply at all. If the host is in NY but the customer is out of state it does not apply. If the service is run by a non-profit it does also not apply. Also, SHAREWARE is affected. If you download shareware and subsequently send in the registration fee, the software producer has to charge you NYS tax-- if he's in NY and the customer is in NY. This particular part is written very poorly IMHO. Hope this helps. I have the text of the memo and some examples I can send to you monday if you want. Best, JP Date: Sat, 11 Sep 1993 19:50:35 -0500 From: farber at central.cis.upenn.edu (David Farber) Subject: NY tax on information services Russell Nelson writes: >> September 1, 1993 New York Newsday >> By Joshua Quittner >> >> Starting today, metropolitan New York residents will pay a hefty >> 13.25% sales tax on information services they get over phones and >> computers - the highest tax on information services in the country, >> experts say. > > IMHO, this is not true (but it sure makes good press). > Reading over the text of the law, it appears to be > targetting the 900/800 oral information providers. It > specifically excludes anything customized for the particular > user, and it specifically excludes written materials. Yes, but apparently the New York authorities disagree with you. See _Newsday_, 9/6: " The Budget Division and the Department of Taxation and Finance agree that the 5-percent surcharge also applies to such wildly popular computer services as CompuServe, Prodigy and America on Line. So, in addition to taxing the poor souls who use those sex-phone services, the new law goes after a more sophisticated and altogether more resourceful crowd, the computer literate." Steve Haynes * Stephen L. Haynes Internet: shaynes at research.westlaw.com * Manager, WESTLAW Research MCI Mail: 221-3969 * & Development Compuserve: 76236,3547 * West Publishing Company Phone: 612/687-5770 * 610 Opperman Drive Fax: 612/687-7907 * Eagan, MN 55123 Date: Sat, 11 Sep 93 23:45:14 -0700 From: djb at silverton.berkeley.edu (D. J. Bernstein) Subject: Taxing the First Amendment The First Amendment _does_ prohibit taxes aimed at the press. See, for example, Grosjean v. American Press Co., 297 U.S. 233 (1936). A law whose effect was to impose fees on several large newspapers was declared void on its face. This protection is not limited to the press; it is a common theme in many First Amendment cases. See, for example, the important case of Freedman v. Maryland, 380 U.S. 51, footnote 3 (1965): ``Appellant also challenges the constitutionality of Sec. 6, establishing standards, as invalid for vagueness under the Due Process Clause; Sec. 11, imposing fees for the licensing and inspection of a film, as constituting an invalid tax upon the exercise of freedom of speech; and Sec. 23, allowing exemptions to various classes of exhibitors, as denying him the equal protection of the laws.'' The Supreme Court didn't rule on these issues---it didn't have to, because it struck down the entire Maryland film censorship statute as an invalid prior restraint. But Freedman's appeal would probably be a good model for an attack on the New York cyberspace tax. The latter tax is, after all, aimed directly at the exercise of freedom of speech, and its exemptions deny equal protection to certain information providers. (Note that the aim of a law is judged by its operation and effect, not by the motives of the legislators, at least for First Amendment purposes.) ---Dan From 72114.1712 at CompuServe.COM Sun Sep 12 20:04:28 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Sun, 12 Sep 93 20:04:28 PDT Subject: A CYPHERPUNK VISION Message-ID: <930913025413_72114.1712_FHF93-1@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cypherpunks, At the Bay Area physical meeting on Saturday, I gave a slightly longer version of the following presentation. Please make sure you read the "call to arms" at the end. Uncle Sandy wants you. S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< * * * A CYPHERPUNK VISION We are fond of saying, "Cypherpunks write code," but what does that really mean? "Writing code" isn't just programming. To me, it is a metaphor for direct, personal action. That's what Phil Zimmermann did when he wrote the code for PGP. But, it is also what John Gilmore did when he sued the NSA. Cypherpunks don't wait for other people to grant them freedom or privacy; they do it themselves. They use their wits and talents to create innovative defenses and bold counter-attacks. Cypher- punks are the ultimate practitioners of "self-help." So what should YOU do, to be a "real" Cypherpunk? The answer is: Whatever interests you. Are you good with electronics? How about breadboarding a voice compressor/encrypter. Can you write code? Maybe you can make a Windows shell for PGP. Mathematically inclined? Tweak the algorithms. Find the weak- nesses; find the improvements. Do you have a flare for writing? Write articles or stories that popularize the Cypherpunk world-view. Is business or law your cup of tea? Start a privacy consultation business and make a buck while fighting the good fight. Whatever you WANT to do, is what you SHOULD do. There is more work to be done than Cypherpunks to do it. Any area of the struggle that is important to you, is also important to others. The battle for freedom and privacy is a target-rich environment. As Marine general "Chesty" Puller said when he was told that the North Koreans had surrounded his position, "Great, we've got them right where we want them. We can fire in any direction!" So where have I decided to fire? As many of you know, I have a background in the law and offshore business. Naturally, I want apply that training and experience to fighting the technological threats to freedom and privacy that gave rise to the Cypherpunks. To that end, I give you my vision: A Bank in Cyberspace. A BANK IN CYBERSPACE Protecting one's privacy is nothing new. For hundreds of years, people have protected their wealth and financial privacy by transnationalizing themselves. In today's world, this means "offshore" banks and other international techniques. In simple terms, by diversifying internationally, you can "forum shop" for the best deals offered by each country's laws. Since all nations are in competition for foreign capital, one can be played off against another. Low taxes and banking secrecy are two services even the poorest of countries can offer. As a result, tax, banking and privacy havens are quite numerous and affordable. Take your pick. The trouble is, tax haven banks are often located in the world's backwaters. Using them just isn't convenient for most people. The obvious answer is technology, but bankers, being conserva- tive, have failed to plumb its enormous potential. It's time for a change--a Cypherpunk change. To that end, I am introducing The Internet Digital Security Bank and Escrow, the first bank founded in cyberspace. The Bank would offer interest bearing checking accounts to the 10-15 million Internet users, plus anyone else with access to e-mail. Unlike traditional banks, there would be no paper checks. All checks would be written as encrypted and digitally signed e-mail messages. In the future, digital cash would also be made available to Bank customers. The escrow services of the Bank would be used to protect both parties to electronic business exchanges. The escrow services would facilitate a wide variety of anonymous transactions. A team of entrepreneurs, computer programers, lawyers and financiers is currently being assembled. If you would like to participate in this project, please contact: Sandy Sandfort, ssandfort at attmail.com. Please include your resume or other info about your education, skills and interests. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From an12070 at anon.penet.fi Sun Sep 12 20:08:30 1993 From: an12070 at anon.penet.fi (an12070 at anon.penet.fi) Date: Sun, 12 Sep 93 20:08:30 PDT Subject: WACO: FBI & BATF used *flamethrower*?! Message-ID: <9309130301.AA07960@anon.penet.fi> edited, from alt.activism === This editorial was in the Arizona of 8/22. It was written by William P. Cheshire, Senior Editorial Columnist. LOOKING BEYOND THE WACO SMOKE An anonymous tipster sent me a videotape the other day describing in startling detail the government's shootout, siege and ultimate destruction - possibly deliberate - of the Branch Davidian compound outside Waco, Texas. The tape is the production of Linda D. Thompson, an Indianapolis lawyer who traveled to Waco to protest the government's initial assault on the compound, which left four agents dead, and now devotes most of her time to investigating how 80 or so people died 50 days later when the place was torched. According to agents of the FBI and the Bureau of Alcohol, Tobacco, and Firearms, the followers of guru David Koresh set fire to their own building when it was stormed by tanks and a small army of heavily armed governments agents. But the videotape, assembled from the government's own film, clearly shows one of the tanks crashing into the building, then backing out again, fire belching from its turret. EYEWITNESSES LACKING This received virtually no publicity because the media were kept under wraps. On a story of this magnitude, reporters and cameramen normally would have been on the scene providing first- hand coverage. But in this instance the press acquiesced in extraordinary restraints. Search and arrest warrants were sealed, and when government agents settled down for what was to be a seven-week siege, the press was allowed to get no closer than two miles from the Branch Davidian compound. As the tanks rolled and the feds broke out their grenades and submachine guns for the final assault on April 19, reporters and cameramen gathered behind distant roadblocks, waiting for government handouts. Miles away the compound was being burned to the ground. A school board can't meet in secret without the media going ballistic, Thompson says, but here the government conducted a massive armored assault on civilians, unencumbered by witnesses. "I'm very discouraged that reporters weren't being more aggressive in Waco," Phil Record, ombudsman for the Fort Worth Star-Telegram, told Mark Holmberg of the Rutherford Institute in Charlottesville, VA. "If there had been a few neutral eyes up there, I would feel much better about it". Thompson is more blunt. "Reporters sucked up everything the ATF and FBI told them," she says. "They're a bunch of weenies and sheep. None of them had the guts to ask challenging questions or the intelligence to ask constitutional questions." FLAME THROWER IDENTIFIED I reached Thompson by phone at the American Justice Federation, a civil liberties group she operates. She now has identified the tank seen backing out of the Branch Davidian building, she told me. "It was an M67A1 tank manufactured by Chrysler," she said. This tank, equipped with a flamethrower, is no longer in service and, according to Thompson, had to be taken from "the graveyard" for the Waco assignment. The clear implication is that the government deliberately set fire to the Branch Davidian compound, killing some 17 children and 69 adults. I asked how she found out about the M67A1, a little-know weapon to which even Jane's Armour and Artillery gives only brief mention. "The driver who drove it from Fort Hood called me," she said. At the end of the Waco madness, President Clinton said the Branch Davidians had "burned themselves up" - and allegation that, in the light of Linda Thompson's allegations, Congress needs to investigate. Already, The Washington Post reports, the Waco embarrassment has prompted a major reshuffle at the ATF. Some officials may be forced to retire, the Post says, and the chief of the intelligence division could be denied "future promotions." Such punishments seem hardly proportionate. As a consequence of the Rodney King beating in Los Angeles, two police officers were tried for the assault and acquitted, then tried again for civil rights violations and sentenced to two and a half years in the federal penitentiary. How is it that federal agents responsible for the death of more than 80 men, women and children may be permitted to retire or even to keep their present jobs? ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From frc%bwnmr4 at harvard.harvard.edu Sun Sep 12 21:23:30 1993 From: frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) Date: Sun, 12 Sep 93 21:23:30 PDT Subject: A CYPHERPUNK VISION In-Reply-To: <930913025413_72114.1712_FHF93-1@CompuServe.COM> Message-ID: <9309130416.AA23342@bwnmr4.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- Sandy wrote: > Can you write code? Maybe you can make a Windows shell for PGP. I said this once before, in private email so I'll repeat it here for the everybody: I'm working on a windows shell for PGP, as well as a pgp.dll for filemanager extensions and supporting drag and drop encryption. I say, give me about 1 month or so (I've got a app to deliver for my real job too) and I'll have stuff that's ready to be tested. I'll start accpeting beta test volunteers now if anybody wants to speak up. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJP0G7bAlE4AqlTZAQFvtgQAjiBanwpGrRxHst4dINjfzmr1Jsa0IkTS YK2QuOE1ichjoLkVbHM/zCbVIaK6UXw0P9dGdD19n5zL3m2WbUYHXhSax875uwmg TAuMNxpvK17oM6i/WFonshGDQJAwjLjtcMM9lnj3J1cPr7MfGiP68TkODeyKORyz gIjM2K5U+aA= =8b9Z -----END PGP SIGNATURE----- From jet at netcom.com Sun Sep 12 22:53:32 1993 From: jet at netcom.com (J. Eric Townsend) Date: Sun, 12 Sep 93 22:53:32 PDT Subject: alt.politics.org.[cia,nsa] and anon posting Message-ID: <9309130545.AA24211@netcom3.netcom.com> would one of the anon posting/remailer gurus post a faq to one of these groups? They could probably use it. -eric From Andrew.Corradini at m.cc.utah.edu Mon Sep 13 00:28:34 1993 From: Andrew.Corradini at m.cc.utah.edu (Andrew Corradini/SBDC) Date: Mon, 13 Sep 93 00:28:34 PDT Subject: WACO: FBI & BATF used *flamethrower*?! In-Reply-To: <9309130301.AA07960@anon.penet.fi> Message-ID: On Mon, 13 Sep 1993 an12070 at anon.penet.fi wrote: > > edited, from alt.activism > > === > > This editorial was in the Arizona of 8/22. It was written by > William P. Cheshire, Senior Editorial Columnist. Oddly enough, this distribution, then, violates Mr. Cheshire's copyright. 'Spose that's one reason the author used the anonymous service. Unfortunately, not too many people think that protecting the rights of someone who created original written work is unreasonable government intrusion. I think even the FF's believed in intellectual property rights. > LOOKING BEYOND THE WACO SMOKE > An anonymous tipster sent me a videotape the other day > describing in startling detail the government's shootout, siege > and ultimate destruction - possibly deliberate - of the Branch > Davidian compound outside Waco, Texas. etc. etc., lots of "our gubment was doing something Wrong". Can someone tell me, please, what the HELL this has to do with cryptography, privacy, digital signatures, digital cash, or ANYTHING except a particular political discussion? BLOODY NOTHING, that's what. If I wanted to receive messages about police and military ethics (or idiocy), I'd subscribe to a bazillion newsgroups like alt.talk.politics, alt.conspiracy, etc. NOT THIS ONE! Suppose that's another reason the poster used the anonymous server. Like I said, folks, topics exist for a reason. This post was so far off the mark as to be obvious even to the most dyslexic Prozac-addict in southern California. PLEASE don't clutter up newsgroups with stuff that don't belong. Note that it was grabbed from alt.activism -- where it DOES belong ... and should have stayed. (NOTE: can anyone else think of a GOOD reason for it to have been anon'd? ;-) Makes you wish for an anon service that detects bull-headedness and blind idealism -- and nukes it. Andrew From ah at dunaad.co.uk Mon Sep 13 04:13:36 1993 From: ah at dunaad.co.uk (Alan Hunter) Date: Mon, 13 Sep 93 04:13:36 PDT Subject: SUBSCRIBE Message-ID: Please SUBSCRIBE A.Hunter at dunaad.co.uk Thanks From pcw at access.digex.net Mon Sep 13 07:19:52 1993 From: pcw at access.digex.net (Peter Wayner) Date: Mon, 13 Sep 93 07:19:52 PDT Subject: Stegno and DAT and digital music... Message-ID: <199309131414.AA07464@access.digex.net> In this week's Sunday NYT, Hans Fantel, their music guy, writes at length about the new "dithered" CD's and how the guys have improved the sound. He says that the original CD format was limited to 16 bits of sound because of costs. But many audiophiles reacted very negatively to the tinny, metalic quality to the music. For this reason, the companies have developed 20 bit DAT recording tape and then come up with ways to "dither" this into 16 bits. I am curious if anyone knows the details of these algorithms. Also, his point suggests that flipping the least significant bit of 16 bit music may not be imperceptable to some ears. If the classical music starts to sound tinny then there might be something subversive in the least significant bits. -Peter Wayner From pmfitzge at fitz.b30.ingr.com Mon Sep 13 07:43:39 1993 From: pmfitzge at fitz.b30.ingr.com (Patrick M. Fitzgerald) Date: Mon, 13 Sep 93 07:43:39 PDT Subject: PGP front-ends In-Reply-To: <9309130416.AA23342@bwnmr4.harvard.edu> Message-ID: <199309131435.AA10756@fitz.b30.ingr.com> frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) writes: > > > Can you write code? Maybe you can make a Windows shell for PGP. > > I said this once before, in private email so I'll repeat it here for > the everybody: I'm working on a windows shell for PGP [...] Fred: How about sending me a snapshot of your gui... I might be up for making one on the Amiga. Any Amiga users on the list? Is there a front-end for X? -- Patrick M. Fitzgerald, pmfitzge at ingr.com ______ / ___ ) On two occasions I have been asked [by members / __)/ /__ of Parliament!], 'Pray, Mr. Babbage, if you (_/it(_____) put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage From mlarsen at cisco.com Mon Sep 13 08:23:39 1993 From: mlarsen at cisco.com (Michael Kelly Larsen) Date: Mon, 13 Sep 93 08:23:39 PDT Subject: unsubscribe Message-ID: <199309131516.AA27525@lager.cisco.com> unscubscribe From bill at kean.ucs.mun.ca Mon Sep 13 09:33:39 1993 From: bill at kean.ucs.mun.ca (Bill Garland) Date: Mon, 13 Sep 93 09:33:39 PDT Subject: subscribe Message-ID: <009727C5.3ECD6DC0.10692@Leif.ucs.mun.ca> Please add me to your mailing list. Thanks. Bill Garland bill at kean.ucs.mun.ca From tcmay at netcom.com Mon Sep 13 11:33:42 1993 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 13 Sep 93 11:33:42 PDT Subject: Cypherpunks--Where Do We Go From Here? Message-ID: <9309131826.AA18811@netcom.netcom.com> This long posting summarizes the recent meeting and includes my own presentation to the meeting. Our physical meeting on Saturday in Mountain View, CA was very successful, with 35 people in attendance, most of them in the same room at the same time for the whole 6 hours (this is not always the case!). The best attendance we've ever had, or at least equalling the crowd we had for the special emergency meeting following the Clipper announcement. I think we all knew the importance of the one-year anniversary and the need to think carefully about our future direction (modulo the fact, pun intended, that we are an organizational anarchy, with little structure, diverse viewpoints, and no compelling reason to get more organized). Eric Hughes began the meeting shortly after noon. Speakers included myself, Sandy Sandfort, Nick Szabo, Dean Tribble, Whit Diffie, Russell Brand, John Gilmore, and others (I apologize to anyone I left out, as I was taking minutes of the meeting and so am relying just on my recollection). Rather than attempt to recap all that was said--and a lot gets said in six hours!--it's best that folks give their own summaries of what they said, or what others said, whatever. And they can post their handouts if they have them available in the right format...Sandy has already done this, for example. Just for quick orientation, here were some of the main themes: * GOALS. Where we have been, where we are, and where we are going. Has progress stalled, after the early results with Phil Zimmermann's PGP and with our Cypherpunks remailers? (We concluded we are mostly in a useful consolidation phase, digesting the early gains as we contemplate future directions in better remailers, digital postage and money, steganography, etc.) * POLITICS. We touched on the political aspects, especially since the "privacy, not anarchy" thread had just the List the few days before the meeting. The consensus was s friendly realization that we would not be resolving anything politically, that the socialists and Hayekians may interpret the world differently, but still agree on the need for strong cryptography. (Folks should appreciate that the physical meetings are very friendly affairs, generally much less contentious than the List can be at times...I wonder what this says about our ideas for anonymous networks? Just something to think about.) * "TAZ." Eric Hughes read a long selection from Hakim Bey's ("not his real name") "TAZ," published in 1990, and excerpted in "Mondo 2000" a while back. "TAZ" was published/helped by Dave Mandl, one of our New York City list members ("New York City?...get a rope!"). TAZ stands for "temporary autonomous zones," a kind of crypto anarchy, albeit with more of postmodernist, literary slant than what we have been pitching. (Our developments were independent, as I had seen only the Mondo excerpt, and that only a couple of years ago, while my "Crypto Anarchist Manifesto" was distributed in 1988.) * BANKS. Digital banks, offshore banking, and possible projects that are starting up. Sandy Sandfort presented material on this. There is real interest in this. We may have "Caymans Cypherpunks" or "Bahamas Cypherpunks" meetings before long. * SPECULATIVE PROJECTS. Nick Szabo presented a list of possible projects, which he recently posted to the list. Things like "the Internet Casino" (betting markets), data havens, and so on. * PRIVACY. Judi Clark, active in the Computers, Freedom and Privacy Conference and other Bay Area computer privacy groups, asked us for inputs to some lectures being arranged. She asked what a "secure network" should be, in terms of privacy. Ideas would fill a post by themselves, but were, as I remember them: voluntary disclosure of data (you tell only what you want made available), self-enforcement as much as possible, limited root access to systems, encryption of links whenever possible, etc. (I'm doing a poor job of summarizing this brainstorming session, though.) * PATENTS. Russell Brand, a computer scientist now attending law school, gave a 90-minute lecture on intellectual property law, with special attention to the cloud of RSA patents (set to expire 1998-2002). * LAWSUITS. John Gilmore spoke briefly about his FOIA lawsuits against the NSA and NIST (especially over the failure to produce Clipper decision documents in a timely fashion, as spelled out in the FOIA procedures) and advised us that some important hearings are coming up in San Francisco in the next month or so. He'll tell the List when the exact dates are. * NEW LANGUAGES. Dean Tribble updated us on "Joule," the secure language/operating system he and others are working on. (One of his associates, Norm Hardy, once worked for IBM on the "Harvest" computer installed at NSA in the early 60s, and detailed in Bamford's "The Puzzle Palace." Norm will give a presentation on Harvest at the next Cypherpunks meeting.) * MISC. Mark Miller strongly praised the "Metro" cover story on "Code Warriors" (the Julian Dibbell piece), noting that two major stories on Cypherunks ("Wired" cover as well) had used the American flag as a motif and had implied that strong crypto and privacy are fundamental American values and that we are cypherpatriots. Several newcomers (Sameer Parekh, Harry Bartholomew, Doug Merritt, others I apologize to for not mentioning). There was a general feeling that the importance of crypto is becoming more and more apparent every day. We've come a long way this past year. After the meeting, we adjourned to the Applewood Inn in Menlo Park for pizza, a break from the usual Chinese or Thai food. After this, several Cypherpunks were seen across the street in the huge Kepler's Books, some even buying the latest issue of "Wired" despite the fact that cryptography inexplicably went from the being #1 on the "Hot" list to not even being listed in this issue! (I guess crypto is being retired from contention, out of fairness to things like virtual reality and body piercings!) ........ Included below is the presentation I gave at the meeting. I also presented a detailed PERT chart graph of important milestones on the way to long range goals. I regret that this ASCII format is too limited to contain it, to paraphrase a French mathematician in the news lately. (Don't ask for PostScript versions...the effort of getting everything right in transmission is unwarranted by the chart.) I apologize for the occassional word wrap seen here, as I used an outliner to generate the material and the line lengths sometimes are too long. Cypherpunks--Where Do We Go From Here? I. Difficult to Set Directions A. an anarchy...no centralized control B. everyone has some axe to grind, some temporary set of priorities C. little economic motivation (and most have other jobs) II. Past, Present, Future A. Where We've Been 1. successful mailing list and monthly meetings 2. spread of crypto: Cypherpunks have helped (PGP)...publicity, an alternative forum to sci.crypt 3. remailers, encrypted remailers 4. ideas for perl scripts, mail handlers 5. general discussion, with folks of several political persuasions 6. concepts: pools, ILF, BlackNet B. Where We Are Now 1. Stalled? a) crypto protocols are hard to build, analyze, deploy b) little incentive for people to put incredible efforts in (unless they're researchers in the field)....look at effort just for PGP c) Has the "low-hanging fruit" already been picked? 2. Need to Decide on Nature of Cypherpunks C. Where We Could Go in the Future 1. Privacy Emphasis 2. Tools and Techniques Emphasis 3. Education and Lobbying Emphasis 4. Possible Directions a) Crypto Tools...make them ubiquitous "enough" so that the genie can't be put back in the bottle (1) can worry about the politics later (socialists vs. anarchocapitalists, etc.) (2) develop and deploy a variety of tools (3) attempt to implement as many "research" tools as possible (4) Commercial Opportunities! b) Education (1) educating the masses about crypto, public forums (2) this was picked by the Cambridge/MIT group as their special interest c) Politics and Lobbying (1) talking to Congressional aides and committee staffers, attending hearings, submitting briefs on proposed legislation (2) coordinating with EFF, CPSR, ACLU, etc. (3) this was picked by the Washington group as their special interest, which is compellingly appropriate (Calif. group is simply too far away) d) Legal Challenges (1) lawsuits against Skipjack, FOIA requests, etc. III. The Heart and Soul of Cypherpunks? A. Competing Goals: 1. Personal Privacy a) PGP, integration with mailers b) education 2. Reducing the Power of Institutions a) whistleblowers group b) Chaum-style credentials (vs. national ID cards, etc.) 3. Crypto Anarchy B. Common Purposes (beyond ideology) 1. Spreading strong crypto tools and knowledge a) PGP 2. Fighting government restrictions and regulations a) Clipper/Skipjack fight was a unifying experience 3. Exploring new directions in cryptology a) digital mixes, digital cash, voting b) no other groups are trying all that we're trying IV. Thesis: Strong crypto is a good thing A. Tool against governments of all flavors, left and right B. Religious freedom C. Free speech D. Personal choice V. Thesis: Crypto can become unstoppable if critical mass is reached A. analogy: the Net...too scattered, too many countries, too many degrees of freedom B. so scattered that attempts to outlaw strong crypto will be futile...no bottlenecks, no "mountain passes" (in a race to the pass, beyond which the expansion cannot be halted except by extremely repressive means) VI. The Path to Crypto Anarchy-A Personal View A. Uses: 1. remailers, anonymity 2. digital cash, for privacy and for tax evasion 3. data havens, bootleg medical treatments, information markets 4. bookies, betting, numbers games, smuggling, tax evasion 5. religious networks (digital confessionals) 6. crimes, digital hits B. Increasing Personal Privacy (under attack, of course) C. Increasing Connectivity--networks, links, speeds D. Privacy + Connectivity = Beyond Control of Governments or Institutions = Crypto Anarchy PERT chart was included at this point. -- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: by arrangement Note: I put time and money into writing this posting. I hope you enjoy it. From gtoal at an-teallach.com Mon Sep 13 12:29:40 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Mon, 13 Sep 93 12:29:40 PDT Subject: ... long live DES (sic) Message-ID: <9118@an-teallach.com> In article <"21031101903991/16267 David.D.L.LANDGREN at pub.oecd.fr writes: > It's all very well to be able to crack DES in 3.5 hours, but I don't know > of too many people who obligingly send out the plaintext and cyphertext of > a message together, or in some other way combinable. If U can get the It may ostensibly be a known-plaintext crack, but with a tiny addition of chips to recognise cleartext, fixed markers like the run in to a compressed file or mail file, or generally less than random output, it ceases to be so. Such chips already exist. G -- Personal mail to gtoal at gtoal.com (I read it in the evenings) Business mail to gtoal at an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212 From geoffw at nexsys.net Mon Sep 13 12:49:41 1993 From: geoffw at nexsys.net (Geoff White) Date: Mon, 13 Sep 93 12:49:41 PDT Subject: The "Cypherpunk Melting Pot" Message-ID: <9309131740.AA04418@nexsys.nexsys.net> > > Anonymous says: > > Bullshit. Privacy is not inherently subversive at all. If you > > take the time to browse back through the Bill of Rights, you might > > recognize this paragraph - > > > > ARTICLE IV > > > > The right of the people to be secure in their persons, > > houses, papers, and effects, against unreasonable searches and > > seizures, shall not be violated, and no Warrants shall issue, but > > upon probable cause, supported by Oath or affirmation, and > > particularly describing the place to be searched, and the persons or > > things to be seized. > > I'll point out something about the history of that line most people > forget. > > Our fine nation was founded by drug smugglers. The drug in question > was Rum, admittedly, but none the less, the point remains -- the > revolutionary war was financed by big time criminals like John Hancock > who made their money in smuggling contraband and other similar acts. > They made sure that the constitution they got was supportive of their > particular business interests. History teachers don't like pointing > this sort of thing out, but its none the less true. My "social studies" teacher from 7 - 9th grade, Mr. Codianni made sure we knew this! (This was around 1968/69 so the System was being stress on all ends) We had a textbook for american history that was made up completely of primary and secondary sources. It was obvious to me early on that the main reasons for the american revolution were economic as opposed to some overwhelming altruism. All of the founding fathers had a lot at stake but would also make a bundle if they could just get rid of that middleman (King George III) From nate at VIS.ColoState.EDU Mon Sep 13 12:58:43 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Mon, 13 Sep 93 12:58:43 PDT Subject: pgpc 2.1 available Message-ID: <9309131950.AA05516@nagel.VIS.ColoState.EDU> -----BEGIN PGP SIGNED MESSAGE----- pcpc (was PGPcompose) 2.1 is available for anonymous ftp from 129.82.156.104 in /pub/pgpc it's in your choice of regular UNIX compress or the new gnuzip format... Adds the ability to mail through anon.penet.fi and then send the mail on through remailers galore. Special thnaks to stig at netcom.com for pointing out lots of problems, and for even re-writing some of the code (specifically the remailer selection piece). Uh, that's it. Have fun, and mail me if you like it. -nate sammons nate at vis.colostate.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJTO9dTgi1fmrpxlAQFTUwP8DIcrJNOYE1JwmgJi8giQfBEg/fBGZ7m7 NI30N8iKBWonTU1OT0OehAKQOj++mHQ2faSjabGq6K8F8UjDKfMxykABrr6LQIaK LRnZER9H/RA0CBpgpL6kN7l4J3gn7RDCS449lBfV1pGucgzN9aSUM0B7UQry+mXN kRtAbTDHzTE= =g2an -----END PGP SIGNATURE----- From norm at netcom.com Mon Sep 13 13:13:43 1993 From: norm at netcom.com (Norman Hardy) Date: Mon, 13 Sep 93 13:13:43 PDT Subject: Stegno and DAT and digital music... Message-ID: <9309132007.AA13469@netcom3.netcom.com> The DAT coding is 16 bit fixed point. The lowest bit always has the same value which is nearly 90 db below the loudest sound. This is perceptible when it is the only signal as is demonstrated in CD demonstrator disks. A steganographer might merely not put data in quiet passages. Alternatively he could plausibly claim that it was caused by a gentle breeze outside the recording studio. In the later case he should add some noise to the next to bottom bit, or generate and add some -85 db white noise and then replace the bottom bit. From remailer at netcom.com Mon Sep 13 13:24:41 1993 From: remailer at netcom.com (remailer at netcom.com) Date: Mon, 13 Sep 93 13:24:41 PDT Subject: PGPcompose (pgpc) 2.0 *just* finished. Message-ID: <9309132014.AA13699@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- At 3:33 AM 9/12/93 -0600, CVL staff member Nate Sammons wrote: >PGPcompose 2.0 is available for ftp from 129.82.156.104 (the macintosh >in my dorm room... ;-) in /pub/pgpc it's all of 11K, so don't sweat >the bandwidth! What does it run on? Should I assume UNIX is the default here? > -will keep you fron doing stupid things, like . . . > signing a message and then sending it > through the remailers or through anon.penet.fi, etc... This ain't so stupid if you're using a digital pseudonym and encrypt at least the first remailer hop. Eternal Optimist Eternal!Optimist at anon.penet.fi -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLJSPwojvfLxJbYYtAQGP8wP8CFhd2hNdP3aUlFYzL56LbilfKn8X2uQj BZEkg3oIXmvwdxC2yWQaujkP0A5AvVCnWdbGyjB4/u7wo48B4cnw3j6zXykHCj8n D6OfmpLrqMpGvfkfgGtuZBC7MItM7GqgZpHq1Cv0RzjG7X59n+pHORfVLTGLTxWJ 070ugKm5PvY= =YS2x -----END PGP SIGNATURE----- From marc at MIT.EDU Mon Sep 13 19:08:48 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Mon, 13 Sep 93 19:08:48 PDT Subject: physical security is the weak link Message-ID: <9309140201.AA10559@milquetoast.MIT.EDU> These articles are reposted with permission from the ClariNet newsgroup clari.tw.computers. Copyright 1993 by UPI. For more info, send mail to info at clarinet.com. --begin repost From: clarinews at clarinet.com (UPI) Subject: Gang hits computer supply firm Keywords: legal investigations, legal, violent crime, computers, manufacturing, corporate products & services, corporate finance Message-ID: Date: Thu, 9 Sep 93 20:06:54 EDT SANTA CLARA, Calif. (UPI) -- Authorities said a gang of armed men stormed into a Silicon Valley electronic supply company Thursday, stealing a large number of valuable computer microprocessors before fleeing in a van. Sgt. Mark Kirby, of the Santa Clara Police Department, said the business takeover was the second of its kind in a week and took just five minutes. ``It's was well planned, they knew exactly what they were looking for,'' he said. ``Unfortunately, this has become a trend in the Silicon Valley. We have about one a month.'' Kirby said the six men rolled up to a loading dock at Wyle Laboratory Inc. about 9:07 a.m. PDT as if they were going to make a legitimate pickup. Two armed men then jumped out of the van and ordered the employees to the floor while four others made their way to a storage room. The police spokesman said a 4-foot-long athletic bag was stuffed with Intel Corp.'s microprocessors -- the ``brains'' that power most personal computers -- and then the robbers fled. No shots were fired and no one was injured. The value of the stolen items was not released. The van was recovered empty a short time later. Kirby said it has since been traced to a Lynwood, Calif., U-Haul dealer and was signed out on Sept. 4. However, the thieves used a fraudulent driver's license to rent the vehicle. Kirby said the thieves likely were filling an order for the lucrative black market in computer components. From: clarinews at clarinet.com (WILLIAM D. MURRAY) Subject: Violent computer chip takeovers worry officials Keywords: lawyers, court proceedings, computers, manufacturing, corporate products & services, corporate finance Message-ID: Date: Fri, 10 Sep 93 19:33:57 PDT SAN JOSE, California (UPI) -- The lucrative trade in computer chips has captured the attention of the state's street gangs, luring them to California's Silicon Valley where the armed takeover of supply warehouses has become a common occurrence, authorities said Friday. Julius Finkelstein, deputy district attorney in charge of the Santa Clara, California, High Tech Crime unit, called the takeovers and the trade in stolen computer parts ``the gang crime of the 1990s. ``We see a trend developing here that concerns us,'' he said. ``These are very violent attacks. Generally, the gang is well armed. It's just a matter of time before someone get hurt. We consider ourselves lucky that it hasn't already happened.'' Finkelstein said gangs were turning their attention to dealing in the impossible to trace stolen chips. ``We are seeing a movement away from drugs and into computer chips by some gangs,'' Finkelstein said. ``This is the coke of the 90's. The chips have become as valuable pound for pound as cocaine and if you get caught, the punishment is much less severe.'' Once the chips are stolen, the district attorney said, they can change hands as many as 3 or 4 times in 24 hours. Finally, the computer parts make their way to what is called ``the gray market. ``It's not really a black market, it's a gray market,'' Finkelstein said. ``That's because it's really not illegal. It made up of suppliers who legitimately buy their chips and those that get them from the gangs. '' The whole system is powered by the marketplace itself. Computer chip manufacturers like Intel Corp. cannot keep pace with the demand for their microprocessors -- the ``brains'' that power most personal computers. So they place companies on an allotment system, forcing those computer manufacturers to turn to the gray market to fill their orders. The chips are also almost impossible to trace. There is no encoding on them to identify them individually. There is a system that shows who manufactured the chips and what day they were manufactured. ``The only way we can generally catch these thieves is to be tipped off,'' Finkelstein said. ``We do prosecute some of these cases, but they are extremely difficult. There is really no way to trace these products. '' The latest takeover robbery occurred Thursday when six masked gunmen stormed into Wyle Laboratory Inc. in Santa Clara and in a matter of five minutes had stolen thousands of dollars worth of Intel CPU microprocessors. Sgt. Mark Kirby, of the Santa Clara Police Department, said the robbery was the second of its kind in a week. He added that the area is averaging at least one of these armed takeovers a month. ``It was well planned, they knew exactly what they were looking for,'' he said. ``Unfortunately, this has become a trend in the Silicon Valley. '' However, Kirby said this one was different -- it was the first pulled off a gang of black gunmen. The robbers abandoned van was discovered later in the day Thursday and traced to Lynwood, California, a location frequented by the Los Angeles gangs. --end repost If people are willing to go to these measures to steal Intel microprocessors, which are generally available, imagine what people will do in order to steal unprogrammed Skipjack chips. In the volume the Government would like to see them made, the physical security which one might want to give to a classified production facility will be difficult or impossible. Marc From ld231782 at longs.lance.colostate.edu Mon Sep 13 19:54:46 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Mon, 13 Sep 93 19:54:46 PDT Subject: NSA harassing crypto software writer over export (fwd, sci.crypt) Message-ID: <9309140249.AA25621@longs.lance.colostate.edu> - NSA harassment alive and well - is this company a `small fish'? doesn't NSA have something better to do? - his request is overbroad, but still needs some kind of help - maybe the laywers on the list can help out too ===cut=here=== From: grady at netcom.com (Grady Ward) Subject: help me fight NSA Organization: Moby lexicons Date: Mon, 13 Sep 1993 23:54:54 GMT An individual at the NSA has recently been warning my publisher of Moby Crypto that they will be breaking the law if they export the product. Since I do not include any executables, only source and other documentation that routinely appears in textbooks that are exported, I think this hasseling is unwarranted and unconstitutional. Since knocking heads with the NSA may result in some kind of process, I need some assistance to bolster my case. What you can do: please send me a reference on every book or magazine article you are aware of that contains any 'source code'. The code can be a fragment or in any computer language as long as it implements encryption or other material that would be export controlled if incoporated in an executable. I think collecting a large number of these citations will help my attornies in pointing out the absurdity of the situation to government attornies if necessary. Please e-mail any citations that you have. Thanks ahead of time. Grady Ward grady at netcom.com From marc at MIT.EDU Mon Sep 13 20:33:47 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Mon, 13 Sep 93 20:33:47 PDT Subject: NSA harassing crypto software writer over export (fwd, sci.crypt) In-Reply-To: <9309140249.AA25621@longs.lance.colostate.edu> Message-ID: <9309140324.AA10611@milquetoast.MIT.EDU> What exactly is "Moby Crypto"? Is it a book? A disk? The current law can be interpreted to mean that a piece of code on paper is legal, but on a disk is not. Clearly, this is what the NSA is doing. Stupid? Yes, IMHO. But the government has refused to see it this way. This person does not need lawyers. He needs congresscritters, preferably a majority of them :-/ Marc From marc at MIT.EDU Mon Sep 13 20:34:47 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Mon, 13 Sep 93 20:34:47 PDT Subject: NSA harassing crypto software writer over export (fwd, sci.crypt) In-Reply-To: <9309140249.AA25621@longs.lance.colostate.edu> Message-ID: <9309140325.AA10617@milquetoast.MIT.EDU> What exactly is "Moby Crypto"? Is it a book? A disk? The current law can be interpreted to mean that a piece of code on paper is legal, but on a disk is not. Clearly, this is what the NSA is doing. Stupid? Yes, IMHO. But the government has refused to see it this way. This person does not need lawyers. He needs congresscritters, preferably a majority of them :-/ >> I think collecting a large number of these citations >> will help my attornies in pointing out the absurdity >> of the situation to government attornies if necessary. He is naive if he things proving that a law is absurd is sufficient to nullify it. Marc From sameer at netcom.com Mon Sep 13 20:49:47 1993 From: sameer at netcom.com (Sameer Parekh) Date: Mon, 13 Sep 93 20:49:47 PDT Subject: testing remailers, the keys for my remailers Message-ID: <9309140343.AA15529@netcom.netcom.com> Has anyone written or is someone writing a script which will take a list of remailers, and ping each of them to see if they are working, both encrypted and unencrypted? If no one has taken on that task, I'd be willing to do it.. I'll list here the remailers for whom I have the keys for... if another remailer exists which I don't know about please send me the key. (Also-- here's the keys for my remailers...) Type bits/keyID Date User ID pub 1024/69464F 1993/09/11 Sameer's Remailer pub 1024/9E3311 1993/09/02 Sameer's Remailer pub 1024/567449 1993/09/01 Sameer's Remailer pub 512/64E8A7 1993/03/05 Remailing Service Anonymous Remailer pub 1024/02C389 1993/06/07 Anonymous Anonymous pub 1024/DB04AB 1993/05/05 Mr. Remailer pub 1024/BA80A9 1992/11/26 Remailer (remailer at rebma.mn.org) pub 1024/7B47C3 1993/01/20 Anonymous Remailer pub 1024/EBCC89 1993/04/27 Cypherpunk Remailer at pub 1024/B5A32F 1992/12/13 Remailer pub 510/0BB437 1992/11/12 Remailing Service pub 510/5620D5 1992/11/15 Remailing Service pub 512/7D154B 1993/04/04 jarthur remailer c/o 13 key(s) examined. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyRU70AAAEEALsLEv31NHZrNBsOYqsr064hT/SUtztIfGEkNxMS9KXo9Sil 3y8hY3r+mkeVPyvinmdjOPBIzHQmzezs9o9Tu/RAYQy8IdrWv/8KjIcZ0K3B+SVp 5d+fW14pOBm6MbcNpjK9RXVBpwAxjcYF2PXor8kT56J+2I9T4W08cWvcaUZPAAUR sAEAtCxTYW1lZXIncyBSZW1haWxlciA8c2FtZWVyQHNvZGEuYmVya2VsZXkuZWR1 PrABAIkAlQIFECyVO8EL8mtIoS4LrQEBDywD/0P2Zx2xWOxv076XsyDSYBYMh3jb iHbFisoaNwwJTcV8p6WwwBZNCsgGs3fEMuhrT2XHCN7f8CGkLvUivt6HvMgTl1EK lD1gaV6b4ZAZzo6PoFB6/8Bxa1K2aMnp0nNXuvRoIHs/jzFVF5YcM1nucUG85pL4 BgK2hOsAPkTK2Ru3sAEAmQCNAiyGXXoAAAEEAMDtjyzGpLKugc49+Na4GZcUZ1Q1 jyZYeofTdNwlTIbs4bGYOaeFCXaQluD4ANsLn9muMVae+q+3gZsIq14klQLO6Xe5 5pZ0Efx5shfFU24S9+xARUrDfMMqD5TtaoBXH9aQBV9mVo0h5Pxu6ng9B0A+GPJg /ygdVqW95EIJnjMRAAUTsAEAtCVTYW1lZXIncyBSZW1haWxlciA8c2FtZWVyQG5l dGNvbS5jb20+sAEAiQCVAgUQLJU79gvya0ihLgutAQGZBQQAgoctBIYxoaL3wIm7 7cKiZFOpXvkgD6ihV1c8La/udKw6MsVCts2ry2Dc8gm3mfEHEWTtZ8h3Wj9yPCma 9C39FiyikxK/JVMm2mOtPxhokY6YBOZSSMlCBdvm7Gtox9Cy65AOLCo0YZh+X9GV CPgyA5S3QyxPGRVSmxil7VHAHFKwAQCZAI0CLIToKAAAAQQAuoNVv3/OeG+gbSMy AW/V7MlY0rILldtec7oO9u5we+oWwsdJi5C3G2spWy6TbIa26sxVYUCacfzEKal/ TBRYhXPJ01BuDggHr8XMn9l3Bdaa+9QmLZHogokHQ8YOGJalHB8esu2Fy7NfDErR u5YZboEAUBwtXSKkTCGeeFJWdEkABRGwAQC0M1NhbWVlcidzIFJlbWFpbGVyIDxj czYwYS1xdUBjb3J5LkVFQ1MuQmVya2VsZXkuRURVPrABAIkAlQIFECyVPBcL8mtI oS4LrQEBKbgEAMSkfgm+PDdC2J6s+aq32TrO9iKmS3nZ1Q0/+eGznGcS6INys6qX MH7GCF3VDwhDBGf1l7/egd8dnNLn29zYSi2uX/H90YqzDlIRW3JMtq9ZIjCkSakZ SnSbEJOgJp/G1t9kZFPP/UDv9iMtqbJXxX7IP2r8Axzv1uXAmUI/WXEksAEA =BdhD -----END PGP PUBLIC KEY BLOCK----- -- Sameer sameer at netcom.com From rjc at gnu.ai.mit.edu Mon Sep 13 21:48:49 1993 From: rjc at gnu.ai.mit.edu (Ray) Date: Mon, 13 Sep 93 21:48:49 PDT Subject: testing remailers, the keys for my remailers In-Reply-To: <9309140343.AA15529@netcom.netcom.com> Message-ID: <9309140441.AA22003@geech.gnu.ai.mit.edu> Sameer Parekh () writes: > > Has anyone written or is someone writing a script which will > take a list of remailers, and ping each of them to see if they are > working, both encrypted and unencrypted? If no one has taken on that > task, I'd be willing to do it.. I'll list here the remailers for whom > I have the keys for... if another remailer exists which I don't know > about please send me the key. Yes, I started writing such a system about 3 weeks ago but quit when school started. Basically, it was a mail server to be operated at gnu. Remailer operators would "register" their remailer along with some stats (PGP or RIPEM capability? Public Key? Private Machine? Delay time? Mix capability? Owner? Comment field.) The software would then "ping" each remailer every 6 hours and update its database. If you wanted a list of current working remailers, you would ask the mail server (I was even thinking of adding socket capability for fast query) I might eventually take some time to finish it (it wasn't even 50% done) but I've got too much work to do now. -Ray -- Ray Cromwell | Engineering is the implementation of science; -- -- EE/Math Student | politics is the implementation of faith. -- -- rjc at gnu.ai.mit.edu | - Zetetic Commentaries -- From mbriceno at aol.com Mon Sep 13 23:43:51 1993 From: mbriceno at aol.com (mbriceno at aol.com) Date: Mon, 13 Sep 93 23:43:51 PDT Subject: warez garbage cluttering the screen Message-ID: <9309140231.tn02846@aol.com> What have these endless bandwidth wasting lists of supposed warez sites to do with Cypherpunks? Please take your personnal vendettas elsewhere. I pay for DL time. ---Marc From loki at convex1.TCS.Tulane.EDU Tue Sep 14 00:38:51 1993 From: loki at convex1.TCS.Tulane.EDU (the mischeivious god) Date: Tue, 14 Sep 93 00:38:51 PDT Subject: warez garbage cluttering the screen In-Reply-To: <9309140231.tn02846@aol.com> Message-ID: <9309140737.AA25877@convex1.tcs.tulane.edu> > > What have these endless bandwidth wasting lists of > supposed warez sites to do with Cypherpunks? Please > take your personnal vendettas elsewhere. I pay for DL time. > > ---Marc > GRRRRRRRRRRRR...... I dont have to pay and I rather found it useful. loki From msattler at netcom.com Tue Sep 14 00:43:51 1993 From: msattler at netcom.com (msattler at netcom.com) Date: Tue, 14 Sep 93 00:43:51 PDT Subject: The "Cypherpunk Melting Pot" Message-ID: <9309140743.AA14959@netcom.netcom.com> Anonymous said: > 5. Cypherpunks' mission is to evangelize the use of > privacy. Sell the sizzle, not the steak! Privacy > is the steak. The sizzle is the possibility of > GETTING AWAY WITH SOMETHING. I have a real problem with the attempted marriage of anarchy and the Bill of Rights. I'm interested in the issue of privacy not because I want to screw our government out of my taxes, but because I want to have the ability to communicate with any of you in private. At different times in our history certain opinions have been suspect for what we now consider no good reason. If I'm a homosexual, I want to be able to communicate with others without worrying that my employer will monitor my email and fire me for being homosexual. If I'm Jewish, and I work in the deep south... Privacy is the ability to keep and communicate thoughts without worrying about someone using them against you. I'm offended to be clumped in with anyone who advocates selling privacy to get away with something. ----------------------------------------------------------------------------- Michael S. Sattler msattler at netcom.com +1 (415) 358-3058 Digital Jungle Software Encrypt now; ask me how. (finger to get PGP key) From thug at phantom.com Tue Sep 14 00:58:51 1993 From: thug at phantom.com (Murdering Thug) Date: Tue, 14 Sep 93 00:58:51 PDT Subject: warez garbage cluttering the screen In-Reply-To: <9309140231.tn02846@aol.com> Message-ID: > What have these endless bandwidth wasting lists of > supposed warez sites to do with Cypherpunks? Please > take your personnal vendettas elsewhere. I pay for DL time. > > ---Marc 1) The fl0w of wArEz keeps the universe in perfect harmony. Without wArEz there would be no life as we know it. And just because you are a rich fat fuck who can afford to plunk down $795 for a copy of Pagemaker, you shouldn't take a moral stance against those who cannot afford such extortion yet need these software tools to keep up technologically with rich fat fucks like yourself. 2) wArEz have A LOT to do with Cypherpunks. Software, pirated or otherwise has value, and as such it must be considered as a form of digital money. One may trade encrypted wArEz anonymously over anonymous mailing lists, FSP/FTP sites, newsgroups like the proposed alt.waste, and BlackNet. wArEz _are_ digital gold coins, they have inherent value, unlike useless encrypted random number certificates advocated by others. 3) I don't give a flying fuck if you pay for your DL time. If you're stupid enough to be using AOL as your Internet port of entry, then you deserve to be ripped off by Compuserve's evil bastard cousin. Why don't you point and click yourself a new brain, and join a flat-rate system like Netcom or any of the hundred other public access internet sites. Support the small entrepreneurs instead of those lazy fat bastard nazi censors at AOL. Thug From sameer at netcom.com Tue Sep 14 01:28:52 1993 From: sameer at netcom.com (Sameer Parekh) Date: Tue, 14 Sep 93 01:28:52 PDT Subject: Really simple script for pgp Message-ID: <9309140826.AA19612@netcom.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- I wrote a really simple script for PGP which I am particularly proud of. (I'm not very experienced at sed/awk/etc. hacking, so that's why I'm so happy with it.) All this does is extract all keys from your pgp keyring with the partial string specified in the cmdline and saves it to either the keyring given as the second argument or a file with the name of the partial string. - -- Sameer sameer at netcom.com #!/bin/sh if [ $2 ] then FILE=$2 else FILE=$1 fi pgp -kv $1 | tail +3 | cut -c30-150 | sed -n -e '/./p' | sed -e 's/^.*$/pgp -kxf \"&\"/' | /bin/sh | pgp -kaf $FILE -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJWAHgvya0ihLgutAQF+qAP6AnuLuCyLKAdysbWbcM5CVYozSQK8ESCf j+njlB9PkfBGA/ap15WWcWQZybeXvglfzl2gjDYftslbb0UNqUyGEw4dPrthGq93 7WiVceatZmGf9zzwvrEOV8xMJfG7SovxY/KDsrXJOxXPTXpdJTB5cG42gQe/MSUX Y3S3RWcD0Lo= =9iQ7 -----END PGP SIGNATURE----- From newsham at wiliki.eng.hawaii.edu Tue Sep 14 01:45:08 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Tue, 14 Sep 93 01:45:08 PDT Subject: warez garbage cluttering the screen In-Reply-To: Message-ID: <9309140844.AA04655@toad.com> > > 1) The fl0w of wArEz keeps the universe in perfect harmony. Without wArEz > there would be no life as we know it. And just because you are a rich fat > fuck who can afford to plunk down $795 for a copy of Pagemaker, you > shouldn't take a moral stance against those who cannot afford such > extortion yet need these software tools to keep up technologically with > rich fat fucks like yourself. If you think prices are outrageous, let the software manufacturers know. Let your friends know, let everyone know. The reason they charge such prices is because they can. The reason they can is because people let them. Even better, support free software alternatives, and get your friends to do the same. > 2) wArEz have A LOT to do with Cypherpunks. Software, pirated or > otherwise has value, and as such it must be considered as a form of > digital money. One may trade encrypted wArEz anonymously over anonymous > mailing lists, FSP/FTP sites, newsgroups like the proposed alt.waste, and > BlackNet. wArEz _are_ digital gold coins, they have inherent value, > unlike useless encrypted random number certificates advocated by others. warez has little to do with cypherpunks other than the fact that warez dewds can use crypto technology to help protect themselves against overly strict and mostly industry driven laws against piracy. Warez is used more as an electronic ego booster than a currency. > 3) I don't give a flying fuck if you pay for your DL time. If you're > stupid enough to be using AOL as your Internet port of entry, then you > deserve to be ripped off by Compuserve's evil bastard cousin. Why don't > you point and click yourself a new brain, and join a flat-rate system like > Netcom or any of the hundred other public access internet sites. Support the > small entrepreneurs instead of those lazy fat bastard nazi censors at AOL. support the cause you believe in. By the same token dont support evil software companies *even by stealing their software!* Use alternatives. Stealing their software doesnt hurt them (contrary to what you would have them believe). Supporting free software and any competitors they have who have plolicies you approve does hurt them. > Thug From newsham at wiliki.eng.hawaii.edu Tue Sep 14 01:48:51 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Tue, 14 Sep 93 01:48:51 PDT Subject: warez garbage cluttering the screen In-Reply-To: <9309140737.AA25877@convex1.tcs.tulane.edu> Message-ID: <9309140848.AA04683@toad.com> > > > > > What have these endless bandwidth wasting lists of > > supposed warez sites to do with Cypherpunks? Please > > take your personnal vendettas elsewhere. I pay for DL time. > > > > ---Marc > > > GRRRRRRRRRRRR...... I dont have to pay and I rather found it useful. > > loki Then maybe a list for warez topics should be formed. I find alot of things on the cypherpunks list that is off-topic to be interesting. The list is however for the discussion of cryptography and privacy. The only thing that all people on this list have in common is their interest in crypto and privacy, and the list should stick to those points. Other topics that are interesting should be taken to private email or put on the appropriate lists (barring of course the occasional slip or wandering of the topic). From rjc at gnu.ai.mit.edu Tue Sep 14 01:48:56 1993 From: rjc at gnu.ai.mit.edu (Ray) Date: Tue, 14 Sep 93 01:48:56 PDT Subject: warez garbage cluttering the screen In-Reply-To: Message-ID: <9309140848.AA23759@geech.gnu.ai.mit.edu> Murdering Thug () writes: > > > What have these endless bandwidth wasting lists of > > supposed warez sites to do with Cypherpunks? Please > > take your personnal vendettas elsewhere. I pay for DL time. > > > > ---Marc > > 1) The fl0w of wArEz keeps the universe in perfect harmony. Without wArEz > there would be no life as we know it. And just because you are a rich fat > fuck who can afford to plunk down $795 for a copy of Pagemaker, you > shouldn't take a moral stance against those who cannot afford such > extortion yet need these software tools to keep up technologically with > rich fat fucks like yourself. And later... > 3) I don't give a flying fuck if you pay for your DL time. If you're > stupid enough to be using AOL as your Internet port of entry, then you > deserve to be ripped off by Compuserve's evil bastard cousin. Why don't > you point and click yourself a new brain, and join a flat-rate system like ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Netcom or any of the hundred other public access internet sites. Support the > small entrepreneurs instead of those lazy fat bastard nazi censors at AOL. Obviously, if you had a brain, you'd be using FreeWare TeX instead of PageMaker, or you'd realize that there are competing packages out that with similar features but at a lower cost. Ya, software is extortion alright. Produce wealth in today's world but refuse to release it to looters without charging them a fee and you're in the protection reacket. Ha. The part about warez being digital coins is nonsense. If there was a free fL0w 0f wAr3z, your currency would be devalued to nothing. There'd be no point of "trading" warez cause anything you had, I could get myself. It is only because wArEz]<1dZ like yourself run pseudo-elitist cliques where having 0-dayz old wAReZ is king that you see any value at all in trading Mortal Kombat or beta copies of Windoze. (these "warez" sites on the net are hilarious. 99% of them are run out of the /tmp directory (under ftp or fsp) and others under student accounts. Unknowingly, many of them show up under archie! So much for secrets. Save yourself, and the net, the trouble of trading warez via anonymous remailers and call up your local pirate bbs instead) From khijol!erc at apple.com Tue Sep 14 01:49:53 1993 From: khijol!erc at apple.com (Ed Carp) Date: Tue, 14 Sep 93 01:49:53 PDT Subject: warez garbage cluttering the screen In-Reply-To: Message-ID: > > What have these endless bandwidth wasting lists of > > supposed warez sites to do with Cypherpunks? Please > > take your personnal vendettas elsewhere. I pay for DL time. > > > > ---Marc > > 1) The fl0w of wArEz keeps the universe in perfect harmony. Without wArEz Ommmmm....."If you can explain it, it isn't the Tao..." > there would be no life as we know it. And just because you are a rich fat > fuck who can afford to plunk down $795 for a copy of Pagemaker, you > shouldn't take a moral stance against those who cannot afford such > extortion yet need these software tools to keep up technologically with > rich fat fucks like yourself. If he's complaining about d/l time, I guess he can't be too rich. Or maybe that's how he got that way? > 2) wArEz have A LOT to do with Cypherpunks. Software, pirated or > otherwise has value, and as such it must be considered as a form of > digital money. One may trade encrypted wArEz anonymously over anonymous > mailing lists, FSP/FTP sites, newsgroups like the proposed alt.waste, and > BlackNet. wArEz _are_ digital gold coins, they have inherent value, > unlike useless encrypted random number certificates advocated by others. Unfortunately, that sort of value is the sort that can get people thrown in the clink unless one is very careful... > 3) I don't give a flying fuck if you pay for your DL time. If you're > stupid enough to be using AOL as your Internet port of entry, then you > deserve to be ripped off by Compuserve's evil bastard cousin. Why don't > you point and click yourself a new brain, and join a flat-rate system like > Netcom or any of the hundred other public access internet sites. Support the > small entrepreneurs instead of those lazy fat bastard nazi censors at AOL. Too much coffee, or not enough Thorazine? ;) All in all, a very entertaining post - I think I woke up my roommate with my chuckles! -- Ed Carp erc at apple.com 510/659-9560 If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From MIKEINGLE at delphi.com Tue Sep 14 02:08:51 1993 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Tue, 14 Sep 93 02:08:51 PDT Subject: Denning@ISSS Expo '93 Message-ID: <01H2XDC6XPT491XDZQ@delphi.com> I was looking through the brochure for ISSS Expo '93, the Third Annual International Security Systems Symposium and Exhibition, to be held in Washington, DC Nov. 15-17. Convention topics: safeguarding proprietary info opsec/intel/counterintel computer/info systems security competitive intelligence (translation: corporate espionage) special topics Exhibits: surveillance systems counter-surveillance detection systems anti-terrorist/penetration information security transmission methodologies computer and communications security miscellaneous One presentation in particular sounds rather ominous: Encryption - The Law (U.S. & International Implications) Speaker: Dorothy "Skipjack" Denning What do you suppose Denning will talk about? Perhaps she will point out that, due to the government's overriding need to perform large-scale, cheap monitoring, only very weak crypto can be exported. And that 40-bit keys can be cracked not only by the government, but also by anyone with idle workstations at night. Naturally, this is a problem for any multinational which doesn't want to be a victim of "competitive intelligence". She might even propose a solution: we can all standardize on Clipper, thereby making the world safe from privacy, and restoring espionage to its proper place as a government monopoly. She will probably forget to mention another solution, however - one which is completely legal and which will be available long before Clipper. A U.S. company can buy ViaCrypt PGP; the foreign branch can use free PGP, and since no cryptographic software crosses the border, no laws are broken. Conference/exhibit info: (301) 986-7800 Exhibit attendance $20 or free with registration form. Conference $595 business, $495 government/military. Maybe some DC-area cypherpunks could show up for the exhibits and crash the party with some highly subversive and seditious materials. From David.D.L.LANDGREN at PUB.oecd.fr Tue Sep 14 06:48:57 1993 From: David.D.L.LANDGREN at PUB.oecd.fr (David LANDGREN, PUB ) Date: Tue, 14 Sep 93 06:48:57 PDT Subject: warez garbage cluttering the screen Message-ID: <"14744141903991/17745 OECDX400*"@MHS> rm -f thug From pmetzger at lehman.com Tue Sep 14 07:34:58 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 14 Sep 93 07:34:58 PDT Subject: warez garbage cluttering the screen In-Reply-To: Message-ID: <9309141429.AA04493@snark.lehman.com> 1) I don't favor piracy. I especially don't favor piracy by people who can't capitalize or spell, and who think that saying "rich fat fucks" is a suave conversational gambit. 2) I agree that piracy is not the proper subject of this list. 3) If Mr. Thug wants to discuss piracy, there are thousands of places for him to do so. Perry Murdering Thug says: > > What have these endless bandwidth wasting lists of > > supposed warez sites to do with Cypherpunks? Please > > take your personnal vendettas elsewhere. I pay for DL time. > > 1) The fl0w of wArEz keeps the universe in perfect harmony. Without wArEz > there would be no life as we know it. And just because you are a rich fat > fuck who can afford to plunk down $795 for a copy of Pagemaker, you > shouldn't take a moral stance against those who cannot afford such > extortion yet need these software tools to keep up technologically with > rich fat fucks like yourself. > > 2) wArEz have A LOT to do with Cypherpunks. Software, pirated or > otherwise has value, and as such it must be considered as a form of > digital money. One may trade encrypted wArEz anonymously over anonymous > mailing lists, FSP/FTP sites, newsgroups like the proposed alt.waste, and > BlackNet. wArEz _are_ digital gold coins, they have inherent value, > unlike useless encrypted random number certificates advocated by others. > > 3) I don't give a flying fuck if you pay for your DL time. If you're > stupid enough to be using AOL as your Internet port of entry, then you > deserve to be ripped off by Compuserve's evil bastard cousin. Why don't > you point and click yourself a new brain, and join a flat-rate system like > Netcom or any of the hundred other public access internet sites. Support the > small entrepreneurs instead of those lazy fat bastard nazi censors at AOL. > > > Thug From geoffw at nexsys.net Tue Sep 14 08:13:58 1993 From: geoffw at nexsys.net (Geoff White) Date: Tue, 14 Sep 93 08:13:58 PDT Subject: warez garbage cluttering the screen Message-ID: <9309141508.AA05531@nexsys.nexsys.net> > From toad.com!owner-cypherpunks at cdp.igc.org Tue Sep 14 06:16:19 1993 > Return-Path: > From: Timothy Newsham > Subject: Re: warez garbage cluttering the screen > To: loki at convex1.TCS.Tulane.EDU (the mischeivious god) > Date: Mon, 13 Sep 1993 22:43:49 -1000 (HST) > Cc: cypherpunks at toad.com > X-Mailer: ELM [version 2.4 PL21] > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset=US-ASCII> > Content-Transfer-Encoding: 7bit > Content-Length: 863 > X-Lines: 21 > Status: RO > > > > > > > > > What have these endless bandwidth wasting lists of > > > supposed warez sites to do with Cypherpunks? Please > > > take your personnal vendettas elsewhere. I pay for DL time. > > > > > > ---Marc > > > > > GRRRRRRRRRRRR...... I dont have to pay and I rather found it useful. > > > > loki > > Then maybe a list for warez topics should be formed. I find alot > of things on the cypherpunks list that is off-topic to be interesting. > The list is however for the discussion of cryptography and privacy. > The only thing that all people on this list have in common is their > interest in crypto and privacy, and the list should stick to those > points. Other topics that are interesting should be taken to > private email or put on the appropriate lists (barring of course > the occasional slip or wandering of the topic). > > Shit, Well I'm interested in the list and I missed it as it went by so will whoever posted it PLEASE send me a copy? geoffw at nexsys.net Thanks and keep up the good work. I personally think people should use their DISCRETION when posting, not hard and fast rules. If I wanted hard and fast rules I'd sign up for Prodigy. An occasional post related to the subject that is obviously of interest to a large sub- population of cypherpunks is appropriate, perhapse in the future put a warning in the subject line so the whinners can hit the "d" key in advance and save that .25 cents or whatever it cost them. And for the person who complained about bandwidth, how do you feel about the fact that we now have to waste more flaming about wasting bandwidth. (Please don't reply to the list, reply to me if you must) From frissell at panix.com Tue Sep 14 08:39:00 1993 From: frissell at panix.com (Duncan Frissell) Date: Tue, 14 Sep 93 08:39:00 PDT Subject: The "Cypherpunk Melti Message-ID: <199309141538.AA15764@panix.com> M >I have a real problem with the attempted marriage of anarchy and the M >Bill of Rights. I'm interested in the issue of privacy not because I M >want to screw our government out of my taxes, but because I want to M >have the ability to communicate with any of you in private. You should be aware of the possible results of your actions, however. A market is a place where traders meet and trade. It involves communications and transfer. When governments intervene in markets, they do so by preventing these communications and transfers. When it becomes technically possible to exclude anyone you like (including the government) from your communications and transfers of non-physical goods and services, you have a free market. Once these traders start trading a higher and higher proportion of the world's goods and services in this free market, government monopoly market controls are broken. The world's governments become mere market actors like everyone else. They lose sovereignty. They can no longer govern (an ever-expanding portion of human activity). They are no longer governments. All from the simple ability to reliably communicate with total privacy. Duncan Frissell What is the world's most hazardous toxic waste dump? Highgate Cemetery in North London. Why? See next Post for the answer. --- WinQwk 2.0b#0 From karn at qualcomm.com Tue Sep 14 08:39:59 1993 From: karn at qualcomm.com (Phil Karn) Date: Tue, 14 Sep 93 08:39:59 PDT Subject: Denning@ISSS Expo '93 In-Reply-To: <01H2XDC6XPT491XDZQ@delphi.com> Message-ID: <9309141539.AA17745@servo> I've seen Denning's name on other security conferences, most recently several weeks ago in DC. As usual, one can always make money by toading for the government. Phil From cme at ellisun.sw.stratus.com Tue Sep 14 08:48:59 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Tue, 14 Sep 93 08:48:59 PDT Subject: UK Privacy Council Message-ID: <9309141545.AA05201@ellisun.sw.stratus.com> UK readers might want to check out comp.society.privacy for the announcement of the forming of the UK Privacy Council. From Hastings at courier8.aero.org Tue Sep 14 09:09:59 1993 From: Hastings at courier8.aero.org (Hastings at courier8.aero.org) Date: Tue, 14 Sep 93 09:09:59 PDT Subject: Spread spectrum radio Message-ID: <0007BCA6.MAI*Hastings@courier8.aero.org> It was encouraging to see messages about spread spectrum recently. Bypassing the telcos could be important in a crypto-hostile legal environment. And who wants to pay for message forwarding when we can do it ourselves efficiently, almost for free? A bit off topic, but I didn't start it: Someone posted a message that the Waco tank driver ID'd the tank in the Waco: The Big Lie video. But the Chrysler model equipped with a flame thrower claimed to be the tank didn't match Neil Schulman's military expert's opinion, that the model in question did not come equipped with a flame thrower, but could easily support one. Linda Thompson (W:TBL producer) then claimed it was the Chrysler flame thrower tank cleverly disguised to look like the others. As Neil told me, "First she says some animal on the tape is a squirrel. I say the zoologist says it's a chipmunk. Then she says it's a chipmunk disguised as a squirrel." For the complete detailed exchange from the Waco echo conference, e-mail me at jkhastings at aol.com or Neil at softserv at genie.geis.com. Sorry for being off topic, but government atrocities DO undermine the argument that law enforcement needs to take away your right to privacy for your own safety. And we're talking about DECIPHERING what's on the video. Yeah, that's it. "Beat the system before the system beats you." Kent - From banisar at washofc.cpsr.org Tue Sep 14 10:05:18 1993 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Tue, 14 Sep 93 10:05:18 PDT Subject: CSSPAB Questions Clipper Message-ID: <00541.2830855938.5353@washofc.cpsr.org> CSSPAB Questions Clipper Govt. Panel Questions Clipper Chip Proposal By David Banisar, The Privacy Times After two days of sometimes tumultuous hearings, a government advisory board chartered to advise the administration and Congress on computer security and privacy issued two resolutions questioning many of the aspects of the Clinton Administration's controversial new encryption scheme, the Clipper Chip. The National Institute for Standards and Technology's Computer System Security and Privacy Advisory Board (CSSPAB) expressed continued concern over many aspects of the proposal including the lack of a convincing statement expressing the problems that the Clipper is supposed to solve, the need to look for possible alternatives to the proposal, the legal, economic, export controls issues, and software implementation of the proposal. In addition, the board also expressed concern that the Clipper proposal could negatively impact the availability of cost-effective security products to the US government and industry and that it may not be marketable or usable worldwide. In a second resolution, the board unanimously called for a public debate of the proposal and recommended that Congress take an active role in determining US cryptography policy. It also recommended that any new policy must address the interests of law enforcement and intelligence, US industry and citizens' privacy and security in the US and worldwide. At the hearings, Geoff Greiveldinger from the Department of Justice reported that the key escrow agents will be announced within a few weeks after briefing members of Congress. Sources inside the administration indicate that the administration may have decided to eliminate from consideration outside organizations holding the keys and are leaning towards the Department of the Treasury as one of the key holders. Doug Miller of the Software Publishers Association (SPA) also presented the latest survey of foreign software with cryptography finding that over 200 products from over 20 countries were available from overseas companies including many that use DES. He expressed concern that the Clipper chip would harm the US software industry while not providing any benefits to the intelligence community, since cryptography was available worldwide. He indicated that they were seeking a legislative solution to the issue. Last year, a renewal of the Export Administration Act t, which removed restrictions on off-the-shelf software with encryption, was vetoed by President Bush. NIST Deputy Director Ray Kammer announced that the Data Encryption Standard (DES) will be recertified for government, non-classified use for another five years. The paperwork has been sent to Secretary of Commerce Ron Brown, who is expected to sign it within two weeks. The Clipper proposal was introduced April 16, 1993 and has been strongly opposed by both civil liberties groups and industry. The proposal calls for use of a secret encryption chip designed by the National Security Agency for non-classified voice and data transmission. The keys for the chip would be split and held in escrow by two government agencies. NIST has submitted the Clipper proposal for public comment. The FIPS was published in the Federal Register at Volume 58, page 40791 (July 30, 1993) and is also available in electronic form from the CPSR Internet Library FTP/WAIS/Gopher cpsr.org /cpsr/crypto/clipper/call-for-comments. Comments are due to NIST by September 28, 1993 to the Director, Computer Systems Laboratory, ATTN: Proposed FIPS for Escrowed Encryption Standard, Technology Building, room B-154, National Institute of Standards and Technology, Gaithersburg, MD 20899. CPSR has created an archive of comments on the proposal and has asked people to electronically submit a copy of their comments to clipper at washofc.cpsr.org. -------------------------------- NON-CERTIFIED TEXT COMPUTER SYSTEM SECURITY AND PRIVACY ADVISORY BOARD RESOLUTION 93-5 SEPTEMBER 1-2, 1993 Subsequent to the June 2-4, 1993 meeting of the CSSPAB, the Board has held an addition 4 days of public hearings and has collected additional public input. The clear message is that the preliminary concerns stated in Resolution 1 of that date have been confirmed as serious concerns which need to be resolved. Public input has heightened the concerns of the Board to the following issues: - A convincing statement of the problem that Clipper attempts to solve has not been provided. - Export and import controls over cryptographic products must be reviewed. Based upon data compiled from US and international vendors, current controls are negatively impacting US competitiveness in the world market and are not inhibiting the foreign production and use of cryptography (DES and RSA). - The Clipper/Capstone proposal does not address the needs of the software industry, which is critical and significant component of the National Information Infrastructure and the US economy. - Additional DES encryption alternatives and key management alternatives should be considered since there is a significant installed base. - The individuals reviewing the Skipjack algorithm and key management system must be given an appropriate time period and environment in which to perform a thorough review. This review must address the escrow protocol and chip implementation as well as the algorithm itself. - Sufficient information must be provided on the proposed key escrow scheme to allow it to be fully understood by the general public. - Further development and consideration of alternatives to the key escrow scheme need to be considered, e.g., three "escrow" entities, one of which is a non-government agency, and a software based solution. - The economic implications for the Clipper/Capstone proposal have not been examined. These costs go beyond the vendor cost of the chip and include such factors as customer installation, maintenance, administration, chip replacement, integration and interfacing, government escrow system costs, etc. - Legal issues raised by the proposal must be reviewed. - Congress, as well as the administration, should play a role in the conduct and approval of the results of the review. Moreover, the following are additional concerns of the Board. - Implementation of the Clipper initiative may negatively impact the availability of cost-effective security products to the US government and the private sector; and - Clipper products may not be marketable or usable worldwide. FOR: Castro, Gangemi, Lambert, Lipner, Kuyers, Philcox, Rand, Walker, Whitehurst, and Zeitler. AGAINST: none ABSTAIN Gallagher [NSA] ABSENT: Colvin ----------------------------------------------------------------- NON-CERTIFIED TEXT COMPUTER SYSTEM SECURITY AND PRIVACY ADVISORY BOARD RESOLUTION 93-6 SEPTEMBER 1-2, 1993 The Board believes that in deciding cryptographic policies and standards in the US, there is a compelling need to consider and evaluate the concerns listed below. We, therefore, endorse the process being pursued by the administration in the form of an interagency review but believe the scope of that review needs to include adequate industry input. We reaffirm our recommendations (of March 1992) that the issues surrounding this policy be debated in a public forum. In view of the worldwide significance of these issues the Board believes that the Congress of the U.S. must be involved in the establishment of cryptographic policy. The board, furthermore, believes that there are a number of issues that must be resolved before any new or additional cryptographic solution is approved as a US government standard: 1. The protection of law enforcement and national security interests. 2. The protection of U.S. computer and telecommunications interests in the international marketplace. 3. The protection of U.S. person's interests both domestically and internationally. FOR: Castro, Gallagher, Gangemi, Lambert, Lipner, Kuyers, Philcox, Rand, Walker, Whitehurst, and Zeitler. AGAINST: none ABSTAIN: none ABSENT: Colvin From doug at netcom4.netcom.com Tue Sep 14 10:18:59 1993 From: doug at netcom4.netcom.com (Doug Merritt) Date: Tue, 14 Sep 93 10:18:59 PDT Subject: warez garbage cluttering the screen Message-ID: <9309141718.AA20046@netcom4.netcom.com> thug at phantom.com (Murdering Thug) said: > 1) The fl0w of wArEz keeps the universe in perfect harmony. [...] > 3) I don't give a flying fuck if you pay for your DL time. [...] These two comments are *highly* inappropriate for this list, so it pains me to have to admit that he's got a point in #2: > wArEz _are_ digital gold coins, they have inherent value, I don't happen to be interested in software piracy, but discussions of software as digital gold coins, stolen or otherwise, are appropriate... but *only* discussions of how they are coins and how that relates to crypto schemes. I wish thug would make a sharper distinction...and keep his flames and generic non-cypherpunk "warez" crap to private email. Doug From nate at VIS.ColoState.EDU Tue Sep 14 10:40:00 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Tue, 14 Sep 93 10:40:00 PDT Subject: PGPC 2.2 available Message-ID: <9309141739.AA08520@nagel.VIS.ColoState.EDU> -----BEGIN PGP SIGNED MESSAGE----- PGPC 2.2 is available for anonymous ftp from 129.82.156.104 in /pub/pgpc/pgpc22.tar.[Z,gz] It is available in either gnuzip or regular compress. Read the README. It comes with a makefile that will add the public keys to your public keyring... you may need to edit that if you don't need it (or want it) to add the keys. I added support for the encrypted remailers... it's quite slick now, IMHO. It can nest as many rounds of encrypted remailing you want, and it will also mail through anon.penet.fi into the remailers. I also signed the archives, and put the signature certificates in near the archives, you can get my public key from fingering nate at monet.vis.colostate.edu have fun, - -nate +-------------------------------------------------------------------- | Nate Sammons email: nate at VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate at monet.VIS.ColoState.Edu for my PGP key | #include | Always remember "Brazil" +----------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJYBudTgi1fmrpxlAQEG4wP9HTn4xqBP/1rvPUwsuUoDpnoN/uzvVl73 fY/j9jnFjA+cAJ0/fnvUtl7Iq1OcowLauZAlIPg8ts7aR3sCT4eQnZZg2fon4xj3 dMeVjy/K3nTXPCoz+67KzIurZxHgyS5BQMzYs8YWi6lE/t7cWfFxE/6IyYMr7bYL B4OG6tKJOL4= =OIsL -----END PGP SIGNATURE----- From drzaphod at brewmeister.xstablu.com Tue Sep 14 10:44:00 1993 From: drzaphod at brewmeister.xstablu.com (drzaphod at brewmeister.xstablu.com) Date: Tue, 14 Sep 93 10:44:00 PDT Subject: The "Cypherpunk Melting Pot" In-Reply-To: <9309140743.AA14959@netcom.netcom.com> Message-ID: > no good reason. If I'm a homosexual, I want to be able to communicate with > others without worrying that my employer will monitor my email and fire > me for being homosexual. If I'm Jewish, and I work in the deep south... > > Privacy is the ability to keep and communicate thoughts without worrying > about someone using them against you. > Michael S. Sattler msattler at netcom.com +1 (415) 358-3058 Soundz like you have opinions on what type of anarchy you'll advocate. "getting away with something" also means breaking the law when the law is severely screwed up. Privacy is needed to maintain our human rights, which brings in the Bill of Rights. You want to be able to communicate freely about your opinions. Me too.. but maybe my opinions are about the overthrowing of the government -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - DrZaphod #Don't Come Any Closer Or I'll Encrypt! - - [AC/DC] / [DnA][HP] #Xcitement thru Technology and Creativity - - [drzaphod at brewmeister.xstablu.com] [MindPolice Censored This Bit] - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From sameer at netcom.com Tue Sep 14 10:45:19 1993 From: sameer at netcom.com (Sameer Parekh) Date: Tue, 14 Sep 93 10:45:19 PDT Subject: Anarchy v. Privacy Message-ID: <9309141745.AA13662@netcom.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- At the recent cypherpunks meeting, Tim, as he posted to the list, mentioned during his presentation conflicting political views, and how we don't plan on making that a big issue-- we will set aside the politics until *later*, when we have full privacy & high bandwidth people can decide what to do, splinter into their own groups, etc., but until then, as we have a common goal of personal privacy, we should work together to reach that goal. It makes a great deal of sense. It strikes me, however, that Tim only took into account the differences between the anarcho-capitalists and the anarcho-syndicalists (A new term-- I've always used anarcho-communist.. are they similar?) while not taking into account the people who don't seem to want an anarchic future. Remember, though, that the cypherpunks is *not* a group with a "party-line". Whether your vision of the future with crypto, I think that having an internal squabble is pointless and futile. Let's work for full privacy. Maybe for those who feel like debating the finer points of anarchy with crypto (on an "intellectual" level) can use a separate list? Peace, - -- Sameer sameer at netcom.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJYDGgvya0ihLgutAQEzJgQA4E+qOPnCwVSkdZM+0BwySxiRXkYqrA87 fd3Dp3meShFto3L9f47p4jHLMR2aUDG0RIxK/BTeSdTZfVwxbgPDt6oSM/lLKwy8 gkmbzlwoL3cHRa7P+P/A7ylClOtjfTCMZ+bRTSFJa4zLFGsnCxdVbpiZUP8cWTFr 8G0EydS+r7Q= =gAA+ -----END PGP SIGNATURE----- From doug at netcom5.netcom.com Tue Sep 14 12:45:01 1993 From: doug at netcom5.netcom.com (Doug Merritt) Date: Tue, 14 Sep 93 12:45:01 PDT Subject: authoritative definition of cryptography? Message-ID: <9309141944.AA23921@netcom5.netcom.com> Can anyone point me to (1) a reasonably authoritative legal definition of what "cryptography" means, that can be used to help decide precisely what does and does not fall under e.g. the export restrictions, and (2) a similar definition from the technical literature, to use in conjunction with #1? Hopefully I won't have to fall back on "I know it when I see it" standards. :-) Thanks, Doug From honey at citi.umich.edu Tue Sep 14 13:09:02 1993 From: honey at citi.umich.edu (peter honeyman) Date: Tue, 14 Sep 93 13:09:02 PDT Subject: authoritative definition of cryptography? Message-ID: <9309142005.AA13289@toad.com> according to denning's book, "cryptography is the science and study of secret writing." webster's 7th says cryptography is "the enciphering and deciphering of messages in secret code." kahn says "the methods of cryptography ... render [a secret message] unintelligible to outsiders by various transformations of the plaintext." peter From ferguson at fiber.sprintlink.net Tue Sep 14 13:19:03 1993 From: ferguson at fiber.sprintlink.net (Paul Ferguson x2044) Date: Tue, 14 Sep 93 13:19:03 PDT Subject: A definitive definition of "crypto" Message-ID: <9309142018.AA15838@fiber.sprintlink.net> On Tue, 14 Sep 1993 12:44:45 PDT, Doug Merritt writes - > Can anyone point me to (1) a reasonably authoritative legal definition > of what "cryptography" means, that can be used to help decide precisely > what does and does not fall under e.g. the export restrictions, and (2) a > similar definition from the technical literature, to use in conjunction > with #1? Doug, I'm not sure how much it will help you in distinguishing your objective, but one of the best general purpose references that I have seen is the sci.crypt Usenet newsgroup FAQ. It's posted occasiuonally to sci.crypt, but I can't think of a site (offhand) where you can FTP it. If you have access to a gopher or WAIS, give that a try. Cheers, _____________________________________________________________________________ Paul Ferguson Mindbank Consulting Group fergp at sytex.com Fairfax, Virginia USA ferguson at icp.net From futor at llnl.gov Tue Sep 14 13:35:02 1993 From: futor at llnl.gov (futor at llnl.gov) Date: Tue, 14 Sep 93 13:35:02 PDT Subject: A definitive definition of "crypto" Message-ID: <9309142034.AA26943@> > [ The FAQ ]'s posted occasiuonally to sci.crypt, > but I can't think of a site (offhand) where you can FTP it. Try rtfm.mit.edu -- they tend to have most of the FAQs there. __ \/ -+- randy -+- all generalizations are flawed -+- futor at llnl.gov From klbarrus at owlnet.rice.edu Tue Sep 14 13:35:22 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Tue, 14 Sep 93 13:35:22 PDT Subject: REMAIL: testing remailer & keys In-Reply-To: <9309140343.AA15529@netcom.netcom.com> Message-ID: <9309142034.AA00504@flammulated.owlnet.rice.edu> I think there are two more remailers: elee7h5 at rosebud.ee.uh.edu, and catalyst at netcom.com (keys below) Incidentally, I see you have the Mr. Remailer key (elee6ue at rosebud.ee.uh.edu). How did that slip out? :-) I must have extracted it instead of elee7h5 at rosebud.ee.uh.edu. Anyway, that one should be stable - I've used it for various scripts hacks and testing, and I restored it to plain form recently. In fact, it may become the preferred remailer on rosebud - the account it is in is still "valid"; it belongs to a friend of mine who is currently working in New Hampshire (he has no telnet access). His password is still valid, and the remailer is set up with his permission (even blessings). I mention this since I have been told by a lawyer that running a remailer on an account I no longer have legitimate access to breaks about three laws here in Texas. So I attempted to re-legitimize my account (described below). Once upon a time that was my account, but I'm through with that grad area, and university, so the account is locked now... but my directory structure is still there. So, I mailed to two people in charge on rosebud and told them to get back to me. So far, I haven't heard anything, so maybe they don't care! Actually, if it doesn't impose a cpu burden (it doesn't) or take up much space (it doesn't), they might not give a crap. elee7h5 at rosebud.ee.uh.edu: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1PokAlQIFECtk lUeDgOzqS1rWMwEBUdAEAIosaOm/+kTsQI53GAqPXr08v5AAfwup5lDiUbCWp17C ueYHZrP4zolAqQ7kyWrkIeHgJHkX3yB6YH/jQ0MeDZERXS69kq2SGVQSH6inGoF9 3WerfGRpdONa597JVcRpklzMUz6bmXnhsiEm/K1FP9pNOZYyS6h/3gs92ikezq3X =tUXb -----END PGP PUBLIC KEY BLOCK----- catalyst at netcom.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyBTjoAAAEEAMIKpRnqXb82TOQpx/vEDwGPXndXaxtfiZeSLZqullWCEbd4 YkCHG/F1i3Wzq4Pgz6nSbb58vMS5RonY7+ZC6IHI8zBpp9oMW3u+lqbk8Z61x49d xwAKlE7Zsk/pOeGrqbsidm83WUqlSGgyOpvq0A8LzT4+WPra8ZvHue9jwOpJAAUR tChBbm9ueW1vdXMgUmVtYWlsZXIgPGNhdGFseXN0QG5ldGNvbS5jb20+iQCVAgUQ LIaqhIOA7OpLWtYzAQH4sgQAsc6s3X75LwWTV65Dw76wdSRKuoI57F2ZZWjSOIQK n1CWUn6YEYOIs3kkdHNd0uz9Mspoy+6BsnWGSW11r8k88VThEoVpJ74o91apR1ML yCEdD7O/+nZK8N484+mN2BcKOdeze4QvgTt+qHHUd+Q5alW9VfXtbNImmSnI3FC/ 8n4= =Hh6a -----END PGP PUBLIC KEY BLOCK----- -- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From klbarrus at owlnet.rice.edu Tue Sep 14 14:44:04 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Tue, 14 Sep 93 14:44:04 PDT Subject: REMAIL: list Message-ID: <9309142142.AA15094@flammulated.owlnet.rice.edu> :: Anon-To: cypherpunks at toad.com Here is an interim release of the list, which includes the elee9sf at menudo and elee6ue at rosebud remailer. (And you thought I was joking when I said that some people run remailers that aren't announced :-) I cleaned up the scripts at elee6ue at rosebud, and in the process of creating the proper directories for caching (which is NOT implemented just yet) I zapped the pgp directory and the keyrings... so now there is a new key for elee6ue at rosebud.ee.uh.edu, keyid = BBC00D. Sorry about that! Also, my key klbarrus at owlnet.rice.edu, keyid = 5AD633 has an A.K.A. on it for elee9sf at menudo.uh.edu. This is NOT the public key to the remailer, whose keyid is DC9EE9. I sign the public keys of remailers I have verified as working, so if you get the latest pubkeys.tar.gz file from soda or the keys from me, you will find a signature from 5AD633 on them. Lastly, thanks to folks who are contributing programs to help other use the remailers! I decided to keep my offerings as shell scripts or batch files, but there is only so much these languages can do, so I welcome "high" level help programs (source included :-). Nate's program is mentioned, but not Alex's (yet) since it isn't available via ftp (yet). I'll try to keep on top of this stuff. Cypherpunk anonymous remailers, 9/15/93 Q1: What are the anonymous remailers? A1: 1: nowhere at bsu-cs.bsu.edu 2: hh at cicada.berkeley.edu 3: hh at pmantis.berkeley.edu 4: hh at soda.berkeley.edu 5: 00x at uclink.berkeley.edu 6: cdodhner at indirect.com 7: hal at alumni.caltech.edu 8: cs60a-qu at cory.eecs.berkeley.edu 9: ebrandt at jarthur.claremont.edu 10: catalyst at netcom.com 11: sameer at netcom.com 12: remailer at rebma.mn.org 13: elee6ue at rosebud.ee.uh.edu 14: elee7h5 at rosebud.ee.uh.edu 15: hfinney at shell.portal.com 16: remail at tamsun.tamu.edu 17: remail at tamaix.tamu.edu 18: remailer at utter.dis.org 19: remailer at entropy.linet.org 20: elee9sf at menudo.uh.edu 21: remail at extropia.wimsey.com NOTES: 1-6 no encryption of remailing requests 7-20 support encrypted remailing requests 21 special - header and message must be encrypted together 12,18,19,21 introduce larger than average delay (not direct connect) 12,18,21 running on privately owned machines 20 supports RIPEM encryption, caches all requests ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks/remailer directory at soda.berkeley.edu (128.32.149.19). chain.zip - program that helps with using remailers dosbat.zip - MSDOS batch files that help with using remailers hal's.instructions.gz - in depth instruction on how to use hal's.remailer.gz - remailer code pubkeys.tar.gz - public keys of remailers which support encryption pubkeys.zip - MSDOS zip file of public keys scripts.tar.gz - scripts that help with using remailers Also, at 129.82.156.104 in /pub/pgpc/ are two files: pgp22.tar.gz, pgp22.tar.Z which assist in using the anonymous remailers, including anon.penet.fi. Mail to me (klbarrus at owlnet.rice.edu) for further help and/or questions. ====================================================================== Q3. Email-to-Usenet gateways? A3. 1: group-name at cs.utexas.edu 2: group.name.usenet at decwrl.dec.com 3: group.name at news.demon.co.uk 4: group.name at news.cs.indiana.edu 5: group-name at pws.bull.com 6: group-name at ucbvax.berkeley.edu NOTES: * This does not include ones that work for single groups, like twwells.com. #1 apparently blocks anonymous remailer posts #6 blocks from non-berkeley sites (so use the berkeley remailers :-) From nobody at indirect.com Tue Sep 14 14:59:03 1993 From: nobody at indirect.com (nobody at indirect.com) Date: Tue, 14 Sep 93 14:59:03 PDT Subject: REMAIL: list Message-ID: <199309142156.AA26314@indirect.com> Here is an interim release of the list, which includes the elee9sf at menudo and elee6ue at rosebud remailer. (And you thought I was joking when I said that some people run remailers that aren't announced :-) I cleaned up the scripts at elee6ue at rosebud, and in the process of creating the proper directories for caching (which is NOT implemented just yet) I zapped the pgp directory and the keyrings... so now there is a new key for elee6ue at rosebud.ee.uh.edu, keyid = BBC00D. Sorry about that! Also, my key klbarrus at owlnet.rice.edu, keyid = 5AD633 has an A.K.A. on it for elee9sf at menudo.uh.edu. This is NOT the public key to the remailer, whose keyid is DC9EE9. I sign the public keys of remailers I have verified as working, so if you get the latest pubkeys.tar.gz file from soda or the keys from me, you will find a signature from 5AD633 on them. Lastly, thanks to folks who are contributing programs to help other use the remailers! I decided to keep my offerings as shell scripts or batch files, but there is only so much these languages can do, so I welcome "high" level help programs (source included :-). Nate's program is mentioned, but not Alex's (yet) since it isn't available via ftp (yet). I'll try to keep on top of this stuff. Cypherpunk anonymous remailers, 9/15/93 Q1: What are the anonymous remailers? A1: 1: nowhere at bsu-cs.bsu.edu 2: hh at cicada.berkeley.edu 3: hh at pmantis.berkeley.edu 4: hh at soda.berkeley.edu 5: 00x at uclink.berkeley.edu 6: cdodhner at indirect.com 7: hal at alumni.caltech.edu 8: cs60a-qu at cory.eecs.berkeley.edu 9: ebrandt at jarthur.claremont.edu 10: catalyst at netcom.com 11: sameer at netcom.com 12: remailer at rebma.mn.org 13: elee6ue at rosebud.ee.uh.edu 14: elee7h5 at rosebud.ee.uh.edu 15: hfinney at shell.portal.com 16: remail at tamsun.tamu.edu 17: remail at tamaix.tamu.edu 18: remailer at utter.dis.org 19: remailer at entropy.linet.org 20: elee9sf at menudo.uh.edu 21: remail at extropia.wimsey.com NOTES: 1-6 no encryption of remailing requests 7-20 support encrypted remailing requests 21 special - header and message must be encrypted together 12,18,19,21 introduce larger than average delay (not direct connect) 12,18,21 running on privately owned machines 20 supports RIPEM encryption, caches all requests ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks/remailer directory at soda.berkeley.edu (128.32.149.19). chain.zip - program that helps with using remailers dosbat.zip - MSDOS batch files that help with using remailers hal's.instructions.gz - in depth instruction on how to use hal's.remailer.gz - remailer code pubkeys.tar.gz - public keys of remailers which support encryption pubkeys.zip - MSDOS zip file of public keys scripts.tar.gz - scripts that help with using remailers Also, at 129.82.156.104 in /pub/pgpc/ are two files: pgp22.tar.gz, pgp22.tar.Z which assist in using the anonymous remailers, including anon.penet.fi. Mail to me (klbarrus at owlnet.rice.edu) for further help and/or questions. ====================================================================== Q3. Email-to-Usenet gateways? A3. 1: group-name at cs.utexas.edu 2: group.name.usenet at decwrl.dec.com 3: group.name at news.demon.co.uk 4: group.name at news.cs.indiana.edu 5: group-name at pws.bull.com 6: group-name at ucbvax.berkeley.edu NOTES: * This does not include ones that work for single groups, like twwells.com. #1 apparently blocks anonymous remailer posts #6 blocks from non-berkeley sites (so use the berkeley remailers :-) From remailer at netcom.com Tue Sep 14 14:59:05 1993 From: remailer at netcom.com (remailer at netcom.com) Date: Tue, 14 Sep 93 14:59:05 PDT Subject: REMAIL: list Message-ID: <9309142152.AA28550@mail.netcom.com> Here is an interim release of the list, which includes the elee9sf at menudo and elee6ue at rosebud remailer. (And you thought I was joking when I said that some people run remailers that aren't announced :-) I cleaned up the scripts at elee6ue at rosebud, and in the process of creating the proper directories for caching (which is NOT implemented just yet) I zapped the pgp directory and the keyrings... so now there is a new key for elee6ue at rosebud.ee.uh.edu, keyid = BBC00D. Sorry about that! Also, my key klbarrus at owlnet.rice.edu, keyid = 5AD633 has an A.K.A. on it for elee9sf at menudo.uh.edu. This is NOT the public key to the remailer, whose keyid is DC9EE9. I sign the public keys of remailers I have verified as working, so if you get the latest pubkeys.tar.gz file from soda or the keys from me, you will find a signature from 5AD633 on them. Lastly, thanks to folks who are contributing programs to help other use the remailers! I decided to keep my offerings as shell scripts or batch files, but there is only so much these languages can do, so I welcome "high" level help programs (source included :-). Nate's program is mentioned, but not Alex's (yet) since it isn't available via ftp (yet). I'll try to keep on top of this stuff. Cypherpunk anonymous remailers, 9/15/93 Q1: What are the anonymous remailers? A1: 1: nowhere at bsu-cs.bsu.edu 2: hh at cicada.berkeley.edu 3: hh at pmantis.berkeley.edu 4: hh at soda.berkeley.edu 5: 00x at uclink.berkeley.edu 6: cdodhner at indirect.com 7: hal at alumni.caltech.edu 8: cs60a-qu at cory.eecs.berkeley.edu 9: ebrandt at jarthur.claremont.edu 10: catalyst at netcom.com 11: sameer at netcom.com 12: remailer at rebma.mn.org 13: elee6ue at rosebud.ee.uh.edu 14: elee7h5 at rosebud.ee.uh.edu 15: hfinney at shell.portal.com 16: remail at tamsun.tamu.edu 17: remail at tamaix.tamu.edu 18: remailer at utter.dis.org 19: remailer at entropy.linet.org 20: elee9sf at menudo.uh.edu 21: remail at extropia.wimsey.com NOTES: 1-6 no encryption of remailing requests 7-20 support encrypted remailing requests 21 special - header and message must be encrypted together 12,18,19,21 introduce larger than average delay (not direct connect) 12,18,21 running on privately owned machines 20 supports RIPEM encryption, caches all requests ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks/remailer directory at soda.berkeley.edu (128.32.149.19). chain.zip - program that helps with using remailers dosbat.zip - MSDOS batch files that help with using remailers hal's.instructions.gz - in depth instruction on how to use hal's.remailer.gz - remailer code pubkeys.tar.gz - public keys of remailers which support encryption pubkeys.zip - MSDOS zip file of public keys scripts.tar.gz - scripts that help with using remailers Also, at 129.82.156.104 in /pub/pgpc/ are two files: pgp22.tar.gz, pgp22.tar.Z which assist in using the anonymous remailers, including anon.penet.fi. Mail to me (klbarrus at owlnet.rice.edu) for further help and/or questions. ====================================================================== Q3. Email-to-Usenet gateways? A3. 1: group-name at cs.utexas.edu 2: group.name.usenet at decwrl.dec.com 3: group.name at news.demon.co.uk 4: group.name at news.cs.indiana.edu 5: group-name at pws.bull.com 6: group-name at ucbvax.berkeley.edu NOTES: * This does not include ones that work for single groups, like twwells.com. #1 apparently blocks anonymous remailer posts #6 blocks from non-berkeley sites (so use the berkeley remailers :-) From nobody at nyx.cs.du.edu Tue Sep 14 15:00:06 1993 From: nobody at nyx.cs.du.edu (nobody at nyx.cs.du.edu) Date: Tue, 14 Sep 93 15:00:06 PDT Subject: REMAIL: list Message-ID: <9309142159.AA14129@nyx.cs.du.edu> Here is an interim release of the list, which includes the elee9sf at menudo and elee6ue at rosebud remailer. (And you thought I was joking when I said that some people run remailers that aren't announced :-) I cleaned up the scripts at elee6ue at rosebud, and in the process of creating the proper directories for caching (which is NOT implemented just yet) I zapped the pgp directory and the keyrings... so now there is a new key for elee6ue at rosebud.ee.uh.edu, keyid = BBC00D. Sorry about that! Also, my key klbarrus at owlnet.rice.edu, keyid = 5AD633 has an A.K.A. on it for elee9sf at menudo.uh.edu. This is NOT the public key to the remailer, whose keyid is DC9EE9. I sign the public keys of remailers I have verified as working, so if you get the latest pubkeys.tar.gz file from soda or the keys from me, you will find a signature from 5AD633 on them. Lastly, thanks to folks who are contributing programs to help other use the remailers! I decided to keep my offerings as shell scripts or batch files, but there is only so much these languages can do, so I welcome "high" level help programs (source included :-). Nate's program is mentioned, but not Alex's (yet) since it isn't available via ftp (yet). I'll try to keep on top of this stuff. Cypherpunk anonymous remailers, 9/15/93 Q1: What are the anonymous remailers? A1: 1: nowhere at bsu-cs.bsu.edu 2: hh at cicada.berkeley.edu 3: hh at pmantis.berkeley.edu 4: hh at soda.berkeley.edu 5: 00x at uclink.berkeley.edu 6: cdodhner at indirect.com 7: hal at alumni.caltech.edu 8: cs60a-qu at cory.eecs.berkeley.edu 9: ebrandt at jarthur.claremont.edu 10: catalyst at netcom.com 11: sameer at netcom.com 12: remailer at rebma.mn.org 13: elee6ue at rosebud.ee.uh.edu 14: elee7h5 at rosebud.ee.uh.edu 15: hfinney at shell.portal.com 16: remail at tamsun.tamu.edu 17: remail at tamaix.tamu.edu 18: remailer at utter.dis.org 19: remailer at entropy.linet.org 20: elee9sf at menudo.uh.edu 21: remail at extropia.wimsey.com NOTES: 1-6 no encryption of remailing requests 7-20 support encrypted remailing requests 21 special - header and message must be encrypted together 12,18,19,21 introduce larger than average delay (not direct connect) 12,18,21 running on privately owned machines 20 supports RIPEM encryption, caches all requests ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks/remailer directory at soda.berkeley.edu (128.32.149.19). chain.zip - program that helps with using remailers dosbat.zip - MSDOS batch files that help with using remailers hal's.instructions.gz - in depth instruction on how to use hal's.remailer.gz - remailer code pubkeys.tar.gz - public keys of remailers which support encryption pubkeys.zip - MSDOS zip file of public keys scripts.tar.gz - scripts that help with using remailers Also, at 129.82.156.104 in /pub/pgpc/ are two files: pgp22.tar.gz, pgp22.tar.Z which assist in using the anonymous remailers, including anon.penet.fi. Mail to me (klbarrus at owlnet.rice.edu) for further help and/or questions. ====================================================================== Q3. Email-to-Usenet gateways? A3. 1: group-name at cs.utexas.edu 2: group.name.usenet at decwrl.dec.com 3: group.name at news.demon.co.uk 4: group.name at news.cs.indiana.edu 5: group-name at pws.bull.com 6: group-name at ucbvax.berkeley.edu NOTES: * This does not include ones that work for single groups, like twwells.com. #1 apparently blocks anonymous remailer posts #6 blocks from non-berkeley sites (so use the berkeley remailers :-) From nobody at rosebud.ee.uh.edu Tue Sep 14 16:09:04 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Tue, 14 Sep 93 16:09:04 PDT Subject: REMAIL: new remailer Message-ID: <9309142307.AA15536@toad.com> -----BEGIN PGP SIGNED MESSAGE----- Hm... something weird happened since I didn't send out four copies of the remailer list. And a message I sent a while ago hasn't appeared yet...? First, I've been told that some people are concerned about my signature appearing on the remailer keys. I sign every remailer key I verify, hopefully in addition to the signature already present from the remailer operator... so if you run a remailer, sign the key if you haven't, and mail it to me, preferable with your public key because I don't like "unknown signator" messages. I will include it in the pubkeys.tar.gz distribution I put (with Eric's help) on soda. That way it won't look like I'm signing every remailer key all by myself :-) Anyway, this is a remailer I've been using for various testing purposes, but haven't announced (and you thought I was joking when I said people are running remailers they haven't announced :-) It is set up in a friend's account with his permission since he is away working in NH with no telnet priveleges. This may become the preferred remailer on rosebud. I have been told by a lawyer that running a remailer from an account I no longer have legitimate access to breaks about three laws in Texas. :( Maybe eventually I'll spring for a commercial setup where I have a little more say. My old account (elee7h5 at rosebud.ee.uh.edu) has been locked since I am no longer in that graduate group (or at that university for that matter). However, the remailer still works, since my directory structure remains. So, I mailed to two people in charge on rosebud, and have asked them to get back to me if they want the remailer cancelled. I haven't heard back, so maybe they support it! Actually though, since the remailer doesn't take up much space nor does it eat much cpu, they may very well not care. But my friend's account is still going strong :-) I've retested the remailing functions, and here is the key (keyid BBC00D) - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyWMdIAAAEEAMjEKj+hSQa1pJlIdAo3DH0qhKIqiNIPiyiDoxXctXR/wix7 lapUizd/Kj1FeYvMgKe1/rYKwgC1oHrCzKXoZ44ipsmaVArj++d3nfjblp/mh0Rd fCnQDt0PZ8wcx0gE87N6vJ77K8iW/dS9D1z9bax77HGl3i3A0kbfRR3Gu8ANAAUR tChNci4gUmVtYWlsZXIgPGVsZWU2dWVAcm9zZWJ1ZC5lZS51aC5lZHU+iQCVAgUQ LJYx1oOA7OpLWtYzAQGUjgQAsimuSOXkjvQubyQc3jjjvgFnV+Vce7TQnlZtjd2P A2S8Yafk/3rcBnVKGQ3ZBmYHc2AcvXwjZEQsTQYiKOQJ8/qzqQsbq7Juwg/Op4Fu GwtCuGERq9qA7lFrKwvbowQWb9kos9Hdor8v/DZREz8IOTbWKYRb8uyjH0jGw57Q b/c= =DWkv - -----END PGP PUBLIC KEY BLOCK----- It isn't the original key since I zapped it when I was shuffling around directories to support caching (which I have not enabled). Sorry! -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJZOSoOA7OpLWtYzAQHkNQQAxdOIX3L+vKoo8OaC8mB5cyGfSEOKULdQ OdbcA4gYKllTea82VLXZxCyYTyYNzIcGJ4v/E3Hod2BKC8wkISuOS0/QG9TXz9hm bDBzmdLNxQApTTbMmVV78o8wX2ol42Tw3pvqvhws61Z8rxBVnoNaV47OsQLYlo77 UJNOzAJtMws= =ADxw -----END PGP SIGNATURE----- From an31185 at anon.penet.fi Tue Sep 14 16:59:04 1993 From: an31185 at anon.penet.fi (Anon of Ibid) Date: Tue, 14 Sep 93 16:59:04 PDT Subject: Testing randomness of PGP-generated IDEA keys Message-ID: <9309142358.AA14909@anon.penet.fi> Hi, you may remember a few weeks back I was going to take a look at the randomness of PGP random number generation.... well, I finally got round to it. Since the MD5 of the file being encrypted is used as part of the random number generation process to prevent anyone copying the randseed.bin file and generating all future keys from it, I wrote a program to read in /usr/dict/words, and loop around generating files containing a random number (using the unix random() call) of random sentences using the words in the dictionary, and encrypt them with a test 384-bit key. The copy of PGP I was using was modified to dumped the 24-byte key/random prefix combination into a file, which the main program read out and processed. Firstly, it maintained a table of counts for each byte value, and secondly (since I gave up statistics years ago), XOR-ed all the bytes in each 24-byte sample together and maintained a table of frequency of XOR values as a simple check for randomness in each 24-byte sample. After running for a few days, the results were: Total bytes generated : 3000504 (125021 runs) Frequency : High: 11960 Low : 11377 Mean: 11721 Spread: 584 (4 %, +2 %, -2 %) Within 50% of mean : 2505989 (83 %) XOR Freq : High: 553 Low : 432 Mean: 488 Spread: 122 (25 %, +13 %, -11 %) Within 50% of mean : 107652 (86 %) Since, as I said, I'm not a statistician, my definitions of the above categories are : Mean - expected frequency, i.e. total number of bytes generated/256, Spread - absolute difference between frequencies of rarest and most common byte values, plus difference as percentage of mean, and spread above and below the mean as a percentage of the mean (rounded to nearest) Lastly, the program summed the frequencies of the bytes whose frequency was between (mean-(mean-low)/2) and (mean+(high-mean)/2), giving the result as an absolute value and a percentage of the total number of bytes generated. >From this, it looks to me like the random number generation is, indeed, pretty random, and if you're trying to break an arbitrary PGP-encrypted file by a brute-force attack on the IDEA-encrypted section, then you don't have any shortcuts based on frequency of bytes in the key. If anyone with a better grasp of statistics wants the original data to look at (25k, containing 24 arrays of byte frequencies and one of XOR frequencies), let me know and I'll email it to you. So, if there is a 'fatal flaw' in PGP, it looks like it must be either the known plaintext, or it must be somewhere in the prime generation code. Since I know nothing about fast methods of testing primality, someone else is going to have to look into that.... (Unless I get bored enough to hunt out some books on the subject) ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From nowhere at bsu-cs.bsu.edu Tue Sep 14 18:10:07 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Tue, 14 Sep 93 18:10:07 PDT Subject: A E-mail to Usenet kludge for cs.texas.edu Message-ID: <9309150112.AA14248@bsu-cs.bsu.edu> > 1: group-name at cs.utexas.edu > 2: group.name.usenet at decwrl.dec.com > 3: group.name at news.demon.co.uk > 4: group.name at news.cs.indiana.edu > 5: group-name at pws.bull.com > 6: group-name at ucbvax.berkeley.edu > > NOTES: > > * This does not include ones that work for single groups, like > twwells.com. > #1 apparently blocks anonymous remailer posts > #6 blocks from non-berkeley sites (so use the berkeley remailers :-) > for further help and/or questions. The comment concerning #1 (group-name at cs.utexas.edu) does not exactly hold true. Apparantly, by simply pasting in the - :: Request-Remailing-To: group-name at cs.utexas.edu header does not suffice. As a general rule of thumb, you must add the minimum in the pasted header - :: Request-Remailing-To: group-name at cs.utexas.edu Subject: Organization: Thanks to Chael Hall for helping me "troubleshoot" this little feature. From remail at tamsun.tamu.edu Tue Sep 14 18:24:08 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Tue, 14 Sep 93 18:24:08 PDT Subject: No Subject Message-ID: <9309150121.AA13893@tamsun.tamu.edu> > If people are willing to go to these measures to steal Intel > microprocessors, which are generally available, imagine what people > will do in order to steal unprogrammed Skipjack chips. In the volume > the Government would like to see them made, the physical security > which one might want to give to a classified production facility will > be difficult or impossible. They thought of this. The Skipjack algorithm is programmed into the chip at the same time the escrowed keys are. If you steal the unprogrammed chips you may learn the list of basic operations that are part of Skipjack. However there are also basic operations implemented on the chip which are *not* part of Skipjack but are there just to confuse someone who would disassemble a chip. Btw. This also means that the actual chip assembly line does not require cleared workers. From mjr at TIS.COM Tue Sep 14 20:00:08 1993 From: mjr at TIS.COM (mjr at TIS.COM) Date: Tue, 14 Sep 93 20:00:08 PDT Subject: Testing randomness of PGP-generated IDEA keys Message-ID: <13737.9309150258@otter.TIS.COM> >Hi, you may remember a few weeks back I was going to take a look at >the randomness of PGP random number generation.... well, I finally >got round to it. Since the MD5 of the file being encrypted is used >as part of the random number generation process to prevent anyone >copying the randseed.bin file and generating all future keys from it, [...] I found myself embroiled in a similar exploration of random number generation as part of some other work, and it took me a while to realize that running statistics on the output of the PRNG is almost useless, if you're using a cryptosystem or cryptographic hash as the PRNG. With any decent cryptosystem, one bit change in the input to the PRNG will cause every bit of the output to have a 50% chance of being different - that's a desirable property in a cryptosystem. DES, and I assume IDEA, show this property. What you've got to look at is the predictability of the input to the PRNG. PGP is in really good shape here, because it bootstraps its PRNG with its input, which presumably is unknown to the attacker. An example of a weak PRNG would be: `date | md5` For example: otter-> cat foo #!/bin/sh date | /usr/local/bin/md5 date | /usr/local/bin/md5 sleep 1 date | /usr/local/bin/md5 otter-> foo f4a66f827a8e62ad9c419f7e2117abc6 f4a66f827a8e62ad9c419f7e2117abc6 bcfa24d319ccdcad56a99be2e203e787 As you expect the first two runs are exactly the same. The second run is completely different. The seed, however, is only very slightly changed (by one second). You could run statistical analyses on the output for a long time and never realize that your random number is really extremely easy to crack. If I knew roughly what day you generated the "random" number on, I could crack it in only 86,400 MD5 hashes, and it's an operation that parallelizes trivially. *MUCH* cheaper to attack the PRNG than the cryptosystem! And if you used a toy PRNG to generate your RSA key, then you're lunchmeat. Anyhow, I've been over-long winded. I think PGP is in good shape because of the aforementioned property of using the message as a seed. Messages that don't change much, or that change predictably, are subject to exhaustive searching. A means of analysing the unpredictability of the seed is more worthwhile. I made some basic starts at doing this by ad hoc measures (generating repeated seeds and running them through a program to count a minimum-bit edit similar to diff) but I wasn't sure enough of the validity of my approach to bother continuing it. My hat is off to the guy who came up with the idea of seeding the PRNG with the message. That was *clever*. mjr. From cme at ellisun.sw.stratus.com Tue Sep 14 20:54:10 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Tue, 14 Sep 93 20:54:10 PDT Subject: more than spread spectrum Message-ID: <9309150353.AA06198@ellisun.sw.stratus.com> There are alternatives to spread spectrum, if we're threatened with loss of freedom to communicate. We could lay our own wires/fibers. We could set up a mesh network of infrared lasers through the air. Last time I looked, there were no laws against shining lights out your window as long as they didn't bother anyone. An infrared laser could hardly bother anyone. We could produce a line of cheap cards to plug into a PC which would do packet routing, using a variety of physical links -- our own wires, lasers, very low range radio, .... Each card would connect to three or more neighbors and become part of the global mesh. Adaptive routing with no global map would suffice for the card and would keep the whole system peer-to-peer with no need for central control and no chance for central tapping. Of course all of these solutions require a high density of users. A college campus might be the right place to start. We could then branch out to cities. I suspect that a place like Chicago or NYC with high rise apartments might be the place to start -- many options for line-of-sight communications. The benefit isn't just for Cypherpunks. It's a free network for the masses -- like the original USENET (with each user donating routing and store/forward) but with unrestricted, low-range, continuously operating physical links. I'll volunteer to do the software for the node card. Does anyone have hardware design/fab to donate to the effort? - Carl From stig at netcom.com Tue Sep 14 21:29:07 1993 From: stig at netcom.com (Stig) Date: Tue, 14 Sep 93 21:29:07 PDT Subject: more than spread spectrum In-Reply-To: <9309150353.AA06198@ellisun.sw.stratus.com> Message-ID: <9309150426.AA00948@netcom2.netcom.com> In <9309150353.AA06198 at ellisun.sw.stratus.com>, Carl Ellison wrote... > There are alternatives to spread spectrum, if we're threatened with > loss of freedom to communicate. > > We could lay our own wires/fibers. > Well, we'd like crypto for the masses and I don't think that the masses are yet ready to put out the bucks for spread spectrum boards and infrared laser communications gear... It'd be really nice to have such a decentralized network, though. > We could set up a mesh network of infrared lasers through the air. Last > time I looked, there were no laws against shining lights out your window as > long as they didn't bother anyone. An infrared laser could hardly bother > anyone. > ... > very low range radio, .... Each card would connect to three or more > neighbors and become part of the global mesh. Adaptive routing with no > global map would suffice for the card and would keep the whole system > peer-to-peer with no need for central control and no chance for central > tapping. > This would be the perfect network in which to deploy DC nets.... (dining cryptographers). ;; __________________________________________________________________________ ;; Stig at netcom.com netcom.com:/pub/stig/00-PGP-KEY ;; It's hard to be cutting-edge at your own pace... 32 DF B9 19 AE 28 D1 7A ;; Bullet-proof code cannot stand up to teflon bugs. A3 9D 0B 1A 33 13 4D 7F From doug at netcom.com Tue Sep 14 22:44:13 1993 From: doug at netcom.com (Doug Merritt) Date: Tue, 14 Sep 93 22:44:13 PDT Subject: more than spread spectrum Message-ID: <9309150541.AA10786@netcom2.netcom.com> cme at ellisun.sw.stratus.com (Carl Ellison) said: >The benefit isn't just for Cypherpunks. It's a free network for the masses... >I'll volunteer to do the software for the node card. Does anyone have >hardware design/fab to donate to the effort? You might want to contact the Garden project, which I believe is operational in San Jose and in Santa Cruz. I'm not up on all the details, but it is far too similar to what you're talking about to ignore. Doug From mgream at acacia.itd.uts.edu.au Tue Sep 14 23:40:32 1993 From: mgream at acacia.itd.uts.edu.au (Matthew Gream) Date: Tue, 14 Sep 93 23:40:32 PDT Subject: more than spread spectrum In-Reply-To: <9309150353.AA06198@ellisun.sw.stratus.com> Message-ID: <9309150640.AA02395@acacia.itd.uts.EDU.AU> In reply to (Carl Ellison): | I'll volunteer to do the software for the node card. Does anyone have | hardware design/fab to donate to the effort? Hmm, this is nice timing I guess :-) Over the last 3-4 weeks I have been mulling over in my head (you know, that process before you actually start putting down on paper) a design for a relatively 'simple' learning bridge, using off the shelf support chips. I'm currently in the middle of an academic semester, and if I don't happen to work during the coming break (for the non-australians, our academic year is mar->nov), then this is something I will take up. The actual design I have in mind has a 839X IEEE802.3 CSMA/CD ethernet controller on the network side plus an 8088 embedded controller to do all the work (or, maybe something else, but 8088 assembly is familiar to me and its a real cheap chip). The output stage is a synchronous HDLC varient (SABM mode, cut down for pp operation) running at a select- able synch rate (anywhere from 19.2k to 10mbps, obviously @ 19.2k you would have problems on a loaded ethernet). One of the main reasons for starting this is that another colleague of mine has an interest in constructing the 2mbps microwave (10GHz) project as seen in your local ARRL handbook. This would tie in nicely, but further to this, it has the possibility to interface to any communications medium you desire (as long as it can handle a synch incoming data stream). It oculd plug into the other side of a spread-spectrum board, it could be used with an async interface and a pc to tunnel traffic across another network, and so on. There is also a possibility to use some of the HDLC initialisation phases to exchange public keys :-), and to encrypt information frames (headers == plaintext) on the fly. 'Generic' and 'Modular' is a basic philosophy of mine. If I do have the time, and complete this project, then I hope to make it 'available' to the masses (so to speak). I can envisage that there would be people interested in such a setup. As an undergrad Computer Systems Engineer student, there are no problems with access to appropriate design and testing equipment, its just a matter of me getting the time. Of course, all this is 'in my head' at the moment, so nothing is definite. Discussion, ideas and pointers are welcome, although the technical side of things maybe straying from the cypherpunk agenda. Matthew. -- Matthew Gream,, M.Gream at uts.edu.au -- Consent Technologies, 02-821-2043. From tigger at indirect.com Wed Sep 15 00:15:13 1993 From: tigger at indirect.com (Jiva De Voe) Date: Wed, 15 Sep 93 00:15:13 PDT Subject: PGPC 2.2 available In-Reply-To: <9309141739.AA08520@nagel.VIS.ColoState.EDU> Message-ID: <199309150712.AA17262@indirect.com> > > -----BEGIN PGP SIGNED MESSAGE----- > > PGPC 2.2 is available for anonymous ftp from 129.82.156.104 > in /pub/pgpc/pgpc22.tar.[Z,gz] > > It is available in either gnuzip or regular compress. > I still can't get this critter decompressed. Is this some sort of joke or something? Has anyone been able to decompress it? gnuzip sez not a zipped file. Uncompress sez, not a compressed file, gunzip won't read it, tar won't read it. I'd really like to try this fellow's product, but have received no reply to my email about how to decompress it and can't make it work. Mebbe some kind person could send me a tar version? (Don't mean to sound flamish BTW, just frustrated) Tigger at indirect.com From mdiehl at triton.unm.edu Wed Sep 15 00:49:08 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 15 Sep 93 00:49:08 PDT Subject: more than spread spectrum In-Reply-To: <9309150541.AA10786@netcom2.netcom.com> Message-ID: <9309150747.AA15660@triton.unm.edu> According to Doug Merritt: >cme at ellisun.sw.stratus.com (Carl Ellison) said: >>The benefit isn't just for Cypherpunks. It's a free network for the masses... >>I'll volunteer to do the software for the node card. Does anyone have >>hardware design/fab to donate to the effort? > > You might want to contact the Garden project, which I believe is operational > in San Jose and in Santa Cruz. I'm not up on all the details, but it is > far too similar to what you're talking about to ignore. ....and keep us posted! Thanx in advance. J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From gg at well.sf.ca.us Wed Sep 15 02:05:14 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 15 Sep 93 02:05:14 PDT Subject: more than spread spectrum Message-ID: <93Sep15.020336pdt.14247-1@well.sf.ca.us> Re. Carl's suggestion to "lay our own wires/fibers..." That's exactly what I'm up to with the Community Dialtone project. Basically it comes down to having a neighborhood switch. We may be doing our first installation in the Winter, about 800 lines if all goes well. Seems to me that owning the switching & transmission infrastructure has a lot of possibilities. Anyway, more news to come on this in a few weeks... The thing is, I've looked into things like having infrared laser networks and various non-switched message relay systems... these just don't have the overall reliability of a decent switched system, for a large number of reasons which essentially boil down to the fact that each individual link is weak enough that even a redundant system can break down badly at points where the link density is relatively thin. Then also there's the question of economic feasilbility; to make a decentralised/non-switched system work, you need an application that is *so* popular that everyone in an area will want to be in. This comes down to subscriber density, and the issue is basically the same with telephone lines, but everyone needs a phone line... cable TV has high market penetration but satellite TV doesn't... how can we expect a lot of average folks to set up an infrared relay, eh...? Seems to me the best thing is to have the IR relays located where they can connect among the switching systems serving the various blocks and neighborhoods. (and if anyone's figured out how to do that at 2.048 Mb, i.e. approx double T1, please email me ASAP). -gg From HFinney at shell.portal.com Wed Sep 15 06:09:10 1993 From: HFinney at shell.portal.com (HFinney at shell.portal.com) Date: Wed, 15 Sep 93 06:09:10 PDT Subject: Remail: errors Message-ID: <9309150646.AA29585@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- I have been out of town for the last week, so I missed some CP mail. It looks like some good things are happening with remailers, though. Kudos to Karl, Sameer, and the others for their work! I have received many messages to my remailer in the last week which came from remail at tamsun.tamu.edu, which were PGP-encrypted apparently in an effort to get my remailer to send them. They did not work, though, because there was no "Encrypted: PGP" header to trigger the remailer's decryption. This can be arranged by creating the message something like this: ======================================================== :: Request-Remailing-To: hfinney at shell.portal.com :: Encrypted: PGP - -----BEGIN PGP MESSAGE----- - -----END PGP MESSAGE------ ======================================================== This would then be sent to remail at tamsun.tamu.edu. I don't know whether the multiplicity of such erroneous messages is just due to one person stubbornly re-trying, or whether there is an error in one of the new programs for creating chained remailer messages. Hal Finney hfinney at shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLJaNuKgTA69YIUw3AQHrNwQAowMEQwuH6YyHoj6T7AqZFLNdTf+eqJ9L LhAatHS94nmC1smkfVNq0dZmigmkvBdMNEPlBZemmxALz+KJw6OSY/ULSBmuVNEq 5rJANh3XimoJWqLISy2lZiuC5Fw2R7UvRadcdM94pncSVvev92Fyf7CqEOOtrGAK PUzRds7BVNo= =FpLa -----END PGP SIGNATURE----- From hfinney at shell.portal.com Wed Sep 15 06:09:17 1993 From: hfinney at shell.portal.com (hfinney at shell.portal.com) Date: Wed, 15 Sep 93 06:09:17 PDT Subject: caching scripts Message-ID: <9309150646.AA29593@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- I am very excited to hear about Karl's progress in experimenting with caching (batching) mail messages. Karl, if it becomes convenient, I'd appreciate seeing a copy of your scripts. I have two thoughts about batching. The first regards the mechanism for arranging for activation of the batch scripts at regular intervals. Karl mentioned at and crontab as two ways of arranging for this. Some users may not be allowed use of these functions. I am not sure I can use them on the systems which I use. Another possibility, it occurs to me, would be an "activation" message sent to each remailer from some system where crontab usage is allowed - one of the systems which is owned by a remailer operator, for example. This system would send out an activation message at midnight every night to each remailer which had requested this function. The activation message would have a special header field which could be trapped by the slocal program and cause it to run the batch script. The other idea I had was to increase the volume of messages passing through the remailers. This way we could batch at more frequent intervals while still having good "mixing" at each step. Suppose some remailer system took on the task of periodically injecting messages into the remailer web. Each message would be a large chain, perhaps through a dozen randomly- chosen remailers, which would end up disappearing by being sent to a "bit bucket" address like nobody at soda.berkeley.edu. With the new scripts appearing for producing random remailer message chains such a program would be quite easy to write. The message injection rate would be adjusted to give each remailer in the system an average load large enough that batching would usually have (say) ten or more messages to work with. Perhaps nine of those ten would be these dummy messages, while one is an actual user message. But it would not be easy to tell these apart, at least for user messages which are in the middle of their chain; each message, dummy and real, is from another remailer and to another remailer. There is no hint as to which are the actual messages. It is true that user messages can be distinguished from dummy ones when they are on their first or last stage in the chain; on the first stage, they are the only messages coming from non-remailer addresses, and on the last stage they are the only messages going to non-remailer addresses. One way to fix this would be, instead of having the final destination of the message be a "bit bucket" address, to instead choose a random Internet address (say, from one of the "whois"-type databases), and to send a message whose body starts with "Test message, please ignore". With the tens or hundreds of thousands of addresses available (and with the geometric growth of the Internet), it should not be necessary ever to repeat an address. So perhaps this slight annoyance to Internet users would be tolerable. Only a small fraction of users would ever receive such a message. The increase in traffic brought about by this dummy message source would not be large in terms of the net as a whole. It would only need to introduce messages at the rate of (# messages per batch) * (# of remailers) / (size of chain per message) per (batch interval). Plausible values might be: # messages per batch: 10 # of remailers: 20 size of chain per message: 10 batch interval: 6 hours This works out to about 3 messages per hour, not too large a load. Of course, this message injection system would only be maintained as long as user message traffic remained too low to provide good mixing in a batch system. As user message traffic increases, the injection rate would be decreased to compensate, until finally it might be possible to eliminate the dummy-message injection completely. Comments are appreciated, as usual. Hal Finney hfinney at shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLJaN5agTA69YIUw3AQECnwP9F+0gMxoL4xoLPyAJS4/owHOmTGW2OE0a nOLkjop+vT388LyZjbj40cRwm0OWpjNXwvsxsmY+Uhc8EYyTu/H1wKn2N2PR0Ufu TD/EYxLFuvXQGviGKftMfM/VbwRXUf1SiUnPovZ7jVaBhacp62y4+C6BQtFSZIft l3T2U1KI+Y4= =11AS -----END PGP SIGNATURE----- From cme at ellisun.sw.stratus.com Wed Sep 15 08:14:19 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Wed, 15 Sep 93 08:14:19 PDT Subject: FTP location for sci.crypt FAQ Message-ID: <9309151511.AA07423@ellisun.sw.stratus.com> >sci.crypt Usenet newsgroup FAQ. It's posted occasiuonally to sci.crypt, >but I can't think of a site (offhand) where you can FTP it. [from the FAQ] The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, sci.answers, and news.answers every 21 days. From loki at convex1.TCS.Tulane.EDU Wed Sep 15 08:29:10 1993 From: loki at convex1.TCS.Tulane.EDU (the mischeivious god) Date: Wed, 15 Sep 93 08:29:10 PDT Subject: PGPC 2.2 available...Problems with GNUZIP?? In-Reply-To: <199309150712.AA17262@indirect.com> Message-ID: <9309151527.AA15762@convex1.tcs.tulane.edu> > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > PGPC 2.2 is available for anonymous ftp from 129.82.156.104 > > in /pub/pgpc/pgpc22.tar.[Z,gz] > > > > It is available in either gnuzip or regular compress. > > > > I still can't get this critter decompressed. Is this some sort of joke or > something? Has anyone been able to decompress it? gnuzip sez not a > zipped file. Uncompress sez, not a compressed file, gunzip won't read it, > tar won't read it. I'd really like to try this fellow's product, but have > received no reply to my email about how to decompress it and can't make it > work. > > Mebbe some kind person could send me a tar version? Ok nate at monet.vis.colostate.edu sez that you can trick the host ftp site into decompressing 4 U!!!1 Use "get" instead of the easier wildcard "mget" and the ftp site does the rest just follow the prompts...if any. However, I am not sure that the ftp sites appreciate this practice so don't do this if you can find alternate means... Also, ftp time takes a LOT longer...so get a cup of tea and sit by your terminal as you need to do some typing if you are going to "get" several .gz files. LOKI on a crippled convex with a fucked kermrc (send me a good one please) and no gnuzip util on the site at all. From wcs at anchor.ho.att.com Wed Sep 15 10:49:22 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Wed, 15 Sep 93 10:49:22 PDT Subject: caching scripts Message-ID: <9309151749.AA03778@anchor.ho.att.com> Hal writes, on the subject of filler messages > It is true that user messages can be distinguished from dummy ones when > they are on their first or last stage in the chain; on the first stage, > they are the only messages coming from non-remailer addresses, and on the > last stage they are the only messages going to non-remailer addresses. > One way to fix this would be, instead of having the final destination > of the message be a "bit bucket" address, to instead choose a random > Internet address (say, from one of the "whois"-type databases), and to > send a message whose body starts with "Test message, please ignore". > With the tens or hundreds of thousands of addresses available (and with > the geometric growth of the Internet), it should not be necessary ever > to repeat an address. So perhaps this slight annoyance to Internet users > would be tolerable. Only a small fraction of users would ever receive > such a message. This is a way to increase the public's annoyance with remailers, when what we need to do is increase their acceptance of them. It also doesn't work - a cleartext message saying "Please ignore" is visible to any eavesdropper, an encrypted message to a real person is annoying and non-readable, and an encrypted message to a bogus person will usually generate bounce-mail (which is obvious to eavesdroppers), or will at least drop on an operator's floor, annoying the operator. If we can get a reasonable number of remailers operating, it makes much more sense to have standard bit-bucket addresses, and if we want to get more traffic to sites that aren't obviously remailers, we need to get their permission. This can either be done by asking people (which the Bad Guys can watch), or perhaps by providing some semi-useful service, like a netnews test sink or mail-a-joke or something; even those tend to be obvious - unless they can also be remailers or at least require crypto or other illegible data input. Bill Stewart From an31185 at anon.penet.fi Wed Sep 15 11:24:22 1993 From: an31185 at anon.penet.fi (Anon of Ibid) Date: Wed, 15 Sep 93 11:24:22 PDT Subject: Testing randomness of PGP-generated IDEA keys Message-ID: <9309151822.AA11900@anon.penet.fi> mjr at TIS.COM said: > I found myself embroiled in a similar exploration of random >number generation as part of some other work, and it took me a while >to realize that running statistics on the output of the PRNG is >almost useless, if you're using a cryptosystem or cryptographic hash >as the PRNG. Yeah, this is a good point. I was assuming that there was no simple way of determining the possible keys from the time and other information you'd get with a random PGP-encrypted file that you wanted to crack. *If* that is the case, then looking at the output of the PRNG is useful to show that the worst-case of a brute force attack using all possible keys cannot be improved by taking the relative frequencies into account when creating the possible keys. It would be embarassing if 0x2A appeared 100 times more frequently than any other byte value, or if there was a strong correlation between the bytes in each key, for example. Whatever the case, we can probably write off any idea of brute force attack like the DES one, unless you have a few billion years to play with. (In which case, you'll do better attacking the RSA key anyway) > What you've got to look at is the predictability of the >input to the PRNG. PGP is in really good shape here, because it >bootstraps its PRNG with its input, which presumably is unknown >to the attacker. An example of a weak PRNG would be: [ Description deleted ] > Anyhow, I've been over-long winded. I think PGP is >in good shape because of the aforementioned property of >using the message as a seed. Messages that don't change >much, or that change predictably, are subject to exhaustive >searching. A means of analysing the unpredictability of >the seed is more worthwhile. Yes, obviously you're right. PGP seems to take the randseed.bin file, the MD5 of the input, and the current time, and munge all of them together using the IDEA encryption routines to create the final results. So, it's not at all clear how to test this end of things (one of the reasons why I decided to look at the output rather than the input). I'll have to poke around more in the code and see if I can work out what it's actually doing with all this stuff to get some idea of how to test it, if possible. The contents of randseed.bin are created by generating some random bytes using the same generation routine as the key and encrypting it with the key, so they should be as random as the sample I created. I could easily rewrite the program to generate the files and just calculate the MD5 and look at that, but, like you, I'm not sure that will tell us anything. Still, I can easily afford the CPU time, so it might be worthwhile anyway. Overall, I'm willing to accept that the key generation works pretty well at this point. What bearing might this have on the suggestions of using electronic cheques (presumably encrypted with PGP) ? If the cheque is a standard format, that might open up some possibilities with this kind of approach, especially if you know who it came from and/or who it's payable to. >My hat >is off to the guy who came up with the idea of seeding >the PRNG with the message. That was *clever*. > >mjr. Definitely. In fact, I wonder if this explains the 'fatal flaw' that people have mentioned. According to the comments in the code, the MD5 was introduced as an improvement over the previous method of generating the key, so perhaps there really was a flaw in this key generation that has now been fixed, or at least greatly improved. ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From mjr at TIS.COM Wed Sep 15 12:09:12 1993 From: mjr at TIS.COM (mjr at TIS.COM) Date: Wed, 15 Sep 93 12:09:12 PDT Subject: Testing randomness of PGP-generated IDEA keys Message-ID: <16690.9309151905@otter.TIS.COM> Anonymous writes: >Yes, obviously you're right. PGP seems to take the randseed.bin file, >the MD5 of the input, and the current time, and munge all of them together >using the IDEA encryption routines to create the final results. Assume the current time is a wash. Any message sent is going to have an approximate time (in seconds) inserted in the header as the MTA moves it, so that value is searchable trivially. For example, this message nicely contains a timestamp: Date: Wed, 15 Sep 1993 18:22:10 UTC I figure searching all the seeds within 12 hours of that will eliminate the time as a seed, and that's only 84,000 searches, which is huge orders of magnitude easier than searching DES. You don't even need gnarly fictional $1.5million DES-searching machines to do it. That leaves the MD5 of the input and randseed.bin. The MD5 of the input is by definition unknown to the attacker in MOST cases, right? If you're using this for confidentiality, that is. If the input is known, then you're left with just randseed.bin. >The contents of randseed.bin are created by generating some random bytes >using the same generation routine as the key and encrypting it with the key, >so they should be as random as the sample I created. I'm not entirely clear on this. It uses the same mechanism as the key and feeds it back through itself? What is the input into this process? Again: ignore the apparent randomness of the output, you need to look at the unpredictability of the input seed. Randseed.bin should be kept secret, clearly, as it's part of your key. >What bearing might this have on the suggestions of using electronic cheques >(presumably encrypted with PGP) ? If the cheque is a standard format, that >might open up some possibilities with this kind of approach, especially if >you know who it came from and/or who it's payable to. If I know the layout of the check and know that the only values that will change are a serial number which increases monotonically, and a value, which averages around $1,000, I can probably crack your PRNG in an hour or two, depending on how many processors I throw at it. Remember that this parallelizes trivially. Also, when you crack the PRNG with a public key system, you *KNOW* instantly that you've gotten the correct key, so the entire process is very hands off. One way of thinking about the problem is trying to count how many bits of unpredictability go into your PRNG seed. If you're willing to assume your adversary can brute-force search DES' 56-bit keyspace, then you'd better assume he's also willing to brute-force search your PRNG. So figure you want more than 56 bits of pure unpredictability as your seed. This is a tricky problem. One option is to give the user a typematic buffer: "hit keys for 30 seconds" - you NEED unpredictability! mjr. From nowhere at bsu-cs.bsu.edu Wed Sep 15 12:44:23 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Wed, 15 Sep 93 12:44:23 PDT Subject: No Subject Message-ID: <9309151944.AA16459@bsu-cs.bsu.edu> Hi, Can someone clue me in to a location of a VMS version of PGP? Thanks From 72114.1712 at CompuServe.COM Wed Sep 15 12:49:12 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Wed, 15 Sep 93 12:49:12 PDT Subject: SKIPJACK IN POPULAR SCI Message-ID: <930915194156_72114.1712_FHF44-1@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cypherpunks, There is a short piece about Skiptap, er, Skipjack, in the electronics section of the October "Popular Science." It has a pretty good diagram and a photo of the Mykotronx chip. It says "Bill Clinton himself decided that the U.S. government will promote a new encoding chip for communications." It also quotes a guy from NIST who says, "Once you accept the fact that law enforcement has to do its job, this is a good solution." (Fortunately, Cypherpunks generally *don't* accept that "fact.") A vice president at Mykotronx, John Droge, tried to create the impression that Skipjack just sort of happened to them. He also gave away the real party at interest. He said, "They [the NSA] came to us with a neat equation and said, `Here you go.'" The article mentioned that 85% of the comments at recent federal hearings were hostile or skeptical. Amazingly, the article never quoted May, Hughes or Gilmore. Where has this writer been? S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From an31185 at anon.penet.fi Wed Sep 15 15:05:31 1993 From: an31185 at anon.penet.fi (Anon of Ibid) Date: Wed, 15 Sep 93 15:05:31 PDT Subject: Random numbers Message-ID: <9309152204.AA24574@anon.penet.fi> mjr at TIS.COM writes: >So figure you want more than 56 bits of pure unpredictability as your >seed. This is a tricky problem. One option is to give the user a typematic >buffer: "hit keys for 30 seconds" - you NEED unpredictability! So, it sounds like what we *really* need is a little box with a shot-noise generator that attaches to a serial port and generates truly random numbers to use for the key. Anyone out there feel like designing one for us ? Also, what's the recommended book/books on cryptanalysis ? Looks like I have a fair amount to read up on..... ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From williacw at vuse.vanderbilt.edu Wed Sep 15 15:35:50 1993 From: williacw at vuse.vanderbilt.edu (Charles Williams) Date: Wed, 15 Sep 93 15:35:50 PDT Subject: Unix version of PGP Message-ID: <9309152234.AA29816@necs.vuse> Is there a UNIversion of PGP? Please Email me the location at: WESLEY at ctrvax.vanderbilt.edu Thanks From newsham at wiliki.eng.hawaii.edu Wed Sep 15 15:45:31 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Wed, 15 Sep 93 15:45:31 PDT Subject: Random numbers Message-ID: <9309152245.AA03105@toad.com> Anon Wrote > mjr at TIS.COM writes: > >So figure you want more than 56 bits of pure unpredictability as your > >seed. This is a tricky problem. One option is to give the user a typematic > >buffer: "hit keys for 30 seconds" - you NEED unpredictability! > > So, it sounds like what we *really* need is a little box with a shot-noise > generator that attaches to a serial port and generates truly random > numbers to use for the key. Anyone out there feel like designing one for us ? Last time I was fingering through an analog parts catalog under the telephony section I noticed a bunch of parts that generate audio-noise. Maybe some of these would be suitable (if they dont use an internal digital state machine to generate the noise). From an23412 at anon.penet.fi Wed Sep 15 16:44:28 1993 From: an23412 at anon.penet.fi (an23412 at anon.penet.fi) Date: Wed, 15 Sep 93 16:44:28 PDT Subject: Joke of the Day Message-ID: <9309152342.AA10070@anon.penet.fi> My actual horoscope for today: "A paradox: Someday, millions will read your words, and yet you shall be anonymous! Your ability to mediate makes you friends with opposing parties." The joke of the day from an AP report on the veep's Information Highway press conference: "American industry already is out front in high-tech development, but a fear exists that better coordinated government-industry relationships in other countries may give an edge to foreign competition." ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From loki at convex1.TCS.Tulane.EDU Wed Sep 15 17:09:14 1993 From: loki at convex1.TCS.Tulane.EDU (the mischeivious god) Date: Wed, 15 Sep 93 17:09:14 PDT Subject: where is VMS PGP 23?????? In-Reply-To: <9309151944.AA16459@bsu-cs.bsu.edu> Message-ID: <9309160007.AA21239@convex1.tcs.tulane.edu> > > Hi, > > Can someone clue me in to a location of a VMS version of PGP? > > Thanks > Send me the info as well at loki at convex1.tcs.tulane.edu Thank you LOKI From doug at netcom.com Wed Sep 15 17:10:33 1993 From: doug at netcom.com (Doug Merritt) Date: Wed, 15 Sep 93 17:10:33 PDT Subject: Joke of the Day Message-ID: <9309160010.AA17092@netcom.netcom.com> an23412 at anon.penet.fi said: >My actual horoscope for today: Uh-oh...your anonymity is partially compromised; we can now narrow down your identity 91.7 percent more closely than before! A few more slips like that and we'll have it down to one of several thousand choices... Speaking of privacy violations, a coworker relates a story from his father (ok, just a FOAF story, but it's still interesting): He needed to find his wife, who'd headed off for some errand and thence to the airport, leaving her spending cash at home. He called her on her cellular car phone, but she'd turned it off. He called Cellular One and explained the problem, and they told him over the phone where she was...he sped off and caught up with her. Although this was handy for him, it's an obvious privacy problem for Cellular One to tell someone where one of their customers is. Doug From loki at convex1.TCS.Tulane.EDU Wed Sep 15 17:14:28 1993 From: loki at convex1.TCS.Tulane.EDU (the mischeivious god) Date: Wed, 15 Sep 93 17:14:28 PDT Subject: SKIPJACK & Police...the real rear entry. In-Reply-To: <930915194156_72114.1712_FHF44-1@CompuServe.COM> Message-ID: <9309160013.AA21301@convex1.tcs.tulane.edu> > Cypherpunks, > > There is a short piece about Skiptap, er, Skipjack, in the > electronics section of the October "Popular Science." It has a > pretty good diagram and a photo of the Mykotronx chip. > > It says "Bill Clinton himself decided that the U.S. government > will promote a new encoding chip for communications." It also > quotes a guy from NIST who says, "Once you accept the fact that > law enforcement has to do its job, this is a good solution." > (Fortunately, Cypherpunks generally *don't* accept that "fact.") Ok...Police = TO PROTECT AND SERVE. To protect us from ourselves....self-righteous fucks decide what to protect us from...with little or no democratic feedback To serve...a long hard disease ridden penis with no condom much less lubrication.. in the butt...part of the S & M appeal of control and authority... Loki From nowhere at bsu-cs.bsu.edu Wed Sep 15 18:49:15 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Wed, 15 Sep 93 18:49:15 PDT Subject: Odds and Ends (Books) (fwd)Re: Books: wanted to buy Message-ID: <9309160148.AA13320@bsu-cs.bsu.edu> In article p00122 at psilink.com, "BSW Gateway" () writes: >I am searching for two out-of-print books. I would like to purchase one >copy each in reasonably good condition. If you have either and are willing >to part with it, please contact me by email. Thanks. > >Tutorial: The Security of Data in Networks >by Davies >IEEE Computer Society Press, 1981 > >Kahn on Codes >by Kahn >Macmillan, 1983 > >Note: the second book is NOT "The Codebreakers" but a later book by Kahn. I tried e-mail but the message is bouncing around like a kangaroo on certain controlled substances. The following is a list of bookstores dealing, more or less specifically with espionage and intelligence and include some coverage of crypto. My recommendation for the first title would be to try Elm. If you contact C&D, ELM, or NIBC, mentioning my name _might_ help. Alec Chambers Cloak and Dagger Books, 9 Eastman Avenue Bedford, NH 03110-6701 Phone: (603) 668-1629 (evenings) Proprietor: Dan Halpin Jr. Dealer in out of print and rare books relating to nonfiction espionage, crypto, terrorism and partisan and guerilla warfare. Stocks more than 10,000 books and will do searches. Dan is extraordinarily amiable and helpful, but does ask that you send $2.50 for a catalog. I have dealt happily with him for some time. Elm Spy Books, P.O.Box 9753 Arnold, MD 21012 Phone: (301) 544-9014. Proprietor: Emil Levine Has a coverage similar to Cloak and Dagger, but is interested in specializing in crypto (he's not too far from Ft. George mmmmmmmfff...). Another helpful individual with whom I have dealt. Catalog costs $2.00. Military Bookman, 29 East 93rd Street New York, NY 10128. Mail Order (212) 348-1280 Large collection of military titles, including military intelligence. Catalogs available National Intelligence Book Center, 1700 K Street NW, Suite 607 Washington DC Phone: (202) 785-4334 FAX: (202) 331-7456 e-mail: 70346.1166 at COMPUSERVE.COM Publishes an annotated, bimonthly publication, Surveillant: Acquisitions for the Intelligence and Security Professional, listing new books, paperback editions, foreign language titles, US government documents on intelligence, video, and audio tapes, forthcoming books and works in progress, and news and events. Annual subscription is $96 in the U.S. The Book Center will also compile bibliographies on _specific_ intelligence on request. All sales are now conducted through Olsson's Books, 1200 F Street, NW, Washington DC 20004 (202) 337-8084. Q.M.Dabney&Co., 11910-P Parklawn Drive, Rockville, MD 20852 Phone (301) 881-1470 Very large military collection with some intelligence titles. Carries only out-of-print books. Not a browsing bookstores, phone orders only, catalogs available. I have dealt happily with them for years although they are SLOW on actually sending the stuff out. Ruth Koffsky Books, 5515 Greystone Street, Chevy Chase, MD 20815 Phone: (301) 656-5587 Specializes in ex-library and reader's copies of works on intelligence, politics, and world affairs. Open by appointment only or by mail. Upon request will send a list of titles on a very specific topic. Sidney Kramer Books, 1825 I Street, NW Washington, DC 20006. Mail order: (202) 293-2685 Fax: (202) 835-9756 Large collection of intelligence-related titles in sections on "intelligence," "military affairs," and "regional studies." Offers catalogs and will special order. Sky Books, 48 E. 50th Street, Second Floor, New York, NY 10022 Mail Order: (212) 688-5086. Large selection of titles on military intelligence and espionage. Offers book club with selection of intelligence titles. From MIKEINGLE at delphi.com Thu Sep 16 00:14:32 1993 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Thu, 16 Sep 93 00:14:32 PDT Subject: Random Numbers Message-ID: <01H300QM3KUI8ZG7IN@delphi.com> an31185 at anon.penet.fi writes: >So, it sounds like what we *really* need is a little box with a shot-noise >generator that attaches to a serial port and generates truly random >numbers to use for the key. Anyone out there feel like designing one >for us? That sounds doable. Tune a radio to a spot where there is static, plug it into the audio in port of a SoundBlaster card, sample a few Kbytes, and MD5 it to get your key. Nobody is going to reconstruct that. < MikeIngle at delphi.com > P.S. Has anyone called Mykotronx lately? I called a while ago and asked for any databooks and appnotes on Clipper. They said the databooks weren't ready yet, and offered to put me on a mailing list for appnotes when they were ready. I got the impression Mykotronx isn't too happy about the status of the Clipper/Spooktap project. :-) From gg at well.sf.ca.us Thu Sep 16 02:04:33 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 16 Sep 93 02:04:33 PDT Subject: caching scripts Message-ID: <93Sep16.020153pdt.14499-3@well.sf.ca.us> filler messages.... Little Jack Horner sat in the corner decrypting a long email letter. The letter was dull but the humorous "null" that it ended with made him feel better! -gg From yerazunis at aidev.enet.dec.com Thu Sep 16 06:54:39 1993 From: yerazunis at aidev.enet.dec.com (I am not a number. I am an unbound variable. 16-Sep-1993 0950) Date: Thu, 16 Sep 93 06:54:39 PDT Subject: Digital noise Message-ID: <9309161351.AA02771@enet-gw.pa.dec.com> Timothy Newsham writes: >Last time I was fingering through an analog parts catalog under the >telephony section I noticed a bunch of parts that generate audio-noise. >Maybe some of these would be suitable (if they dont use an internal >digital state machine to generate the noise). Unfortunately, last time I checked, they used a fairly short internal PRNG to generate the "noise" (which means it's not noise at all, it's completely correllated and repeating, it just _sounds_ like noise to a human ear. To get real random noise, try using a transistor "backwards", as a zener diode. Then look at the voltage- it's quite "noisy", esp. if you use a decent-sized series resistor (try 100Kohms). -Bill (done this before)... From freeman at MasPar.COM Thu Sep 16 08:30:46 1993 From: freeman at MasPar.COM (Jay R. Freeman) Date: Thu, 16 Sep 93 08:30:46 PDT Subject: Digital noise Message-ID: <9309161529.AA05681@cleo.MasPar.Com> > To get real random noise, try using a transistor "backwards", as a > zener diode. Then look at the voltage- it's quite "noisy", esp. if you > use a decent-sized series resistor (try 100Kohms). When I was in graduate school, a colleague built a gadget based on this principle as a source of Poisson-distributed pulses for testing the post-detector electronics of X-ray and extreme-ultraviolet astronomical instruments. I don't remember the precise source of the noise, but it was similar to the "zener" trick cited in that it was based on quantum phenomena rather than a mathematical generator. The idea was to get random pulses of varying amplitudes, amplify them up and use only those bigger than a threshold to generate output pulses. The instrument also averaged the output rate and used it via feedback to adjust the amplifier, so as to obtain a desired average rate of outputs. I think that for a while at least there was a commercial random-noise generator available that used this principle, though I don't remember whose (and it's been long enough that it probably doesn't matter). Try scientific-instrument catalogs, et cetera. -- Jay Freeman From cme at ellisun.sw.stratus.com Thu Sep 16 08:49:20 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Thu, 16 Sep 93 08:49:20 PDT Subject: Random Numbers Message-ID: <9309161545.AA09335@ellisun.sw.stratus.com> >Date: Thu, 16 Sep 1993 02:38:26 -0400 (EDT) >From: Mike Ingle >Subject: Random Numbers >Message-Id: <01H300QM3KUI8ZG7IN at delphi.com> > >That sounds doable. Tune a radio to a spot where there is static, plug it >into the audio in port of a SoundBlaster card, sample a few Kbytes, and >MD5 it to get your key. Nobody is going to reconstruct that. A poster a while back on sci.crypt pointed out that if you plug nothing in to the audio input (eg., /dev/audio on a Sun), what you get is circuit noise. If you then compress it, you get pretty good random input. It's not something someone else can monitor or interfere with. If you then pull off some bits for encryption keys and encrypt the rest using those keys, .... I have a small C program to do that -- do any left-over compression and build a shell script to drive IDEA for encryption. It's avbl by mail if anyone wants it. If enough want it, I'll post it on sci.crypt. > < MikeIngle at delphi.com > [p.s.] > I got the impression Mykotronx isn't too happy about the status >of the Clipper/Spooktap project. :-) Yeah? Do tell. What did they say? From mjr at TIS.COM Thu Sep 16 09:49:20 1993 From: mjr at TIS.COM (mjr at TIS.COM) Date: Thu, 16 Sep 93 09:49:20 PDT Subject: Random Numbers Message-ID: <18957.9309161647@otter.TIS.COM> I admit I'm guilty of being somewhat ignorant of how PGP implements randseed.bin. My experience with PGP indicates that it's pretty well-thought-out in general, so perhaps I'm repeating the obvious. One possibility is to treat part of the random seed as if it was your secret RSA key. Systems like PEM store the RSA key encrypted on disk someplace - you could also store an encrypted random seed which you decrypt when you retrieve the secret key, use to bootstrap your PRNG, and then replace with some output from the PRNG when you're done. That way, the seed is (by definition) hidden, and an attacker is going to have much more trouble attacking your PRNG by searching your random seed space. mjr. From stig at netcom.com Thu Sep 16 10:29:21 1993 From: stig at netcom.com (Stig) Date: Thu, 16 Sep 93 10:29:21 PDT Subject: Fwd: PERSONAL COMMUNICATIONS SERVICES (PCS) SPECTRUM AUCTION Message-ID: <9309161725.AA28448@netcom2.netcom.com> I thought the Cypherpunks might take an interest in this... In <9309151633.AA29877 at essential.org>, james love wrote... > > Taxpayer Assets Project > Information Policy Note > September 15, 1993 > > > TAXPAYER ASSETS PROJECT FILES COMMENTS WITH FCC ON > PERSONAL COMMUNICATIONS SERVICES (PCS) SPECTRUM AUCTION > > On Friday September 10, 1993 the Taxpayer Assets Project > (TAP) filed comments with the Federal Communications Commission > (FCC) on the proposed auction of spectrum for Personal > Communications Services (PCS). PCS is the name for a new class > of wireless telecommunications services that industry groups > claim will generate more than $200 billion in revenue by the year > 2010. > > TAP's comments addressed two issues, the size of the > spectrum blocks to be auctioned, and the bidding methods used to > allocate the PCS licenses. > > BACKGROUND > > Congress and the Clinton Administration will use auctions to > award licenses to use new spectrum that was previously allocated > to the government and other uses. Industry groups are engaged in > intense lobbying over the terms of the auctions, which will be > designed by the FCC. A key issue is the number of licenses to be > awarded in each market. PCS Action, Inc., an industry trade > group, wants the FCC to limit the number of licenses in each > market, in order to limit "excessive" competition, that would > "marginalize" PCS services. PCS Action prefers two licenses per > market, and "certainly no more than three." PCS Action, Inc. has > also argued that large blocks of spectrum (40 Mhz) are needed for > each license for technical reasons. If the large 40 Mhz blocks > are used the FCC can award no more than 3 license per market. > > Other potential license holders or PCS competitors have > argued that much smaller spectrum blocks are technically > feasible, and would provide more post auction competition. MCI > and Bell Atlantic have filed comments with the FCC saying that 20 > Mhz blocks are adequate, and some PCS bidders have indicated that > blocks as small as 10 Mhz may be large enough. The issue of the > size of spectrum blocks is important, since it will determine the > maximum number of licenses that can be issued in each local > market. > > A second issue that has received less attention concerns the > methods used to receive revenues from winning bidders. The > government can require bidders to submit up front cash payments, > or payments over time, including royalties against future PCS > revenues. > > > > TAP COMMENTS ON THE SIZE OF PCS SPECTRUM BLOCKS > > Regarding the size of the spectrum blocks to be auctioned, > TAP said: > > The FCC should allow bidders to purchase the smallest > possible blocks of the spectrum, while providing for > mechanisms that will allow bidders to aggregate or > consolidate blocks, subject to FCC approval. . . > > By choosing the smallest possible blocks of spectrum to > auction, the FCC will assign the initial rights to use the > spectrum to a potentially large group of license holders, > who can be expected to consider a wider range on innovative > PCS services. However, some important PCS services may > require the larger bandwidth. The FCC can easily > accommodate this problem by allowing bidders to aggregate > and consolidate spectrum blocks, in order to offer higher > bandwidth services. The aggregation and consolidation of > spectrum blocks should be subject to an FCC finding that the > new allocation is in the public interest. This procedure > would allow more flexibility in determining the size of > allocation blocks with each market, and provide better > opportunities for smaller firms to bid on spectrum. > > The initial size of spectrum blocks will be an important > decision, since it is unlikely that the FCC will "split" > licenses, even if it turns out that smaller blocks are adequate > to provide useful PCS services. By beginning with the "smallest > possible blocks," the FCC can always allow license holders to > aggregate and consolidate blocks, if the larger blocks are truly > needed. This will also allow local markets to consider a wider > range of configurations, including combinations of small and > large blocks, as PCS markets develop. > > > TAP CAUTIONS AGAINST BIDDING METHODS THAT RELY EXCESSIVELY UPON > UP FRONT CASH PAYMENTS > > TAP also told the FCC the auction should not rely > excessively on up front cash payments. The federal government > can structure the payments on the license in a number of ways, > including up front cash payments, fixed payments spread out over > several years, or payments which are contingent on future cash > flows, such as royalties on future revenues or units of services > provided. > > The PCS spectrum auction will be the largest non-financial > auction held by the federal government. But the economic value > of a PCS license will depend upon a highly uncertain cash flow > over the long period of time. If the FCC auctions the licenses > to the highest cash bidders, the government will be asking firms > to pay now for the rights to enter a business that will not be > fully developed for many years. > > TAP raised two objections to excessive reliance upon up > front cash payments to auction the spectrum. First, many smaller > firms will be unlikely to raise enough cash to bid against the > larger incumbents in the telecommunications markets. Second, > bidders will discount the future "economic rents" from licenses > by a higher "discount rate" than the government's costs of > capital (the rate of interest on its bonds), leading to excessive > discounting of license revenues. > > In order to promote more competition in the auctions, and > also to increase the present value of license payments, TAP urges > the FCC to consider a bidding system that combines cash payments > with payments that are contingent upon future PCS revenues, such > as a royalty on future PCS revenues. We believe that over the > long run, the government (the taxpayers) will earn more from > royalties on a mature PCS market, than it will earn from up front > cash payments for licenses. > > --------------------------------------------------------------- > Taxpayer Assets Project, P.O. Box 19367, Washington, DC 20036 > v. 202/387-8030; f. 202/234-5176; internet: tap at essential.org > --------------------------------------------------------------- > Subscriptions to tap-info are available by sending an email > message to listserver at essential.org with the folowing message: > subscribe tap-info your name > --------------------------------------------------------------- ;; __________________________________________________________________________ ;; Stig at netcom.com netcom.com:/pub/stig/00-PGP-KEY ;; It's hard to be cutting-edge at your own pace... 32 DF B9 19 AE 28 D1 7A ;; Bullet-proof code cannot stand up to teflon bugs. A3 9D 0B 1A 33 13 4D 7F From bart at netcom.com Thu Sep 16 11:54:43 1993 From: bart at netcom.com (Harry Bartholomew) Date: Thu, 16 Sep 93 11:54:43 PDT Subject: Government agenda on cryptography Message-ID: <9309161853.AA13914@netcom5.netcom.com> From the National Information Infrastructure Agenda for Action: Action: Review privacy concerns of the NII. The IITF has developed a work plan to investigate what policies are necessary to ensure individual privacy, while recognizing the legitimate societal needs for information, including those of law enforcement. The IITF has also developed a work plan to investigate how the government will ensure that the infrastructure's operations are compatible with the legitimate privacy interests of its users. Action: Review of encryption technology. In April, the President announced a thorough review of Federal policies on encryption technology. In addition, Federal agencies are working with industry to develop new technologies that protect the privacy of citizens, while enabling law enforcement agencies to continue to use court-authorized wiretaps to fight terrorism, drug rings, organized crime, and corruption. Federal agencies are working with industry to develop encryption hardware and software that can be used for this application. MUST reading I suggest. Sources for FTP: The package is available in ASCII format through both FTP and Gopher. The name of the file is "niiagenda.asc". Access information and directories are described below. FTP: Address: ftp.ntia.doc.gov Login as "anonymous". Use your email address or guest as the password. Change directory to "pub". Address: enh.nist.gov Login as "anonymous" using "guest" as the password. Address: isdres.er.usgs.gov Login as "anonymous". Use your email address or "guest" as the password. Change directory to npr. The package also may be present in a self extracting compressed file named "niiagend.exe". Remember to issue the binary command before "getting" the compressed file. I also have it here on Netcom in /u4/bart/public with read permissions set I think so it can be copied. From gnu Thu Sep 16 11:59:20 1993 From: gnu (John Gilmore) Date: Thu, 16 Sep 93 11:59:20 PDT Subject: Whit Diffie on satellite TV, Sept 28th Message-ID: <9309161858.AA20873@toad.com> ---------------------------------------------------------------------------- The Florida SunFlash Sunergy #7 Satellite Broadcast September 28, 1993 SunFLASH Vol 57 #14 September 1993 ---------------------------------------------------------------------------- 57.14 Sunergy #7 Satellite Broadcast September 28, 1993 Live Satellite Broadcast. Theme is "Cyberjockying in the 21st Century". This next Sunergy live broadcast will focus on the issues and technologies surrounding the worldwide movement of information. It will take a look at the internet, information suppliers, information retrievers and the other related resources. Discussions will also include regulation and security on the internet. ---------------------------------------------------------------------------- Note: the Ft. Lauderdale office will be hosting this event in our office at 500 Cypress Creek Rd West, Ft. Lauderdale 305 776 7770 12 noon to 1:45 EDT. -johnj ---------------------------------------------------------------------------- Contact: sunergy at sun.com phone: +1 415/336-5847 If you have satellite receive capabilities and wish to downlink this program please send email to sunergy at sun.com. We will add your name to our alias and send the appropriate satellite and transponder information when it becomes available. ##################################### Sunergy #7 Satellite Broadcast September 28, 1993 9:00 - 10:45 am PDT Cyberjockying in the 21st Century ###################################### How will supernetworks transport you to the far reaches of the data galaxy? What is the current status of the internet and other "information highways"? What can these "highways" do for you today? This next Sunergy live broadcast will focus on the issues and technologies surrounding the worldwide movement of information. It will take a look at the internet, information suppliers, information retrievers and the other related resources. Discussions will also include regulation and security on the internet. Demonstrations will include: - a live teleconference over workstations between 3-4 geographies - sending white papers over the vertical blanking interval of a satellite signal to various sites - the use of WAIS to access information - others TBA Guests include: John Gage - Director of the Science Office, SMCC Whitfield Diffie - Distinguished Engineer, Security - SMCC Carl Malamud - President, Internet Multicasting Service Brewster Kahle - President, WAIS Inc If you wish to downlink this broadcast, please send email to sunergy at Sun.COM or phone the Sunergy office at +1 415/336-5847 Program is available on satellites over Europe (west, central and east), Canada, Latin America and the US. _______________________________________________________________________ Biographies: John Gage Director, Science Office Sun Microsystems Computer Corporation John Gage works for Bill Joy, the Chief Technical Officer of Sun, and is responsible for Sun's relationships with the world scientific and public policy communities, international scientific institutions and groups developing new forms of scientific research involving computing. He is on scientific and advisory panels of the United States National Science Foundation, the US Congress Office of Technology Assessment, the European institute of Technology and the United States National Academy of Sciences. He has recently been appointed to the US National Research Council Mathematical Sciences Education Board. He is a member of ACM, IEEE, SIAM, AMS, AAAS, and SMPTE. He attended the Harvard Business School and the Harvard Graduate School of Public Policy. He did doctoral work in economics and mathematics at the university of Berkeley at the same time as Bill Joy. Gage subsequently left Berkeley with Joy to start Sun in 1982. Gage is on the Board of Directors of Unicode, an industry consortium of IBM, Microsoft, Apple, Novell, Sun, GO Corporation, and others to provide multilingual capability in all world scripts for all documents and applications. _______________________________________________________________________ Carl Malamud President Internet Multicasting Service Carl Malamud is the author of seven professional reference books including STACKS (Prentice Hall), Analyzing Sun Networks (Van Nostrand Reinhold), and Exploring the Internet: A Technical Travelogue (Prentice Hall). Currently, Carl is producing the Internet Town Hall and Internet Talk Radio series for the Internet Multicasting Service and conducts research on integration of telephone systems into the Internet. ________________________________________________________________________ Whitfield Diffie Distinguished Engineer Sun Microsystems Whitfield Diffie is best known for his 1975 discovery of the concept of public key cryptography, for which he was recently awarded a Doctorate in Technical Sciences (Honoris Causa) by the Swiss Federal Institute of Technology. For a dozen years prior to assuming his present position in 1991, Diffie was Manager of Secure Systems Research for Northern Telecom, functioning as the center of expertise in advanced security technologies throughout the corporation. Among his achievements in this position was the design of the key management architecture for NT's recently released PDSO security system for X.25 packet networks. Diffie received a Bachelor of Science degree in mathematics from the Massachusetts Institute of Technology in 1965. Prior to becoming interested in cryptography, he worked on the development of the Mathlab symbolic manipulation system --- sponsored jointly at Mitre and the MIT Artificial Intelligence Laboratory --- and later on proof of correctness of computer programs at Stanford University. He is the recipient of the IEEE Information Theory Society Best Paper Award for 1979 and the IEEE Donald E. Fink award for 1981. _________________________________________________________________________ Brewster Kahle President Wide Area Information Servers, Inc. Inventor and architect of the WAIS electronic publishing system, Brewster Kahle has lead the multi-company effort to build a practical system for end-users to find and retrieve information from servers worldwide. Before this work, he helped design and build parallel supercomputers at Thinking Machines Corporation. Brewster was schooled at MIT in Computer Science and Artificial Intelligence. ********************************************************************** For information about SunFlash send mail to info-sunflash at Sun.COM. Subscription requests should be sent to sunflash-request at Sun.COM. Archives are on draco.nova.edu, ftp.uu.net, sunsite.unc.edu, src.doc.ic.ac.uk and ftp.adelaide.edu.au All prices, availability, and other statements relating to Sun or third party products are valid in the U.S. only. Please contact your local Sales Representative for details of pricing and product availability in your region. Descriptions of, or references to products or publications within SunFlash does not imply an endorsement of that product or publication by Sun Microsystems. Send brief articles (e.g. third party announcements) and include contact information (non-800#, fax #, email, etc) to: John McLaughlin, SunFlash editor, flash at Sun.COM. +1 305 351 4909 From strong+ at CMU.EDU Thu Sep 16 12:04:43 1993 From: strong+ at CMU.EDU (Thomas W. Strong, Jr.) Date: Thu, 16 Sep 93 12:04:43 PDT Subject: Random Numbers In-Reply-To: <18957.9309161647@otter.TIS.COM> Message-ID: mjr at TIS.COM writes: > One possibility is to treat part of the random seed as > if it was your secret RSA key. Systems like PEM store the RSA > key encrypted on disk someplace - you could also store an > encrypted random seed which you decrypt when you retrieve the > secret key, use to bootstrap your PRNG, and then replace with > some output from the PRNG when you're done. That way, the seed > is (by definition) hidden, and an attacker is going to have > much more trouble attacking your PRNG by searching your random > seed space. You don't want to do that... that would amount to using one seed (probably when you created your key) and then generating a key from that. Since the relationship between a random seed and the IDEA key is known, one can be reproduced from the other. (to go from key to seed would take considerably longer, but it's doable) Since you are storing what effectively amounts to the random number generated from the seed in place of the seed, all an adversary has to do is get one of your IDEA keys from a message that he can read. Once he has that, he gets the seed used, and then just works it forward from there. Instead of having 2^128 possible keys, you've just let him narrow it down to a couple hundred or so. There's a reaason that you have to give it a new seed rather often. ----------------------------------------------------------------- Tom Strong N3NBB ts49+ at andrew.cmu.edu From pcw at access.digex.net Thu Sep 16 12:59:21 1993 From: pcw at access.digex.net (Peter Wayner) Date: Thu, 16 Sep 93 12:59:21 PDT Subject: CSSPAB meeting of September 1 and 2. Message-ID: <199309161955.AA19000@access.digex.net> I'm sorry that this is so late, but I got backed up doing too many other things. Feel free to go to the anonymous mailers and post sarcastic remarks, straight-forward discussions or other comments. --Peter ----------------------- Here's my report from what I saw attending the Computer System Security and Privacy Advisory Board meeting on September 1st and 2nd in Baltimore, MD. This group is a Congressionally chartered organization with the responsibity to render advice on questions of cryptography and computer security. It's members are made up of people from government and industry. One member must be a representative from the National Security Agency. The meeting this time was at the Hyatt in Baltimore and there were several differences between this meeting and the last two which were held at the National Institute of Standards and Technology in Gaithersburg, MD. First, there were coffee, juice and doughnuts available in the morning. Second, I did not notice any recording devices or stenographers keeping track of what was said. Previous meetings at NIST had been both video and audio taped. There were two major parts to the meeting: 1) listening presentations from a variety of different people and 2) debating resolutions about the government's proposed Key Escrow standard. I attended most of the presentations, but I skipped most of the debate about the resolutions. The remarks that follow are basically my personal recollections. The most interesting bit of information I learned on the first day concerned a software version of the Key Escrow system. The strongest and least controversial arguments against deploying all revolve around the fact that the proposed chips we've seen so far are all based in hardware. Adding an additional chip to computers and phones costs money ($25-100), adds weight (bad for portable phones) and increases power consumption. None of these are desirable attributes. More importantly, a hardware standard not very flexible and the nation's entire computer system could be compromised for 6 months to a year if the key escrow agents went bad. That's my estimate for the amount of time it would take us to replace all the chips. NIST, in recognition of these facts, has announced a "Cooperative Research and Development" plan (called CRADA-- the "A" might stand for agreement). This would allow members of industry and academia to join together with NIST and the NSA to try and discover a good, software based, Key Escrow scheme. Ray Bonner, deputy director of NIST, discussed the plan and said that he wasn't sure that it would lead to anything but that it was worth a try. He also said that we should keep a copy of the Federal Register containing the announcement (Vol 58, #162, Tues, Aug 24 1993, pg 44662) because it could be the only CRADA ever involving the NSA. It could become a collectors item. If anyone is interested in getting involved with this project, they should call Dennis Branstad at NIST (301-975-2913). To me, it seems like it is easy to accomplish a key escrow plan in software. It just depends how many features you want to add. A simple method is to encrypt the session key with the government's public key(s)and append this in a LEAF. If the cops wanted to listen in, they could decrypt the LEAF using the private key(s that would be kept by the escrow agency. Naturally, this could be compromised if the keys got out. More sophisticated methods could involve a three-way Diffie-Hellman key exchange at the start of each conversation on the phone system. Or the government might want to explore Silvio Micali's work at MIT. It would also be possible to use Gus Simmon's subliminal channels to implement a signature/escrow scheme. The LEAF would be a DSS signature and the session key would be held in subliminal channel. The other half of the conversation would be able to verify that the LEAF was there and the conversation was authentic, and the LE people could get the key if they so desired. (This could be easily broken. I can't remember the details of Simmons's solution at this moment.) There are several other answers that come to mind. The traditional objections to software implementations of the Key Escrow plan are (1) easy tamperability and (2) publication of NSA secrets. While software may be easier to change, people have also proposed very simple ways to circumvent Clipper. If both halves of the conversation coordinate themselves beforehand, any amount of duplicity is possible whether or not a hardware chip is part of the standard. It is possible to super-encrypt the entire data stream in software and the LEAF would be foiled. It doesn't seem as if there is that much difference on a relative scale. The critical problem to developing a software key escrow system is finding a way to prevent a modified piece of software from working with an unmodified piece of software. This would stop people from establishing links without prior arrangements for extra security. I believe that this may be possible to do this using two different types of LEAFS and shifting session keys every so often. Of course, sending out a software version of an algorithm will leak information from the NSA-- something that really worries them. But the CRADA says that the NSA will work on the software Key escrow plan on a complete unclassifed basis. People on the CSSAB made light of the strangeness of all of this. Other Presentations Most of the rest of the meeting was devoted to people not saying anything on purpose. The plan to give the DSS to the RSA to resolve patent differences and give the nation a standard has not generated any new facts. Mike Rubin, the lawyer in charge, was not at the meeting and he is apparently processing the public comments as I write. Some summarized the comments as uniformly stating, "Free is good, paying is bad." A group of computer scientists from NIST came to discuss their plan for the Federal Criteria for secure systems and the new "Common Criteria" that may emerge. This is an updated version of the old Orange Book classification scheme of C2 and B1 and stuff like that. The scientists said the draft is being finished but it isn't ready for release. But now, they're working on "Something Better." This is a new plan to standardize the grading of secure systems with other countries and evolve a "Common Criteria." In general, the board groused about the fact that the public and industry have never been invited to give comments during the process. The summary of this talk is: "We might be able to tell you something someday." Geoff Greiveldinger took up a whole hour in the afternoon to tell us that it would be impolite for him to discuss the key escrow system with the CSSAB before talking about it with Congress. He is the lawyer from the Justice department responsible for setting up the system. Some members of the board mentioned that the board was chartered by Congress and so he could speak freely, but others refused to be so impolite as to question his polite excuse. He filled the hour with more descriptions with all of the restrictions that they place on wiretaps at the Justice department. Once again, I found myself wondering why they are going through so much trouble over something that just seems to cause them grief. The taps cost money. They divert manpower. Etc. Yet, the FBI and the rest of the community is willing to go through a full court press on this topic. The taps are essential in crime encapsulated in conversations (i.e. influence peddling, bribery). Perhaps those of us outside of government (sadly only 4 out 5 people) should quit worrying about this topic. The crimes we're likely to commit all involve action: grand theft auto, drunk driving, pickpocketting, murder, rape, illegal parking etc. No one really cares what we say. It's just if we _do_ something and violate a property right. Usually, members of the government are the ones who could break the law just by openning their mouth. Some people from the Social Security Agency came to tell the board about their internal security procedures that they use to track down people inside the agency generating information for outsiders like private detectives. They routinely run sting operations where they call up information brokers and ask them to get a Social Security file for an individual. Then they watch for accesses to that record and flag the miscreant. One of the old hobbies at the agency was looking up the records of stars. (When your job is sitting around watching people get old, you've got to have something to do.) The agency keeps a watch list of the celebrity's real name and SS number. Special programs now watch for inquiries into these records. A nice guy from ARPA (Steve Squires) came and showed us complicated slides representing the various factions at ARPA who are going about developing the National Information Infrastructure. It seemed to be more a polite introduction than a fact-based briefing about what might come out of Al Gore's dreams. Dorothy Denning came to say that there was no final report from the outside team performing an outside review of the Clipper algorithm. In general, she said that the comments have been favorable to their work. Several members of the board questioned the independence of the review given that it was done at the NSA using NSA's computers and NSA's programmers. They also wondered about the depth of the review because it was apparent that Denning leaned heavily on the NSA's analysis. The EFF and Clipper The final presentation came from Jerry Berman from the EFF. In reality, he was representing the "Digital Privacy and Security Working Group" which is a group of industry and political groups that have joined together to say something about Clipper. This was the last presentation of the meeting and it became sort of a climax because people kept saying, "We'll see what the EFF has to say." Their statement was simple. The group feels that it can accept Clipper if any participation in the key escrow program is completely volutary. They proposed to test the administration's committment to volunteerism by noting whether they relaxed export requirements. To me, the statement was little more than a political gambit. All of the companies involved in the DPSWG really, really, really want export restrictions eased. So they offered their support for Clipper as a quid pro quo. Let us export anything (not just Clipper) and we'll support it. If you ask me, they shouldn't have been so bald about their horse trading, but then I'm not a regular in Washington log rolling. It should be possible to make a statement about Clipper without involving the other issue, but maybe it's a smart deal. The main members of the group are companies and the group had to standardize its message on what its members want. The Debate The rest of the meeting was centered around the debate on the board's resolution on Clipper. I missed most of this because it really seemed very petty. Most of the board wanted to say that the Clipper chip was a pain in the neck that wasn't worth the trouble but they couldn't come up with the right words. Is it "expensive", "more expensive than software", "more expensive than other alternatives", etc. The fight seemed to break down between government employees and non-government employees. Those outside the government kept arguing for stronger language and those inside kept saying things like, "But expensive relative to what? We don't have any concrete cost estimates." In the end, they passed resolutions that recorded reservations and a call for "public" debate on the topic including a decision by Congress on the needs of key escrow. If you have any questions about this summary, feel free to contact me at pcw at access.digex.com. --Peter Wayner From ferguson at fiber.sprintlink.net Thu Sep 16 13:54:45 1993 From: ferguson at fiber.sprintlink.net (Paul Ferguson x2044) Date: Thu, 16 Sep 93 13:54:45 PDT Subject: CRADA Message-ID: <9309162151.AA18816@fiber.sprintlink.net> On Thu, 16 Sep 1993 15:55:22 -0400, Peter Wayner wrote - > NIST, in recognition of these facts, has announced a "Cooperative > Research and Development" plan (called CRADA-- the "A" might > stand for agreement). This would allow members of industry and > academia to join together with NIST and the NSA to try and discover > a good, software based, Key Escrow scheme. Ray Bonner, deputy director > of NIST, discussed the plan and said that he wasn't sure that it > would lead to anything but that it was worth a try. He also said > that we should keep a copy of the Federal Register containing the > announcement (Vol 58, #162, Tues, Aug 24 1993, pg 44662) because > it could be the only CRADA ever involving the NSA. It could become > a collectors item. Where could one find an ASCII copy of the pertinent portion of the Federal Register (specifically, Vol. 58, #162, Tues., Aug 24 1993, pg 44662) that includes this "CRADA"? If anyone manages to obtain a copy, please let us (me) know. _____________________________________________________________________________ Paul Ferguson Mindbank Consulting Group fergp at sytex.com Fairfax, Virginia USA ferguson at icp.net From norm at netcom.com Thu Sep 16 16:34:47 1993 From: norm at netcom.com (Norman Hardy) Date: Thu, 16 Sep 93 16:34:47 PDT Subject: Abstract: of The Digital Silk Road Message-ID: <9309162332.AA03396@netcom3.netcom.com> Existing and proposed mechanisms for digital money all require large overhead to transfer money between parties. This overhead makes them unsuitable for extremely low cost activities such as delivering and routing packets. We propose a money system with extremely low transaction cost built into the communication protocols. The money introduced by this system is much more like coins than like bank accounts; it supports only small transactions, requires limited trust among the participants, and requires no central bank. With this as a foundation, we then describe elements of an open system that fully supports network resource management, routing, interconnection with the Internet, and other information services, across trust boundaries with competing providers for all services. This supports a style of informal information commerce. To appear in "Agoric Systems: Market Based Computation", edited by Wm. Tulloh, Mark S. Miller and Don Lavoie. A draft of this paper is available thru anonymous ftp at netcom.com:pub/joule/DSR1.ps.gz, DSR1.rtf and DSR1.txt. The file format, .rtf, (Rich Text Fotmat) can be read by many different word processors including those from Microsoft, MacWrite II, and some Unix systems. I will produce other formats with a bit of pressure. From frissell at panix.com Thu Sep 16 17:59:23 1993 From: frissell at panix.com (Duncan Frissell) Date: Thu, 16 Sep 93 17:59:23 PDT Subject: Fortune Mag Article Message-ID: <199309170055.AA17939@panix.com> Foutune Magazine has a special issue (dated Autumn 1993) called Making High Tech Work for You on the stands now with much of interest to our activities. Look particularly at the last non-ad page (162) "Your Wallet in the Year 2000" filled with digital signatures, public key crypto, and digital cash. Likewise gambling, remailers, etc. Sample quote: "The global cash economy is growing so fast that President-elect Clinton says she's worried about the government's ability to regulate and tax commerce." There's also an article on the movement of commerce and enterprise networks to Internet. Be sure to catch the hot hot tub photo of JG and the profile of Cygnus Support on page 57. Duncan Frissell What is the most toxic hazardous waste dump on earth? Highgate cemetary in north London. Karl Marx's brain (the earth's most hazardous substance) is buried there (together with the rest of him>. --- WinQwk 2.0b#0 From norm at netcom.com Thu Sep 16 18:19:24 1993 From: norm at netcom.com (Norman Hardy) Date: Thu, 16 Sep 93 18:19:24 PDT Subject: How to use cipher programs without trusting them. Message-ID: <9309170117.AA13564@netcom2.netcom.com> The shortest summary of all this is that cipher program should be deterministic and written to a public spec so that they may be checked short of the hazardous task of reading code. This may be quixotic but that has never stopped me. I propose here a way to choose secret random numbers and random primes without having to trust a single program exclusively. Suppose that you want to choose a random n bit number. You type text while trying to make it random in some subjective sense. The text accepts only space and letters and ignores all else. The text is interpreted as a base 53 number and reduced modulo 2^n. Note that 53 and 2^n are relatively prime. Experiments have shown that this type of "typewriter random" produces about one or two bits of information per character depending on the typist. This assumes an unspecified form of information compression which I do not recall. It did, however, look for patterns that were specific to people trying to type random characters at a keyboard. One caution: if choosing random numbers this way becomes routine one falls into habits that makes the numbers no longer independent. Different programs can easily be written according to such a standard and their results compared. The skeptic runs two or three programs and compares the output. After a few trials it may be reasonable to trust one of the programs. A natural adjunct of such a program is a prime tester that seeks primes in some arithmetic sequence. The sequence is chosen according to published rules from keyboard selected random numbers. I hear that PGP pads messages with random information in order to thwart known plaintext attacks. This is wise but the paranoid wonders how the random information is selected. The padding prevents output from two programs from being compared for compliance. Some will argue that if the cipher program were malicious it could stash your secrets somewhere on your disk that was destined for export for reasons unrelated to ciphering. The SoftPC story below indicates that there are problems even when the cipher program is programmed to spec. I know of operating systems where cipher programs may be installed so as not to have the authority to stash your secrets away. I don't know whether such operating systems will ever see commercial use. There are several problems with keyboard timing. The first that I saw mentioned arises when running such a program on SoftPC which is a clever program to execute programs designed for IBM PCs on the Macintosh. The clock appears not to run (I think the story is) and while the random numbers look impressive they depend only on the number of keystrokes and nothing else! There is much more technology such as SoftPC coming down the pike. From stig at key.amdahl.com Thu Sep 16 20:10:51 1993 From: stig at key.amdahl.com (Jonathan Stigelman) Date: Thu, 16 Sep 93 20:10:51 PDT Subject: Trust fund to support free software. Backed, in part, by PGP. Message-ID: <9309170308.AA01240@stigma.key.amdahl.com> Path: key!amdahl!pacbell.com!decwrl!decwrl!concert!samba.oit.unc.edu!sunSITE!mdw From: callis at noc.usfca.edu (Kim C. Callis) Newsgroups: comp.os.linux.announce Subject: Re: The Linus Fund (EVERYONE READ THIS THREAD) Followup-To: comp.os.linux.misc Date: 13 Sep 1993 18:09:55 GMT Organization: Linux. It's not just for breakfast anymore. Lines: 76 Approved: linux-announce at tc.cornell.edu (Matt Welsh) Message-ID: <272d1j$2i5 at samba.oit.unc.edu> References: <270rt7$jrv at vixen.cso.uiuc.edu> <270sih$do at nigel.msen.com> NNTP-Posting-Host: calypso.oit.unc.edu Keywords: Linux fund money donations Originator: mdw at sunSITE [Forwarded from c.o.l.d at request of Jeff Kopmanis. --mdw] In article <26ung9$n2m at noc.usfca.edu> callis at noc.usfca.edu (Kim C. Callis) writes: >> >> Fellow Linux Users, >> >> I have read the messages regarding donations to Linus in order for hime >> to continue the development of Linux. I will even admit that I am >> surprised that people are genuinely interested in rewarding the creator >> of Linux for his contributions. >> This has moved me in ways I can understand, so I am going to do the >> following. On Monday, September 13, I will open and deposit $100.00 in a >> trust account. Anyone interested in contributing to the Linus Dream >> Machine Fund can send a donation which will be deposited in the account. >> During this time, we will find out from Linus what his dream machine >> consists of and figure out the ammount of money needed to achieve this >> machine. At the time when we receive the amount, a machine will be >> configured to meet Linus' specifications and sent off to him. >> >> Of course the question will be how can you confirm that I am not taking >> this money in Linus name and going to have a big party with it. Well, I >> am hoping that the goodwill of the net will out-weigh any pessimistic >> views but if not, I have come up with a plan. >> >> All monies received will be amounts will be publicly posted. When money >> is received, I will send the person a receipt which will be signed with >> a public key signature of mine (using PGP 2.0). Each week, I will post >> to the net a total of all monies received, and a person can check to see >> if his or her name is on the list. The account will be set up as a trust >> account with myself as administrator limited to withdrawing of funds to >> be distributed to one Linus Torvald (Sorry, I have the spelling of the >> name somewhere...) in Finland. So, that will limit the money >> distrubution. Also to all interested parties in the united States, I >> will send via e-mail the (800) automated account inquiry number for BoA, >> as well as account information and any needed access number need to find >> the status of the account. >> >> As mentioned above, when an amount is reached which will allow Linus to >> purchase his dream machine (Please bear in mind Linus, that you need to >> monitor the posting and vary your list according to funds available), >> BoA will cut a certified funds check to Linus, and only to Linus. >> >> Considering what we have received from Linus, I think that this would be >> a noble gesture on the part of all of us who without Linus would have >> been doomed to buying some version of Un*x and paying a stiff prices for >> all the add-ons which the Linux provides us for free. Furthermore, this >> would serve to show the goodwill of a community based not on race, >> color, or creed, but upon content of character. Let's face it, few of us >> ever get to meet people who post via netnews or write programs which we >> tend to use day to day. Yet we communicate with each other as if we have >> known each other for long periods of time. We instruct each other, we >> learn from each other, we argue (flame) each other, and we grow from all >> of this. I believe that the Internet serves as a moderator of >> internation goodwill. Let's see if we can take it one step forward, and >> see if the goodwill extends all the way to rewarding someone for a great >> contibution to our community. >> >> If anyone has any suggestions, rebuttals, or general comments on how to >> make this idea of mine work, please feel free to e-mail me or post for >> general discussion. >> >> -- >> ******************************************************************* >> * Kim C. Callis * >> * Univ. of San Francisco, San Francisco, CA * >> * EMAIL: callis at usfca.edu or callis at dons.ac.usfca.edu * >> ******************************************************************* >> DISCLAIMER: As long as nothing I say attempts to represent the >> views of the Univ. of San Francisco, they could care less what I >> have to say. Meaning that anything said, like it or not, is strictly >> my own personal opinion and views. -- Send submissions for comp.os.linux.announce to: linux-announce at tc.cornell.edu From ld231782 at longs.lance.colostate.edu Thu Sep 16 21:05:52 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 16 Sep 93 21:05:52 PDT Subject: KEY ESCROW PROCEDURES Message-ID: <9309170404.AA28623@longs.lance.colostate.edu> (Disclaimer: in no way should any of my own writings on this subject be construed as supportive of key escrow.) Key escrow procedures as revealed in Congress, received via M. Godwin and J. Berman of EFF. First is J. Berman analysis followed by text itself, covering the various types of interception under 3 laws: omnibus Crime Control & Safe Streets (1968), Foreign Intelligence Surveillance Act (FISA), and finally under state statutes. (Perhaps someone can identify the differences in the various procedures buried in the bureacratese, but they are all largely verbatim copies.) Notes: 1) escrow agencies (finally) IDENTIFIED: NIST and `non-law enforcement component of the Dept. of Treasury' as `tentative' choices to be finalized in `the next few days'. 2) LE agents have to get `black boxes' (a PC) to extract/read the LEAF (ID field) of the communications. Each box has an ID. 3) according to Berman, the LE agency *faxes* (?) the device ID number to the agents along with certifications on interception authority, ID of the black box, and the length of authorization. 4) agencies transmit the keys to the black box in a secure, encrypted channel. `key components will only work with that particular black box, and only for the state duration of the intercept'. 5) the most ominous sounding paragraph is the following, which specifically *revokes* any rights or guarantees to privacy or `due process' based on the technology & procedures: >These procedures do not create, and are not intended to create, >any substantive rights for individuals intercepted through >electronic surveillance, and noncompliance with these procedures >shall not provide the basis for any motion to suppress or other >objection to the introduction of electronic surveillance evidence >lawfully acquired. that is, this disclaimer seems to be an attempt to evade the `exclusionary rule' and `poisoned tree' legal doctine (the practice of courts in excluding evidence illegally obtained and other evidence therefrom) by legislative fiat. Major criticisms *not* addressed by this protocol: - why isn't the link *to* the encryption agencies, wherein the Clipper phone ID is sent, secure & encrypted itself? If police `fax' these ID's, what is to prevent them from trading them and misrepresenting them on the warrants seen by the agencies? - Berman writes that the LE agents tell the key escrow agencies how long they are requesting the warrant. Now, this is strange. Does the escrow agency ever refuse a warrant if the time period is not legal under the applicable law? and is any police agent going to request *less* than the maximum period allowed by law? - we have claim that records are kept on many sides, such as the requesting side and the granting sides. are records kept of *failed* requests? or do all `illegally-phrased requests' rejected by the key escrow agencies simply disappear? - In fact, do the key escrow agencies *ever* reject a request? this plan below says nothing of the grounds under which requests may be denied. What's the point? - NO indication of the critically important key generation protocol. Are we to take Denning's American Scientist article as authoritative? if so, forget it. - If there is no legal penalty in court for violating the protocols, as the disclaimer seems to attempt to evoke, what's the point? at the *bare minimum* there is required exclusion of tainted taps, and other penalties for infringing parties are wholly in order. Berman also reveals very fascinating glimpses: `The Administration rejects the argument that voice encryption is readily available.' The AT&T product `posed a unique threat in terms of voice quality, affordability, portability and strength of the encryption' -- strong confirmation of the theories that Clipper was rushed out, prematurely, to face it. They are clearly strongly concerned about new Motorola products, the `next voice encryption product in the pipeline'. (NSA is in *big* trouble when there is more than one pipeline to choke, as is rapidly becoming the case). Interesting insights into administration psyche with Berman's quotes of government officials: 1) `Clipper market share' will cause momentum to the standard (hee, hee) 2) `careless bad guys' will use Clipper (yeah, right) 3) why private key agencies rejected, but also the NSA: the former, concerns on longevity and security related to profit, the latter, `for credibility reasons' (snicker) 4) `key criterion' for escrow agents: `experience in and an infrastructure for handling sensitive information' 5) `briefers admitted it is not really a key escrow system'. (!) escrows' obligation `will be to the government' with `no duties or responsibilities to users' (?!) > Both John Podesta and Mark Richard stated that there is no plan on >or over the horizon to outlaw non-escrowed encryption. 6) International aspects `thorniest to deal with'. Clipper exportable with a license (surprise). `Other nations would not participate in the escrow system.' Hm, I doubt it. Not if the NSA can help it. Cypherpunks: one can sense the undertone of confusion, hopelessness and despair in these accounts. Let's keep up the heat until the omelette has completely vaporized. ------- Forwarded Message Date: Thu, 16 Sep 1993 17:31:54 -0400 From: jberman (Jerry Berman) Subject: CLIPPER ESCROW AGENTS CHOSEN In the next several days, the Administration will announce it has chosen at least one escrow agency and has developed procedures for accessing escrow keys pursuant to warrant. Here is an account of an Administration hill staff briefing on September 16, 1993 and the draft procedures for law enforcement, foreign intelligence, and state and local law enforcement wiretapping. We are looking for comments and analysis. Please circulate widely. Jerry Berman, EFF. ================== RE: Clipper Escrow Agent Briefing for Congressional Staff Yesterday, September 15, 1993, a briefing was held for congressional staff regarding the status of the Clipper project. The lead briefers for the Administration were Mark Richard, Deputy Assistant Attorney General, Criminal Division, DOJ; Jim Kallstrom, FBI; Geoff Greiveldinger, Special Counsel, Narcotic and Dangerous Drug Section, DOJ; and John Podesta. Also present were Mary Lawton, Counsel for Intelligence Policy and Review, DOJ; Mike Waguespack, NSC; and Dwight Price, National District Attorneys Association. The Administration has tentatively settled on NIST and a yet to be determined non-law enforcement component of the Department of the Treasury as the "escrow agents." The Administration will finalize the choices in the next few days, according to John Podesta. The Attorney General will make an announcement, in what form has not been determined, but it will probably not be a Federal Register notice. The Attorney General will announce that she has adopted, and the escrows have agreed to follow, the attached procedures. The system will work as follows: (1) A black box (actually a PC) in the possession of a law enforcement agency will be able to read the Law Enforcement Access Field in a Clipper encrypted data stream and extract the identification number specific to the Clipper chip being used by the intercept target. Cost of the black box yet undetermined. How many will be purchased by law enforcement yet undetermined, although if use of Clipper becomes common, the black boxes will be in great demand, by federal as well as state and local agencies. They will be available only to law enforcement, with yet to be specified controls on their sale. Each black box will have a unique identifier. (2) The law enforcement agency will fax the device ID number to each of the escrow agents, along with a certification that the agency has authority to conduct the intercept, the ID number of the intercepting agency's black box, and the time period for which the intercept is authorized (in the case of Title III's, up to thirty days, with extensions). (3) The escrow agents will transmit the key components by encrypted link directly into the black box of the requesting law enforcement agency. The key components will only work with that particular black box, and will only work for the stated duration of the intercept. If the intercept is extended, the law enforcement agency will have to send a new request to the escrow agents to extend the life of the key components. The escrow agents will maintain logs of the requests. Greiveldinger stressed that the system is "replete with recordation of the transactions that will occur." The escrow agents also have a responsibility for maintaining the integrity of the chip manufacturing process. In opening remarks describing the need for the Clipper escrow system, Kallstrom had stressed that the AT&T product posed a unique threat in terms of voice quality, affordability, portability and strength of the encryption. The Administration rejects the argument that voice encryption is readily available. The AT&T product, which isn't available yet, is unique, and competing products, the Administration argues, are yet further in the future. The next voice encryption product in the pipeline is Motorola's, and Motorola has expressed interest in using Clipper in its product. The Administration argued that the need for compatibility would drive a significant share of the market to Clipper or Capstone-based products. Escrow coverage will not be complete, but the bad guys are careless and are expected to use Clipper products. The key criterion used in selecting the escrow agents was whether the agency had experience in and an infrastructure for handling sensitive information. The Administration did not want to use a law enforcement or national security component, for credibility reasons. It did not want to use private entities based on concerns about longevity and not wanting security to be governed by the need to make a profit. The briefers admitted that the proposed system is not really an escrow. The agencies holding the key components will not have any duties or responsibilities to the Clipper users. The escrows' obligation will be to the government, and they will be liable to Clipper users only under the Bivens doctrine, where any failure must be shown to be wilful. Both John Podesta and Mark Richard stated that there is no plan on or over the horizon to outlaw non-escrowed encryption. John and Mark said that the international aspects of the escrow/encryption issue are the thorniest to deal with, and there are no answers yet. Clipper products would be exportable with a license, although other countries may try to keep them out. (Nobody asked questions about changes in the rules governing export of non-Clipper encryption.) Other nations would not participate in the escrow system, nor, presumably, would they be allowed to buy the black boxes. E.G., if the British intercepted an IRA communication that appeared to be encrypted with Clipper, and came to the FBI for help, the anticipated escrow system would not allow the FBI to get the key from the escrow agents. ================== PROPOSED PROCEDURES AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUNCTION WITH INTERCEPTS PURSUANT TO TITLE III The following are the procedures for the release of escrowed key components in conjunction with lawfully authorized interception of communications encrypted with a key-escrow encryption method. These procedures cover all electronic surveillance conducted pursuant to Title III of the omnibus Crime Control and Safe Streets Act of 1968, as amended (Title III), Title 18, United States Code, Section 2510 et seq. 1) In each case there shall be a legal authorization for the interception of wire and/or electronic communications. 2) All electronic surveillance court orders under Title III shall contain provisions authorizing after-the-fact minimization, pursuant to 18 U.S.C. 2518(5), permitting the interception and retention of coded communications, including encrypted communications. 3) In the event that federal law enforcement agents discover during the course of any lawfully authorized interception that communications encrypted with a key escrow encryption method are being utilized, they may obtain a certification from the investigative agency conducting the investigation, or the Attorney General of the United States or designee thereof. Such certification shall (a) identify the law enforcement agency or other authority conducting the interception and the person providing the certification; (b) certify that necessary legal authorization has been obtained to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorized; (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key escrow encryption chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the law enforcement agency or other authority for decryption of the intercepted communications. 4) The agency conducting the interception shall submit this certification to each of the designated key component escrow agents. If the certification has been provided by an investigative agency, as soon thereafter as practicable, an attorney associated with the United States Attorney's Office supervising the investigation shall provide each of the key component escrow agents with written confirmation of the certification. 5) Upon receiving the certification from the requesting investigative agency, each key component escrow agent shall release the necessary key component to the requesting agency. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification of the requesting agency, as well as the subsequent confirmation of the United States Attorney's office. In addition, the requesting agency shall retain a copy of the certification and provide copies to the following: (a) the United States Attorney's office supervising the investigation, and (b) the Department of Justice, Office of Enforcement operations . 7) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the requesting agency to decrypt intercepted communications shall terminate, and the requesting agency may not retain the key components. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUNCTION WITH INTERCEPTS PURSUANT TO FISA The following are the procedures for the release of escrowed key components in conjunction with lawfully authorized interception of communications encrypted with a key-escrow encryption method. These procedures cover all electronic surveillance conducted pursuant to the Foreign Intelligence Surveillance Act (FISA), Pub. L. 9S-511, which appears at Title 50, U.S. Code, Section 1801 et seq. 1) In each case there shall be a legal authorization for the interception of wire and/or electronic communications. 2) In the event that federal authorities discover during the course of any lawfully authorized interception that communications encrypted with a key-escrow encryption method are being utilized, they may obtain a certification from an agency authorized to participate in the conduct of the interception, or from the Attorney General of the United States or designee thereof. Such certification shall (a) identify the agency participating in the conduct of the interception and the person providing the certification; (b) certify that necessary legal authorization has been obtained to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorized; (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key escrow encryption chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the agency participating in the conduct of the interception for decryption of the intercepted communications. 4) This certification shall be submitted to each of the designated key component escrow agents. If the certification has been provided by an agency authorized to participate in the conduct of the interception, as soon thereafter as practicable, an attorney associated with the Department of Justice, office of Intelligence Policy and Review, shall provide each of the key component escrow agents with written confirmation of the certification. 5) Upon receiving the certification, each key component escrow agent shall release the necessary key component to the agency participating in the conduct of the interception. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification, as well as the subsequent written confirmation of the Department of Justice, Office of Intelligence Policy and Review. 7) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the agency participating in the conduct of the interception to decrypt intercepted communications shall terminate, and such agency may not retain the key components. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUCTION WITH INTERCEPTS PURSUANT TO STATE STATUTES Key component escrow agents may only release escrowed key components to law enforcement or prosecutorial authorities for use in conjunction with lawfully authorized interception of communications encrypted with a key escrow encryption method. These procedures apply to the release of key components to State and local law enforcement or prosecutorial authorities for use in conjunction with interceptions conducted pursuant to relevant State statutes authorizing electronic surveillance, and Title III of the omnibus Crime Control and Safe Streets Act of 1968, as amended, Title 18, United States Code, Section 2510 et seq. 1) The State or local law enforcement or prosecutorial authority must be conducting an interception of wire and/or electronic communications pursuant to lawful authorization. 2) Requests for release of escrowed key components must be submitted to the key component escrow agents by the principal prosecuting attorney of the State, or of a political subdivision thereof, responsible for the lawfully authorized electronic surveillance. 3) The principal prosecuting attorney of such State or political subdivision of such State shall submit with the request for escrowed key components a certification that shall (a) identify the law enforcement agency or other authority conducting the interception and the prosecuting attorney responsible therefore; (b) certify that necessary legal authorization for interception has been obtained to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorized (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key escrow chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the law enforcement agency or other authority for decryption the intercepted communications. 4) Such certification must be submitted by the principal prosecuting attorney of that State or political subdivision to each of the designated key component escrow agents. 5) Upon receiving the certification from the principal prosecuting attorney of the State or political subdivision, each key component escrow agent shall release the necessary key component to the intercepting State or local law enforcement agency or other authority. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification of the principal prosecuting attorney of the State or political subdivision. In addition, such prosecuting attorney shall provide a copy of the certification to the Department of Justice. 7) The U.S. Department of Justice may, to assure conformance with these procedures, make inquiry of the certifying prosecuting attorney regarding, inter alia, the genuineness of the certification and confirmation of the existence of lawful authorization to conduct the relevant electronic surveillance. The inquiry of the U.S. Department of Justice will not involve intrusion into matters that must, under relevant statute, be kept from public disclosure. 8) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the intercepting law enforcement agency or other authority to decrypt intercepted communications shall terminate, and the intercepting law enforcement agency or other authority may not retain the key components. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. - ----------------------------------------------------------- ------- End of Forwarded Message From wcs at anchor.ho.att.com Thu Sep 16 21:44:52 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Thu, 16 Sep 93 21:44:52 PDT Subject: Random Numbers Message-ID: <9309162016.AA23078@anchor.ho.att.com> > mjr at TIS.COM writes: > > One possibility is to treat part of the random seed as > > if it was your secret RSA key. Systems like PEM store the RSA > > key encrypted on disk someplace - you could also store an > > encrypted random seed which you decrypt when you retrieve the > > secret key, use to bootstrap your PRNG, and then replace with > > some output from the PRNG when you're done. That way, the seed > > is (by definition) hidden, and an attacker is going to have > > much more trouble attacking your PRNG by searching your random > > seed space. > > You don't want to do that... that would amount to using one seed [...] I was under the impression that mjr's suggestion was to use the randseed the same way it's being used now, only to store it encrypted instead of clear. This has some advantages - stealing it is now much less useful. On the other hand, it means you need to use your secret key when encrypting files, as well as when decrypting or signing them, which increases the exposure of your secret key as well as being annoying. > Since the relationship between a random seed and the IDEA key is > known, one can be reproduced from the other. If the IDEA key is generated by a one-way function such as MD5, it's ostensibly 2**128 work to duplicate an MD-5 hash, and potentially 2**400-2**500 work to generate the input to the hash (which is essentially impossible, since the input:hash is N:1, not 1:1.) Of course, it's still easy to implement wrong, leading to lossage :-) But even something as simple-minded as sessionkey = MD5(randseed+constant) newrandseed = MD5(randseed+differentconstant) would be pretty secure (and the real thing also includes timestamp and MD5 of the message, further randomizing it; haven't looked at the randseed code.) # Bill Stewart wcs at anchor.ho.att.com +1-908-949-0705 Fax-4876 # AT&T Bell Labs, Room 4M-312, Crawfords Corner Rd, Holmdel, NJ 07733-3030 From rjc at gnu.ai.mit.edu Thu Sep 16 23:14:54 1993 From: rjc at gnu.ai.mit.edu (Ray) Date: Thu, 16 Sep 93 23:14:54 PDT Subject: Remail: errors In-Reply-To: <9309150646.AA29585@jobe.shell.portal.com> Message-ID: <9309170610.AA29796@geech.gnu.ai.mit.edu> HFinney at shell.portal.com () writes: > > -----BEGIN PGP SIGNED MESSAGE----- > > I have been out of town for the last week, so I missed some CP mail. > It looks like some good things are happening with remailers, though. > Kudos to Karl, Sameer, and the others for their work! > > I have received many messages to my remailer in the last week which > came from remail at tamsun.tamu.edu, which were PGP-encrypted apparently > in an effort to get my remailer to send them. > > They did not work, though, because there was no "Encrypted: PGP" header > to trigger the remailer's decryption. This can be arranged by > creating the message something like this: Opps, that was me. When I was debugging/testing my anonymous forwarding/anonymous list software I sent multiple messages before looking for the reply. (because the software randomly chooses a chain, and I wasn't sure which remailers introduce a delay) The problem was that Encrypted: PGP was only being added for the first remailer in the chain but the body was being re-encrypted for each remailer. -- Ray Cromwell | Engineering is the implementation of science; -- -- EE/Math Student | politics is the implementation of faith. -- -- rjc at gnu.ai.mit.edu | - Zetetic Commentaries -- From khijol!erc at colossus.apple.com Thu Sep 16 23:21:22 1993 From: khijol!erc at colossus.apple.com (Ed Carp) Date: Thu, 16 Sep 93 23:21:22 PDT Subject: Trust fund to support free software. Backed, in part, by PGP. In-Reply-To: <9309170308.AA01240@stigma.key.amdahl.com> Message-ID: > [Forwarded from c.o.l.d at request of Jeff Kopmanis. --mdw] I object to the list being made a vehicle to ask for donations - I don't think that this is the place for such things, and I doubt that this has more than a passing relationship to most of the lists posted on. -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From kelly at netcom.com Fri Sep 17 00:24:55 1993 From: kelly at netcom.com (Kelly Goen) Date: Fri, 17 Sep 93 00:24:55 PDT Subject: No Subject Message-ID: <9309170724.AA09162@netcom.netcom.com> ------- Forwarded Message Subject: (fwd) *FLASH* Moby SUBPOENA served Newsgroups: comp.org.eff.talk,sci.crypt,alt.security.pgp,talk.politics.crypto Organization: NETCOM On-line Communication Services (408 241-9760 guest) Xref: netcom.com comp.org.eff.talk:20002 sci.crypt:17638 alt.security.pgp:4909 talk.politics.crypto:102 Newsgroups: comp.org.eff.talk,sci.crypt,alt.security.pgp,talk.politics.crypto Path: netcom.com!grady From: grady at netcom.com (Grady Ward) Subject: *FLASH* Moby SUBPOENA served Message-ID: Organization: Moby lexicons X-Newsreader: TIN [version 1.1 PL8] Date: Fri, 17 Sep 1993 04:56:51 GMT Lines: 22 FLASH At 10:30 PM EST 9/16/93 a subpoena was served on the Austin Code Works of Austin TX relating "any and all correspondence, contracts, payments, records, incluing computer data relating to Moby Crypto and any other commercial product relating to PGP and RSA" you are commanded to give to Michael J. Yamaguchi United States Attorney Northern District of California served by Theodore R. Siggins, special agent Department of Treasury, US Customs Service More details later. - -- Grady Ward grady at netcom.com 3449 Martha Ct. compiler of Moby lexicons Arcata, CA 95521-4884 e-mail or finger grady at netcom.com (707) 826-7715 (voice/24hr FAX) for more information ------- End of Forwarded Message From kelly at netcom.com Fri Sep 17 00:34:55 1993 From: kelly at netcom.com (Kelly Goen) Date: Fri, 17 Sep 93 00:34:55 PDT Subject: (fwd) Subpoena served on Crypto Message-ID: <9309170734.AA10493@netcom.netcom.com> Xref: netcom.com alt.wired:475 comp.lang.c:62219 alt.activism:50763 misc.legal:62914 alt.censorship:19449 Newsgroups: alt.wired,comp.lang.c,alt.activism,misc.legal,alt.censorship Path: netcom.com!grady From: grady at netcom.com (Grady Ward) Subject: Subpoena served on Crypto Message-ID: Organization: Moby lexicons X-Newsreader: TIN [version 1.1 PL8] Date: Fri, 17 Sep 1993 06:59:50 GMT Lines: 180 FOR IMMEDIATE RELEASE Subpoena served on Austin Code Works for material related to Moby Crypto. At 10:30 PM EDT Thursday, 16 Sept 1993 Theodore R. Siggins, special agent for the Department of Treasury, U.S. Customs Service office of enforcement for Austin, TX (512) 482-5502 served the following subpoena: United States District Court Northern District of California TO: Custodian of Records Austin Code Works 11100 Leafwood Lane Austin, TX (512) 258-0785 SUBPOENA TO TESTIFY BEFORE GRAND JURY documents of object(s) PLACE U.S. Courthouse & Federal Building 280 South First Street San Jose, CA 95113 Grand Jury Room 2115 September 22, 1993 9:00 AM YOU ARE ALSO COMMANDED to bring with you Any and all correspondence, contracts, payments, and record, including those stored as computer data, relating to the international distribution of the commercial product "Moby Crypto" and any other commercial product related to PGP and RSA Source Code for the time period June 1, 1991 to the present. CLERK RICHARD W. WIERKING by deputy clerk (illegible) This subpoena is issued on application of the United States of America Michael J. Yamaguchi United States Attorney Assistant U.S. Attorney William P. Keane 280 S. First St., Suite 371 San Jose, CA 95113 (408) 291-7221 s/a Robin Sterzer, Customs 93-1348(SJ) 93-1(SJ) 9 September 1993 served by Theodore R. Siggins special agent Department of Treasury U.S. Customs Service Office of Enforcement P.O. Box 99 Austin, TX 78767 (FTS) 770-5502 (512) 482-5502 --------------------------- BACKGROUND ---------------------------- The day before yesterday I faxed the following to the NSA: Grady Ward 3449 Martha Ct. Arcata, CA 95521 (707) 826-7715 grady at netcom.com Charlotte Knepper National Security Agency 301 688 7834 FAX 301 688 8183 14 Sep 93 Re: Moby Crypto and the Austin Code Works Recently you phoned Maria Guthery at the Austin Code Works (512-258-0785) to voice your concern about the publication for export of my product 'Moby Crypto'. As the editor and author of the compilation I made sure not to include any executable code -- only the algorithmic description in C source code that can be found (and exported) from scores of books and journals from the US distributed throughout the world. I believe that this material qualifies for the 'public domain' technical documentation exception under the current DTR rules. It seems to me that proscribing the publication of material because it is conveyed on a magnetic media rather than paper pulp is an NSA initiative that is both destructive to our basic freedom of expression and to the trade renaissance that Vice President Al Gore and the Clinton Administration are trying to foster. Even the Supreme Court recognizes the role of the computer media in protecting our freedom; beginning this 1993 calendar year all decisions will be provided in electronic form. Further, as you may know, it was recently decided that White House records in electronic form must be protected as a permanent archive of our government. Clearly, magnetic media must be treated as a logical extension of the power and fundamental right of the print media. Please phone, fax, e-mail or post your ideas or any literature to me that you think useful if I have misapprehended the situation. Of course if you wish I will send you a gratis copy of the software (about nine megabytes of sources for DES, RSA, IDEA, Lucifer, PGP, SHA, and so on) for your advice and comments. Very truly yours, GRADY WARD --------------------- WHAT YOU SHOULD DO --------------------- NSA and the US Treasury has started a new, agressive campaign to prevent the spread of cryptographic ideas, algorithms, sources, and documentation. The subpoena was served on the ACW in the night because they MIGHT have sold a copy of source code, already available worlwide, to a foreign national. If you value the freedom to disseminate ideas on both paper and magentic and electronic media, you should immediately preserve your right to have such knowledge by obtaining a copy of the source to Pretty Good Privacy and all other cryptographic materials before a possible complete blackout of such material is attempted by the US authorities. It is not yet against the law to possess source code to PGP, the world's foremost encryption application in the United States. Source is available for a variety of platforms including MS-DOS, Unix, and Macintosh from the following sites: soda.berkeley.edu ghost.dsi.unimi.it nic.funet.fi ota.ox.ac.uk van-bc.wimsey.bc.ca and many other sites For more information about PGP, send a blank mail message to: pgpinfo at mantis.co.uk -- Grady Ward grady at netcom.com 3449 Martha Ct. compiler of Moby lexicons Arcata, CA 95521-4884 e-mail or finger grady at netcom.com (707) 826-7715 (voice/24hr FAX) for more information From kelly at netcom.com Fri Sep 17 00:54:56 1993 From: kelly at netcom.com (Kelly Goen) Date: Fri, 17 Sep 93 00:54:56 PDT Subject: (fwd) pgpwin11 Message-ID: <9309170754.AA11959@netcom.netcom.com> Path: netcom.com!netcomsv!decwrl!usenet.coe.montana.edu!netnews.nwnet.net!henson!news.reed.edu!usenet From: pwilk at reed.edu (The Cannibal) Newsgroups: alt.security.pgp Subject: pgpwin11 Date: 13 Sep 1993 21:02:23 GMT Organization: Reed College, Portland, Oregon Lines: 12 Message-ID: <272n4v$pco at scratchy.reed.edu> NNTP-Posting-Host: reed.edu I just downloaded pgpwin11.zip from garbo.uwasa.fi. It is in the /windows/util directory i think. I haven't tried it out, but I am all in a froth to try it out. just thought you might like to know. it's a windows pgp shell you ninny. -- The _O_ "Darkness may cover me: midnight may steal along my living veins; Cannibal | yea and the ultimate futility, the ghastly nothing on which all things play may break ice-thin crust and freeze my soul" pwilk at reed.edu -=public key available on finger=- - John Cowper Powys From kelly at netcom.com Fri Sep 17 00:55:56 1993 From: kelly at netcom.com (Kelly Goen) Date: Fri, 17 Sep 93 00:55:56 PDT Subject: (fwd) New pgp-public-keys server! Message-ID: <9309170752.AA11832@netcom.netcom.com> Newsgroups: alt.security.pgp Path: netcom.com!netcomsv!decwrl!uunet!pipex!sunic!trane.uninett.no!news.eunet.no!nuug!news.eunet.fi!KremlSun!kiae!relcom!rd.relcom.msk.su!blaster From: blaster at rd.relcom.msk.su (Victor A. Borisov) Subject: New pgp-public-keys server! Sender: usenet at newcom.kiae.su (Mr. Usenet) Organization: Relcom R&D Date: Thu, 16 Sep 1993 09:21:20 GMT X-Newsreader: TIN [version 1.1 PL6] Message-ID: <1993Sep16.092120.15509 at newcom.kiae.su> Lines: 28 Hello everybody. I am glad to introduce my pgp public keys server. This server has Internet address: "pgp-public-keys at kiae.su". It physically placed in Relcom corp. (Moscow). I will maintain this server (my name is Victor Borisov aka blaster, my Internet address is "blaster at rd.relcom.msk.su"). For beginning of interaction with server, you can (as usually) send empty letter with header: To: pgp-public-keys at kiae.su From: your at internet.address Subject: help I use 0.16a version of Michael Graff server as software. My server exchange added keys with other servers. All messages from server will also contain Russian text. Sincerely your, Victor Borisov. -- Victor A. Borisov aka blaster; Relcom R&D; Email: blaster at rd.relcom.msk.su; Phone: +7(095)-943-4735; +7(095)-198-9510; === Don`t panic! == From kelly at netcom.com Fri Sep 17 00:59:26 1993 From: kelly at netcom.com (Kelly Goen) Date: Fri, 17 Sep 93 00:59:26 PDT Subject: Sorryabout the very last mailing Message-ID: <9309170756.AA12137@netcom.netcom.com> Sorry about the very last mailing about the PGP shell... BUT the earliers forwards about the Mobycrypt distrbution were indeed critical... MUCH more is happening on this front in the next week... will report as I get details. cheers kelly -- From kelly at netcom.com Fri Sep 17 00:59:56 1993 From: kelly at netcom.com (Kelly Goen) Date: Fri, 17 Sep 93 00:59:56 PDT Subject: PGP Customs investigation subpoena (fwd) Message-ID: <9309170757.AA12199@netcom.netcom.com> Forwarded message: From karn at qualcomm.com Fri Sep 17 01:00:55 1993 From: karn at qualcomm.com (Phil Karn) Date: Fri, 17 Sep 93 01:00:55 PDT Subject: (fwd) Subpoena served on Crypto In-Reply-To: <9309170734.AA10493@netcom.netcom.com> Message-ID: <9309170759.AA02702@servo> Get on the phone to EFF ASAP. Here's the bibliography I promised earlier. If someone would put this up on soda and perhaps even add to the list, I'd really appreciate it. --Phil ------ As a few people have requested, here's my current bibliography of DES source code listings found in various widely published books or magazines. Note that I have explicitly excluded the dozens of books and publications that merely *describe* the DES algorithm -- even descriptions complete enough to use as a basis for implementation. They don't count because, as we all know, only Americans are smart enough to turn an algorithm description into C code (or so our government believes.) Additions or corrections to this list are welcome. Again, I'm only interested in actual code listings. --Phil "The Standard Data Encryption Algorithm", Harry Katzan Jr, Petrocelli Books, 1977 ISBN 0-89433-016-0 (APL). "Computer Networks", Andrew S. Tanenbaum, Prentice Hall (both editions; second edition is ISBN 0-13-162959-X). (Pascal) "Numerical Recipes", William H. Press et al, Cambridge University Press. (Fortran and Pascal version is ISBN 0-521-30811-9. Also in "Numerical Recipes in C"). "UNIX System Security", Wood and Kachan, Hayden. ISBN 0-8104-6267-2. Byte Magazine, April 1977 (6502 Assembler). "Cryptography: An Introduction to Computer Security", Seberry and Pieprzyk, Prentice Hall Australia. (C) "Mathematical Cryptology for Computer Scientists and Mathematicians", Wayne Patterson, Rowman and Littlefield, 1987. ISBN 0-8476-7438-X. Introduction to the Analysis of the Data Encryption Standard (DES), by Wayne G. Barker, ISBN 0-89412-169-3 (soft cover), 0-89412-170-7 (library bound), 1991, Aegean Park Press, Appendix G. (Basic, of all things). From kelly at netcom.com Fri Sep 17 01:01:23 1993 From: kelly at netcom.com (Kelly Goen) Date: Fri, 17 Sep 93 01:01:23 PDT Subject: PGP Customs investigation subpoena (fwd) Message-ID: <9309170759.AA12315@netcom.netcom.com> Forwarded message: From kelly Fri Sep 17 01:08:07 1993 From: kelly (Kelly Goen) Date: Fri, 17 Sep 93 01:08:07 -0700 Subject: (fwd) Korea now accepts secret US patent applications Message-ID: <9309170808.AA12777@netcom.netcom.com> Xref: netcom.com misc.legal.computing:4115 misc.int-property:2011 Newsgroups: misc.legal.computing,misc.int-property Path: netcom.com!csus.edu!wupost!cs.utexas.edu!uunet!world!srctran From: srctran at world.std.com (Gregory Aharonian) Subject: Korea now accepts secret US patent applications Message-ID: Organization: The World Public Access UNIX, Brookline, MA Date: Thu, 9 Sep 1993 16:14:30 GMT Lines: 15 On July 29, 1993, the republic of South Korea became the 17th country to sign an agreement with the United States to protect patent rights of patent applications fild in the United States for which the government has classified secret and indefinitely delay the prosecution of the patent. Existing countries, mostly COCOM members, are: Australia, Belgium, Canada, Denmark, France, Germany, Greece, Italy, Japan, Luxembourg, Netherlands, Norway, Portugal, Sweden, Turkey and United Kingdom. For more information on secrecy aspects of US patents, contact Robert Garrett at the Patent Office, 703-308-0753. -- ************************************************************************** Greg Aharonian srctran at world.std.com Source Translation & Optimization 617-489-3727 P.O. Box 404, Belmont, MA 02178 -- From nowhere at bsu-cs.bsu.edu Fri Sep 17 01:15:55 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Fri, 17 Sep 93 01:15:55 PDT Subject: No Subject Message-ID: <9309170816.AA08549@bsu-cs.bsu.edu> We need to get the 9 megs of Moby Crypto stuff mentioned out to as many sites as we can before the boots of the Feds seal our doom. Before the hearing next Wednesday. Use the Cypherpunks remailers to send as much out as you can. Janet Reno and her BATF/DEA/narcoterrorist New World Order fascist goons are now taking action against one of our own fellow privacy activists , Grady Ward, and the Austin Code Works. Use the remailers to post ftp sites we should send stuff too. As some of our more paranoid members have said, odds are high that this list is high on the list of places they're watching. USE THE FUCKIN' REMAILERS, FOLKS!!!! > From: grady at netcom.com (Grady Ward) > Subject: Subpoena served on Crypto > Message-ID: > Organization: Moby lexicons > X-Newsreader: TIN [version 1.1 PL8] > Date: Fri, 17 Sep 1993 06:59:50 GMT > Lines: 180 > > FOR IMMEDIATE RELEASE > > Subpoena served on Austin Code Works for > material related to Moby Crypto. ...... > SUBPOENA TO TESTIFY BEFORE GRAND JURY > documents of object(s) > ... > U.S. Courthouse & Federal Building > 280 South First Street > San Jose, CA 95113 So I guess this means the guys in the San Fran area won't get inside. Grand Juries are sealed. Remember these sites: > soda.berkeley.edu > ghost.dsi.unimi.it > nic.funet.fi > ota.ox.ac.uk > van-bc.wimsey.bc.ca > > and many other sites > The ones outside the States may be OK for a while. Until the NEW WORLD ORDER and the U.N. Crypto Authority gets control. Yours in fear, -TURING From kelly at netcom.com Fri Sep 17 02:04:57 1993 From: kelly at netcom.com (Kelly Goen) Date: Fri, 17 Sep 93 02:04:57 PDT Subject: (fwd) Korea now accepts secret US patent applications (fwd) Message-ID: <9309170902.AA15463@netcom.netcom.com> Forwarded message: From prz at columbine.cgd.ucar.EDU Fri Sep 17 00:32:46 1993 From: prz at columbine.cgd.ucar.EDU (Philip Zimmermann) Date: Fri, 17 Sep 1993 02:32:46 -0500 Subject: PGP Customs investigation subpoena Message-ID: <9309170735.AA23358@columbine.cgd.ucar.EDU> I will be posting a note similar to this one later on Friday to various newsgroups. You saw it here first. -prz -------------------------------------------------------------- On Tuesday, 14 September 93, Leonard Mikus, president of ViaCrypt, also known as LEMCOM Systems, in Phoenix, Arizona, was served a Subpoena to Testify Before Grand Jury, to produce documents. The subpoena was issued by the US District Court of Northern California, by Assistant US Attorney William P. Keane in San Jose, as part of an investigation from the San Jose office of US Customs, conducted by Special Agent Robin Sterzer. The US Attorney above Keane is Michael J. Yamaguchi. ViaCrypt is the company that will be selling a fully licensed commercial version of PGP, starting in November. ViaCrypt has a license from PKP to sell products that embody the patents held by PKP. That includes PGP, using the RSA algorithm. The subpoena, dated 9 September, orders the production of "Any and all correspondence, contracts, payments, and records, including those stored as computer data, involving international distribution related to ViaCrypt, PGP, Philip Zimmermann, and anyone or any entity acting on behalf of Philip Zimmermann for the time period June 1, 1991 to the present." The date specified for the production of documents is 22 September 93. The written agreement between ViaCrypt and myself explicitly states that US State Department cryptographic export controls will be adhered to. The implications of this turn of events are that this US Customs investigation has escalated to the level of a Federal Grand Jury and a US Attorney. US Customs says that this change was precipitated by a ruling recently handed down from the State Department that PGP is not exportable. Other subpoenas and/or search warrants are expected. I am the principal target of the investigation. I have advised EFF, CPSR, and my other attorneys of the situation. A legal defense fund will be set up by my lead attorney (Phil Dubois, 303 444-3885) here in Boulder. This case raises some serious public policy questions regarding First Amendment rights to publish, rights to privacy as affected by widespread availability of cryptographic technology, the equivalance of electronic publication with paper publication, the availablity of lawful domestic cryptographic technology in the face of export controls, and certain other Constitutional rights. This may turn into the test case for these issues. -Philip Zimmermann prz at acm.org 303 541-0140 -- From gtoal at an-teallach.com Fri Sep 17 03:29:27 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Fri, 17 Sep 93 03:29:27 PDT Subject: PGP Customs investigation subpoena (fwd) Message-ID: <9819@an-teallach.com> In article <9309170757.AA12199 at netcom.netcom.com> kelly at netcom.com writes: > The subpoena, dated 9 September, orders the production of "Any and > all correspondence, contracts, payments, and records, including those > stored as computer data, involving international distribution related > to ViaCrypt, PGP, Philip Zimmermann, and anyone or any entity acting > on behalf of Philip Zimmermann for the time period June 1, 1991 to > the present." The date specified for the production of documents is > 22 September 93. Fun fun fun! Now we also get to find out if someone can be forced to disclose his pgp key! G -- Personal mail to gtoal at gtoal.com (I read it in the evenings) Business mail to gtoal at an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212 From gg at well.sf.ca.us Fri Sep 17 04:35:01 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 17 Sep 93 04:35:01 PDT Subject: more on AT&T Message-ID: <93Sep17.043111pdt.13955-3@well.sf.ca.us> Compared to the recent news of subpoenas, the following is pretty mild stuff, but nonetheless it may be of some value: An AT&T companywide newsletter sent to 300,000 employees, contained a cartoon showing people all over the world talking together on the phone. In every continent there was a picture of a human, except for the continent of Africa, where a **monkey** was pictured. Upon having the obvious racist significance of this pointed out, AT&T issued an apology. Okay, anyone who can come up with a copy of this thing, email me: gg at well.sf.ca.us. LEt's get it into circulation; it will help make things hot for the company which sells Phones With Big Brother Inside. Hey, re these subpoenas: time for an emergency meeting to discuss legal strategies, publicity strategies, and all that stuff, yes? How about Sunday? -gg From nowhere at bsu-cs.bsu.edu Fri Sep 17 05:21:03 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Fri, 17 Sep 93 05:21:03 PDT Subject: Pasting syntax Message-ID: <9309171222.AA15326@bsu-cs.bsu.edu> Regarding pasting headers for remailers - How does one paste in a "Cc"? Can it be done by adding it to the paste header, like so? :: Request-Remailing-To: Subject: Organization: Cc: I guess I'll find out.... From nowhere at bsu-cs.bsu.edu Fri Sep 17 05:35:02 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Fri, 17 Sep 93 05:35:02 PDT Subject: Moby Crypto Message-ID: <9309171233.AA15782@bsu-cs.bsu.edu> Punkz, With the recent turn of events concerning the subpoenas for Austin Code Works, Grady Ward and Phil Zimmerman, I would suggest that each of us do our parts to disseminate PGP and all other forms of crypto FAR AND WIDE, as quickly as possible. The battle has been joined! From nobody at rosebud.ee.uh.edu Fri Sep 17 08:35:09 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Fri, 17 Sep 93 08:35:09 PDT Subject: REMAIL pasting syntax Message-ID: <9309171534.AA07928@toad.com> Earlier, an anonymous person asked about pasting syntax, about how to paste in a CC: header. The answer is: it depends on which remailer you use. For a Hal-style cypherpunks remailer, you would do something like this: ----------8< cut here >8---------- :: Request-Remailing-To: someone at somwhere ## CC: I am pasting this into the header as the mail leaves Here is my message ----------8< cut here >8---------- But, if you use Chael's remailer (since I beleive he wrote his own software!), you would do this: ----------8< cut here >8---------- :: Request-Remailing-To: someone at somewhere CC: I am pasting this into the header as the mail leaves Here is my message ----------8< cut here >8---------- Of course, you would only want to paste at the last hop since the remailers would trim it out otherwise. For example, this message should have an "X-CC:" header I pasted in. -- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From doug at netcom.com Fri Sep 17 09:09:28 1993 From: doug at netcom.com (Doug Merritt) Date: Fri, 17 Sep 93 09:09:28 PDT Subject: Trust fund to support free software. Backed, in part, by PGP. Message-ID: <9309171608.AA25945@netcom2.netcom.com> Although that's an interesting scheme, it would be even more trustworthy to send the money directly to the trust bank account, which can be done in simple ways. We need better algorithms than the one suggested. Doug From cman at IO.COM Fri Sep 17 10:35:10 1993 From: cman at IO.COM (Douglas Barnes) Date: Fri, 17 Sep 93 10:35:10 PDT Subject: New info on Austin subpoena In-Reply-To: <9309170734.AA10493@netcom.netcom.com> Message-ID: <9309171732.AA15873@illuminati.IO.COM> Cypherpunks: I spoke just now with Maria Nekam, the owner of Austin Code Works. She is doing fine, has complied with the request for documents, and believes that her company has nothing to hide. She believes that they have taken all reasonable precautions to prevent the export of the DES materials. Interestingly enough, she had been contacted by the NSA a couple of weeks ago, and informed of the restrictions on exporting DES, although she was already complying with these restrictions. I asked if there was anything that the various organizations could do to help; she feels that the situation is under control. When asked about her opinion of the DES export restrictions, she declined to comment, saying that her company was just a small player and she didn't want to get involved. I told her about the crypto conference we are having (coincidentally?) on the same day as the hearing. Since her presence is not required at the hearing, she will try to attend. As I was writing the above, my phone call to Theodore R. Siggins, the customs agent mentioned in the subpoena was returned. We spoke briefly; he was friendly but felt "it would be inappropriate for me to comment on any matters concerning the grand jury." When I asked him if this was part of an overall crackdown on cryptography export, he referred me to the special agent in charge, Leonard Lindheim, (202) 229-4561. Doug -- ---------------- /\ Douglas Barnes cman at illuminati.io.com / \ Chief Wizard (512) 447-8950 (d), 447-7866 (v) / () \ Illuminati Online metaverse.io.com 7777 /______\ From ssteele at eff.org Fri Sep 17 11:25:10 1993 From: ssteele at eff.org (Shari Steele) Date: Fri, 17 Sep 93 11:25:10 PDT Subject: Crypto Witchhunt? Message-ID: <199309171821.AA24935@eff.org> To the 'net community: EFF is very concerned about the Customs Department-initiated grand jury investigation into encryption export violations. Two U.S. companies have been subpoenaed to produce documents related to the "international distribution" of commercial products utilizing PGP and RSA source code. Neither of these companies are engaged in the international distribution of any illegal materials. EFF is working with the concerned parties and is trying to find out the scope of the grand jury investigation. Unfortunately for us in this case, grand jury investigations are secret, so learning the scope is proving to be quite difficult. What we do know is this: Austin Code Works, a software publisher in Austin, Texas (heavy sigh), has been planning to publish a code document written by Grady Ward called Moby Crypto. Grady describes Moby Crypto as simply containing descriptive source code, not executable object code, describing many cryptographic routines that are freely available around the world. Most of this material has been released in print form already. The important distinction seems to be that Moby Crypto will be released in machine-readable format. Austin Code Works has told Customs Agents that it does not intend to release Moby Crypto outside of the U.S., yet the company has been subpoenaed to release all documents related to this product. (Incidently, if Moby Crypto contains no executable code, it should be exportable under ITAR, just as textbooks containing such materials are exportable.) ViaCrypt, a Phoenix, Arizona,-based (heavy sigh again -- man, does this ring familiar) software producer that has a license to sell software products that use the RSA algorithm, was issued a similar subpoena. ViaCrypt has recently contracted with Phil Zimmermann, creator of the PGP encryption code, to sell a commercial version of PGP. ViaCrypt only distributes its products containing the RSA algorithm within the United States, since RSA is not exportable under ITAR. EFF has been in touch with Phil Zimmermann and his attorney, Grady Ward, and the owner of Austin Code Works. We have advised everyone that there is nothing to hide and that they should abide by the subpoenas and produce the documents requested. We will not know what the appropriate response should be until the grand jury makes its determinations. In the meantime, we want everyone to know that EFF is committed to ensuring that the right to use and publish whatever encryption method an individual chooses to use is protected. Jerry Berman, EFF's Executive Director, issued the following internal message this morning: >I've assured Phil that he is not alone, and I have talked with his attorney. >If Phil is charged with export control violations based on making PGP >available in the US on a non-commercial basis and it happens to get >published or copied overseas, First Amendment issues indeed may be joined. >As of now, ViaCrypt has done no "exporting" and does not intend to. I have >the subpoena. Indeed, EFF has copies of both subpoenas. We will continue to keep you informed of what's going on as we learn the facts. EFF is deeply concerned, and we want Phil and everyone else involved to know that they are not alone. As soon as it becomes clear what specifically is being investigated, EFF will respond. Shari ****************************************************************************** Shari Steele Director of Legal Services Electronic Frontier Foundation 1001 G Street, NW Suite 950 East Washington, DC 20001 202/347-5400 (voice), 202/393-5509 (fax) ssteele at eff.org From Lyle_Seaman at transarc.com Fri Sep 17 11:35:10 1993 From: Lyle_Seaman at transarc.com (Lyle_Seaman at transarc.com) Date: Fri, 17 Sep 93 11:35:10 PDT Subject: CHAUM CHIMES IN In-Reply-To: <9309091550.AA23383@ellisun.sw.stratus.com> Message-ID: Excerpts from internet.cypherpunks: 9-Sep-93 Re: CHAUM CHIMES IN Carl Ellison at ellisun.sw. (1183) > ..From: > > SANDY SANDFORT Reply to: ssandfort at attmail.com > [ . . . ] > >Of course, the next letter to the editor calls for the adoption > >of systems to track every vehicle at all times. The genius who > >wrote the letter, thinks it would be a good way to prevent > >nuclear, biological or chemical terrorism. Geeeeez. > It was signed by Dorothy Denning, right? Actually, it was signed by... John Locke I thought it was satire, but maybe not. It gets so hard to tell, these days. From cme at ellisun.sw.stratus.com Fri Sep 17 11:59:30 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Fri, 17 Sep 93 11:59:30 PDT Subject: KEY ESCROW PROCEDURES Message-ID: <9309171855.AA00716@ellisun.sw.stratus.com> Meanwhile, where is the proof that the key being requested corresponds to a person on whom a wiretap has been ordered? From cme at ellisun.sw.stratus.com Fri Sep 17 12:25:11 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Fri, 17 Sep 93 12:25:11 PDT Subject: remail Moby Crypto? nonsense. Message-ID: <9309171922.AA00786@ellisun.sw.stratus.com> >Date: Fri, 17 Sep 93 03:16:48 -0500 >Message-Id: <9309170816.AA08549 at bsu-cs.bsu.edu> > >We need to get the 9 megs of Moby Crypto stuff mentioned >out to as many sites as we can before the >boots of the Feds seal our doom. >Before the hearing next Wednesday. This is silly. The Moby Crypto stuff is already available worldwide. That's what makes the government's case so incredibly stupid -- but of course, I'm not a lawyer. :-| - Carl From cme at ellisun.sw.stratus.com Fri Sep 17 13:11:09 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Fri, 17 Sep 93 13:11:09 PDT Subject: Moby Crypto Message-ID: <9309172009.AA00893@ellisun.sw.stratus.com> I hope you keep in mind that the existence of optical character readers puts printed pages in the domain of machine-readable media. - Carl From pcw at access.digex.net Fri Sep 17 14:01:38 1993 From: pcw at access.digex.net (Peter Wayner) Date: Fri, 17 Sep 93 14:01:38 PDT Subject: Ke Escrow Procedures... Message-ID: <199309172100.AA00640@access.digex.net> Carl Ellison writes: Meanwhile, where is the proof that the key being requested corresponds to a person on whom a wiretap has been ordered? When I saw a preliminary briefing given to the CSSPAB, the DOJ suggested that there would be no list kept equating names to Clipper Chip ID #. Of course such a list would be a real disaster because people would routinely be shifting hardware left and right. Any list would become immediately out of date. This means that there is really no feasible way to discover misuse. -Peter From frc%bwnmr4 at harvard.harvard.edu Fri Sep 17 16:25:15 1993 From: frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) Date: Fri, 17 Sep 93 16:25:15 PDT Subject: No Mail in 24 hours.... Message-ID: <9309172301.AA11151@bwnmr4.harvard.edu> Did somebody die or what? FRC From fergp at sytex.com Fri Sep 17 18:45:16 1993 From: fergp at sytex.com (Paul Ferguson) Date: Fri, 17 Sep 93 18:45:16 PDT Subject: The lighter side Message-ID: <5ws20B1w165w@sytex.com> And on a lighter note: Newsgroups: comp.org.eff.talk,sci.crypt,alt.security.pgp,talk.politics.cry pto From: john at iastate.edu (John Hascall) Subject: Re: *FLASH* Moby SUBPOENA served Organization: Iowa State University, Ames, IA Date: Fri, 17 Sep 1993 13:39:39 GMT Lines: 21 grady at netcom.com (Grady Ward) writes: }SUBPOENA TO TESTIFY BEFORE GRAND JURY .. }YOU ARE ALSO COMMANDED to bring with you }Any and all correspondence, contracts, payments, and record, }including those stored as computer data, relating to the }international distribution of the commercial product "Moby }Crypto" and any other commercial product related to PGP and RSA }Source Code for the time period June 1, 1991 to the present. I don't suppose they'd see the humor of bringing it on a disk and encrypted... John -- John Hascall ``An ill-chosen word is the fool's messenger.'' Systems Software Engineer Project Vincent Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551 Newsgroups: comp.org.eff.talk,sci.crypt,alt.security.pgp,talk.politics.cry pto From: grady at netcom.com (Grady Ward) Subject: Re: *FLASH* Moby SUBPOENA served Followup-To: comp.org.eff.talk,sci.crypt,alt.security.pgp,talk.politics.cr ypto Organization: Moby lexicons X-Newsreader: TIN [version 1.1 PL8] Date: Fri, 17 Sep 1993 14:44:34 GMT Lines: 18 John Hascall (john at iastate.edu) wrote: : I don't suppose they'd see the humor of bringing : it on a disk and encrypted... HEhe obstruction of justice he he ten years ho ho heh he But seriously, encryption makes it possible to take the fifth amendment and *mean* it... (Not that anyone here has anything to hide, of course.) -- Grady Ward grady at netcom.com 3449 Martha Ct. compiler of Moby lexicons Arcata, CA 95521-4884 e-mail or finger grady at netcom.com (707) 826-7715 (voice/24hr FAX) for more information Paul Ferguson | privacy \'pri-va-see\ n, pl, -cies; Mindbank Consulting Group | 1: the quality or state of being apart Fairfax, Virginia USA | from others 2: secrecy fergp at sytex.com | ferguson at icp.net | Privacy -- Use it or lose it. From tcmay at netcom.com Fri Sep 17 21:19:33 1993 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 17 Sep 93 21:19:33 PDT Subject: Check out "EFFector Online 6.1" Message-ID: <9309180417.AA08798@netcom5.netcom.com> The latest "EFFector Online," available in the usual places, is oriented toward crypto, having a lengthy summary of the Skipjack/Capstone issue (more legalese about escrow than crypto) and a nice Barlow piece on crypto (updating his piece a year ago in CACM). Barlow even mentions "unless you're a real cypherpunk," so we're entering the language. I'd post the whole thing here, except that it's 1100+ lines. Definitely check it out! -Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From remailer at netcom.com Fri Sep 17 22:15:20 1993 From: remailer at netcom.com (remailer at netcom.com) Date: Fri, 17 Sep 93 22:15:20 PDT Subject: Crypto crackdown - this is it! Message-ID: <9309180507.AA04586@mail.netcom.com> Well, we knew that this had to happen eventually. Isn't it ironic that, as we read that crypto is flourishing in the Soviet Union, that their supreme court has just accepted the validity of digital signatures, we find ourselves under attack here at home! Seems like we're putting up walls just as fast as they are tearing them down over there. I just sent e-mail to those crypto developers in the Soviet Union; maybe I'll get a visit from the Thought Police. After all, I did mention RSA, IDEA, and PGP in the message, and there's not much doubt the bad guys monitor the link to the Soviet Union, now is there? In fact, everyone who has a public key on the key servers could be a suspect. This crackdown can serve no legitimate security purpose, since the algorithms involved are all readily available worldwide. This can only serve two purposes: (1) to intimidate any company which might consider publishing useful cryptographic software and information, and (2) to establish a precedent and set up the machinery for a drug-war-style crackdown on all privacy and digital speech. Why is the government so reluctant to treat digital media as equivalent to paper media? Real simple. Paper requires an organization to distribute it. If the government really wants to, they can conduct a Gestapo raid and confiscate everything (Steve Jackson Games) and prevent the publication of anything on paper. With electronic media, they can't do anything. Once it's on a disk or on the Usenet, information is forever beyond their control. The government is about to lose all control over information, and the idea scares the hell out of them. What is happening is that the network is replacing the hierarchy as the basic unit of human organization. Naturally, those who run the hierarchies don't want this to happen. The bad guys have been trying to figure out what to do since PGP was released. Being leftover cold warriors, they really don't know how to attack freeware distribution. The idea of free distribution of information is totally alien to them. But as soon as commercial sales were mentioned, they knew what to do. Yes, we should fight them tooth and nail on this one, but we should also learn a valuable lesson from it: they can't handle freeware! It's only when we go commercial, with a visible base of operations, that they know how to attack us. We need a method of zero-knowledge collaboration on software development. People could work together on a project without knowing anything about each other. This would involve a newsgroup for discussion of projects, anonymously of course, and the exchange of pseudonymous PGP keys. Private mail would be sent by posting with the recipient's key id in the subject, making it easy to grep for. Development could be broken up among different people, functions and code fragments could be posted and exchanged, and the whole program compiled and released, in such a way as to be totally untraceable. Code we need now! Windows NT, OS/2, and UNIX implementations of PGP, set up as a server so that any application can access PGP primitives. This would establish PGP as a standard encryption server outside the US. People use what is easy, so make it easy. A program to transparently encrypt hard drives on the fly, similar to KOH or Norton Diskreet (except don't use DES, and allow only part of the drive to be encrypted, like Diskreet), to protect people against unreasonable search and seizure. Let's face it, with the drug war, the Constitution's search and seizure protections are DEAD! They may not be able to prosecute you based on illegal evidence, but they can take everything you own and keep it until you are broke and homeless. A tape backup program which securely (IDEA or similar) encrypts streaming tapes. This would protect people from seizure of their records and archives. Government loves to seize paper; give the bastards something they can't read! The next few weeks and months may be decisive. This is it. If we succeed, we could have a future of freedom, privacy and equality brought about by the inherently democratic nature of networks in general and public key crypto in particular. A world in which digital cash has starved the dinosaurs of government and digital media have made censorship forever impossible. But, if we fail: "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. But at any rate they could plug in your wire whenever they wanted to. You had to live - did live, from habit that became instinct - in the assumption that every sound you made was overheard, and, except in darkness, every movement scrutinized." -- 1984 BTW: when setting up encrypted remailer bounces, be sure to change the subject at every bounce to defeat traffic analysis based on the subject line being the same all the way through. For example: :: Request-Remailing-To: Subject: Be careful, write code, spread PGP, we might actually win this thing! From ld231782 at longs.lance.colostate.edu Fri Sep 17 22:36:19 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Fri, 17 Sep 93 22:36:19 PDT Subject: WE'RE UNDER ATTACK Message-ID: <9309180534.AA27719@longs.lance.colostate.edu> First of all, the attacks on Moby Crypto (Grady Ward) and on PGP are *clearly* linked in the SAME systematic assault on cryptographic distribution, as S. Steele of EFF has indicated. Both the subpoenas were served by US District Court of Northern California, San Jose. The head attorney mentioned in both cases is Michael J. Yamaguchi. The subpoenas are virtually identical. Both mention W. P. Keane, Assistant attorney, and special agent Robin Sterzer. They appear to have been served on the same *day*, perhaps even the same *time*. (Rule X of systematic warfare: coordinate attack timing on all fronts.) Here is where the dissimilarity seems to start. Grady Ward was unequivocally being harassed by the *NSA* prior to this date as he reported on various newsgroups. Is the summons related to this NSA inquiry? It would be inconceivable at this point to believe that it wasn't. PGP & PRZ were being harassed by *customs officials* prior to this date, possibly under the complaints of PKP. Now, these two situations have been totally aligned in the simultaneous serving of the subpoenas. Is this a systematic assault by the NSA, PKP, or Customs Officials? Does it have something to do with the ink-still-drying agreement between PRZ and Viacrypt? Who convened the grand jury? *somebody* is targeting cryptographic distribution in a devastating initial two-pronged blow. The curious coincidence of clearcut NSA harassment of Moby Crypto on one hand and the PKP harassment of PGP on the other, *united* in the subpoena, with the chocolate ViaCrypt agreement timing on top, is extremely unsettling, and perhaps altogether the strongest fodder so far for NSA-PKP conspiracy theories. We must try to determine whose rules we are playing by. Is this a customs investigation? Treasury Dept.? The situation with NSA is that they don't really ever act directly, they always go through some other henchmen to do the dirty work. This smells like them. But the case of the NSA convening a grand jury does not appear to have a historical precedent. What's going on here? ATTACK PLAN At this early date it is impossible to formulate something sensible. Everyone is completely disoriented. This is like a grenade going off in the room. However, my initial reaction is that the subpoenas seem to be OVERBROAD. They could be argued by a competent attorney, given the simultaneous targeting of two completely disparate cryptographic enterprises, to represent an OUTRAGEOUS FISHING EXPEDITION. Isn't there a way to contest a subpoena in court? these legal mechanisms need to be employed IMMEDIATELY. what is the significance of the date June 1, 1991, the date back to which all cryptographic materials are requested? Does this have any meaning to PGP or some law? If anyone can figure out the meaning, it may be a route to a counterattack. From binder at well.sf.ca.us Fri Sep 17 23:11:20 1993 From: binder at well.sf.ca.us (Matt Binder) Date: Fri, 17 Sep 93 23:11:20 PDT Subject: reporter seeking interview subjects Message-ID: <93Sep17.230857pdt.14382-4@well.sf.ca.us> Hi, my name is Matt Binder. Please help me... I'm a radio reporter in the SF Bay area working on a series of pieces about invasions of privacy in the computer age. I'm looking for interesting "case studies" that I can use to horrify my listeners out of their complacency. My most immediate need is to find someone whose medical records were used (perused!) improperly, and/or whose records were incorrect and resulted in the denial of insurance, employment, loans, adoptions, etc. But please also let me know about privacy invasions in other areas (employer e-mail monitoring, workplace drug testing, credit problems, weird solicitations, etc.) for future stories. I've been a science and technology reporter for ten years, the first five at KPFA in Berkeley. This series of reports will air on a number of different stations and networks including Pacifica, KPFA, KQED and The Christian Science Monitor radio network. Feel free to circulate this request as you like. Thanks, Matt p.s. I will be really busy until 9/23 so don't give up on me if you don't hear back right away. I'm binder at well.sf.ca.us From ld231782 at longs.lance.colostate.edu Fri Sep 17 23:30:22 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Fri, 17 Sep 93 23:30:22 PDT Subject: Clipper production problems Message-ID: <9309180628.AA28163@longs.lance.colostate.edu> This is a vague hint that Clipper development is not going quite as planned -- delayed at least 2 quarters (half year!). I sure wonder what is going on in the trenches. All you Mycotronx employees out there, feel free to post anonymously :) ===cut=here=== From: koontzd at nebula.lrcs.loral.com (David Koontz ) Newsgroups: alt.privacy.clipper,talk.politics.crypto Subject: MYK-78 Clipper Chip Availability Date: 16 Sep 93 18:53:13 GMT Organization: Loral Rolm Computer Systems I just got off the phone with someone at AT&T Surety Communications, the date given for availability of clipper chips for inclusion in products is 1st quarter '94 (January). The previous date was 3rd quarter '93 (September), which was obviously missed. The date originated with a U.S. government agency. Will the date get further out still? [I got confirmation Mykotronx is unhappy about the delay] { I know some people who might be happy .. djf} For those not willing to wait, you can purchase Telephone Security Devices now, and for an extra $100 you can get a free upgrade to the Escrow Encryption Standard latter. Any more delays and I might not bet on it. The existing nongovernment TSDs used a Type IV proprietary encryption algorithm and NOT DES. (I'll wait for January before ordering a pair) ------- End of Forwarded Message From ld231782 at longs.lance.colostate.edu Fri Sep 17 23:35:23 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Fri, 17 Sep 93 23:35:23 PDT Subject: SEA Internet party, NY Message-ID: <9309180630.AA28278@longs.lance.colostate.edu> Society for Electronic Access. ===cut=here=== Date: Fri, 17 Sep 1993 16:46:17 -0400 (EDT) From: steven cherry Subject: Electronic flyer for Sept 27th Intro to Internet event What follows is the flyer for the upcoming Intro to Internet event on Sept 27th. Please feel free to post this far and wide (or at least wide). A physical flyer will also be available this weekend. If you have already volunteered to post these and I have not contacted you by Sunday, or if you have not volunteered yet but would like to, contact me. - -- stc at panix.com Steven Cherry - -cut here- ####### ###### ####### ####### ### # # ####### ###### ####### # # # # # # ## # # # # # # # # # # # # # # # # # # # # ##### ###### ##### ##### # # # # # ###### # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # ####### ####### ### # # # # # ####### ##### ###### ### # # ##### ###### ###### # # ###### ##### # # # # ## # # # # # ## # # # # # # # # # # # # # # # # # # # # # # # # # # # #### ###### # # # #### # # # # # # # # # # # # # # # # # # # # # # ## # # # # # ## # # # ###### ### # # # ###### # # # # ###### # Date: Monday, September 27, 1993 Time: 6:30 PM Place: Chambers St. (bet. Centre St. and Broadway) in Manhattan The Society for Electronic Access (SEA), a New York metro area group focusing on electronic civil liberties and access issues will be holding an "Introduction the Internet" event. Topics that will be covered: + What is the Internet? + Electronic mail + Usenet Newsgroups + Using the Internet for research + Interactive real-time communications (IRC, talk, MUDs) using the Internet + What do you need to get connected? Our speakers will include Clay Irving, who is a Unix systems analyst and captain of the winning Team.Panix Internet Hunt crew; Karen Schneider, a public librarian and Internet trainer; Shabbir Safdar, an expert at computer games and interactive services; and Joe King, a publisher and the producer of the award-winning Personal Computer Show. In addition, several Internet-access providers in the 212/718 area will be present to tell you about their systems including rates, features, and how you can sign up. Refreshments will be served. RSVP..........RSVP...........RSVP..........RSVP..........RSVP The event is free, but *reservations are required* to attend. To make a reservation to attend, or for more information: leave voice-mail at (212) 592-3801 or send E-mail to gab at sea.org. For additional information about the SEA (including the time and place of the next SEA meeting), call via modem (212) 787-3100 and enter "sea-info" at the "login: " prompt, or send E-mail to "sea-info at sea.org" (you will receive an automatic reply); or you may leave voice mail request at (212) 592-3801. ------- End of Forwarded Message From newsham at wiliki.eng.hawaii.edu Sat Sep 18 01:15:22 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Sat, 18 Sep 93 01:15:22 PDT Subject: reporter seeking interview subjects In-Reply-To: <93Sep17.230857pdt.14382-4@well.sf.ca.us> Message-ID: <9309180811.AA21373@toad.com> > > Hi, my name is Matt Binder. Please help me... > I'm a radio reporter in the SF Bay area working on a series > of pieces about invasions of privacy in the computer age. I'm > looking for interesting "case studies" that I can use to horrify ^^^^^^^^ > my listeners out of their complacency. My most immediate need is ^^^^^^^^^^^^^^ > to find someone whose medical records were used (perused!) > improperly, and/or whose records were incorrect and resulted in > the denial of insurance, employment, loans, adoptions, etc. But [...] Just what I love from the media, using sensationalism to convey a preconceived idea instead of looking at the facts and reporting it. Does it matter that he is reporting on our side and not the other side? From XXCLARK at indst.indstate.edu Sat Sep 18 01:16:21 1993 From: XXCLARK at indst.indstate.edu (XXCLARK at indst.indstate.edu) Date: Sat, 18 Sep 93 01:16:21 PDT Subject: Escrow what ain't Message-ID: <9309180813.AA21395@toad.com> Extract from EFFector Online Volume 6 No. 1 "... The briefers admitted that the proposed system is not really an escrow. The agencies holding the key components will not have any duties or responsibilities to the Clipper users. The escrows' obligation will be to the government, and they will be liable to Clipper users only under the Bivens doctrine, where any failure must be shown to be wilful. ..." If it isn't really an "escrow", why do we continue to use the term? If keys are, in effect, surrendered before the fact, why not call it the "key surrender system" when we write or speak about this miasma? Or any other term more nearly accurate than what it is not... Haven't seen a single post promoting tax evasion all day. How curious. --------------------------------------------------------------------- internet : xxclark at indst.indstate.edu Vanilla BITNET: XXCLARK at INDST We're all Bozos on this bus... ---------------------------------------------------------------------  From newsham at wiliki.eng.hawaii.edu Sat Sep 18 01:20:22 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Sat, 18 Sep 93 01:20:22 PDT Subject: Crypto crackdown - this is it! Message-ID: <9309180820.AA21475@toad.com> Anon Said: > Code we need now! > > Windows NT, OS/2, and UNIX implementations of PGP, set up as a > server so that any application can access PGP primitives. This > would establish PGP as a standard encryption server outside the US. > People use what is easy, so make it easy. I would love to see this happen. The programs I have written (Circ and link) are currently using an implementation of RSA I grabbed off of the ghost site in italy. It is slow and the interface is poor. I would love to have a library of routines that will use PGP key files, use PGP random number generation etc. It would also be nice if this library allowed access to the math primatives as well, for implementing other schemes not in the library like DH (which maybe should be part of the library). Alls that needs be done is to rip out all the crypto routines, the random number routines and the key management routines and placing them in seperate modules. PGP could be rewritten with this new structure which would probably make it alot easier to manage and find bugs in (due to modularity). This would also ease recofinguring PGP to do other encryptions (like triple DES). The PGP command interface would just be a front end, and graphical front ends could access internals directly instead of hacking around the normal PGP front end. Is this something we could see happen? What do PGP people have to say about it? ... From mdiehl at triton.unm.edu Sat Sep 18 01:49:34 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sat, 18 Sep 93 01:49:34 PDT Subject: To: an5877@anon.penet.fi Message-ID: <9309180846.AA21442@triton.unm.edu> Sorry folks. This person anonymously sent me a message to which he expects a reply. But it is impossible for me to reply to this person anonymously since he would be able to place my anonymous Id with my real Id. I know I should learn how to "bounce" anonymous messages, but there seems to be a lack of standardization in this area which I don't want to deal with at the moment. Sorry for the bandwidth. -----BEGIN PGP MESSAGE----- Version: 2.2 hDwC8VlOkFb8HfkBAYCgq9GJ1tSQXsX5Pm5pGrvFfjJPaIRlsYcLdotqAUuSx6jj Rgl3GZfgp8WRRigwd6qmAAAEmyQ6+Ci6MqT5oSmmXNUJ3rR/cguMWRHDt1TOJlae ck6ezF0MZZlQCWp4Lvh7IhWNZckT9pQ4VWHsWqp5jgeWzYaRbspVfEWnZXVvEAvT 9qZVgNJn7ZGlrmXjkpLTMj+/bk516lLAuVCpGj1TaiIRPTt7YEKgJIYY5FjNdvc5 kLkab5GJcRaNOLG8VjVlSyxRg+sbce1eUEgNaIJtg0VvR2dy9BlPyh3xbBgko3C5 3DZ9TIpM3dtHUueOCm16BRITEkzBvHOYgL+xcj4RVcWrkkxI/hiEi12u1SthDQHK CVmvYcsnt5XGgp27dTPprS1i6COPIHtufH7l9/GIbBrOfn4+whegAl0TT72dL2An on62k+RMP2uPFkbAMNPGtMuWZW0ibpoqx/Wz5njsV8ubPVXDXayiXl0WSGBst/DV dQ56iqmV2tUI5ZDe09ARpnkj61mdnjvlBvFYaoRo6SCI2iLg7m6VsUm6XzNYBzG0 KNvpsd0SLFqz98wrSYIK9RqFrvgNKklsliGwciDwg7AJBYIUxxqrmSvRLtZ7eucm 5+Qc5uMPbPp6UohewDp20zwLz6Jjxff7APZOONKn58xKj+bpbKJb2giuohcI+ZzU EJMGis+dZQtcUPHonf6GQ65ly3HDDcDu5nAz9qZOkLASEZ0zRJjgOXprC6bwyiYF p1tXZCIAJPlEeT6uAejMEhBGeUxmbzd0mgGP+Zft0ITMDESeJS/Z3dtW16OcI1+k i77lMw6cNxtLjy5BDgjGaMUhQy7fH9+Xu7csuhoaTPGn+ljSyfxYyV1BwCdYW0h6 lhR3lblqAzSjQrEFQIm9GOn5rHM2iUh0cCPisc0ZKDHsBt6ay4gB5B+MkbO3MPj9 9QtIAtfzjBbJXUh+/jZgKD6lgix3FLoGLt7yYOcxZ4FIcviEW4/5gKoieIy6DPtk WN9L8bSjodnMtKBNFx/H4nUL5HAFyB9WV5PTD3RjgBIZ9p0CNn9TOUkplYQ1uOHa Amfw/z1IIa3Db5YIxEJinRbwfjWudG0jwaaa1Bj6xn/OxY4guw1k3WJ17PrTP61b DDonzptjqRY9UHcvnnrolIaESFYT5Cb2dUZk5yXEcjOsG90lKkIJ+pueGOYY3ZDh CuCONfnAT7ph+vjtYHA0w+s5q6I5rGOI3Pwa7eRi2N4U/bV/O8k207i2NFeqJZ/l aQMs0eFk31mdz4NFsEctX7DZ7bNo5xhQH4ojCDcUhP2GFkghMr6683NGsH90qjZJ 52h23g4ZXCOONDJLkR4kPzcWF+CzfgFPAYzDzjSYPa02RAlapOBV41HkNNJ69vae X5cypQ/HyCIvos6ayNZHdPI+y+13U1GBdwu5O1AwaONqz/B0Q2H3jriSHzqAdDZK 0N8qvutz0PouNBlcMHpTUxon7VTR10oSRV/JieQqYVJ+nlT8WBj+mVxsU2ZGD2mH peg8ZpJWP3X7tW7518BQRH95fLcEoX4Fcnb509hGv9+F+JTH30eG6H5R1aDD6ZXT tfgz05vIrelBI8XYJuZtmid1cxQzXBwML9r9skgF7Scp8q+1pDeAUz4yAp/Oyw== From mdiehl at triton.unm.edu Sat Sep 18 01:55:23 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sat, 18 Sep 93 01:55:23 PDT Subject: To: an5877@anon.penet.fi, again. Message-ID: <9309180852.AA21489@triton.unm.edu> Sorry folks. This person anonymously sent me a message to which he expects a reply. But it is impossible for me to reply to this person anonymously since he would be able to place my anonymous Id with my real Id. I know I should learn how to "bounce" anonymous messages, but there seems to be a lack of standardization in this area which I don't want to deal with at the moment. Sorry for the bandwidth. -----BEGIN PGP MESSAGE----- Version: 2.2 hDwC8VlOkFb8HfkBAYCgq9GJ1tSQXsX5Pm5pGrvFfjJPaIRlsYcLdotqAUuSx6jj Rgl3GZfgp8WRRigwd6qmAAAEmyQ6+Ci6MqT5oSmmXNUJ3rR/cguMWRHDt1TOJlae ck6ezF0MZZlQCWp4Lvh7IhWNZckT9pQ4VWHsWqp5jgeWzYaRbspVfEWnZXVvEAvT 9qZVgNJn7ZGlrmXjkpLTMj+/bk516lLAuVCpGj1TaiIRPTt7YEKgJIYY5FjNdvc5 kLkab5GJcRaNOLG8VjVlSyxRg+sbce1eUEgNaIJtg0VvR2dy9BlPyh3xbBgko3C5 3DZ9TIpM3dtHUueOCm16BRITEkzBvHOYgL+xcj4RVcWrkkxI/hiEi12u1SthDQHK CVmvYcsnt5XGgp27dTPprS1i6COPIHtufH7l9/GIbBrOfn4+whegAl0TT72dL2An on62k+RMP2uPFkbAMNPGtMuWZW0ibpoqx/Wz5njsV8ubPVXDXayiXl0WSGBst/DV dQ56iqmV2tUI5ZDe09ARpnkj61mdnjvlBvFYaoRo6SCI2iLg7m6VsUm6XzNYBzG0 KNvpsd0SLFqz98wrSYIK9RqFrvgNKklsliGwciDwg7AJBYIUxxqrmSvRLtZ7eucm 5+Qc5uMPbPp6UohewDp20zwLz6Jjxff7APZOONKn58xKj+bpbKJb2giuohcI+ZzU EJMGis+dZQtcUPHonf6GQ65ly3HDDcDu5nAz9qZOkLASEZ0zRJjgOXprC6bwyiYF p1tXZCIAJPlEeT6uAejMEhBGeUxmbzd0mgGP+Zft0ITMDESeJS/Z3dtW16OcI1+k i77lMw6cNxtLjy5BDgjGaMUhQy7fH9+Xu7csuhoaTPGn+ljSyfxYyV1BwCdYW0h6 lhR3lblqAzSjQrEFQIm9GOn5rHM2iUh0cCPisc0ZKDHsBt6ay4gB5B+MkbO3MPj9 9QtIAtfzjBbJXUh+/jZgKD6lgix3FLoGLt7yYOcxZ4FIcviEW4/5gKoieIy6DPtk WN9L8bSjodnMtKBNFx/H4nUL5HAFyB9WV5PTD3RjgBIZ9p0CNn9TOUkplYQ1uOHa Amfw/z1IIa3Db5YIxEJinRbwfjWudG0jwaaa1Bj6xn/OxY4guw1k3WJ17PrTP61b DDonzptjqRY9UHcvnnrolIaESFYT5Cb2dUZk5yXEcjOsG90lKkIJ+pueGOYY3ZDh CuCONfnAT7ph+vjtYHA0w+s5q6I5rGOI3Pwa7eRi2N4U/bV/O8k207i2NFeqJZ/l aQMs0eFk31mdz4NFsEctX7DZ7bNo5xhQH4ojCDcUhP2GFkghMr6683NGsH90qjZJ 52h23g4ZXCOONDJLkR4kPzcWF+CzfgFPAYzDzjSYPa02RAlapOBV41HkNNJ69vae X5cypQ/HyCIvos6ayNZHdPI+y+13U1GBdwu5O1AwaONqz/B0Q2H3jriSHzqAdDZK 0N8qvutz0PouNBlcMHpTUxon7VTR10oSRV/JieQqYVJ+nlT8WBj+mVxsU2ZGD2mH peg8ZpJWP3X7tW7518BQRH95fLcEoX4Fcnb509hGv9+F+JTH30eG6H5R1aDD6ZXT tfgz05vIrelBI8XYJuZtmid1cxQzXBwML9r9skgF7Scp8q+1pDeAUz4yAp/Oyw== =tHfY -----END PGP MESSAGE----- From frissell at panix.com Sat Sep 18 05:35:27 1993 From: frissell at panix.com (Duncan Frissell) Date: Sat, 18 Sep 93 05:35:27 PDT Subject: Crypto crackdown - this i Message-ID: <199309181233.AA23795@panix.com> R >They may not be able to prosecute you based on illegal evidence, but R >they can take everything you own and keep it until you are broke R >and homeless. Unless you are judgement proof. For a small fee, I am always willing to teach people how to become judgment proof (which is *not* the same thing as poor). Duncan Frissell ::Exclude *.gov --- WinQwk 2.0b#0 From collins at newton.apple.com Sat Sep 18 06:06:53 1993 From: collins at newton.apple.com (Scott Collins) Date: Sat, 18 Sep 93 06:06:53 PDT Subject: anon.penet.fi Message-ID: <9309181302.AA09384@newton.apple.com> >What is your policy on chaining to anon.penet.fi? Hmmm, it would be bad to post to anon.penet.fi through a remailer, as the anon id assigned by penet would be associated with the remailer, _not_ with you. Therefore, people who responded to the message would actually be sending mail to the operator of the remailer that was the hop into penet. Not to mention the fact if the remailer account were also a personal account, and the operator was a client of penet, that his anon id could be compromised in this way (if he was foolish enough not to have a password). Therefore, it seems reasonable that remailers should refuse to mail into penet, unless and until a non-anonymous reply to anonymous mail facility becomes available there. To the penet knowledgeable: is my understanding correct? Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From hughes at ah.com Sat Sep 18 09:36:57 1993 From: hughes at ah.com (Eric Hughes) Date: Sat, 18 Sep 93 09:36:57 PDT Subject: anon.penet.fi In-Reply-To: <9309181302.AA09384@newton.apple.com> Message-ID: <9309181636.AA21944@ah.com> >Therefore, it seems reasonable that remailers should refuse to mail into >penet, unless and until a non-anonymous reply to anonymous mail facility >becomes available there. There is already non-pseudonymizing reply available for pseudonymous mail. It periodically comes up on the list, and is periodically corrected. The irony of the situation is that the solution was invented on this list a few months ago. Solution: if you send to na12345 at anon.penet.fi, then your mail won't be pseudonymized; if you send to an12345 at anon.penet.fi, then your mail will be pseudonymized. an = anonymous na = not anonymous Eric From ebrandt at jarthur.Claremont.EDU Sat Sep 18 10:45:30 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Sat, 18 Sep 93 10:45:30 PDT Subject: anon.penet.fi In-Reply-To: <9309181302.AA09384@newton.apple.com> Message-ID: <9309181743.AA28411@toad.com> > To the penet knowledgeable: is my understanding correct? It depends on the remailer. Mine, for example, sends messages with a From: line of "eli-remailer at jarthur...", and some others do similar things. I believe this address already has a penet address. I have no problems with chaining from here to penet, though I suggest making it clear that 1) attempts to reply will result in an ugly bounce, and 2) the persona using the chained ID can be identified only by continuity of digital signature. IMHO, this is useful way of bumping the anonymity level up a notch over posting directly with penet -- an attacker needs both penet's lists and a bunch of sendmail logs. Others, including Julf, may feel differently, as this provides some degree of "hit-and-run anonymity". PGP 2 key by finger or e-mail Eli ebrandt at jarthur.claremont.edu From rees at cs.bu.edu Sat Sep 18 11:31:31 1993 From: rees at cs.bu.edu (David Rees) Date: Sat, 18 Sep 93 11:31:31 PDT Subject: Does this seem illegal to you? Message-ID: <9309181829.AA17045@csa.bu.edu> Hi. Just picked this up from alt.dcom.telecom. Doesn't it seem like an illegal invasion of privacy to do something like this? Or maybe I just don't have the whole picture. Anyway, here it is: >GOING FROM A TO B. You're in your car. You're at A. You want to go >to B. You have no idea where B is. So you go to a Sprint payphone >and use its TeleMap service, give the telephone number of your >destination, and receive precise directions. (Tampa Tribune 9/12/93 >B&F 5) Of course, if you have a wrong phone number, that may be a >problem. You may go to C, wherever that is. -Dave (rees at cs.bu.edu) From rarachel at ishara.poly.edu Sat Sep 18 11:50:31 1993 From: rarachel at ishara.poly.edu (A1 ray arachelian (library)) Date: Sat, 18 Sep 93 11:50:31 PDT Subject: Does this seem illegal to you? In-Reply-To: <9309181829.AA17045@csa.bu.edu> Message-ID: <9309181446.AA06998@ishara.poly.edu> Actually you don't have to give the exact phone number. In most dense areas the phone number prefix should be enough to get you in the proximity of where you want to go. Then when you get there, find a pay phone call up the person you want to reach and ask for directions from your current location. Of course, it becomes an invasion of privacy if you use the guy's real number and he hasn't invited you! From mnemonic at eff.org Sat Sep 18 11:55:31 1993 From: mnemonic at eff.org (Mike Godwin) Date: Sat, 18 Sep 93 11:55:31 PDT Subject: KEY ESCROW PROCEDURES In-Reply-To: <9309171855.AA00716@ellisun.sw.stratus.com> Message-ID: <199309181851.AA05084@eff.org> Carl writes: > Meanwhile, where is the proof that the key being requested corresponds to > a person on whom a wiretap has been ordered? The authorized key request will normally occur after law-enforcement officials have snagged the chip serial number from the LEAF (law-enforcement field) of the signal they captured with an authorized wiretap. --Mike From tcmay at netcom.com Sat Sep 18 12:00:31 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 18 Sep 93 12:00:31 PDT Subject: Does this seem illegal to you? In-Reply-To: <9309181829.AA17045@csa.bu.edu> Message-ID: <9309181859.AA04438@netcom5.netcom.com> > Hi. Just picked this up from alt.dcom.telecom. Doesn't it seem like > an illegal invasion of privacy to do something like this? Or maybe > I just don't have the whole picture. Anyway, here it is: > > > >GOING FROM A TO B. You're in your car. You're at A. You want to go > >to B. You have no idea where B is. So you go to a Sprint payphone > >and use its TeleMap service, give the telephone number of your > >destination, and receive precise directions. (Tampa Tribune 9/12/93 > >B&F 5) Of course, if you have a wrong phone number, that may be a > >problem. You may go to C, wherever that is. > > -Dave (rees at cs.bu.edu) No. Phone area codes and prefixes already are "public knowledge" pointers to neighborhoods...I don't know if the last 4 digits are, but probably. The "right to privacy" debate is often clouded, in my opinion, by confusing ideas of what is and isn't mine, what others are "allowed" to type into their computers or write in their address books, etc. In a free sociey, if I come across a piece of information, I can write it down, sell it, etc. In a true free market, some phone companies might offer more privacy features. Credit card companies know they will lose their card subscribers if they go "too far" (a market issue) in disclosing credit records to third parties. This is quite analogous to your scenario described here. Your friend at "B" needs to consider other options, such as using remote message services for his phone needs, switches of the sort George Gleason and others have talked about, and so on. (I don't think merely having an unlisted number is enough, though.) Market solutions generally are better than coercive laws. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From tcmay at netcom.com Sat Sep 18 12:11:32 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 18 Sep 93 12:11:32 PDT Subject: Does this seem illegal to you? In-Reply-To: <9309181446.AA06998@ishara.poly.edu> Message-ID: <9309181909.AA05282@netcom5.netcom.com> A1 Ray A. writes: > Actually you don't have to give the exact phone number. In most dense areas > the phone number prefix should be enough to get you in the proximity of > where you want to go. Then when you get there, find a pay phone call up > the person you want to reach and ask for directions from your current > location. > > Of course, it becomes an invasion of privacy if you use the guy's real > number and he hasn't invited you! Nonsense! (Not to sound like David Sternlight, or anything.) This is what doors and locks are all about: to keep out folks who come to our houses uninvited. Anyone is free to look up the publically available information (or privately available, if they get access to it...another matter) and go to a physical location. My house, your house, Dorothy Denning's house, whatever. Trespass is another matter entirely. So is "stalking" (though I fear the concept is being increasingly overused and may infringe other basic rights). -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From marc at MIT.EDU Sat Sep 18 12:59:38 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Sat, 18 Sep 93 12:59:38 PDT Subject: WE'RE UNDER ATTACK In-Reply-To: <9309180534.AA27719@longs.lance.colostate.edu> Message-ID: <9309181957.AA24648@deathtongue.MIT.EDU> >> However, my initial reaction is that the subpoenas seem to be >> OVERBROAD. They could be argued by a competent attorney, given the >> simultaneous targeting of two completely disparate cryptographic >> enterprises, to represent an OUTRAGEOUS FISHING EXPEDITION. Isn't there >> a way to contest a subpoena in court? these legal mechanisms need to be >> employed IMMEDIATELY. Lance, calm down. PRZ and ViaCrypt have their own lawyers. Mike Godwin in contact with PRZ, and we all saw Shari's message from the exec dir of the EFF, so they are involved. We are technologists, not lawyers. For now, I'll let the lawyers formulate the response to this attack. They know the game better than you or I do. When my help is requested, they'll get it. For now, we need to continue doing what we've been doing: distributing technology, experimenting with remailers, and increasing awareness. Not taking the government on with no tools, no experience, and no clue. Marc From gnu Sat Sep 18 14:15:33 1993 From: gnu (John Gilmore) Date: Sat, 18 Sep 93 14:15:33 PDT Subject: CRADA In-Reply-To: <9309162151.AA18816@fiber.sprintlink.net> Message-ID: <9309182113.AA01102@toad.com> You can get large parts of the Federal Register online on the Internet from gopher.internet.com, using the gopher protocol. Unfortunately, the people who run the service claim to not permit republication. I tried to sign up as their real customer, but this bogosity got in the way. Why pay money to these people for access to public domain info that you then can't use? Here is as much as you can get without being a subscriber:
Date="08/24/93" Citation="58 FR 44662" Group="NONE" Type="NOTICE" Department="DEPARTMENT OF COMMERCE" Agency="NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST), COMMERCE" Subject="Opportunity To Join a Cooperative Research and Development Consortium To Develop Secure Software Encryption With Integrated Cryptographic Key Escrowing Techniques"
------------------------------------------------------------ National Institute of Standards and Technology [Docket No. 930789-3189] Opportunity To Join a Cooperative Research and Development Consortium To Develop Secure Software Encryption With Integrated Cryptographic Key Escrowing Techniques AGENCY: National Institute of Standards and Technology (NIST), Commerce. ACTION: Notice of opportunity to join a cooperative research and development consortium.
------------------------------------------------------------ National Institute of Standards and Technology [Docket No. 930789-3189] Opportunity To Join a Cooperative Research and Development Consortium To Develop Secure Software Encryption With Integrated Cryptographic Key Escrowing Techniques AGENCY: National Institute of Standards and Technology (NIST), Commerce. ACTION: Notice of opportunity to join a cooperative research and development consortium. .. ------------------------------------------------------------ SUMMARY: The National Institute of Standards and Technology (NIST) seeks industrial and academic parties interested in entering into a cooperative research consortium on the development of new technology for secure software encryption with integrated cryptographic key escrowing techniques. The program will be undertaken within the scope and confines of The Federal Technology Transfer Act of 1986 (15 U.S.C. 3710a), which provides federal laboratories including NIST, with the authority to enter into cooperative research agreements with qualified parties. Under ----------------------------------------------------------------------------- Full access to this file is restricted to subscribers only. To become a subscriber to this service, please read the information provided at the top level of the Counterpoint Publishing Internet Federal Register Gopher. Please send any and all comments to 'fedreg at internet.com' -- Thanks. ---------------------------------------------------------------------------- From klbarrus at owlnet.rice.edu Sat Sep 18 15:19:39 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sat, 18 Sep 93 15:19:39 PDT Subject: Cypherpunks & GOPHER Message-ID: <9309182215.AA01627@flammulated.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, I'd like to announce the Cypherpunks Gopher Site - dedicated to putting up information for access, and meant to be a list resource. I'm running the gopher site at chaos.bsu.edu, thanks to Chael Hall, who graciously donated an account to me to be used for any and all projects. This is something I've been wanting to do for quite some time but have been unable to. But now I have an account and a sympathetic system administrator...! Chaos.bsu.edu is 147.226.53.28, and the port is 2000. That is port 2000 and not the usual port 70 - when Chael and I have some more time I will ask him to perform the various and necessary incantations (chown) and I'll move it to the usual place. So: try 'gopher 147.226.53.28 2000' and browse around. The site doesn't have much stuff yet... I plan to add more information sometime in the future. Currently the site consists of some old back articles from the list, some faq's, etc. I plan to sift for more stuff, especially Clipper related, and add it in. In posting back articles, I have attempted to give proper credit at the BOTTOM of the article, unless a signature already appears. I figure that posts sent to the list are meant to be seen, but if the original author of something wants is taken off, mail me. If lots of people want stuff removed, I'll probably just solve the whole problem with 'rm -rf ~/gopher-data' I will sift through my archives of the list, incomplete as they are, and add files when I have time. Direct questions to: klbarrus at owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJuILIOA7OpLWtYzAQFcjgP+K2MOSFKX1M+Y903DKTSdEAOoVdLSl/N4 /1eukQ5B8f09Rw6zU2AjpxcGa4uQcKQ2brNGXzEG4n3+SK5WcEq5t5+oLQ679jrM /aWcWLJWT9sNoiJPQt0li26BWhKhFQSanqbDr+MZ+5JRWu5FBIFgM4cOe0gwK3p1 5S9NokdBBfE= =gMFB -----END PGP SIGNATURE----- From ld231782 at longs.lance.colostate.edu Sat Sep 18 16:21:37 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sat, 18 Sep 93 16:21:37 PDT Subject: analysis: attack PKP driven? significance of June 1, 1991 Message-ID: <9309182319.AA10597@longs.lance.colostate.edu> June 1 1991 is the date that both the MobyCrypt and PRZ subpoenas reach to. What is the significance? the early indication: this is the date of the 'official' release of PGP 1.0. C'punks: upon further reflection this dual assault seems to be ostensibly PKP motivated/driven. It is possible the prior NSA harassment of Moby Crypto was just a shocking coincidence. As reported on this list by D. Barnes , NSA had been prodding Austin Code Works (Maria Nekam) over DES export many months prior to this date. Does ACW currently deal with cryptographic software? how is it NSA was bugging them *months* ago? did Grady Ward indicate that long ago publicly (Usenet) his intent to use them as a publisher? This reminds me of stories of censorship of Yardley from Kahn (The Codebreakers) and censorship of Kahn reported by Bamford (Puzzle Palace) -- somehow, the NSA just *knows* when publishers are coming out with information related to cryptography or the NSA (I wonder how? ). We need more information: - how long has the NSA been harassing Austin Code Works? - does Austin Code works currently deal with cryptographic code? - or is this all entirely due to Grady Ward's Moby Crypto project? - was NSA complaining about (1) DES or (2) something else? export? - how did NSA find out that Austin Code Works was involved with Moby Crypto? On the other hand, the evidence that this is primarily PKP motivated seems to be in the primarily *PGP* and *RSA* oriented aspect of the subpoena queries. My current pet theory is that PKP has seen Grady Ward talking about his cryptographic recipe book on newsgroups (Bidzos has been known to track and respond on sci.crypt) and lumped him in an accusation & complaint, filed with the customs office, that ITAR laws on cryptographic export of cryptographic algorithms have been violated -- hence the investigation by a customs agency, the PGP 1.0 release date, the Viacrypt timing, etc. Maybe PKP got the impression that G. Ward was including RSA Source code -- has he said so on Usenet? -- this would be very inflammatory for them. RSA has virtually *no* international protection, all the patents only apply in the U.S. Finally, there is some other peripheral evidence regarding PRZ in this line I'm not really at liberty to state. that's the current 'conventional wisdom', anyway, subject to nanosecond fluctuation. Point: I think this new episode will without any doubt resolve whose side PKP is on. They've successfully remained in the shadows, like the NSA, until now, but like the NSA is discovering, continuing this will be impossible... Another point: remember the amazing scrutiny given to the E911 document, its *exact* and *precise* path of geneological distribution and leaking in the court proceedings and subsequent literature (e.g. B. Sterling, Hacker Crackdown)? I suspect, very soon, the same laserlike magnifying-glass pinpoint attention is going to be focused on exactly *who* first made PGP available *internationally* outside the U.S. -- anyone who can come forward with information on this (it all appears to have transpired in 1991) will be momentously affected. I don't know if this can be traced as effectively, however. The tracks are bit cool, and some people may not want to exactly *announce* this information. From pcw at access.digex.net Sat Sep 18 16:31:36 1993 From: pcw at access.digex.net (Peter Wayner) Date: Sat, 18 Sep 93 16:31:36 PDT Subject: CRADA robber Message-ID: <199309182329.AA09416@access.digex.net> I spoke with Dennis Branstad at length a couple of days ago about just what it means to get involved with NIST in the Software Key Escrow CRADA. It was a nice conversation and he told me that he personally didn't seem to think that a workable system would emerge, but that others felt differently. Plus the push for a software solution meant that the agency felt that it should at least explore the topic before dismissing it. The system seems to be quite commercial. A group of people and companies petition NIST to get involved with the project and then a group forms out of a subset of these applications. Usually this is the team that is most likely to get the job done. For that reason, people need to bring something to the project be it expertise, capital or whatever. At the end, the group owns the intellectual property rights to what is discovered. This may be something patentable and it could be worth some money. I don't know how likely this is, but it seems possible. In fact, it is probably the reason many of the participants are willing to enter into the project. The role of NIST is both gatekeeper and fascilitator. They get everyone together and occasionally push things along. In this case, they'll also offer some technical assistance which will include feedback from the NSA. Dennis Branstad said that this would most likely take the form of Siskel and Ebert-like ratings of the systems proposed. The NSA would suggest, "Yes" or "No" but they probably wouldn't go into details. This is because the procedure would be unclassified and the NSA usually won't relate technical details without classifying them. I've read the Federal Register announcement and it really isn't that interesting. There are only two columns of text and most of it is devoted to the formatting and standard operating procedures. This note contains much more information than the announcement itself. This leaves me with several questions: * Is this process intended to fail? Will NIST just keep saying that software isn't good enough and that way they'll be able to answer the criticism that hardware is too expensive? * How selective is the group formation process? Are people really out for money? * There are supposedly several other groups interested in participating. Who are they? Is it RSA and PKP? * Is a software process really that much more insecure than a hardware based approach? Sure, it is easier to tamper with software, but given that we can always tamper with the software shell around the Clipper hardware, it shouldn't be _that_ much different. -Peter From klbarrus at owlnet.rice.edu Sat Sep 18 16:39:39 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sat, 18 Sep 93 16:39:39 PDT Subject: gopher site Message-ID: <9309182336.AA08747@flammulated.owlnet.rice.edu> I forgot to mention I will take suggestions for what to place at the gopher site - for example, what 10 or so Clipper articles from the archives at soda.berkeley.edu MUST be available? I haven't read them all and won't have the time for the forseeable future to do so. Pointers and suggestions to other docs and files are welcome. Should I put stuff like appropriate rfc's and documentation (pgp and ripem, etc.) or not? All of this is subject to disk space and it may be I'll give preference to shorter items. I am leaning towards including the rfc's for PEM and the two for Rivest's MD4/MD5 hash algorithms. -- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From collins at newton.apple.com Sat Sep 18 18:05:36 1993 From: collins at newton.apple.com (Scott Collins) Date: Sat, 18 Sep 93 18:05:36 PDT Subject: anon.penet.fi Message-ID: <9309190057.AA01078@newton.apple.com> >Solution: if you send to na12345 at anon.penet.fi, then your mail won't >be pseudonymized; if you send to an12345 at anon.penet.fi, then your mail >will be pseudonymized. Good. Therefore, remailers should translate 'Request-Remailing-To:' addresses like this: if ( /an(\d+ at anon.penet.fi)/ ) { s//na$1/; } That is unless there are fifty other ways to say @anon.penet.fi. In which case, I would need to know the fifty ways. Is this reasonable? Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From an12070 at anon.penet.fi Sat Sep 18 18:19:40 1993 From: an12070 at anon.penet.fi (S. Boxx) Date: Sat, 18 Sep 93 18:19:40 PDT Subject: NIST proposes software key escrow development Message-ID: <9309190114.AA08060@anon.penet.fi> Peter Wayner writes of the NIST announcements to develop software-based key escrow. I think it would be utmost folly for software developers to work with the NIST and NSA on this or invest any time or capital. The fundamental requirement for NSA approval is the implementation of Skipjack in *software* in such a way that the algorithm is *protected* like it is in the booby trapped Clipper chips-- that is, impossible to deduce. But this appears to be complete *fantasy*. Any such system must rely on some kind of a hardware approach. But then we're back to where we've started -- Clipper and Capstone. Only the NSA has enough inbred, insular self-delusion to propose that 'secure' software is even a *possibility*. These companies could better spend their time proving that Fermat's Last Theorem is FALSE. (Hey Cypherpunks! I KNOW! what we need is a Secure Clipper Encryption Server that handles encryption via Email! Let's get the NSA to run it! Then it would *really* be secure! ) Furthermore, anyone who submits to this development is giving the NSA valuable (free?) development time for the purpose of, fundamentally, a KEY ESCROW SYSTEM. Now, perhaps someone can explain to me why a software system for depriving us of our rights is superior to one in hardware? Doesn't anyone have the faint glimmer of the idea that NSA, the *premier* cryptographic agency in the *world*, with unsurpassed technological and engineering prowess in the area, would have already *figured out* how to do this if it was *at all* feasible? Personally, I think this stinks putridly of an NSA decoy to simply claim or suggest that they're responsive to alternative solutions. This is nothing but a *cruel mirage* in a *barren desert*. >At the end, the group owns the intellectual property rights to >what is discovered. This may be something patentable and it could >be worth some money. I don't know how likely this is, but it >seems possible. In fact, it is probably the reason many of the >participants are willing to enter into the project. yes, that's *exactly* what we need -- another software patent. But this is just a meaningless dangling carrot. (They damn well *better* have rights to whatever they develop under private capital.) >The role of NIST is both gatekeeper and fascilitator. They get >everyone together and occasionally push things along. In this >case, they'll also offer some technical assistance which will >include feedback from the NSA. Dennis Branstad said that this would >most likely take the form of Siskel and Ebert-like ratings of the >systems proposed. The NSA would suggest, "Yes" or "No" but they >probably wouldn't go into details. This is because the procedure >would be unclassified and the NSA usually won't relate technical >details without classifying them. Take a LOOK at what you've written, and ask if this project has ANY CHANCE of succeeding. The NIST is proposing that a lot of companies put in work into a key escrow system in software, that the NSA has ultimate overruling veto power with *no explanation* of negative answers. This all to come up with something that the NSA ultimately must *accept* under the whole point of the proposal. What's the POINT?! Yes, sign me up today to do DEVELOPMENT WORK for the NSA on a KEY ESCROW SYSTEM. Let's put in thousands of man-hours to come up with something as fundamentally feasible in principle as perpetual motion! All for the sheer joy of the thought the NSA *might* pat us on the back! how could this be anything but the most PRODUCTIVE and REWARDING experience?! A company would have to be INSANE to go with this as presented! >* Is this process intended to fail? Will NIST just keep saying that >software isn't good enough and that way they'll be able to answer >the criticism that hardware is too expensive? you mean the NSA -- and does that answer your question? >* How selective is the group formation process? Are people really >out for money? I think NIST would be overjoyed to hear that anyone outside of NSA consultants is interested. >* There are supposedly several other groups interested in participating. >Who are they? Is it RSA and PKP? RSA, PKP, RSADSI, Bidzos -- that makes at least four, right? the KGB would also like a secure software system. Sternlight & Denning would surely sign up. Just another dangling carrot -- or rather, an apple with a razor blade inside. >* Is a software process really that much more insecure than a hardware >based approach? Sure, it is easier to tamper with software, but given >that we can always tamper with the software shell around the Clipper >hardware, it shouldn't be _that_ much different. is an ASCII text file really that much more pliable than a silicon computer chip?! I'm trying to be gentle, but you simply don't seem to get it! the NSA wants a software implementation of Clipper that is TAMPERPROOF and INVISIBLE. This is like asking for a way to send locked lead safes through phone lines! it's based on a fundamentally *bizarre* premise! We *cannot* tamper with Skipjack in its present forms of use -- Clipper and Capstone -- they would not exist unless the NSA had the tamperproof technology. And the first rule of software is that it is 'TAMPERLADEN'! ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From doug at netcom.com Sat Sep 18 19:15:38 1993 From: doug at netcom.com (Doug Merritt) Date: Sat, 18 Sep 93 19:15:38 PDT Subject: NIST proposes software key escrow development Message-ID: <9309190211.AA17219@netcom.netcom.com> an12070 at anon.penet.fi said: >I think it would be utmost folly for software developers to work with the NIST >and NSA on this or invest any time or capital. Clearly this is true for cypherpunk sw developers, but others see an opportunity to make some bucks. >The fundamental >requirement for NSA approval is the implementation of Skipjack in >*software* in such a way that the algorithm is *protected* like it is in >the booby trapped Clipper chips-- that is, impossible to deduce. > >But this appears to be complete *fantasy*. Any such system must rely on >some kind of a hardware approach. Not necessarily. Zero knowledge proof techniques, for instance, can be applied to make source code as impenetrable as one wishes. This tends to carry a heavy runtime overhead, of course. And even hardware solutions can be reverse engineered. In fact, it's guaranteed to happen eventually. Triple layer metal interconnect chips can be selectively peeled via ion beam etching to reveal them to scanning tunneling electron microscope probing. Camouflage in the form of unnecessary functional units that mask actual operation can be uncovered by data flow analysis. Such a project would be extremely expensive...but someone will eventually do it. The Mafia or the KGB, for instance, if no one else. >Doesn't anyone have the faint glimmer of the idea that NSA, the *premier* >cryptographic agency in the *world*, with unsurpassed technological and >engineering prowess in the area, would have already *figured out* how to do >this if it was *at all* feasible? I think everyone assumes that the NSA is technologically several steps ahead of the game at all times, and clearly they have their own agenda. Some people just don't see their hidden agendas as threatening. C'est la vie. I think it makes for a very interesting chess game, myself. The NSA is attempting checkmate, but they're not strongly enough positioned to do so. In chess parlance, it's a bluff, but one with enough steel behind it to force a response, which gives them a minor but real tactical advantage. The obvious counter-response is to advance a pawn towards queening...which is already in progress. I'm reasonably happy with what the NSA appears to be doing in regard to foreign intelligence gathering; it's their domestic agenda that threatens the constitution. But that's in the nature of spook organizations. "Eternal vigilance is the price of liberty." Doug From khijol!erc at apple.com Sat Sep 18 20:15:39 1993 From: khijol!erc at apple.com (Ed Carp) Date: Sat, 18 Sep 93 20:15:39 PDT Subject: NIST proposes software key escrow development In-Reply-To: <9309190211.AA17219@netcom.netcom.com> Message-ID: > Not necessarily. Zero knowledge proof techniques, for instance, can be > applied to make source code as impenetrable as one wishes. This tends to > carry a heavy runtime overhead, of course. Could you go into more detail on this? Thanks! -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From strick at versant.com Sat Sep 18 20:16:39 1993 From: strick at versant.com (strick -- henry strickland) Date: Sat, 18 Sep 93 20:16:39 PDT Subject: gopher site In-Reply-To: <9309182336.AA08747@flammulated.owlnet.rice.edu> Message-ID: <9309190315.AA26187@versant.com> THUS SPAKE Karl Lui Barrus : # I forgot to mention I will take suggestions for what to place at the # gopher site - for example, what 10 or so Clipper articles from the # archives at soda.berkeley.edu MUST be available? I haven't read them # all and won't have the time for the forseeable future to do so. My archives of SURFPUNK are archived at "http://www.acns.nwu.edu/surfpunk/" via WWW (or XMosaic). In the past I've appropriated a lot of cypherpunk emails. You might look through there for ideas. # Pointers and suggestions to other docs and files are welcome. Should # I put stuff like appropriate rfc's and documentation (pgp and ripem, # etc.) or not? All of this is subject to disk space and it may be I'll # give preference to shorter items. I wonder if these are not already gophered somewhere. Then you can merely hyperlink to them. Perhaps Mark could run a gopher with his latest RIPEM docs for you, and others could do the same for their wares. (Just for the halibut I tried "gopher gopher.uu.net" and "gopher ftp.uu.net" but no dice. If you were using WWW instead of gopher, you could link "ftp://ftp.uu.net/inet/rfc/rfc1321".) There are probably other gopherdatahavens (and WWW webs) with cryptostuff that you could link to, en masse, in an "other gophers" section. BTW, I took a look, Karl, and I think your gopher is off to a good start. strick From tcmay at netcom.com Sat Sep 18 20:36:39 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 18 Sep 93 20:36:39 PDT Subject: Definition of "Zero Knowledge" In-Reply-To: Message-ID: <9309190335.AA22435@netcom5.netcom.com> > > Not necessarily. Zero knowledge proof techniques, for instance, can be > > applied to make source code as impenetrable as one wishes. This tends to > > carry a heavy runtime overhead, of course. > > Could you go into more detail on this? Thanks! > -- > Ed Carp, N7EKG erc at apple.com 510/659-9560 I didn't write the item above, but I'll add my comments anyway. Zero knowledge interactive proof systems are a critical part of modern crypto. Here's the brief summary from the Cypherpunks Glossary, available by anon. ftp at soda.berkeley.edu in pub/cypherpunks/misc as glossary.text.gz. *** zero knowledge proofs -- proofs in which no knowledge of the actual proof is conveyed. Peggy the Prover demonstrates to Sid the Skeptic that she is indeed in possession of some piece of knowledge without actually revealing any of that knowledge. This is useful for access to computers, because eavesdroppers or dishonest sysops cannot steal the knowledge given. Also called minimum disclosure proofs. Useful for proving possession of some property, or credential, such as age or voting status, without revealing personal information. By the way, this Glossary was distributed at the very first Cypherpunks meeting, a year ago. While never intended as an FAQ, it still may be of value to subscribers here. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From cme at ellisun.sw.stratus.com Sat Sep 18 21:15:39 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Sat, 18 Sep 93 21:15:39 PDT Subject: software key escrow ruse Message-ID: <9309190411.AA03947@ellisun.sw.stratus.com> Isn't it obvious? 1. People try to do key escrow in S/W (rather than refuse to play along with key registration) 2. By doing so, they lend apparent approval to the idea of registration. 3. The S/W effort fails, of course. 4. Conclusion: S/W encryption is no good and must be abandoned because you can't do key registration that way. It is important not to entertain the notion of registration, even as an academic exercise, lest the effort be used to claim that some reasonable person believes key registration is OK. - Carl From khijol!erc at apple.com Sat Sep 18 21:20:38 1993 From: khijol!erc at apple.com (Ed Carp) Date: Sat, 18 Sep 93 21:20:38 PDT Subject: Definition of "Zero Knowledge" In-Reply-To: <9309190335.AA22435@netcom5.netcom.com> Message-ID: > > > Not necessarily. Zero knowledge proof techniques, for instance, can be > > > applied to make source code as impenetrable as one wishes. This tends to > > > carry a heavy runtime overhead, of course. > > > > Could you go into more detail on this? Thanks! > > -- > > Ed Carp, N7EKG erc at apple.com 510/659-9560 > > I didn't write the item above, but I'll add my comments anyway. > > Zero knowledge interactive proof systems are a critical part of modern > crypto. Here's the brief summary from the Cypherpunks Glossary, > available by anon. ftp at soda.berkeley.edu in pub/cypherpunks/misc as > glossary.text.gz. Thanks for the definition (but I knew that, anyway). Sorru I wasn't clear - what I was looking for was examples of how zero-knowledge proof techniques could make source code impenetrable. Source would be nice, too... ;) -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From strick at versant.com Sat Sep 18 21:39:42 1993 From: strick at versant.com (strick -- henry strickland) Date: Sat, 18 Sep 93 21:39:42 PDT Subject: gopher links Message-ID: <9309190439.AA26663@versant.com> writes to me: # strick wrote: # > (Just for the halibut I tried "gopher gopher.uu.net" and # > "gopher ftp.uu.net" but no dice. If you were using WWW instead # > of gopher, you could link "ftp://ftp.uu.net/inet/rfc/rfc1321".) # # Gopher can link to ftp directly without the destination being served by a # gopher server. RT*M: (p.s. I have no idea why they call them "cool" links) Actually, I have RT*Protocols, but the original protocols, not the one you describe here. Come to think of it, it looks like this is executed by the gopher server, since it also has a "exec" option. Not so efficient for ftp, but the old client-server protocol would still work. Karl, if this works with your gopherd, you should abuse it ... strick # GOPHERD(8) # # # ADDING COOL LINKS # One cool thing you can do with .Links is to add neato ser- # vices to your gopher server. Adding a link like this: # # Name=Cool ftp directory # Type=1 # Path=ftp:hostname at path/ # Host=+ # Port=+ # # Name=Cool ftp file # Type=0 # Path=ftp:hostname at file # Host=+ # Port=+ # # Will allow you to link in any ftp site into your gopher. # Make sure that there is a /tmp directory to store the # files for the gateway. Note that if you're running with- # out the -c option, you must create a "tmp" directory at # the top level of the gopher-data directory. # # Another neat thing you can do is to execute shell scripts: # # Name=Execed command name # Type={a type} # Path=exec:"args":/scriptname # Host=+ # Port=+ # # This is usually used by other types of gateway scripts. # For instance, The first script might take a search and get # a few hits. It could then generate "exec" scripts that # would retrieve the actual document the hit referred to. # # Note that the scriptname *must* begin with the magic char- # acter "#!/". It also must be executable. # From pmetzger at lehman.com Sat Sep 18 21:41:39 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sat, 18 Sep 93 21:41:39 PDT Subject: analysis: attack PKP driven? significance of June 1, 1991 In-Reply-To: <9309182319.AA10597@longs.lance.colostate.edu> Message-ID: <9309190439.AA02129@snark.lehman.com> "L. Detweiler" says: > > C'punks: upon further reflection this dual assault seems to be ostensibly PKP > motivated/driven. It is possible the prior NSA harassment of Moby Crypto was > just a shocking coincidence. Why all this silly speculation? We will all know the complete answers soon enough. There is no need for us to reach out and "investigate". There are lots of better uses of our time. Cypherpunks CODE, remember? Go out and code or give radio interviews. Trying to second guess facts that we will soon have directly in our hands seems unnecessary. > We need more information: > > - how long has the NSA been harassing Austin Code Works? > - does Austin Code works currently deal with cryptographic code? > - or is this all entirely due to Grady Ward's Moby Crypto project? > - was NSA complaining about (1) DES or (2) something else? export? > - how did NSA find out that Austin Code Works was involved with Moby Crypto? "We" need no information. We are not the attorneys. EFF and the rest are involved and have fine lawyers and investigators. Anything "We" uncover will be useful only for personal amusement. "We" don't even have our facts right -- the "NSA" has not been directly harassing ANYONE. Although we may speculate with some likely accuracy that the NSA has been involved, it is the Commerce and State departments that enforce the crypto export laws. I'd calm down, Mr. Detweiler. Write some code -- its a productive persuit. Perry From jkhastings at aol.com Sat Sep 18 22:07:10 1993 From: jkhastings at aol.com (jkhastings at aol.com) Date: Sat, 18 Sep 93 22:07:10 PDT Subject: So. Calif. Cypherpunks Outreach Message-ID: <9309190053.tn53627@aol.com> "State Evader" comes out of the Green Dragon Tavern BBS (213) 365-1132 pseudonym closet to shamelessly promote his upcoming speeches at the H.L. Mencken Forum and the Libertarian Party of CA Region 62 Los Angeles Westside: ------------------------------------------------------------ State Evader = J. Kent Hastings Assistant Director of the Agorist Institute, "Techtics" columnist for the Tactics of the Movement of the Libertarian Left newsletter, internet cypherpunk, and ham radio operator WA6ZFY. Both speeches will be on the topic: "Cyber Cash: Free Market Money Comes of Age" I will talk about untraceable digital cash, public-key cryptography, spread-spectrum radio, un manned vehicles, and the latest government actions that threaten everyone's privacy: The Clipper/ Skipjack key escrow agents and the subpoenas served to the Austin Code Works and ViaCrypt for all PGP, RSA export info. -------------------------------------------------------------- Mencken info: (310) 289-3234 (reserve now!) L.P. info: (310) 477-6491 -------------------------- Mencken location: The Old Spaghetti Factory 5939 Sunset Blvd near Hollywood Freeway in L.A. Wednesday September 22, 1993 6:30 Libatio ns, 7:00 Dinner, 8:00 Speaker, 10:00 Adjournment First time "virgins" reserved: $3 -------------------------------------------------- L.P. of CA Region 62 L.A. Westside: Chris's Italian Restaurant 10105 Venice Blvd. at Clarington Ave Thursday, September 23, 1993 Cocktails 6:30, Dinner 7:00, Talk 8:30 Not sure if admission is charged. ---------------------------------------------- Kent - From ld231782 at longs.lance.colostate.edu Sat Sep 18 22:32:10 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sat, 18 Sep 93 22:32:10 PDT Subject: more deranged lunatic ravings -- just delete 'em! Message-ID: <9309190530.AA15035@longs.lance.colostate.edu> From: "Perry E. Metzger" >Why all this silly speculation? We will all know the complete answers >soon enough. There is no need for us to reach out and "investigate". ah yes, just like everyone 'soon enough' knew the 'complete answers' behind the Steve Jackson Games investigation. All we have to do is sit around and wait for it to be handed to us by everyone involved, including The Enemy. Look at that E911 investigation -- this was an example of *community* involvement. Laywers on *both* sides were unaware of the fact that E911 documents were publicly available, that they could even be *ordered* from Mountain Bell with no restriction, until someone 'out there' made the link and pointed it out -- and this was a *very* significant aspect of the defense case. >"We" need no information. We are not the attorneys. EFF and the rest >are involved and have fine lawyers and investigators. Anything "We" >uncover will be useful only for personal amusement. the situation *directly affects* us *now*. what is the scope of the grand jury investigation? could it potentially be *expanded* beyond this initial inquiry? what about sites that are currently distributing PGP outside the U.S.? what about the fact that cypherpunks have *always* been closely involved with PGP and its international distribution? >"We" don't even >have our facts right -- the "NSA" has not been directly harassing >ANYONE. say *what*?! Grady Ward has been posting for over a week on a bazillion Usenet groups that Agent X from the NSA has contacted him, with a phone number, fax, and identification standard for NSA employees (I forwarded one of his early messages here). A representative from Austin Code Works informed a Cypherpunk (who wasn't afraid to do a little poking around himself) they have been prodded by the NSA months prior over DES export. And "the NSA has not been directly harassing ANYONE." well, yes, I guess they haven't stuck anybody on the rack, if that's what you mean. >I'd calm down, Mr. Detweiler. Write some code -- its a productive >persuit. ah yes, I'm 'persuing' the sequels to PGP and Moby Crypt right now you seem to be fundamentally averse to excitement. this is the Cryptographic Case of a decade, and we're all to just wait patiently for the bleached official reports prior to a proper, dainty discussion? not I. but in deference to you, Mr. Metzger, and others, I will not post any more speculation ... without some new juicy articles to speculate on :) From klbarrus at owlnet.rice.edu Sat Sep 18 23:31:41 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sat, 18 Sep 93 23:31:41 PDT Subject: GOPHER: misc Message-ID: <9309190629.AA02026@flammulated.owlnet.rice.edu> Thanks for the feedback about links - I didn't read that far in the server.doc! It looks like I could point to the EFF gopher for legislation and stuff, if they wouldn't mind...? But, stuff I link to has to be available from another gopher, right? I mean, I just can't point to a directory on some machine and have gopher retrieve the file for viewing? Or can I? Because I definitely would like to have the RFC's and message digest stuff viewable, or pointed to. Also, will gopher uncompress a file before displaying? I think I should read the gopher FAQ :-) And look at WWW when I have some time. Also, where is the "Digital Silk Road" paper? I'd like to put the text version in the "Digital Cash" section. I'd also like to put the two reports at cwi up, but those are postscript... gopher.wustl.edu has a TANTALIZING menu item for the ftp site, but I got a connection refused message. I need to talk to Chael to see exactly what kind of disk space we have to work with - it looks like to me an ftp option retrieves files to the gopher site (chaos). I put up some more stuff, including remailer public keys, but not much more on anonymous mail and still nothing on clipper. -- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From gg at well.sf.ca.us Sun Sep 19 01:26:43 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Sun, 19 Sep 93 01:26:43 PDT Subject: Does this seem illegal to you? Message-ID: <93Sep19.012433pdt.14190-1@well.sf.ca.us> Sprint TeleMap: You've been after this woman who gives you the ultimate hard-on, but she won't play. Every night you write her another letter, pouring out your heart, begging for her hand, telling her all the lucious things you'll do with her once she comes to her senses and lets you into her life. Lately you've been getting your letters back,"return to sender, no such addressee" in purple Post Office ink. But no matter, you call her number, and get the recording with her new number. You've been getting angrier lately, as she's changed her number three times now. If only she would let you into her life, you'd make wonderful music together by the moonlight- but No!, she just won't play. The anger has been building, and lately you've been taking to leaving more and more desperate messages on her answering machine. She's really getting to you now, you want to teach her a lesson, a lesson she'll never forget. You've been trying to follow her car home from work, but for some reason she's not driving the same car or taking the same route; she might even have changed jobs. Boy oh boy, you'll teach *her* a lesson, teach *her* to say No to you! You feel inside your jacket, where your .38 is carefully tucked. Yeah, teach her a lesson for sure! And lo, a Sprint payphone! You dial the 1-800 number and ask for directions... give them her last known phone number... the seconds tick by, your head whirling with the things you're going to tell her and make her plead with you.... a second or two later, the operator comes back on the line. Go right at Harbor... left at Main... two blocks down to Third, second house on the left. Aha, there we go. Thank you, operator. A warm bulge rises in your pants as you contemplate your next move. Boy are you going to teach her a lesson! This special moment brought to you by Sprint TeleMap. , From nate at VIS.ColoState.EDU Sun Sep 19 06:39:45 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Sun, 19 Sep 93 06:39:45 PDT Subject: GOPHER: misc In-Reply-To: <9309190629.AA02026@flammulated.owlnet.rice.edu> Message-ID: <9309191336.AA10883@monet.VIS.ColoState.EDU> Karl Lui Barrus coersed the electrons into symbolizing: >I think I should read the gopher FAQ :-) And look at WWW when I have >some time. Speaking of WWW, I am working on a DoE project (the "Computational Science Education Project", CSEP for short), and part of this prject involves the development of a WWW-able book.... so what i am saying is that I have quite a lot of experience with WWW, and would be more than happy to help develop (or just plain develop) a set of HTML (the type of document that WWW readers (such as NCSA Mosaic) read)... I don't think that I would feel comfortable running it from the machines in my laboratory, but I will speak to my boss about it when the time is right, maybe I'll ask about letting people have their own home pages... that are defined as being separate from the project or something. Anyway, if anyone is willing to donate some drive space, and wants to set up a WWW server, I know how, and I can get it done. Just trying to do my part, -nate sammons -- +-------------------------------------------------------------------- | Nate Sammons email: nate at VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate at monet.VIS.ColoState.Edu for my PGP key | #include | Always remember "Brazil" +----------------------+ From pmetzger at lehman.com Sun Sep 19 08:15:48 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 19 Sep 93 08:15:48 PDT Subject: more deranged lunatic ravings -- just delete 'em! In-Reply-To: <9309190530.AA15035@longs.lance.colostate.edu> Message-ID: <9309191513.AA08482@snark.lehman.com> "L. Detweiler" says: > > From: "Perry E. Metzger" > >Why all this silly speculation? We will all know the complete answers > >soon enough. There is no need for us to reach out and "investigate". > > ah yes, just like everyone 'soon enough' knew the 'complete answers' behind > the Steve Jackson Games investigation. We did, yes. You see, the ATTORNEYS, who were being PAID, because they were PROFESSIONALS, handled things. As I've noted in private mail to you, *WE* are not conducting this investigation. *WE* are not involved. *WE* haven't been summoned to provide evidence in court. > Look at that E911 investigation -- this was an example of *community* > involvement. Laywers on *both* sides were unaware of the fact that E911 > documents were publicly available, that they could even be *ordered* from > Mountain Bell with no restriction, until someone 'out there' made the link > and pointed it out -- and this was a *very* significant aspect of the > defense case. Well, yes -- so what? If you wanted to go out and make a systematic list of encryption software available overseas for the defense, that would indeed be a useful act. It seems, however, that you are intent on yammering. Its one thing if you were looking for useful evidence, but it seems that you are simply going around screaming about how the NSA is out to get us. Well, the yammering is not an "investigation". If you do want to help, find something productive. > >"We" need no information. We are not the attorneys. EFF and the rest > >are involved and have fine lawyers and investigators. Anything "We" > >uncover will be useful only for personal amusement. > > the situation *directly affects* us *now*. what is the scope of the grand > jury investigation? Thats a secret. Even if you found out, which would require subborning a juror (a crime) or otherwise bribing an official (a crime), you would be put in jail for contempt of court if you told anyone. > could it potentially be *expanded* beyond this initial inquiry? Of course. Anything can be expanded. It could also fail to bring indictments -- but thats unlikely. It is said, not without truth, that a grand jury will indict a ham sandwich if the prosecutor asks. > what about sites that are currently distributing PGP outside the > U.S.? They are beyond the scope of U.S. law. None of these are hard questions. They are all, in fact, trivial. You know, many of the decafinated brands taste just as good as the real thing nowadays. I'd try them. > you seem to be fundamentally averse to excitement. Well, yes. I don't get easily excited about court cases. The case is IMPORTANT, but having had long experience with courts, I know that things are going to take years to resolve. I was once involved in a civil suit that required five years to resolve -- and there are probate cases around that have required decades. Look at the process here. The Grand Jury investigation gets followed, possibly, with indictments, which are followed, some very long period of time later, by a trial, which also takes a long period. It could be a year or even several before we even finish the trial phase on this, and by the time it goes through all the levels of appeal to the Supreme Court (assuming fundamental questions of constitutional law come up_ it could be many years before its all over. I have a great deal of trouble getting excited over something that will take years to resolve, yes. This is not like watching the D-Day invasion, or even like watching trench warfare in WWI. This is very much like watching people playing chess while immersed in ice cold molasses. Hard to get thrilled by the pace, Mr. Detweiler. Perry From pmetzger at lehman.com Sun Sep 19 08:25:48 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 19 Sep 93 08:25:48 PDT Subject: Does this seem illegal to you? In-Reply-To: <93Sep19.012433pdt.14190-1@well.sf.ca.us> Message-ID: <9309191523.AA08506@snark.lehman.com> If he has her phone number, and its listed, he can check any reverse phone directory, get her address, and do this anyway. He doesn't need spring telemap. If she's stupid enough not to get an unlisted number, then Sprint Telemap isn't going to do anything worse than what can be done already. Perry "George A. Gleason" says: > Sprint TeleMap: > > You've been after this woman who gives you the ultimate hard-on, but she > won't play. Every night you write her another letter, pouring out your > heart, begging for her hand, telling her all the lucious things you'll do > with her once she comes to her senses and lets you into her life. Lately > you've been getting your letters back,"return to sender, no such addressee" > in purple Post Office ink. But no matter, you call her number, and get the > recording with her new number. You've been getting angrier lately, as she's > changed her number three times now. If only she would let you into her > life, you'd make wonderful music together by the moonlight- but No!, she > just won't play. The anger has been building, and lately you've been taking > to leaving more and more desperate messages on her answering machine. She's > really getting to you now, you want to teach her a lesson, a lesson she'll > never forget. You've been trying to follow her car home from work, but for > some reason she's not driving the same car or taking the same route; she > might even have changed jobs. Boy oh boy, you'll teach *her* a lesson, > teach *her* to say No to you! You feel inside your jacket, where your .38 > is carefully tucked. Yeah, teach her a lesson for sure! And lo, a Sprint > payphone! You dial the 1-800 number and ask for directions... give them her > last known phone number... the seconds tick by, your head whirling with the > things you're going to tell her and make her plead with you.... a second or > two later, the operator comes back on the line. Go right at Harbor... left > at Main... two blocks down to Third, second house on the left. Aha, there > we go. Thank you, operator. A warm bulge rises in your pants as you > contemplate your next move. Boy are you going to teach her a lesson! > > This special moment brought to you by Sprint TeleMap. > , From mech at eff.org Sun Sep 19 08:37:18 1993 From: mech at eff.org (Stanton McCandlish) Date: Sun, 19 Sep 93 08:37:18 PDT Subject: reporter seeking interview subjects In-Reply-To: <9309180811.AA21373@toad.com> Message-ID: <199309191535.AA11204@eff.org> > > Hi, my name is Matt Binder. Please help me... > > I'm a radio reporter in the SF Bay area working on a series > > of pieces about invasions of privacy in the computer age. I'm > > looking for interesting "case studies" that I can use to horrify > > my listeners out of their complacency. My most immediate need is > ^^^^^^^^^^^^^^ > > Just what I love from the media, using sensationalism to convey a > preconceived idea instead of looking at the facts and reporting it. > Does it matter that he is reporting on our side and not the other > side? Why of course it does. No wishing and praying will make the media suddely become pure and holy. This is a propaganda war, and there's no reason for both sides not to get in on the act. Otherwise, it's like fighting guns with slingshots. -- DISCLAIMER: This message represents only my OWN opinion, not that of EFF. Stanton McCandlish Electronic Frontier Foundation Online Activist & SysOp mech at eff.org NitV-DataCenter BBS SysOp Fido: IndraNet: 369:111/1 From doug at netcom.com Sun Sep 19 08:59:46 1993 From: doug at netcom.com (Doug Merritt) Date: Sun, 19 Sep 93 08:59:46 PDT Subject: gopher links In-Reply-To: Message-ID: <9309191557.AA16407@netcom4.netcom.com> henry strickland said: >(p.s. I have no idea why they call them "cool" links) "cool" links are the opposite of "hot links". The latter are active; nontrivial computation is done when the link is followed. The former are passive and merely point to information. Hypertext jargon. Then again, the man page you quoted implies that the author just thinks that such things are cool. Doug From doug at netcom.com Sun Sep 19 09:16:50 1993 From: doug at netcom.com (Doug Merritt) Date: Sun, 19 Sep 93 09:16:50 PDT Subject: Definition of "Zero Knowledge" Message-ID: <9309191615.AA18299@netcom4.netcom.com> From: khijol!erc at apple.com (Ed Carp) >Thanks for the definition (but I knew that, anyway). Sorru I wasn't clear - >what I was looking for was examples of how zero-knowledge proof techniques >could make source code impenetrable. An arbitrary algorithm can be translated into a zero proof theory model that is intractable to functionally analyze. Its operations on inputs and outputs can take place within the realm of the intractable model, with the inputs and outputs being transformed from the encoding of the outside realm into an encoding useful to the realm of the model. The inputs and outputs are the queries and answers of zero proof theory. With such a thing, knowing every detail of the registers and instructions being executed at all times still wouldn't tell you what you really wanted to know. I'm unsure whether this has been published, let alone implemented; I just thought it was an obvious corollary back when ZPT itself was first published. It might have been discussed in the literature at the time, but if so, I've forgotten. I'm also not claiming this is necessarily a useful approach in practice, because the obvious ways of implementing such a thing would be more than a little slow. I suspect that it could be done efficiently with a little algorithmic cleverness, but I don't have evidence of that this instant. I'm currently designing something with very much the same flavor, but with somewhat different goals, and computational expense of the operators in the model is precisely the difficulty with that, too, so far. Doug -- Doug Merritt doug at netcom.com Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow Unicode Novis Cypherpunks Gutenberg Wavelets Conlang Logli Alife HC_III Computational linguistics Fundamental physics Cogsci SF GA VR CASE TLAs From doug at netcom.com Sun Sep 19 09:29:46 1993 From: doug at netcom.com (Doug Merritt) Date: Sun, 19 Sep 93 09:29:46 PDT Subject: NIST proposes software key escrow development In-Reply-To: Message-ID: <9309191627.AA19045@netcom4.netcom.com> Brad Huntting said: >> And even hardware solutions can be reverse engineered. In fact, it's > >Why? The easiest way to foil SlipJack is to simply run another >encryption mechanism on top of it. Because we weren't (just then) talking about foiling it, we were talking about whether it could be figured out. Unless I misunderstood the discussion from careless reading, the point seemed to be that they wanted to make the workings of the chip secret. I was furthmore assuming that there would be motivation for people to figure out such secrets because it would help them do their own illicit decryptions, but that's getting slightly off subject. >> I'm reasonably happy with what the NSA appears to be doing in regard to >> foreign intelligence gathering; it's their domestic agenda that threatens >> the constitution. But that's in the nature of spook organizations. > >I dont know about you, but many of my best friends are "foreigners", >and many of them live in riskier situations than I do (both in the >US and abroad). Their need for privacy is at least as pressing as >mine. The argument that "we" can abuse the rights of "foreigners" >is nationallistic at best and jingoistic at its worst. That's not what I said. The charter of the NSA isn't to abuse the rights of your foreign friends. Now that you've raised the subject, I wouldn't be happy with the NSA doing so, either. I have friends outside the U.S. too. I just meant that countries do intelligence gathering on each other all the time as a matter of course, and most of that isn't abusive in nature, it's just the usual game of politics and defense etc. But I suppose it's silly of me to say something like that on a list with so many rabid paranoids; how could I possibly imagine that not *every* act of the NSA is inherently ***EVIL***!? Sigh. Doug From klbarrus at owlnet.rice.edu Sun Sep 19 09:56:50 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sun, 19 Sep 93 09:56:50 PDT Subject: GOPHER: cpsr Message-ID: <9309191655.AA06177@flammulated.owlnet.rice.edu> I just discovered the CPSR gopher (gopher.cpsr.org) mirrors the cypherpunk soda archive, including the clipper directory there. So I'll figure out how to create a link to it. I don't know about cool links though; the only gopher sever and client I could compile on chaos (net BSD some.version) was gopher1.12S, and I don't think is has that functionality. Later, I'll give the gopher2.06 a try again. Plus, I've noticed that sometimes the name resolver can find chaos.bsu.edu, sometimes not, for whatever reason. So maybe I'll talk to Chael and see if we can't make a gopher login for telnet access. -- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From rwalters at gtech.com Sun Sep 19 09:59:46 1993 From: rwalters at gtech.com (Walters, Randy) Date: Sun, 19 Sep 93 09:59:46 PDT Subject: Delete Me Message-ID: <9308197484.AA748456788@ccgate.gtech.com> Hi, there... Please delete me from the cypherpunks mailing list. It's a little greater traffic than I expected... Sorry about the hassle, and thanks. R. From hfinney at shell.portal.com Sun Sep 19 10:19:46 1993 From: hfinney at shell.portal.com (hfinney at shell.portal.com) Date: Sun, 19 Sep 93 10:19:46 PDT Subject: Restrictions on crypto exports Message-ID: <9309191700.AA28106@jobe.shell.portal.com> Like L. Detweiler, I can't resist the temptation to speculate a little bit on the apparent legal crackdown on export of crypto. The relevant section of the law is the Arms Export Control Act of 1968, codified in sections 2751 and following of Title 22 of the U.S. Code. Section 2778 deals with control of arms exports and imports. In that section, the President is authorized to determine what are "defense articles"; the articles so designated constitute the "Munitions List". "Any person who willfully violates any provision of this section... shall upon conviction be fined for each violation not more than $1,000,000 or imprisoned not more than ten years, or both." So there are potentially very serious sanctions for violations of this Act. One interesting point is the use of the word "willfully". This has been held in several court cases to mean that the government must show that an accused not only exported munitions, but that he did so knowing that it was illegal. Legally, this means that there must be a showing of "specific intent". For example, in U.S. v Lizarraga-Lizarraga, the appellate court wrote (in 541 F2d 826), "At trial and on appeal, the defendant admits that he purchased the ammunition and that he intended to export it to Mexico. His defense is bsed on the contention that he had no knowledge that his conduct violated the law. Hence, the appellant claims that to be found guilty under 22 U.S.C. 1934 [the predecessor to 22 U.S.C. 2778], the government must prove that he intended to violate the statute.... We agree, and hold that he was entitled to a specific intent instruction. Accordingly, we reverse his conviction and remand for a new trial." The justice discusses several reasons for concluding that "willfully" implies a need to show specific intent, among them that the articles on the Munitions List are not obviously illegal to export, finally concluding: "Accordingly, we hold that in order for a defendant to be found guilty of exporting under 22 U.S.C. 1934, the government must prove that the defendant voluntarily and intentionally violated a known legal duty not to export the proscribed articles, and the jury should be so instructed." There are several other court cases which agree with this conclusion. Therefore, the government will have to show not only that PGP was exported, but that whoever did it knew that the export was illegal. For example, the headnotes to U.S. v Malsom state, "Conviction for violation of 22 USC 2778 requires showing of criminal intent; use of circuitous shipment route to ship replacement parts for military airplanes supports finding of criminal intent." Apparently in that case the parts were shipped in a circuitous manner designed to prevent detection, and this fact itself was evidence that the defendants knew they were breaking the law. If PGP were exported overseas in some straightforward manner, such as being made available for FTP in the U.S., it would be much harder for the government to show criminal intent than if it had been written onto a floppy hidden in a crate of frozen vegetables or something. So it will be interesting to see how the government approaches the intent issue. Other interesting points come from the ITARs themselves, which implement this section of the U.S. Code. Subchapter M of Title 22 of the Code of Federal Regulations is the International Traffic in Arms Regulations. This subchapter encompasses sections 120 and following of that Title. Section 120 has mostly definitions, section 121 has the Munitions List itself, and the remaining sections deal mostly with regulations and reporting requirements. Category XIII of the Munitions List, Auxiliary Military Equipment, includes: "Cryptographic (including key management) systems, equipment, assemblies, modules, integrated circuits, components or software with the capability of maintaining secrecy or confidentiality of information or information systems". It is followed by a long list of exceptions, and exceptions to the exceptions, none of which appear to apply to PGP or RSA. So on the face of it, this appears to be a fairly broad prohibition on the export of cryptographic software. However, there is an interesting sentence in part 125 of this subchapter. In 125.1(a), it says, "Information which is in the 'public domain' (see section 120.18) is not subject to the controls of this subchapter." Note that by "this subchapter" it must mean Subchapter M, the entire ITAR. "Public domain" is defined in 120.18: "Public domain means information which is published and which is generally accessible to the public: (a) Through sales at newsstands and bookstores; (b) Through subscriptions which are available without restriction to any individual who desires to obtain or purchase the published information; (c) Through second class mailing privileges granted by the U.S. Government; or, (d) At libraries open to the public." So, this is a possible defense against a charge that exporting PGP or other RSA software violates the ITARs. If one could argue that the software was public domain, and that the software could be considered "information" (hard to argue against if it was exported electronically), then it is not covered by the ITARs. The public domain issue is not completely clear, but one could certainly make a case that software available on BBS sites or by FTP fell into categories (b) or (d) of the public domain definition, or at a minimum that the degree of public availability in these situations is very similar to that envisioned by the authors of this definition. Alternatively, the defense could argue that irrespective of whether a particular implementation was public domain, that the main cryptographic algorithm involved, the RSA cryptosystem, was certainly public domain by the letter of the definition. So, if there is a court case, I'd expect that this might be one of the main issues of contention between defense and prosecution. The last issue I'll mention is the meaning of "Export". This is defined in 120.10. "Export means, for purposes of this subchapter: (a) Sending or taking defense articles out of the United States in any manner, or... (d) Disclosing or transferring technical data to a foreign person, whether in the United states or abroad..." I've just listed the most relevant parts here. Several months ago, Jim Bidzos of RSADSI published a document attacking the legality of PGP, and in that document he claimed that making PGP available for FTP constituted export, and in fact that posting it to your neighborhood BBS also constituted export. (Ironically, a few weeks later there was a flap when RSADSI made its own RSA software available for FTP, and some foreign nationals downloaded it.) The presumed justification for this reasoning would be that making the information publically available in this way could "disclose" it to a foreign person. A similar argument was described in a very interesting post Dan Bernstein made to sci.crypt a few months ago. Dan was trying to get permission to export information about a cryptographic technique he had developed: Excerpts from a State Department conversation Daniel J. Bernstein 22 July 1993 Here are some excerpts, edited for legibility, from a conversation I had with Charles Ray of the Office of Defense Trade Controls on 26 March 1993. These excerpts are now in the public record. Please do not assume that the comments below reflect any official State Department position, although my notes list Charles Ray as a ``special assistant'' to DTC Director William B. Robinson. Dots represent omissions, not pauses. DJB means me. CR means Ray. DJB: What I'm trying to understand is: Suppose somebody makes some technical data which is a defense article, it's on the Munitions List, and goes to a library. The library agrees, and puts it on their shelves. Then ... doesn't that make it public domain, assuming that there are no contractual problems or anything? CR: Actually, that could be argued a number of ways. But it could also be argued that if the person made something that was a Munitions List item, and particularly if they did it knowingly and they put it in a public library where anyone has access to it, that it could be considered a violation of the Arms Export Control Act. It would I think depend a lot on their motives for doing it. [Material elided] CR: ... Hypothetically, if a person deliberately created a Munitions List item, and deliberately placed it in a public library so as to evade the restrictions ... I think that person might still find himself or herself subject to certain sanctions should there be an incident of this information falling into the hands of a foreign entity. So, here Ray is basically making that same argument, that putting something into the public domain by putting it into a library could itself be considered "export" if it resulted in a foreign entity getting access. So, the government may be trying to set up a "Catch 22" situation here, where any attempt to make information "public domain" will be automatically considered an attempt to export it. I would think that the defense could come up with some good replies to any attempt by the prosecution to make this argument. The ITARs are intended to control foreign export, and it appears to be a large extension of their power to attempt to control what things American citizens may take to their own domestic libraries. Of course, people should remember that the investigation is still at an early stage now. The grand jury may or may not decide to issue criminal charges; if they do, the accused may choose to plead guilty to a lesser charge rather than take the risk of a court battle; even if the matter goes to court, the accused will of course choose his defense based on his own considerations of advantage. It's not clear that even a favorable court decision will free the flow of cryptographic software. Hal Finney hfinney at shell.portal.com From khijol!erc at apple.com Sun Sep 19 10:29:46 1993 From: khijol!erc at apple.com (Ed Carp) Date: Sun, 19 Sep 93 10:29:46 PDT Subject: more deranged lunatic ravings -- just delete 'em! In-Reply-To: <9309191513.AA08482@snark.lehman.com> Message-ID: > As I've noted in private mail to you, *WE* are not conducting this > investigation. *WE* are not involved. *WE* haven't been summoned to > provide evidence in court. First off, 'we' ARE involved. This case is IMPORTANT, and can have far- reaching consequences for us. This reminds me of the old story that starts out 'they came and got the Jews, and I said nothing because I wasn't a Jew...'. > Well, yes. I don't get easily excited about court cases. The case is > IMPORTANT, but having had long experience with courts, I know that Agreed, it IS important! > I have a great deal of trouble getting excited over something that > will take years to resolve, yes. This is not like watching the D-Day > invasion, or even like watching trench warfare in WWI. This is very > much like watching people playing chess while immersed in ice cold > molasses. Hard to get thrilled by the pace, Mr. Detweiler. The attorneys and other experts looking at this case apparantly don't share your lack of enthuasism. Even in the very early stages, the groundwork that is laid in a case like this is of TREMENDOUS importance to the outcome of the case, regardless of how long it takes to be resolved. Frankly, I'm surprised at your lackadaisical attitude - if you had been involved in the justice system in this country for any length of time, you'd have realized that EVERY step taken along the way is IMPORTANT, regardless of how trivial or unimportant those steps appear now. Cases involving billions of dollars have been decided by trivial details. -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From an36440 at anon.penet.fi Sun Sep 19 11:05:51 1993 From: an36440 at anon.penet.fi (an36440 at anon.penet.fi) Date: Sun, 19 Sep 93 11:05:51 PDT Subject: more deranged lunatic ravings -- just delete 'em! Message-ID: <9309191802.AA23218@anon.penet.fi> >Look at the process here. The Grand Jury investigation gets followed, Finally, a voice of reason. The justice system must be followed by all sides, not just the defendant. While this is an important case, it's important to see it in perspective. The EFF and others have set themselves up to provide defense in just such situations. If you want to help them by gathering "evidence", good for you. But you aren't doing ANY good by ranting on a Internet mail list. We can all read the non-hysterical informational postings to see what's happening. Mr. Detweiler, you are just adding noise and confusion. ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From tcmay at netcom.com Sun Sep 19 11:15:50 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 19 Sep 93 11:15:50 PDT Subject: Bobby Ray Inman wants ciphers restricted! Message-ID: <9309191812.AA20377@netcom5.netcom.com> Here's another one of those apparent "trial balloons," this time from an influential former Director of the NSA. As DIRNSA, Admiral Inman was the one who in the late 1970s proposed restrictions on the use of public key cryptography, at least according to Bamford in "The Puzzle Palace." Inman later was in the CIA, then MCC in Austin, and is now involved in venture capital in various ways. I believe his VC firm invested in Cylink, one of the four partners in Public Key Partners (the others being RSADSI, Stanford, and MIT). (Paranoids like us might look for links to Mykotronx....) Enough speculation for now. Here's the item: From: howard at hal.com (Howard Gayle) Newsgroups: talk.politics.crypto,alt.politics.libertarian,comp.org.eff.talk,alt.privacy.clipper Subject: von Mises Inst. Free Market article on Clipper Date: 19 Sep 1993 16:29:34 GMT Message-ID: <27i1de$edv at hal.com> Reply-To: howard at hal.com (Howard Gayle) Summary: Government subsidies imply government control. Keywords: Bobby Ray Inman, NSA, registration, EFF The September 1993 issue of "The Free Market" has an article by Gary McGath about Clipper. "The Free Market" is a monthly non-technical newsletter from the Ludwig von Mises Institute. Gary McGath is the publisher of the "Thomas Paine Review." Here's a quote: "Bobby Ray Inman, former director of the NSA, has even proposed `a registry of institutions which can legally use ciphers,' as he explained in his recent book. `If you get somebody using one who isn't registered, then you go after him.'" McGath also mentions the EFF: "The Electronic Frontier Foundation, which opposes the Clipper, still applauds legislation to subsidize network access. But by inviting the government to build their `highway,' EFF is inviting in the traffic cops. "The only way to keep our communications free of governmental intrusion is to keep them free of governmental involvement." -- Howard Gayle HAL Computer Systems, Inc. 1315 Dell Avenue Campbell, California 95008 USA howard at hal.com Phone: +1 408 379 7000 extension 1080 FAX : +1 408 379 5022 -- From pmetzger at lehman.com Sun Sep 19 11:19:47 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 19 Sep 93 11:19:47 PDT Subject: more deranged lunatic ravings -- just delete 'em! In-Reply-To: Message-ID: <9309191818.AA08784@snark.lehman.com> Ed Carp says: > > As I've noted in private mail to you, *WE* are not conducting this > > investigation. *WE* are not involved. *WE* haven't been summoned to > > provide evidence in court. > > First off, 'we' ARE involved. Oh? Have you been hired as an attorney for either side? > This case is IMPORTANT, and can have far- > reaching consequences for us. Yes, thats fine and well, but this is very different from saying that "*WE* have to conduct an investigation and get to the bottom of this" as if "we" are even a group or in possession of resources to do any such thing. Indeed, what Mr. Detweiler has largely been proposing is yammering. Cypherpunks CODE. Quit yammering and start coding. I'm coding. Its fine to keep up to date. Its fine to send big checks to EFF. Its fine to do some legwork if you think it can help. However, what is the point in saying inane things like "we have to find out what the grand jury is investigating" when its a bloody secret and we don't get to find out until they unseal their indictments? > > I have a great deal of trouble getting excited over something that > > will take years to resolve, yes. This is not like watching the D-Day > > invasion, or even like watching trench warfare in WWI. This is very > > much like watching people playing chess while immersed in ice cold > > molasses. Hard to get thrilled by the pace, Mr. Detweiler. > > The attorneys and other experts looking at this case apparantly don't share > your lack of enthuasism. Even in the very early stages, the groundwork that > is laid in a case like this is of TREMENDOUS importance to the outcome of > the case, regardless of how long it takes to be resolved. Frankly, I'm > surprised at your lackadaisical attitude Not lackadaisical. Simply not in a state of hyperactive disarray. WE are not doing the groundwork. The attorneys are. WE are not about to be charged with a crime. WE have no reason to go into a frenzy of activity -- I see nothing that WE can do. It isn't up to us. You sound like someone upset that the supreme court is about to rule about abortion and screaming "WE HAVE TO DO SOMETHING". Well what, precisely, do you propose to do? Take over the legal work when you aren't a lawyer? Complain? Scratch your crotch and look important? This isn't in our hands. If you think you have information of use to the lawyers, give it to them and be done with it -- there is nothing else you can do. > Cases involving billions of dollars have been decided by trivial details. Oh? How many cases involving billion dollar settlements can you name? Care to give us a list? Perry From prz at columbine.cgd.ucar.EDU Sun Sep 19 11:35:50 1993 From: prz at columbine.cgd.ucar.EDU (Philip Zimmermann) Date: Sun, 19 Sep 93 11:35:50 PDT Subject: Statement from Zimmermann on PGP investigation Message-ID: <9309191832.AA24906@columbine.cgd.ucar.EDU> Some of you may have received my Internet message of a couple of days ago about the ongoing U.S. Customs investigation of the exportation of PGP, which has now progressed to the level of Federal Grand Jury subpoenas. This earlier message was intended by me for distribution to a very small group of friends who previously communicated their concern about me and the investigation and asked to be kept informed. I did not send the message to anyone outside this group. Unfortunately, I did not adequately assert my desire that the message not be further disseminated. It appears that the message has gone completely public. This was not my intention. My lawyer, Phil Dubois, has been in touch with the Assistant U.S. Attorney (William Keane) assigned to the investigation. We have no reason to believe that Mr. Keane is anything other than a professional and reasonable person. He made it clear that no decision has been made regarding any prosecution of anyone for any offense in this matter. Such decisions will not be made for some time, perhaps several months. Mr. Keane also made clear his willingness to listen to us (me and my lawyer) before making any decision. It appears that both Mr. Keane's mind and the lines of communication are open. My fear is that public dissemination of my message will close the lines of communication and put Mr. Keane into an irretrievably adversarial position. Such a result would not serve any of our interests. My lawyer tells me that nothing irritates a prosecutor more than being the subject of what he perceives to be an orchestrated publicity campaign. He also tells me that his nightmares involve FOAs (Friends Of the Accused), invariably people with good intentions, doing things on their own. I understand that the issues involved in this investigation are of the greatest importance and transcend my personal interests. Even so, I would rather not turn an investigation into a full-scale federal prosecution. I ask that everyone keep in mind that the government's resources are limitless and that mine are not. Speaking of resources, many of you have offered help, and I am grateful. Those wishing to contribute financially or otherwise should contact either me or Philip L. Dubois, Esq., at dubois at csn.org or by phone at 303-444-3885 or by mail at 2305 Broadway, Boulder, CO, 80304. Mr. Dubois has just got on the Internet and is still learning how to use it. Donated funds will be kept in a trust account, and all contributions will be accounted for. If this whole thing somehow goes away with money left in the account, the balance will be refunded to contributors in proportion to the amounts of their contributions. This message can be widely circulated on public forums. Philip Zimmermann prz at acm.org 303 541-0140 From khijol!erc at apple.com Sun Sep 19 11:55:50 1993 From: khijol!erc at apple.com (Ed Carp) Date: Sun, 19 Sep 93 11:55:50 PDT Subject: more deranged lunatic ravings -- just delete 'em! In-Reply-To: <9309191818.AA08784@snark.lehman.com> Message-ID: > Ed Carp says: > > > As I've noted in private mail to you, *WE* are not conducting this > > > investigation. *WE* are not involved. *WE* haven't been summoned to > > > provide evidence in court. > > > > First off, 'we' ARE involved. > > Oh? Have you been hired as an attorney for either side? Nope. That's not the point, and you know it. The point being (and I'm not even sure why I'm bothering to explain this to you - you're intelligent) this case has the potential to affect ALL of us, not just the participants in the case. > > This case is IMPORTANT, and can have far- > > reaching consequences for us. > > Yes, thats fine and well, but this is very different from saying that > "*WE* have to conduct an investigation and get to the bottom of this" > as if "we" are even a group or in possession of resources to do any > such thing. Indeed, what Mr. Detweiler has largely been proposing is > yammering. *I* proposed no such thing. Get your facts straight. > Cypherpunks CODE. Quit yammering and start coding. I'm coding. Its Yeah, and women are supposed to stay home, barefoot and preggers. Yeah, right. > fine to keep up to date. Its fine to send big checks to EFF. Its fine > to do some legwork if you think it can help. However, what is the > point in saying inane things like "we have to find out what the grand > jury is investigating" when its a bloody secret and we don't get to > find out until they unseal their indictments? I think it's pretty clear what they're investigating. > > > I have a great deal of trouble getting excited over something that > > > will take years to resolve, yes. This is not like watching the D-Day > > > invasion, or even like watching trench warfare in WWI. This is very > > > much like watching people playing chess while immersed in ice cold > > > molasses. Hard to get thrilled by the pace, Mr. Detweiler. > > > > The attorneys and other experts looking at this case apparantly don't share > > your lack of enthuasism. Even in the very early stages, the groundwork that > > is laid in a case like this is of TREMENDOUS importance to the outcome of > > the case, regardless of how long it takes to be resolved. Frankly, I'm > > surprised at your lackadaisical attitude > > Not lackadaisical. Simply not in a state of hyperactive disarray. WE > are not doing the groundwork. The attorneys are. WE are not about to > be charged with a crime. WE have no reason to go into a frenzy of > activity -- I see nothing that WE can do. It isn't up to us. Oh, Jesus-Christ-on-a-crutch...It *IS* up to us! WE are THE PEOPLE ... or do you believe that the words "We, the People" on the Declaration of Independence have no meaning? WE are going to decide the outcome of this case. WE are going to be sitting on the jury, WE are going to be writing letters to the local newspapers, WE are going to be watching the trial (if one ever comes about). > You sound like someone upset that the supreme court is about to rule > about abortion and screaming "WE HAVE TO DO SOMETHING". Well what, > precisely, do you propose to do? Take over the legal work when you > aren't a lawyer? Complain? Scratch your crotch and look important? Well, scratching my crotch and looking important HAD crossed my mind. :) What do you think, that even the Supreme Court works in a social and political vacumm? If you believe that, you are pretty naive. Public opinion shapes everything we do, everything we see. If we aren't out there helping to shape puyblic opinion, SOMEONE is going to be doing it, and they might not be so supportive of individual rights. > This isn't in our hands. If you think you have information of use to > the lawyers, give it to them and be done with it -- there is nothing > else you can do. > > > Cases involving billions of dollars have been decided by trivial details. > > Oh? How many cases involving billion dollar settlements can you name? > Care to give us a list? Many. The Getty Oil deal of several years back comes to mind, as does the Texaco vs. Pennzoil deal. You don't think that Roe v. Wade didn't have an economic impact? -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From an36440 at anon.penet.fi Sun Sep 19 11:59:47 1993 From: an36440 at anon.penet.fi (an36440 at anon.penet.fi) Date: Sun, 19 Sep 93 11:59:47 PDT Subject: more deranged lunatic ravings -- just delete 'em! Message-ID: <9309191856.AA03213@anon.penet.fi> >First off, 'we' ARE involved. This case is IMPORTANT, and can have far- >reaching consequences for us. This reminds me of the old story that starts >out 'they came and got the Jews, and I said nothing because I wasn't a Jew...'. Funny thing about some people on this list and alt.conspiracy, the first line of defense to accusations of hysteria is often "Look at what happened to the Jews...". The Jews didn't have professionals employed to fight for their side of the argument, didn't have the justice system to provide a legal framework within which both sides must maneuver, didn't have a lot of what prz, et al., have. >The attorneys and other experts looking at this case apparantly don't share >your lack of enthuasism. Even in the very early stages, the groundwork that You make my case. "The attorneys". What exactly are YOU doing with all your yammering, besides making a loud noise? ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From doug at netcom.com Sun Sep 19 12:19:47 1993 From: doug at netcom.com (Doug Merritt) Date: Sun, 19 Sep 93 12:19:47 PDT Subject: more deranged lunatic ravings -- just delete 'em! Message-ID: <9309191916.AA05457@netcom4.netcom.com> erc at apple.com said: >Nope. That's not the point, and you know it. The point being (and I'm not >even sure why I'm bothering to explain this to you - you're intelligent) >this case has the potential to affect ALL of us, not just the participants >in the case. True. But the question is, specifically what are you suggesting "all of us" do right now? When I say specifically, I mean for instance not just "find out information about XYZ" like you said before, I mean the "and then what?" part as well. Most of us will probably do our best to learn whatever we can rather than ignoring the situation. But *then* what? What's your suggestion? >Well, scratching my crotch and looking important HAD crossed my mind. :) Besides that, I mean. :-) Doug From tcmay at netcom.com Sun Sep 19 12:22:20 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 19 Sep 93 12:22:20 PDT Subject: What can we do in the next few days? Message-ID: <9309191920.AA25767@netcom5.netcom.com> Lots of flames lately about "lunatic ravings" and what Cypherpunks can or can't do to help in the next few days. Here's my take on the situation: * Keep current, read all the various groups covering this. * Add articles and comments whenever you have something to say. Your argument might help one of the lawyers make his case. (One of "our" lawyers, one hopes.) Hal Finney's article this morning falls squarely into this category. We may have few lawyers amongst us, but we can contribute comments and background items that the lawyers may find useful. Not much time left before the grand jury convenes on Wednesday, but time to help after that. I agree of course with the sentiment that "Cypherpunks write code," or at least write text on semi-technical topics, and agree with the current focus of our group on stuff like remailers, digital cash, data havens, and the like. The EFF, CPSR, and ACLU are already focussed on issues of legal cases, privacy laws, etc., and are staffed with mostly lawyers and legal-background folks. We fill a niche they cannot fill. * Phil Karn and others have written about DES implementations that are already described, published, etc., both inside and outside the U.S. This may help with the precedent issue, namely, establishing that DES is already widely available (in case this is an important issue). In particular, see the messages a few days back about compiling a list of published DES (and IDEA, too) codings. Add to the list if you can. Cypherpunks can help on this, if they have some experience with DES, IDEA, and the like. Perhaps after the indictment (I'm guessing there'll be one) we can find out from the lawyers if our backgrounds in hacking and crypto can be tapped to help in the defense. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From khijol!erc at apple.com Sun Sep 19 13:09:47 1993 From: khijol!erc at apple.com (Ed Carp) Date: Sun, 19 Sep 93 13:09:47 PDT Subject: more deranged lunatic ravings -- just delete 'em! In-Reply-To: <9309191916.AA05457@netcom4.netcom.com> Message-ID: > erc at apple.com said: > >Nope. That's not the point, and you know it. The point being (and I'm not > >even sure why I'm bothering to explain this to you - you're intelligent) > >this case has the potential to affect ALL of us, not just the participants > >in the case. > > True. But the question is, specifically what are you suggesting "all of us" > do right now? When I say specifically, I mean for instance not just > "find out information about XYZ" like you said before, I mean the > "and then what?" part as well. Most of us will probably do our best to > learn whatever we can rather than ignoring the situation. But *then* what? > What's your suggestion? > > >Well, scratching my crotch and looking important HAD crossed my mind. :) > > Besides that, I mean. :-) Hehehe... :) Gee, I don't *know* - but I'm not the high-powered brains behind this outfit - that's Tim's job. ;) And he has made good suggestions, too! I just don't agree with Perry's apparant advice that we all just sit around on our collective asses with our heads in the sand, waiting for Big Brother to come and roll over us. :) -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From vznquest at well.sf.ca.us Sun Sep 19 13:35:52 1993 From: vznquest at well.sf.ca.us (Alan E. Mason) Date: Sun, 19 Sep 93 13:35:52 PDT Subject: Cypherbusts, etc. Message-ID: <93Sep19.133139pdt.14391-4@well.sf.ca.us> I just heard about the grand jury BS going down around PGP, etc, via the EFF forum on the Well and would like to do whatever I can to support the defense effort (when it comes) etc. I am a writer with some small access to local media and a big interest in the outcome of this test of our 1st amendment rights. I would also like to get on your "mailing list" if you have one. Mail should be sent to vznquest at netcom.com Thanks, and keep up the good work! Alan Mason From pmetzger at lehman.com Sun Sep 19 14:09:48 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 19 Sep 93 14:09:48 PDT Subject: What can we do in the next few days? In-Reply-To: <9309191920.AA25767@netcom5.netcom.com> Message-ID: <9309192107.AA09104@snark.lehman.com> Timothy C. May says: > > Lots of flames lately about "lunatic ravings" and what Cypherpunks can > or can't do to help in the next few days. > > Here's my take on the situation: > [rest elided.] What he said. Thank you, Tim. Perry From strick at osc Sun Sep 19 14:19:47 1993 From: strick at osc (strick -- henry strickland) Date: Sun, 19 Sep 93 14:19:47 PDT Subject: GOPHER: dealing with postscript In-Reply-To: <9309190629.AA02026@flammulated.owlnet.rice.edu> Message-ID: <9309191943.AA02835@versant.com> THUS SPAKE Karl Lui Barrus : # # Also, where is the "Digital Silk Road" paper? I'd like to put the # text version in the "Digital Cash" section. I'd also like to put the # two reports at cwi up, but those are postscript... Suggestion: Put them under a gopher subdirectory named "Postscript Files" inside the directory they are appropriate to. Then by default people see the plaintext files and the "Postscript Files" subdirectory. If people are postscript-capable, they can then go down the next level. Or append "(Postscript)" to the displayed file name, to make it clear that way. As MIME becomes integrated into internet tools and widely available, this problem will solve itself. "application/postscript" is already a standard MIME Content-Type. In the meantime, don't shy away from making information available, especially if it is in a format as "widely accessible" as postscript is. strick From pmetzger at lehman.com Sun Sep 19 14:25:54 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 19 Sep 93 14:25:54 PDT Subject: more deranged lunatic ravings -- just delete 'em! In-Reply-To: Message-ID: <9309192122.AA09137@snark.lehman.com> Ed Carp says: > > True. But the question is, specifically what are you suggesting "all of us" > > do right now? When I say specifically, I mean for instance not just > > "find out information about XYZ" like you said before, I mean the > > "and then what?" part as well. Most of us will probably do our best to > > learn whatever we can rather than ignoring the situation. But *then* what? > > What's your suggestion? > > > Gee, I don't *know* - but I'm not the high-powered brains behind > this outfit - that's Tim's job. ;) And he has made good suggestions, too! > > I just don't agree with Perry's apparant advice that we all just sit > around on our collective asses with our heads in the sand, waiting > for Big Brother to come and roll over us. Thats not my advice. I just recommend that we leave the lawyering to the lawyers or those who, like John Gilmore or Dan Bernstein, have learned enough that they might be able to tell valuable things to them. The rest of us have many things we can do, which Tim has already said, but among them are... 1) Code! Code! Code! The more stuff is out there, the less they will be able to do. 2) Spread cryptographic software. 3) Catalog publically available cryptographic software overseas on the net. The lawyers might need this. 4) Catalog publically available cryptographic software and textbook descriptions in the U.S. -- the lawyers might need this. 5) Write articles describing the overall picture and get them published. 6) Keep informed. etc. Perry From mech at eff.org Sun Sep 19 14:49:48 1993 From: mech at eff.org (Stanton McCandlish) Date: Sun, 19 Sep 93 14:49:48 PDT Subject: Cypherbusts, etc. In-Reply-To: <93Sep19.133139pdt.14391-4@well.sf.ca.us> Message-ID: <199309192147.AA15250@eff.org> > I just heard about the grand jury BS going down around PGP, etc, via the > EFF forum on the Well and would like to do whatever I can to support the > defense effort (when it comes) etc. I am a writer with some small access to > local media and a big interest in the outcome of this test of our 1st > amendment rights. Great! One thing to do would be to do editorials for as many papers as possible. The greatest problem facing "us" (meaning anyone opposing the clipper fiasco), is that the general populace are ignorant, by and large of the following things: 1) what encryption/cryptography is, and why they should care. 2) that any successful attempt to squash public cryptography and replace it with govt. spy-mechanisms sets a really terrible precedent. In following decades we would likely see the removal of more rights and privacy, and the approval of ever more invasive "law enforcement" techniques. 3) what the history of agencies such as NSA and the SS is, and why they are not to be trusted (noting that Treasury controls not only Customs, who are responsible for enforcing many of the laws affecting crypto, but the SS, and BATF, could be of use. We are supposed to trust some unspecified Treasury sub-bureaucracy [not to mention NIST] to hold the keys to our privacy in the right hand, while menacing users of private cryptography via subpoenas and grand juries with the left hand?) 4) that BILLIONS of dollars every year are lost by US businesses to the industrial espionage of foreign competitors, who are under no ITARish restrictions on how they protect what they hold. 5) that the ITAR and the Clipper/Capstone/Clipjack scheme threatens to destroy the US market for cryptographic applications, while this market, with a potential easily in the billions of dollars per year, goes to other nations. With one exception of course: PKP/RSADSI, who have a virtual monopoly on crypto in this country due to patents on algorithms (aka "ownership" of properties of mathematics, "possession" of natural processes of the universe. What next? Will GE get a trademark on sunlight?) Ask the hard question: What is the relationship between PKP/RSA and the US Government? Why is RSA granted these patents? Why does NIST insist on giving exclusive license on DSA encryption to RSA, despite the fact that DSA was developed with YOUR tax money, not the capital of a private business entity? 6) that it is painfully obvious that the "to stop drug dealers, child molesters, and terrorists" rhetoric is a very lame and transparent excuse. Not even a stupid criminal would use crypto that the govt. freely admits was designed with wiretapping in mind. The ONLY way that Clipper could be useful is if all other forms of cryptography that the govt. cannot crack are BANNED outright. Given that it seems clear that the targets are not nebulous Bad Guys (TM), but the US citizenry at large. Lest this sound paranoid, note that even when directly asked, the govt. has yet to deny it is NOT considering banning non-Clipper cryptographic applications. Beyond this, the original proposal hinted strongly that the "key escrow agents" would not be govt. agencies. So much for that. NSA's lackey, NIST, on one hand, and our friends the Treasury on the other. Boy, I sure feel safe, don't you? There's plenty of other issues, but that's a good place to start. As has been adequately hashed out here, there's not much for J. Random Citizen to do about the subpoenas. This does not hold true of the entire Clipper scheme, nor of the NIST/PKP scandal. Make it plain to your readers that crypto is important, and is for them. Make it obvious that they DO have a stake in what is going on right now, and they can play a part. > I would also like to get on your "mailing list" if you have one. Send a message with "SUBSCRIBE " in the BODY of the message to cypherpunks-request at toad.com. -- DISCLAIMER: This message represents only my OWN opinion, not that of EFF. Stanton McCandlish Electronic Frontier Foundation Online Activist mech at eff.org NitV-DataCenter BBS SysOp Fido: IndraNet: 369:111/1 From erc at wetware.com Sun Sep 19 15:29:48 1993 From: erc at wetware.com (Ed Carp) Date: Sun, 19 Sep 93 15:29:48 PDT Subject: (fwd) New Intel Slogan Message-ID: Path: khijol!wetware!iggy.GW.Vitalink.COM!pacbell.com!ames!agate!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!uunet.ca!wildcan!news2.uunet.ca!xenitec!looking!funny-request Message-ID: Date: Sat, 18 Sep 93 19:30:02 EDT Newsgroups: rec.humor.funny Subject: New Intel Slogan From: shah at santur.nuo.dec.com (Amitabh Shah) Keywords: topical, smirk, original Approved: funny at clarinet.com Lines: 17 [This is original.] In view of the recent burglaries at computer warehouses in the Silicon Valley, where the burglars have stolen Intel's x86 processor chips, Intel has decided to use a new corporate slogan. The idea for this slogan is based on the theft-resistant stickers seen on the windows of cars in NYC. All stores carrying/manufacturing PCs made with Intel's processors, as well as the PCs themselves will now bear a sticker that says: "No Intel Inside". -- Selected by Maddi Hausmann. MAIL your joke (jokes ONLY) to funny at clarinet.com. Please! No copyrighted stuff. Also no "mouse balls," dyslexic agnostics, Iraqi driver's ed, Administratium, strings in bar or bell-ringer jokes. -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From magdalen at well.sf.ca.us Sun Sep 19 16:26:57 1993 From: magdalen at well.sf.ca.us (Tiffany Lee Brown) Date: Sun, 19 Sep 93 16:26:57 PDT Subject: more deranged lunatic ravings ... Message-ID: <93Sep19.162406pdt.14406-3@well.sf.ca.us> The recent flood of rantmail between Perry Metzger, E. Carp, etc., started as an interesting and relevant argument but has degenerated to the point of annoyance. The former suggested calming down and writing some code - perhaps he could go off and do just that, rather than wasting his time (and ours) trying to keep folx from encouraging others to engage in personal investigation of an issue which concerns them. If you think writing code's the only thing to do - go do it. If you think getting people riled up about the situation is important - go do it. Yammering at each other ain't gonna make the world a safer and more private place. -magdalen From bill at twwells.com Sun Sep 19 17:06:57 1993 From: bill at twwells.com (T. William Wells) Date: Sun, 19 Sep 93 17:06:57 PDT Subject: Definition of "Zero Knowledge" In-Reply-To: <9309191615.AA18299@netcom4.netcom.com> Message-ID: In article <9309191615.AA18299 at netcom4.netcom.com>, Doug Merritt wrote: : An arbitrary algorithm can be translated into a zero proof theory model : that is intractable to functionally analyze. Its operations on inputs and : outputs can take place within the realm of the intractable model, with : the inputs and outputs being transformed from the encoding of the outside : realm into an encoding useful to the realm of the model. The inputs and : outputs are the queries and answers of zero proof theory. : : With such a thing, knowing every detail of the registers and instructions : being executed at all times still wouldn't tell you what you really : wanted to know. So, with such a translated algorithm, even if I had the complete source code, I would be unable to determine what it does? If you create one of these, be sure to submit it to the Obfuscated C contest; it'll be the ultimate! :-) : I'm unsure whether this has been published, let alone implemented; I just : thought it was an obvious corollary back when ZPT itself was first published. : It might have been discussed in the literature at the time, but if so, : I've forgotten. Got a good reference for ZPT? Something that the mathematically inclined, who wants just the facts, all the facts, and none of the BS that passes for explanations and which usually obscures more than it clarifies? From frc%bwnmr4 at harvard.harvard.edu Sun Sep 19 17:36:57 1993 From: frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) Date: Sun, 19 Sep 93 17:36:57 PDT Subject: Definition of "Zero Knowledge" (fwd) Message-ID: <9309200033.AA17197@bwnmr4.harvard.edu> Forwarded message: > From frc Sun Sep 19 20:22:47 1993 > Subject: Re: Definition of "Zero Knowledge" > To: erc at apple.com > Date: Sun, 19 Sep 93 20:22:47 EDT > In-Reply-To: ; from "Ed Carp" at Sep 18, 93 9:16 pm > > Thanks for the definition (but I knew that, anyway). Sorru I wasn't clear - > > what I was looking for was examples of how zero-knowledge proof techniques > > could make source code impenetrable. > > Source would be nice, too... ;) > Check out a product called C-Shroud by ??Gimpel Software... > I think it does this.. or at least tries.... > FRC I meant to send this across the list, and not just to erc. Here's it is for everyone else. FRC From doug at netcom.com Sun Sep 19 17:40:55 1993 From: doug at netcom.com (Doug Merritt) Date: Sun, 19 Sep 93 17:40:55 PDT Subject: Definition of "Zero Knowledge" Message-ID: <9309200038.AA04119@netcom.netcom.com> bill at twwells.com (T. William Wells) said: >Got a good reference for ZPT? Something that the mathematically >inclined, who wants just the facts, all the facts, and none of >the BS that passes for explanations and which usually obscures >more than it clarifies? In the current context, the best reference that I know of is to the methodology of Goedel's Theorem rather than to ZPT; it has each of the properties that I mentioned except for the ZPT operations, which can be added in a conceptually straightforward way. The most readable in depth treatment of that that I know of is "Goedel's Proof" by Ernest Nagel and James R. Newman, c. 1958 and still in print as a cheap paperback. If someone has good ZPT references that would be interesting too; I've lost the stuff I used to have on that. Doug From tcmay at netcom.com Sun Sep 19 18:15:55 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 19 Sep 93 18:15:55 PDT Subject: Definition of "Zero Knowledge" In-Reply-To: <9309200038.AA04119@netcom.netcom.com> Message-ID: <9309200113.AA27507@netcom5.netcom.com> > In the current context, the best reference that I know of is to > the methodology of Goedel's Theorem rather than to ZPT; it has each > of the properties that I mentioned except for the ZPT operations, > which can be added in a conceptually straightforward way. The most > readable in depth treatment of that that I know of is "Goedel's Proof" > by Ernest Nagel and James R. Newman, c. 1958 and still in print as > a cheap paperback. > > If someone has good ZPT references that would be interesting too; I've > lost the stuff I used to have on that. > Doug Doug, I am not aware that the zero knowledge results of Goldwasser, Micali, Rackoff, etc., circa 1984-5, are actually implied by Godel's results of the 1930s. I'd be very intrigued to hear more about this. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From ANSPRING at delphi.com Sun Sep 19 18:30:56 1993 From: ANSPRING at delphi.com (ANSPRING at delphi.com) Date: Sun, 19 Sep 93 18:30:56 PDT Subject: Restrictions on crypto exports Message-ID: <01H35AR2BPS68ZEFI2@delphi.com> hal finney quotes: "Public domain" is defined in 120.18: "Public domain means information which is published and which is generally accessible to the public: (a) Through sales at newsstands and bookstores; (b) Through subscriptions which are available without restriction to any individual who desires to obtain or purchase the published information; (c) Through second class mailing privileges granted by the U.S. Government; or, (d) At libraries open to the public." I'm way out of my depth here, but can it be argued that what constitutes ublic domain" is not being exhaustively defined here? That is, does the legalese here mean that ONLY a,b,c, and d publishing modes are PD, or can you argue that a,b,c, and d are just *examples* of PD publishing, and that there are other modes that just weren't mentioned. If making something available for anonymous FTP is not putting it in the public domain, then what the hech is it? From ld231782 at longs.lance.colostate.edu Sun Sep 19 18:35:56 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sun, 19 Sep 93 18:35:56 PDT Subject: Attn: P. Metzger and an36440, please delete this immediately Message-ID: <9309200134.AA00413@longs.lance.colostate.edu> Forwarded from J. Bidzos. this actually *strengthens* the NSA theories. (go ahead, flame me some more. I've been called, culling from all the best, a ``screaming, ranting, hysterical, yammering lunatic running about like a headless barnyard fowl just adding noise and confusion'' -- can anyone top that?) I'm leaving out Bidzos' email address so he is not harassed any further than I've already done :) ------- Forwarded Message Date: Sun, 19 Sep 93 11:17:18 PDT Message-Id: <9309191817.AA10201 at RSA.COM> To: ld231782 at longs.lance.colostate.edu In-Reply-To: "L. Detweiler"'s message of Sat, 18 Sep 93 17:24:41 -0600 <9309182324.AA10638 at longs.lance.colostate.edu> Subject: PGP & Moby Crypto investigation PKP, RSA, nor I have anything to do with this subpoena business. No complaint has been filed. This looks to be an investigation into violation of export laws, but I don't know. ------- End of Forwarded Message From khijol!erc at apple.com Sun Sep 19 18:41:58 1993 From: khijol!erc at apple.com (Ed Carp) Date: Sun, 19 Sep 93 18:41:58 PDT Subject: Definition of "Zero Knowledge" In-Reply-To: <9309200038.AA04119@netcom.netcom.com> Message-ID: > In the current context, the best reference that I know of is to > the methodology of Goedel's Theorem rather than to ZPT; it has each > of the properties that I mentioned except for the ZPT operations, > which can be added in a conceptually straightforward way. The most > readable in depth treatment of that that I know of is "Goedel's Proof" > by Ernest Nagel and James R. Newman, c. 1958 and still in print as > a cheap paperback. This reminds me of a science fiction story that I read once, published in Analog: the smart-ass encrypted the solution of how to produce stable antimatter, or cold fusion, or something similar, using Godel's Theorem. The politicos back on Earth said that it would take them 200 years to factor the N-size number that was sent back to Earth. :) Now, if I could just remember the name of the story and the issue... -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From pmetzger at lehman.com Sun Sep 19 19:15:57 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 19 Sep 93 19:15:57 PDT Subject: Attn: P. Metzger and an36440, please delete this immediately In-Reply-To: <9309200134.AA00413@longs.lance.colostate.edu> Message-ID: <9309200214.AA09657@snark.lehman.com> "L. Detweiler" says: > Forwarded from J. Bidzos. > > this actually *strengthens* the NSA theories. What theories? We *know* they are the ones who care about crypto and have been trying to keep it restricted. This is as interesting as saying "you know, I think that France is in Europe." Some have accurately made the statement that the NSA does not directly enforce any anti crypto export regulations but has to act through the commerce department and the department of state, but we all know that they are the ones who care in the long run. As for who in particular set off this investigation, well, what does that matter? Lets say that it was the NSA. Does this change anyone's strategy here? > (go ahead, flame me some more. I've been called, culling from all the > best, a ``screaming, ranting, hysterical, yammering lunatic running > about like a headless barnyard fowl just adding noise and confusion'' > -- can anyone top that?) Nah. I think that I pretty much summarized it the first time, although you are misquoting me, in so far as I didn't use all those terms in one phrase. Perry From MIKEINGLE at delphi.com Sun Sep 19 19:25:57 1993 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Sun, 19 Sep 93 19:25:57 PDT Subject: Cryptophone Message-ID: <01H35CYYEGKY91WN6Y@delphi.com> Where is the cryptophone project? I haven't seen anything about it for a while. Last I read, a company had a commercial triple-DES product with no public key - has anyone seen this? How is the sound quality? The cryptophone is the best way to drive a stake through the heart of Clipper. Suppose someone writes a crypto program and gives it to some friends. One of the friends uploads it to a BBS. Someone calls up from a foreign country and downloads it from the BBS. Who is at fault? The person who wrote it, for not retaining control over his product? The friend who uploaded it, for placing it where a foreigner could access it? The operator of the BBS, for not screening the file and preventing the foreigner from downloading it? Or the foreigner himself, who is probably out of range of U.S. law in any case? Suppose someone writes a crypto program and makes it generally available to anyone who wants it. It goes out of the country, but there is no way to know who sent it out of the country or how. Can they prosecute the person who wrote it for not maintaining control over it? If they can, this means, among other things, that selling the Norton Utilities to someone without checking to see that they are a citizen is illegal, and that having PKZIP on your BBS is illegal. If the precedent gets established that the person who writes such a program is responsible for keeping it out of the hands of foreigners, that would be a big problem. All crypto would have to be published anonymously, because nobody could risk signing their name to it. This must not happen! The flamewar going on here is counterproductive; they must be laughing down at the fort. --- MikeIngle at delphi.com From remailer at netcom.com Sun Sep 19 19:26:59 1993 From: remailer at netcom.com (remailer at netcom.com) Date: Sun, 19 Sep 93 19:26:59 PDT Subject: reporter seeking interview subjects Message-ID: <9309200220.AA14061@mail.netcom.com> At 11:35 AM 9/19/93 -0400, Stanton McCandlish wrote: >> > looking for interesting "case studies" that I can use to horrify >> > my listeners out of their complacency. My most immediate need is >> ^^^^^^^^^^^^^^ >> >> Just what I love from the media, using sensationalism to convey a >> preconceived idea instead of looking at the facts and reporting it. >> Does it matter that he is reporting on our side and not the other >> side? > >Why of course it does. No wishing and praying will make the media suddely >become pure and holy. This is a propaganda war, and there's no reason >for both sides not to get in on the act. Otherwise, it's like fighting >guns with slingshots. No horror, no story. Who wants to hear a story about how they're perfectly safe letting the world look at their medical history? If that was true, no one would want to hear about it on the radio. From frissell at panix.com Sun Sep 19 19:29:50 1993 From: frissell at panix.com (Duncan Frissell) Date: Sun, 19 Sep 93 19:29:50 PDT Subject: Crypto crackdown - this i Message-ID: <199309200226.AA17164@panix.com> F >Unless you are judgement proof. Since I have received 4 pieces of E-mail asking for a definition, I will beg the indulgance of the list... Being 'judgement proof' means that even if a civil judgement is obtained against you, it cannot be satisfied. It means that you have no attachable property. The property can be in the name of another person or entity or in another jurisdiction. It is a very relaxing feeling. In the mid '80s for example when Roy Cohn (of the Army-McCarthy Hearings) was dying of AIDS, he had outstanding judgments of almost $1.5 million against him from the IRS and private parties. Meanwhile, he lived in a brownstone on the upper east side of Manhattan, used a house in the Hamptons, and regularly flew Concorde to Europe. The judgements were never executed against him, however because he had no money. He was judgment proof. The houses and other perks were supplied to him by the law firm of which he was an obviously valuble employee. Judgement proofing yourself is a powerfull concept. Duncan Frissell Who has remained judgment proof for years by employing the oldest trick in the book -- transferring all of his assets to the brains of his children (via various educational institutions) where they are immune to siezure. --- WinQwk 2.0b#0 From mgream at acacia.itd.uts.edu.au Sun Sep 19 19:49:50 1993 From: mgream at acacia.itd.uts.edu.au (Matthew Gream) Date: Sun, 19 Sep 93 19:49:50 PDT Subject: Does this seem illegal to you? In-Reply-To: <9309191523.AA08506@snark.lehman.com> Message-ID: <9309200247.AA03875@acacia.itd.uts.EDU.AU> In reply to (Perry E. Metzger): | If he has her phone number, and its listed, he can check any reverse | phone directory, get her address, and do this anyway. He doesn't need | spring telemap. If she's stupid enough not to get an unlisted number, | then Sprint Telemap isn't going to do anything worse than what can be | done already. A company over here in Australia rekeyed the telephone directory offshore and offered a reverse-directory on our 0055 system (analogous to your 900s), there was considerable uproar over the facility. Firstly the police and community groups (including privacy groups) were of course angered at the ability for criminals to reverse lookup targets. The 'teleco' also made some vague allegations about the legitimacy of rekeying their phone- books. Anyway, under considerable pressure, reverse directory lookups were removed for all 'residential' numbers, although the director of the company was adamant that he was under no legal obligation to do so, but took the action due to 'public concern'. It should also be noted that from the outset the company did provide the ability for people to dial up a secondary number and have their entry removed. Although, it must be said that CDROM whitepages are available, and i'm ignorant of what limitations have been built into them to stop people (i.e. corporations) turning them into reverse directories. I thought it was interesting enough when the original poster talked about the TeleMap service, but to now find out that reverse directories are 'common', ho hum. Matthew. -- Matthew Gream,, M.Gream at uts.edu.au -- Consent Technologies, 02-821-2043. From pmetzger at lehman.com Sun Sep 19 19:55:57 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 19 Sep 93 19:55:57 PDT Subject: Cryptophone In-Reply-To: <01H35CYYEGKY91WN6Y@delphi.com> Message-ID: <9309200251.AA09720@snark.lehman.com> Mike Ingle says: > Where is the cryptophone project? There is no one such project. There are several of them that I know of. If you think its an interesting thing to do, I strongly encourage working on it on your own -- its not the sort of thing that requires lots of people working on it, but it is the sort of thing that more people talk about than do. > I haven't seen anything about it for a while. Last I read, a company > had a commercial triple-DES product with no public key - has anyone > seen this? How is the sound quality? The cryptophone is the best way > to drive a stake through the heart of Clipper. I fully agree. Recent developments have been interesting on other fronts. 24kbps and 28kbps modems have arrived on the market, albeit at high prices. When the final V.Fast standard comes in, 28kbps modems should cost only a few hundred dollars. Although ordinary workstations can't do CELP fast enough, GSM appears to be easily workable even on "normal" computers. > Suppose someone writes a crypto program and gives it to some friends. One of > the friends uploads it to a BBS. Someone calls up from a foreign country and > downloads it from the BBS. Who is at fault? The person who wrote it, for not > retaining control over his product? The friend who uploaded it, for placing > it where a foreigner could access it? The operator of the BBS, for not > screening the file and preventing the foreigner from downloading it? Or the > foreigner himself, who is probably out of range of U.S. law in any case? There is no case law or statute on this. The folks writing the laws didn't understand computers and had no notion of the fact that it was possible for someone physically outside the country to access information physically inside the country. With luck, the case will simply be overturned, and there may never be any case law defining this silly form of "export". Perry From bill at twwells.com Sun Sep 19 20:07:27 1993 From: bill at twwells.com (T. William Wells) Date: Sun, 19 Sep 93 20:07:27 PDT Subject: Definition of "Zero Knowledge" In-Reply-To: <9309200038.AA04119@netcom.netcom.com> Message-ID: In article <9309200038.AA04119 at netcom.netcom.com>, Doug Merritt wrote: : The most : readable in depth treatment of that that I know of is "Goedel's Proof" : by Ernest Nagel and James R. Newman, c. 1958 and still in print as : a cheap paperback. I have that book. It's a good one. It's exactly the sort of thing I was referring to. From mnemonic at eff.org Sun Sep 19 20:35:57 1993 From: mnemonic at eff.org (Mike Godwin) Date: Sun, 19 Sep 93 20:35:57 PDT Subject: Restrictions on crypto exports In-Reply-To: <01H35AR2BPS68ZEFI2@delphi.com> Message-ID: <199309200332.AA16970@eff.org> ANSPRING asks: > hal finney quotes: > > "Public domain" is defined in 120.18: "Public domain means information > which is published and which is generally accessible to the public: > (a) Through sales at newsstands and bookstores; (b) Through subscriptions > which are available without restriction to any individual who desires > to obtain or purchase the published information; (c) Through second class > mailing privileges granted by the U.S. Government; or, (d) At libraries > open to the public." > > I'm way out of my depth here, but can it be argued that what constitutes > > ublic domain" is not being exhaustively defined here? It matters not, IMHO, since an ftp archive site qualifies as a library open to the public. --Mike From stig at netcom.com Sun Sep 19 20:39:50 1993 From: stig at netcom.com (Stig) Date: Sun, 19 Sep 93 20:39:50 PDT Subject: reporter seeking interview subjects In-Reply-To: Message-ID: <9309200337.AA13543@netcom3.netcom.com> In <93Sep17.230857pdt.14382-4 at well.sf.ca.us>, Matt Binder wrote... > Hi, my name is Matt Binder. Please help me... > I'm a radio reporter in the SF Bay area working on a series > of pieces about invasions of privacy in the computer age. I'm > looking for interesting "case studies" that I can use to horrify > my listeners out of their complacency. I think it's really important that if you're looking to shock your audience that you also show a glimpse of not only the "light at the end of the tunnel" but also a glimpse of the reasons that people would be better off making a dash for the end of the tunnel than trying to run back to the tunnel's start. Otherwise, you're just fueling the anxieties of countless luddites and techonophobes. > My most immediate need is > to find someone whose medical records were used (perused!) I hardly speak for all of the cypherpunks, of course, but generally we work the "Big Brother" side of the street. There are others who are more on top of this sort of thing. Judyc at well might be a good resource for this sort of thing. Stig ;; __________________________________________________________________________ ;; Stig at netcom.com netcom.com:/pub/stig/00-PGP-KEY ;; It's hard to be cutting-edge at your own pace... 32 DF B9 19 AE 28 D1 7A ;; Bullet-proof code cannot stand up to teflon bugs. A3 9D 0B 1A 33 13 4D 7F From jkhastings at aol.com Sun Sep 19 20:40:57 1993 From: jkhastings at aol.com (jkhastings at aol.com) Date: Sun, 19 Sep 93 20:40:57 PDT Subject: Retry flyer Message-ID: <9309192329.tn62002@aol.com> I got some strange mail failure messages from my speech flyer. This attempt won't include any "cc:" to extropians. --------------------------------------------------- "State Evader" comes out of the Green Dragon Tavern BBS (213) 365-1132 pseudonym closet to shamelessly promote his upcoming speeches at the H.L. Mencken Forum and the Libertarian Party of CA Region 62 Los Angeles Westside: ------------------------------------------------------------ State Evader = J. Kent Hastings Assistant Director of the Agorist Institute, "Techtics" columnist for the Tactics of the Movement of the Libertarian Left newsletter, internet cypherpunk, and ham radio operator WA6ZFY. Both speeches will be on the topic: "Cyber Cash: Free Market Money Comes of Age" I will talk about untraceable digital cash, public-key cryptography, spread-spectrum radio, unmanned vehicles, and the latest government actions that threaten everyone's privacy: The Clipper/ Skipjack key escrow agents and the subpoenas served to the Austin Code Works and ViaCrypt for all PGP, RSA export info. -------------------------------------------------------------- Mencken info: (310) 289-3234 (reserve now!) L.P. info: (310) 477-6491 -------------------------- Mencken location: The Old Spaghetti Factory 5939 Sunset Blvd near Hollywood Freeway in L.A. Wednesday September 22, 1993 6:30 Libations, 7:00 Dinner, 8:00 Speaker, 10:00 Adjourn ment First time "virgins" reserved: $3 -------------------------------------------------- L.P. of CA Region 62 L.A. Westside: Chris's Italian Restaurant 10105 Venice Blvd. at Clarington Ave Thursday, September 23, 1993 Cocktails 6:30, Dinner 7:00, Talk 8:30 Not sure if admission is charged. ---------------------------------------------- Kent - From ld231782 at longs.lance.colostate.edu Sun Sep 19 20:52:00 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sun, 19 Sep 93 20:52:00 PDT Subject: key escrow procedures In-Reply-To: <199309181851.AA05084@eff.org> Message-ID: <9309200349.AA03036@longs.lance.colostate.edu> C. Ellison: > Meanwhile, where is the proof that the key being requested corresponds to > a person on whom a wiretap has been ordered? M. Godwin: >The authorized key request will normally occur after law-enforcement >officials have snagged the chip serial number from the LEAF >(law-enforcement field) of the signal they captured with an authorized >wiretap. This begs the question. Does anybody pay any attention to what I write? I addressed this in my posting -- if the police send the device ID of the LEAF field via *fax* what is to prevent different officers from trading IDs? the fundamental point is that the key escrow agency *only* gets a request for a key based on an ID -- how do they know the `warrant' given them actually applies to *that* key ID? answer: they don't. and as I wrote: is there *any* circumstance under which a key escrow agency rejects a key request? if not, WHAT'S THE POINT? ah yes, what we need is a PHONE REGISTRATION DATABASE (BWAHAHAHA <- insane depraved mad laugh). T.C. May wrote a long time ago about the possibility of a `black market' in key ID exchange among the police. What's to prevent it? the point is that the NSA in its wretchedly naive way is treating the police as a SECURE COMPONENT. there might be ways of alleviating this, such as ensuring that the link from the `black box' to the key escrow agency is secure, as I wrote. We have to wait for this idea to penetrate the brain of Mr. GraveDigger of the NSA who's in charge of the design. again, though, this all only shows the sheer intellectual bankruptcy of the key escrow aspect of the Key Escrow Proposal. if I heard that NSA was improving their thought control techniques based on anything I write I would burn all my email... NSA Clipper Slogan: KEY ESCROW: LEAVE THE DETAILS TO US. From ld231782 at longs.lance.colostate.edu Sun Sep 19 21:07:01 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sun, 19 Sep 93 21:07:01 PDT Subject: Bidzos on ITAR Message-ID: <9309200405.AA03325@longs.lance.colostate.edu> Responding to H. Finney's probing, sterling, and brilliant analysis of ITAR (which I was utterly embarrassed to see buried and sandwiched in sordid flames) J. Bidzos claims that ``The ITAR specifically exempts software from being considered public domain'' and points out that the PKP FTP site in question that H. refers to as `causing a big stink' was *non-anonymous*. I would like to see J. Bidzos' sci.crypt posting reposted here *ASAP* by some bored cypherpunk who would like to ``contribute''! Major cyberspace points await! From an15348 at anon.penet.fi Sun Sep 19 21:15:57 1993 From: an15348 at anon.penet.fi (Gideon) Date: Sun, 19 Sep 93 21:15:57 PDT Subject: Does this seem illegal? Message-ID: <9309200412.AA03705@anon.penet.fi> * Reply to msg originally in CYPHERPUNKS Uu> From: gg at well.sf.ca.us ("George A. Gleason") Uu> ...Thank you, operator. A warm bulge rises in your pants as Uu> you contemplate your next move. Boy are you going to teach her a Uu> lesson! Uu> This special moment brought to you by Sprint TeleMap. Wait. You've done this before, right? ___ Blue Wave/QWK v2.12 ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From doug at netcom.com Sun Sep 19 22:16:00 1993 From: doug at netcom.com (Doug Merritt) Date: Sun, 19 Sep 93 22:16:00 PDT Subject: Definition of "Zero Knowledge" Message-ID: <9309200512.AA11486@netcom4.netcom.com> khijol!erc at apple.com (Ed Carp) said: >This reminds me of a science fiction story that I read once, published in >Analog: the smart-ass encrypted the solution of how to produce stable >antimatter, or cold fusion, or something similar, using Godel's Theorem. > >The politicos back on Earth said that it would take them 200 years to >factor the N-size number that was sent back to Earth. :) > >Now, if I could just remember the name of the story and the issue... "The Gold at the Starbow's End", Frederik Pohl, Ballantine Books, 1972. Serialized in Analog in '71 or 72. Great book! You're showing your age. ;-) ( Like I'm not...if anyone on the list wasn't born at that point, I don't wanna hear about it :-) I think this was the first place I ever heard of Go"del numbering. Doug From doug at netcom.com Sun Sep 19 22:19:53 1993 From: doug at netcom.com (Doug Merritt) Date: Sun, 19 Sep 93 22:19:53 PDT Subject: Does this seem illegal to you? Message-ID: <9309200517.AA12216@netcom4.netcom.com> mgream at acacia.itd.uts.edu.au (Matthew Gream) said: >Although, it must be said that CDROM whitepages are available, and i'm >ignorant of what limitations have been built into them to stop people >(i.e. corporations) turning them into reverse directories. In the U.S., you can buy CD-ROM white pages for the entire US for $99, and the same database reverse-directoried for another $99. (Approximately; this is from memory from a magazine ad I saw 4 days ago.) Such things have been available on paper for a long time, but this media and these prices will doubtless have social repercussions. As before, people can make a point of having their address not listed in any such directory, forward or reverse, if they're careful enough. However, the need to do so probably increases as reverse indexing becomes so vastly more available. Doug From ebrandt at jarthur.Claremont.EDU Sun Sep 19 22:55:59 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Sun, 19 Sep 93 22:55:59 PDT Subject: Definition of "Zero Knowledge" (fwd) In-Reply-To: <9309200033.AA17197@bwnmr4.harvard.edu> Message-ID: <9309200552.AA25175@toad.com> > Check out a product called C-Shroud by ??Gimpel Software... > I think it does this.. or at least tries.... C-Shroud does nothing with zero-knowledge proofs, or anything nearly that sophisticated. It simply mungs identifiers, strips comments and whitespace, and things of that sort. The idea is to get the machine independence (heh) of C, with the unreadability (heh) of object code. It can't really be that hard to read -- after all, most of the human-work in disassembly is precisely the job of analyzing an uncommented HLL program with meaningless identifiers. Eli ebrandt at jarthur.claremont.edu From ebrandt at jarthur.Claremont.EDU Sun Sep 19 23:19:51 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Sun, 19 Sep 93 23:19:51 PDT Subject: Stegno and DAT and digital music... In-Reply-To: <199309131414.AA07464@access.digex.net> Message-ID: <9309200619.AA25512@toad.com> > improved the sound. He says that the original CD format was > limited to 16 bits of sound because of costs. But many audiophiles > reacted very negatively to the tinny, metalic quality to the music. Heh. Lack of sufficient bits for digital sound results in a floor of uniformly-distributed white noise for complex signals such as music. If audiophiles really hear "tinny" or "metallic" sound in double-blind tests, it would more likely be due to the sampling rate. The 44kHz rate means that skimping on the lowpass filter will push the cutoff into the audible range, which means you lose some upper harmonics and get to hear any phase nonlinearity in the filter. > For this reason, the companies have developed 20 bit DAT recording > tape and then come up with ways to "dither" this into 16 bits. > > I am curious if anyone knows the details of these algorithms. Round to 16 bits. The higher-precision recording format is good because it lets noise (e.g. from mixing up a quiet signal) chew off four bits before it gets on the CD. You can do a little better than rounding, but not much. > Also, his point suggests that flipping the least significant > bit of 16 bit music may not be imperceptable to some ears. It may well not be, particularly if you do it without regard to the piece's amplitude. That 6dB of hiss may be perceptible during pauses. A more subtle flaw is that the signal will have artificial statistical characteristics. Natural noise in recordings is typically Gaussian, not uniform noise covering exactly one bit. What this means is that if the LSB is total uncorrelated hash, the bit above will have some noise. Look at a quiet passage. If the LSB is noise city and the 14th is uniformly zero, somebody twiddled with the digital data. This is a more reasonable way of screening for this sort of steganography than hiring a bunch of audiophiles. One fix is to cover your nefarious LSB activities by first adding sufficient Gaussian noise. My intuition, however, is that any amount short of microwaving the CD will leave a little bit of correlation between the original and the noised lower bits. With sufficient data, I think you can burn through the Gaussian noise and get enough information to make a call on whether the LSB has been twiddled. And a CD is a lot of data. > -Peter Wayner Eli ebrandt at jarthur.claremont.edu From cvoid at netcom.com Sun Sep 19 23:22:30 1993 From: cvoid at netcom.com (Christian Void) Date: Sun, 19 Sep 93 23:22:30 PDT Subject: Newsgroup... Message-ID: So, is there a specific reason why someone hasn't created an newsgroup? It seems appropriate, as most of the current mass amounts of traffic are dedicated to paranoia and bickering... Christian Void /T71 | "I don't like it, and I'm sorry I | VMResearch, Inc. cvoid at netcom.COM | ever had anything to do with it." | P.O. Box 170213 Tel. 1+415-807-5491 | -Erwin Schrodinger (1887-1961) | SF, CA 94117 * PGP v2.3a Public Key Available Via Finger * From ld231782 at longs.lance.colostate.edu Sun Sep 19 23:49:53 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sun, 19 Sep 93 23:49:53 PDT Subject: Congrats to STANTON MCCANDLISH - EFF Online Activist Message-ID: <9309200646.AA06246@longs.lance.colostate.edu> Congratulations to S. McCandlish, a longtime BBS operator, cypherpunk loyalist and PGP promoter, who, if nobody else noticed, just won the coveted Online Activist position advertised by EFF some weeks ago. He has plans to put together an EFF BBS and archive on a fast machine with Internet connectivity. He'll be moving to Washington D.C. by October and running his previous BBS from there. Hope to hear more from him here on his progress! Maybe he can sneak a few subversive cypherpunk rants onto the archive! :) From jersmit at eis.calstate.edu Mon Sep 20 00:32:30 1993 From: jersmit at eis.calstate.edu (Jeremy R. Smith) Date: Mon, 20 Sep 93 00:32:30 PDT Subject: Message to the net (fwd) Message-ID: This is a message a friend of mine wanted me to post on the 'Net. I figured the Cypherpunk list would be one of the best places to start. Jeremy Smith ---------- Forwarded message ---------- Date: 20 Sep 93 02:02:13 EDT From: Ole Grunbaum, 75320,672 To: Jeremy Smith, >INTERNET:jersmit at eis.calstate.edu Date: , 22:47 Subject: I am a Danish journalist, stationed in the US, writing for a daily newspaper in Copenhagen, mostly about technology, but also gennerally about culture. I am particularly interested in the political and ethical questions that computers and networks pose, pa rticularly in regards to government and large corporations. I have covered a lot of hacker cases, and right now I am interested in the Kevin Poulsen, alias Dark Dante, case. I am looking for people who know Kevin. I can not understand why he has been 30 mo nths now in custody without a court case. If anyone can help me, and are willing to talk to me, please write to my compuserve account, 75320,672 or internet: ogrunba at eis.calstate.edu - my name is Ole Grunbaum, and my newspaper is Politiken. From ld231782 at longs.lance.colostate.edu Mon Sep 20 00:46:02 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Mon, 20 Sep 93 00:46:02 PDT Subject: meaningless rumor Message-ID: <9309200742.AA07328@longs.lance.colostate.edu> >From a high-level source in contact with an *extremely* high level source: Rumor: Moby Crypto was targeted because G. Ward intended to include PGP on distribution disks. The investigation is primarily PGP oriented, and G. Ward is just a bystander who got caught up. PRZ & PGP is the essential target. Notes (1) phrasing of the subpoenas definitely confirms this -- PGP is mentioned in both. (2) can we find any Usenet postings where G. Ward announced intent to distribute PGP with Moby Crypto to help confirm this? (3) Current Underground Digest just came out -- it (contrarily) hypes the Moby Crypto `attack' as foremost, and *mislabels* PRZ's comments as `reaction to Moby Crypto attack' -- in fact, there is no indication that he knew of Moby Crypto when he wrote those. From smb at research.att.com Mon Sep 20 04:29:54 1993 From: smb at research.att.com (smb at research.att.com) Date: Mon, 20 Sep 93 04:29:54 PDT Subject: meaningless rumor Message-ID: <9309201128.AA29694@toad.com> From a high-level source in contact with an *extremely* high level source: Rumor: Moby Crypto was targeted because G. Ward intended to include PGP on distribution disks. The investigation is primarily PGP oriented, and G. Ward is just a bystander who got caught up. PRZ & PGP is the essential target. Notes (1) phrasing of the subpoenas definitely confirms this -- PGP is mentioned in both. (2) can we find any Usenet postings where G. Ward announced intent to distribute PGP with Moby Crypto to help confirm this? Ward posted a note that (in essence) asked for help in evading the ITARs. (Well, I suppose it could have been someone forging a posting...). He went so far as to offer to provide mailing labels to someone abroad who would redistribute Moby Crypto, though from a country where that would be legal -- but never said how the first copy would get to the trans- shipment point. Some reasons were given why this sequence was going to be technically legal -- but if you were a U.S. attorney investigating the export of cryptographic software, it's the sort of thing that almost has to be investigated. Face it -- if Ward *wanted* to generate a test case, he couldn't have done a much better job; a private note to the authorities could have been ``misfiled'', but an announcement to tens of thousands of readers around the world? C'mon -- they may or may not be stupid, and they may or may not be paranoid, but their entire raison d'etre is to wield power, and Grady just slapped that authority in the face. Spitting at your local traffic cop would have been a lot safer. As for PKP -- *somehow*, it wandered out of the U.S. Probably, someone in power decided that that finally needed investigating in detail, to see if a law was broken. And Sternlight is right -- if they decide to indict, they may throw in charges of importing IDEA, though I doubt that they'd indict just on those grounds; in an era of key escrow, they'd certainly like a court to rule they had the power to exclude subversive foreign crypto.... --Steve Bellovin From paul at poboy.b17c.ingr.com Mon Sep 20 05:52:37 1993 From: paul at poboy.b17c.ingr.com (Paul Robichaux) Date: Mon, 20 Sep 93 05:52:37 PDT Subject: What can we do in the next few days? (fwd) Message-ID: <199309201250.AA11675@poboy.b17c.ingr.com> > I wrote Grady Ward under separate cover about Bruce Schneier's > upcoming book, published by John Wiley & Sons.. Last I heard, its > title was "Practical Cryptography," and it's scheduled to hit the > streets around November 1st. > The book includes source code for DES, RSA, DH, IDEA, and several > others (Snefru and Lucifer?). IMHO its most salient feature is the > inclusion of that source code _on a floppy._ > This should probably be added to the reference list; I've emailed > Bruce to get the ISBN number and will post it when he responds. > Illegitimus nil carborundum, > -Paul -- Paul Robichaux, KD4JZG | "Change the world for a better tomorrow. But perobich at ingr.com | watch your ass today." - aaron at halcyon.com Intergraph Federal Systems | Be a cryptography user- ask me how. From mab at crypto.com Mon Sep 20 06:06:05 1993 From: mab at crypto.com (Matt Blaze) Date: Mon, 20 Sep 93 06:06:05 PDT Subject: meaningless rumor In-Reply-To: <9309201128.AA29694@toad.com> Message-ID: <9309201255.AA14286@crypto.com> .... >they may throw in charges of importing IDEA, though I doubt that they'd >indict just on those grounds; in an era of key escrow, they'd certainly >like a court to rule they had the power to exclude subversive foreign >crypto.... ..... > --Steve Bellovin Steve, Assuming that whoevever implemented PGP did not himself import the cipher, but based the implementation on the EUROCRYPT '90 paper that was 'imported' by Springer-Verlag, I don't understand what the basis would be for such a charge. Now an indictment against Springer for shipping the proceedings (which contained C source code for IDEA) into the US - that would be interesting... -matt From pmetzger at lehman.com Mon Sep 20 06:07:08 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 20 Sep 93 06:07:08 PDT Subject: meaningless rumor In-Reply-To: <9309200742.AA07328@longs.lance.colostate.edu> Message-ID: <9309201302.AA14912@snark.lehman.com> "L. Detweiler" says: > From a high-level source in contact with an *extremely* high level source: > > Rumor: Moby Crypto was targeted because G. Ward intended to include > PGP on distribution disks. The investigation is primarily PGP > oriented, and G. Ward is just a bystander who got caught up. PRZ & > PGP is the essential target. Thanks. That one was REALLY hard to figure out from the fact that the subpoena mentioned only PGP. Your high level source could be anyone in the continental U.S. If you are going to act like a conspiracy theory type, could you at least maybe stick to *interesting* rumors? Perry From smb at research.att.com Mon Sep 20 06:16:06 1993 From: smb at research.att.com (smb at research.att.com) Date: Mon, 20 Sep 93 06:16:06 PDT Subject: meaningless rumor Message-ID: <9309201313.AA01100@toad.com> Assuming that whoevever implemented PGP did not himself import the cipher, but based the implementation on the EUROCRYPT '90 paper that was 'imported' by Springer-Verlag, I don't understand what the basis would be for such a charge. Now an indictment against Springer for shipping the proceedings (which contained C source code for IDEA) into the US - that would be interesting... As you say, ``assuming''. The Feds can afford to lose that count because of the facts of this case; they can't afford to lose on a point of law. I don't know what the facts are, or what they can prove about them. They may not, either, at this point, pending the results of the grand jury probe. From cme at ellisun.sw.stratus.com Mon Sep 20 07:16:07 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Mon, 20 Sep 93 07:16:07 PDT Subject: KEY ESCROW PROCEDURES Message-ID: <9309201410.AA06972@ellisun.sw.stratus.com> >From: Mike Godwin >Message-Id: <199309181851.AA05084 at eff.org> >Subject: Re: KEY ESCROW PROCEDURES >Date: Sat, 18 Sep 1993 14:51:57 -0400 (EDT) > >Carl writes: > >> Meanwhile, where is the proof that the key being requested corresponds to >> a person on whom a wiretap has been ordered? > >The authorized key request will normally occur after law-enforcement >officials have snagged the chip serial number from the LEAF >(law-enforcement field) of the signal they captured with an authorized >wiretap. Mike, that's the theory but there is no proof that the signal was captured with an authorized wiretap. For that, the key registration agents have to trust the law enforcement agency. If the LE agency can be trusted, there's no need for the key registration agencies. Part of the reason for encryption of communications is to guard against illegal actions by law enforcement agencies. - Carl From an5877 at anon.penet.fi Mon Sep 20 07:26:08 1993 From: an5877 at anon.penet.fi (deadbeat) Date: Mon, 20 Sep 93 07:26:08 PDT Subject: meaningless rumor Message-ID: <9309201423.AA25630@anon.penet.fi> -----BEGIN PGP SIGNED MESSAGE----- > Assuming that whoevever implemented PGP did not himself import the cipher, but > based the implementation on the EUROCRYPT '90 paper that was 'imported' > by Springer-Verlag, According to idea.c in the PGP sources: * Algorithm developed by Xuejia Lai and James L. Massey, of ETH Zurich. * This implementation modified and derived from original C code * developed by Xuejia Lai. Of course, idea.c and PGP as a whole have been substantially improved by an international community; importing their warez may be as much of an "offense" as importing IDEA. (Certainly the prosecution of these actions is equal in absurdity.) DEADBEAT -----BEGIN PGP SIGNATURE----- Version: 2.3 iQBFAgUBLJ26yfFZTpBW/B35AQEOlQF/WiYCKSLEDU9XDL57YIHGIRxaBae3vIiA BkTK/sLzZKsVPM87Ol2qGRa4n5kttHfU =MCTV -----END PGP SIGNATURE----- ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From gtoal at an-teallach.com Mon Sep 20 07:39:56 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Mon, 20 Sep 93 07:39:56 PDT Subject: Newsgroup... Message-ID: <10249@an-teallach.com> In article cvoid at netcom.com writes: > So, is there a specific reason why someone hasn't created an > newsgroup? It seems appropriate, as most of the current > mass amounts of traffic are dedicated to paranoia and bickering... Erm... because this is the only place left we can have a sensible discussion without Sternlight bringing any argument down to the level of the absurd? G -- Personal mail to gtoal at gtoal.com (I read it in the evenings) Business mail to gtoal at an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212 From visgraph!forrie Mon Sep 20 08:39:55 1993 From: visgraph!forrie (Forrest Aldrich) Date: Mon, 20 Sep 93 08:39:55 PDT Subject: Encrypted logins? Message-ID: <199309201329.AA04289@visgraph.uucp> Is there a way to set up an encrypted login session, whereby the calling program would need a 'key' in order to decrypt the connection to even see the 'login: ' prompt? I thought I saw something like this for the ham-radio enthusiasts. It uses plain-DES to do the work. But this would require that your calling program be some type of comm prog with the decryption/encryption abilities within. I understand that some gov logins use this type of scheme. From huntting at glarp.com Mon Sep 20 08:56:10 1993 From: huntting at glarp.com (Brad Huntting) Date: Mon, 20 Sep 93 08:56:10 PDT Subject: meaningless rumor In-Reply-To: <9309201255.AA14286@crypto.com> Message-ID: <199309201553.AA01896@misc.glarp.com> > Assuming that whoevever implemented PGP did not himself import the > cipher, but based the implementation on the EUROCRYPT '90 paper > that was 'imported' by Springer-Verlag, I don't understand what > the basis would be for such a charge. Now an indictment against > Springer for shipping the proceedings (which contained C source > code for IDEA) into the US - that would be interesting... Wait a minute. Does ITAR actuall prohibit importing crypto _to_ the US? I've never heard of it being used this way. brad From pmetzger at lehman.com Mon Sep 20 08:57:12 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 20 Sep 93 08:57:12 PDT Subject: Encrypted logins? In-Reply-To: <199309201329.AA04289@visgraph.uucp> Message-ID: <9309201554.AA15303@snark.lehman.com> Forrest Aldrich says: > Is there a way to set up an encrypted login session, whereby the calling > program would need a 'key' in order to decrypt the connection to even > see the 'login: ' prompt? There are many such systems. I suppose the kerberos suite's "klogin" is the most popular these days, and options were being defined in telnet to allow end to end encryption, though I don't know where they've gotten to at this point. > I thought I saw something like this for the > ham-radio enthusiasts. It uses plain-DES to do the work. But this would > require that your calling program be some type of comm prog with the > decryption/encryption abilities within. Of course it would require a special communications program on both ends -- there is no other way to do it. Perry From doug at netcom.com Mon Sep 20 09:17:13 1993 From: doug at netcom.com (Doug Merritt) Date: Mon, 20 Sep 93 09:17:13 PDT Subject: a quote Message-ID: <9309201615.AA12922@netcom4.netcom.com> Sorry to add to the S/N ratio, but I can't resist passing on this (unattributed) quote I saw in someone's .sig: > Giving power and money to the government is like giving whiskey and > keys to a 17 year old. Well, I thought it was amusing. :-) Doug From lefty at apple.com Mon Sep 20 09:37:13 1993 From: lefty at apple.com (Lefty) Date: Mon, 20 Sep 93 09:37:13 PDT Subject: a quote Message-ID: <9309201626.AA02479@internal.apple.com> >Sorry to add to the S/N ratio, but I can't resist passing on this >(unattributed) quote I saw in someone's .sig: > >> Giving power and money to the government is like giving whiskey and >> keys to a 17 year old. P. J. O'Rourke, _A_ _Parliament_ _of_ _Whores_ -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From pmetzger at lehman.com Mon Sep 20 09:46:10 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 20 Sep 93 09:46:10 PDT Subject: a quote In-Reply-To: <9309201615.AA12922@netcom4.netcom.com> Message-ID: <9309201640.AA15403@snark.lehman.com> Doug Merritt says: > Sorry to add to the S/N ratio, but I can't resist passing on this > (unattributed) quote I saw in someone's .sig: > > > Giving power and money to the government is like giving whiskey and > > keys to a 17 year old. Its from P.J. O'Rourke's "Parliament of Whores". Perry From pcw at access.digex.net Mon Sep 20 10:09:57 1993 From: pcw at access.digex.net (Peter Wayner) Date: Mon, 20 Sep 93 10:09:57 PDT Subject: a quote Message-ID: <199309201706.AA03915@access.digex.net> I seem to think the quote should be attributed to P.J. O'Rourke. I'm also pretty sure it came from _Parliament of Whores._ -Peter From jrk at sys.uea.ac.uk Mon Sep 20 10:16:12 1993 From: jrk at sys.uea.ac.uk (Richard Kennaway) Date: Mon, 20 Sep 93 10:16:12 PDT Subject: a quote Message-ID: <1048.9309201714@s5.sys.uea.ac.uk> Lefty writes: >>Sorry to add to the S/N ratio, but I can't resist passing on this >>(unattributed) quote I saw in someone's .sig: >> >>> Giving power and money to the government is like giving whiskey and >>> keys to a 17 year old. > >P. J. O'Rourke, _A_ _Parliament_ _of_ _Whores_ He is American, I presume? Sorry to draw this tangent even further out, but I can't resist pointing out that in the UK it is perfectly legal to give whiskey and keys (car keys, I assume) to a 17 year old, and the heavens have not fallen. "Petrol and matches to a 5 year old" might be a better comparison. -- ____ Richard Kennaway __\_ / School of Information Systems Internet: jrk at sys.uea.ac.uk \ X/ University of East Anglia uucp: ...mcsun!ukc!uea-sys!jrk \/ Norwich NR4 7TJ, U.K. From warlord at MIT.EDU Mon Sep 20 11:16:13 1993 From: warlord at MIT.EDU (Derek Atkins) Date: Mon, 20 Sep 93 11:16:13 PDT Subject: meaningless rumor In-Reply-To: <199309201553.AA01896@misc.glarp.com> Message-ID: <9309201812.AA24475@toxicwaste.MEDIA.MIT.EDU> > Wait a minute. Does ITAR actuall prohibit importing crypto _to_ > the US? I've never heard of it being used this way. Most of the interpretation that I have heard, including an interpretation from Jim Bidzos, say that crypto imports _INTO_ the US are LEGAL, unless that piece of crypto was *illegally* exported from the US first. So, if A was illegally exported, you cannot import it and expect it to be legal. However, if it was developed outside the US, you can legally bring it into the US, according to this interpretation. David Sternlight has a different opinion. (Which I'm sure he'd gladly fill you mailbox explaining :-). -derek Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory Secretary, MIT Student Information Processing Board (SIPB) PGP key available from pgp-public-keys at pgp.mit.edu warlord at MIT.EDU PP-ASEL N1NWH From wcs at anchor.ho.att.com Mon Sep 20 11:39:58 1993 From: wcs at anchor.ho.att.com (Bill Stewart +1-908-949-0705 wcs@anchor.ho.att.com) Date: Mon, 20 Sep 93 11:39:58 PDT Subject: Restrictions on crypto exports Message-ID: <9309201723.AA21359@anchor.ho.att.com> Mike - you write that an FTP archive is a library open to the public. While it looks like one to me, the important thing is convincing a grand jury or jury that it's true, or heading off a prosecutor who'll try to paint ftp archives as 'subversive hacker BBSs' or nonsense like that. (Which won't stop them from treating them as libraries if it's useful for other things they're doing.) Until there are some court cases setting precedent one way or the other, they can try to construe it narrowly when they want narrow and broadly when they want broad. It would seem that some cheap insurance in cases like this is to make sure that most of the interesting material finds its way into paper libraries, and start documenting it. Do you know if anyone's doing this in an organized fashion? (I'm in the process of moving west, so I can't start doing this with my friendly town librarian, but I may try once I'm resettled.) Bill Stewart From hughes Mon Sep 20 11:59:57 1993 From: hughes (Eric Hughes) Date: Mon, 20 Sep 93 11:59:57 PDT Subject: META: list topicality Message-ID: <9309201858.AA06108@toad.com> I just received this unsubscribe note here on toad.com. >Noise to signal ratio is worse than sci.crypt. Please unsubscribe me. I, personally, am getting tired of worthwhile people unsubscribing from the list because the impropriety of others. Recommendations: 1. Send more private e-mail. Keep your flames of _all_ types off the list. 2. If something offends you, _do_ respond, and only in private. I have the suspicion that certain members of the list are not receiving enough hostile email in response to inappropriate postings. We want more negative and postive reinforcement. 3. This is not a list for paranoids. Shut up here and go somewhere else. If enough people tell you you're paranoid, then it is likely that you _are_ paranoid. 4. Do not immediately reply to postings. Wait, be thoughtful, and make sure you're not going to make an ass out of yourself. And to be sure, there are some asses being made on this list. 5. Exercise restraint. If you must make a response to something, first make sure it shouldn't go in private email. Eric From mnemonic at eff.org Mon Sep 20 12:01:12 1993 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 20 Sep 93 12:01:12 PDT Subject: a quote In-Reply-To: <9309201615.AA12922@netcom4.netcom.com> Message-ID: <199309201858.AA24064@eff.org> Doug Merritt writes: > Sorry to add to the S/N ratio, but I can't resist passing on this > (unattributed) quote I saw in someone's .sig: > > > Giving power and money to the government is like giving whiskey and > > keys to a 17 year old. > > Well, I thought it was amusing. :-) Comes from P.J. O'Rourke's PARLIAMENT OF WHORES. --Mike From mnemonic at eff.org Mon Sep 20 12:07:14 1993 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 20 Sep 93 12:07:14 PDT Subject: a quote In-Reply-To: <1048.9309201714@s5.sys.uea.ac.uk> Message-ID: <199309201904.AA24115@eff.org> Richard Kennaway writes of P.J. O'Rourke: > He is American, I presume? Sorry to draw this tangent even further out, > but I can't resist pointing out that in the UK it is perfectly legal to > give whiskey and keys (car keys, I assume) to a 17 year old, and the > heavens have not fallen. The issue for O'Rourke is not the legality of doing so; it's the wisdom of doing so. I can't resist pointing out that it's no wiser to give drunken teenagers the car keys in the UK than it is in the USA. --Mike From mnemonic at eff.org Mon Sep 20 12:17:43 1993 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 20 Sep 93 12:17:43 PDT Subject: Restrictions on crypto exports Message-ID: <199309201915.AA24268@eff.org> Bill Stewart writes: "Mike - you write that an FTP archive is a library open to the public. While it looks like one to me, the important thing is convincing a grand jury or jury that it's true, or heading off a prosecutor who'll try to paint ftp archives as 'subversive hacker BBSs' or nonsense like that." I don't think we disagree here. "Do you know if anyone's doing this in an organized fashion?" No. I'm really just making a prediction of what the likely outcome of such cases will be. --Mike From pcw at access.digex.net Mon Sep 20 12:46:14 1993 From: pcw at access.digex.net (Peter Wayner) Date: Mon, 20 Sep 93 12:46:14 PDT Subject: a quote Message-ID: <199309201943.AA27701@access.digex.net> Nah. When I'm drunk and driving I always use the left side of the road. If I was in Britain, there would be no problem! From talon57 at well.sf.ca.us Mon Sep 20 12:47:15 1993 From: talon57 at well.sf.ca.us (Brian D Williams) Date: Mon, 20 Sep 93 12:47:15 PDT Subject: MISC: thought for the dat Message-ID: <93Sep20.124245pdt.14224-2@well.sf.ca.us> thought for the day; In Starfleet, all communications are encrypted automatically. Although there is no honor in knowledge gained through stolen transmissions, some of our enemies have no honor. A true Klingon does not "sneak"-he shouts into the face of his enemy. But I have seen many types of dishonor, and so I am prepared for it. -Lieutenant Worf,chief of security, U.S.S.Enterprise From the star trek next generation book "20th century computers and how they worked" by Jennifer Flynn published by alpha books. ISBN 1-56761-257-1 Brian Williams Cypherpatriot From mccoy at ccwf.cc.utexas.edu Mon Sep 20 13:12:16 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Mon, 20 Sep 93 13:12:16 PDT Subject: money money money... Message-ID: <199309202009.AA17310@flubber.cc.utexas.edu> I have been tossing some of the electronic money ideas around in my head, and the two things that seemed to be the hardest problems were how to keep the feds from stomping on such a bank and how to give its currency value. Here are a couple of thoughts on these problems: Legalities: Why does it need to be a bank? Actually, it seems to me that the first step is to actually create the "currency" for use as a means of exchange and let the net provide the banking structure. Once currency exists cryptography will allow for the banking structure to be created in whatever manner the market demands. The hard part seems to be the jump-starting necessary to create the currency and get the system going. So why not approach this as a currency problem and not as a banking problem. In other words, how much easier is it to set up a "currency exchange and check cashing" operation compared to a bank or credit union? All the digital currency exchange would need to take in the money from users, and pay out digital coins in cash. Once such an operation existed the formation of a digital economy would be possible by just migrating existing services to work with the system. Such an operation could support itself by charging a small transaction fee (e.g. $0.25 for deposits and $0.25 for withdrawls plus the postage for sending the check...) Products and Value: I have only glanced over the papers available, but the IMP archive stuff (internet mercantile protocols) might just provide the immediate market for us to piggy-back upon. The imp people seem to be oriented towards using PEM for monetary transactions, but it seems to me that it would be possible to subvert such a system for our own use by simply setting up a server similar to an anonymous remailer that allows one to deposit electronic currency from the previously mentioned currency exchange and then creates a imp system PEM message coming from the remailer. The remailer can ask as a sort of purchasing agent, converting the digital coins created by the currency exchange into whatever type of imp certificates the user wants and it uses the purchasing agents identity to provide the anonymity that the imp schemes seem to not care about... So, what say you fellow cypherpunks? jim p.s. Anyone coming to the crypto conference in Austin Wednesday? If so and you want a copy of my most recent draft of a "Musings on a Crypto-Secure Linux" let me know and I will bring a few printed copies... From smb at research.att.com Mon Sep 20 13:19:58 1993 From: smb at research.att.com (smb at research.att.com) Date: Mon, 20 Sep 93 13:19:58 PDT Subject: MISC: thought for the dat Message-ID: <9309202019.AA07247@toad.com> thought for the day; In Starfleet, all communications are encrypted automatically. Although there is no honor in knowledge gained through stolen transmissions, some of our enemies have no honor. A true Klingon does not "sneak"-he shouts into the face of his enemy. But I have seen many types of dishonor, and so I am prepared for it. -Lieutenant Worf,chief of security, U.S.S.Enterprise From the star trek next generation book "20th century computers and how they worked" by Jennifer Flynn published by alpha books. ISBN 1-56761-257-1 Hardly a new sentiment. From Kahn: ``Gentlemen do not read each other's mail''. Henry Stimson, Secretary of State, 1929, shutting down the American Black Chamber. In 1940, Stimson was Secretary of War, and a recipient of MAGIC.... From tcmay at netcom.com Mon Sep 20 13:42:17 1993 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 20 Sep 93 13:42:17 PDT Subject: Need to Declare Policies on Remailer Record-Keeping Message-ID: <9309202040.AA29073@netcom5.netcom.com> (I hope this is not considered "off-topic" by anyone.) It would be nice if the operators of the current remailers made clear their archiving/record-keeping policies on remailer traffic. An "ideal mix" is like an "ideal op amp": very hard to build in practice, but very useful as a concept. David Chaum's 1981 paper anticipated many of the issues some of us later discovered, and which are dwell upon at length on this list. Some brief descriptions of the "ideal mix" (remailer): 1. Records. No records kept of incoming or outgoing traffic (in Chaum's mix, done by tamper-resistant hardware implementing software that keeps no records; in DC-Net approach, no single entity knows traffic, so only collusion can reveal traffic). Score: Many remailers keep records/logs, either explicitly ("to help in debugging") or by default (Unix records, system requirements, etc.) I have been shocked on a couple of occasions--a useful, educational shock--to get e-mail messages from the operators of remailers, saying things like "I couldn't help noticing your comments--I agree with you that...." Now partly this was my problem, in that I was not using PGP to chain my transmissions (in which case no snooping remailer operator will be able to get my true name except by colluding or traffic analyis), but it also indicated that some remailers are not taking a sufficiently hands-off policy...more on this point later. 2. Encryption, obviously, to hide mapping between ingoing and outgoing traffic. Score: Pretty good (no pun intended), though use of encryption is reported to be low. PGP has helped immensely. 3. Latency: some number N of messagers needs to be stored (securely, unobservably, as in #1) and then sent out in an order that obscures order of arrival. (Lex order, for example.) Score: Someone has been trying to implement this, but it is not widespread. (People want fast response, and in a low overall message volume environment, this could be impossible. If N = 100, could be a very long wait.) 4. Padding of message lengths in such a way that messages cannot be tracked by message length. Score: I don't think this is being implemented. We've talked about "quantizing" to several standard message lengths ("short," "medium," and "long," uncreatively enough) for this reason. 5. Other issues can be found in Chaum's papers, in the attacks on DC-Nets (one of which I distributed with the 70 pages of printed material handed out at the first Cypherpunks meeting), and in the many messages on remailers here on this list. Hal Finney's analysis, for example. In light of the recent subpoena, I urge that #1, record-keeping, be addressed quickly. If the authorities are seeking sources of crypto material, or routes used in conveying such material, they may conceivably issue subpoenas for site records. Some suggestions, which protect the remailer operators and the users: a. Keep no records, use scripts to delete records that may be generated that you have control over. b. The "best" remailers will be on systems under the control of the remailer operator himself (there seem to be a few of these), as he can control archiving and logs. c. Remailer operators should announce their policies on logs, announcing their philosophy (e.g., "to protect myself, I keep copies of all traffic through my remailer," or, "I keep no records whatsover--once it's through my system, all traces are deleted."). d. Trust in what they remailer operators say is another big issue...if the FBI operated a remailer, would you trust what they say? One avenue for helping here is to have independent agents reporting on their experiences, and perhaps confronting the remailers with evidence (such as the "helpful messages" I 've sometimes gotten) of their actual policies. e. Increased use of encryption. Lots more here. For now, just getting the remailers to publically state their policies will be helpful. To us, in allowing better market choice in which remailers we use, and to them by making their lack of record-keeping (for example) a matter of public record. Let's plan ahead for the day when Cypherpunks traffic, and remailer records, get subpoenaed. That _could_ be the next test case. I don't think I'm being paranoid. In any case, there are some fairly easy _social_ changes to the remailer system that we can make that will improve the security against traffic analysis and subpoenas. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From tcmay at netcom.com Mon Sep 20 13:47:45 1993 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 20 Sep 93 13:47:45 PDT Subject: MISC: thought for the dat In-Reply-To: <9309202019.AA07247@toad.com> Message-ID: <9309202045.AA00314@netcom5.netcom.com> > -Lieutenant Worf,chief of security, U.S.S.Enterprise > > > From the star trek next generation book "20th century computers > and how they worked" by Jennifer Flynn published by alpha books. > ISBN 1-56761-257-1 > > Hardly a new sentiment. From Kahn: > > ``Gentlemen do not read each other's mail''. Henry Stimson, > Secretary of State, 1929, shutting down the American Black Chamber. > Speaking of crypto in "Star Trek," wasn't this in "The Wrath of Kahn"? -Tim (Sorry, Eric, for wasting bandwidth...at least it's not a flame.) -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From cjl at micro.med.cornell.edu Mon Sep 20 13:59:58 1993 From: cjl at micro.med.cornell.edu (Chris Leonard) Date: Mon, 20 Sep 93 13:59:58 PDT Subject: nonrandom string Message-ID: <9309202102.AA02623@ micro.med.cornell.edu> I address this to the list at large hoping that one or more of you can explain something unusual that I observed. A friend of mine and I have been using PGP for several months and I just recently noted that in at least three of the recent posts to me that the first 18 characters of the encrypted message were identical. The first words of the plaintexts were not identical and so I assume that these characters are something else, perhaps the stuffer that I have heard mention of on this list. This repeating string is of concern for obvious reasons (e.g. so much for anonymity), and I would like to understand the cause of its recurrence. Please post to me and I will post a precis of the most reasonable suggestions. cjl From wcs at anchor.ho.att.com Mon Sep 20 14:01:14 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Mon, 20 Sep 93 14:01:14 PDT Subject: meaningless rumor Message-ID: <9309202028.AA03562@anchor.ho.att.com> Matt writes: > [Steve writes:] > >they may throw in charges of importing IDEA, though I doubt that they'd > >indict just on those grounds; in an era of key escrow, they'd certainly > >like a court to rule they had the power to exclude subversive foreign > >crypto.... > > Assuming that whoevever implemented PGP did not himself import the cipher, but > based the implementation on the EUROCRYPT '90 paper that was 'imported' > by Springer-Verlag, I don't understand what the basis would be for such a > charge. Now an indictment against Springer for shipping the proceedings > (which contained C source code for IDEA) into the US - that would be > interesting... If memory serves me correctly, Phil's original PGP offered DES and bass-o-matic, and the IDEA encryption was implemented in the Europeans PGP2.0 version (though I don't know if it was done by Phil or by Europeans, I think the latter.) This means that the IDEA implementation was imported by person or persons unknown, presumably including Phil and many others. During one round of Sternlight Wars, I proposed doing a U.S. implementation, but John Gilmore convinced me that importing software is legal under the then-existing ITAR wording. This could be an opportunity to test it in court. Bill From klbarrus at owlnet.rice.edu Mon Sep 20 16:29:59 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Mon, 20 Sep 93 16:29:59 PDT Subject: REMAIL: policy Message-ID: <9309202326.AA20134@flammulated.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- Tim asks about remailer policy: here is mine. About logging: I think there are two kinds of logs remailers can keep. By default, the "archive.remail" and "archive.pgp" (and "archive.ripem") files are kept, which record messages as they pass through. Also, there is debugging logging, which records stuff like the return value of pipes, user environment variables, whether pasting tokens and message delimiters are found, etc. Further, Hal showed how the maildelivery file can be extended to log usage only - an entry appended to a file for every use (see the cypherpunks gopher site :-) in "Anonymous Mail" for how to do this). I don't keep debugging logging or archive logging - I unlink the archive.* files every time slocal is invoked. Actually, I don't keep usage logs either. However, I haven't had a chance to drop in a sendmail agent, so there is always the syslog file I can't control. Hm.. I suppose I could just remove the relevant lines from the maildelivery file and avoid the archive.* files completely. I will do that. Errors (malformed messages) are dropped in the elee7h5 at rosebud and elee6ue at rosebud remailers, and get forwarded to me (klbarrus at owlnet.rice.edu) from the elee9sf at menudo.uh.edu remailer. This is so mail intended for me but sent to my old address still gets here. Furthermore, the elee7h5 at rosebud remailer is locked - I can't log in anymore. But, the directory structure is preserved, the remailer still works last time I tried, and I mailed to the admin asking him to contact me about this about two weeks ago, and haven't heard back. Encryption: elee7h5 at rosebud, elee6ue at rosebud, elee9sf at menudo support PGP encryption. Also elee9sf at menudo supports RIPEM. Caching: elee9sf at menudo caches messages, remailing in a random order at midnight. More precisely, it caches them in random order and mails out every midnight. So if you wrap your PGP encrypted message inside a RIPEM encryption, it will stay until midnight the first day to unwrap the RIPEM, and then will stay till midnight the next day to unwrap PGP to get the remailing request. Message padding: I'm experimenting with this, but not in production mode just yet. It's easy enough to pad so the messages waiting to be remaild are the same size, but I want to extend this so what leaves via sendmail or it's replacement is also the same size. Ownership: well, these are all school accounts so I don't have final authority over the machines. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJ47zYOA7OpLWtYzAQECcgP/ZuQ/zT5hJx3yIITTmq7RGLX5s4FUoHN0 cf0LXhNKZGIbINeI6wGxn1edCFrwrm9DujuAQpf0J+9yVgENlvU9VB2Z5BhorRQW zoFKMrEW6mwPHYR/ga7l0FKqG2WVLSo4DE37Tba6VnFY5vOEnt+KCkDaQXyNcOIc EbYcehaYafE= =irE+ -----END PGP SIGNATURE----- From nobody at soda.berkeley.edu Mon Sep 20 16:31:17 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Mon, 20 Sep 93 16:31:17 PDT Subject: your mail Message-ID: <9309202328.AA12607@soda.berkeley.edu> What do you put in the Subject: line of an encrypted or anonymous message? We need something standard to prevent traffic analysis on this field. My suggestion is always to put "Subject: Re: your mail", since so much mail already has that, due to a feature of the popular mailer elm. If there is no standard, one could correlate Subject: patterns with people. Notice this message has been sent through "fmt" (and almost through "spell") to remove more nuances. Next we need an English-to-bland-English translator that smooths over individual language features (unless you're practicing stegonagraphy, then you want one that inserts them!) From sameer at netcom.com Mon Sep 20 18:16:18 1993 From: sameer at netcom.com (Sameer Parekh) Date: Mon, 20 Sep 93 18:16:18 PDT Subject: REMAIL: policy Message-ID: <9309210111.AA19275@netcom.netcom.com> Remailers: sameer at soda.berkeley.edu sameer at netcom.com cs60a-qu at cory.eecs.berkeley.edu Policy: At this point I log everything and delete it daily, manually. This will change, RSN. (It was for debugging purposes.) I will change it so that the archive.* files are not created. (By editing the maildelivery file.) It's run on two school systems, and netcom. The cory account will disappear at the end of the semester, but I will hopefully be able to have that mail forwarded to sameer at netcom, and once I get my semi-permanent class account next semester I'll try to get stuff forwarded to there. Soon I will have linux running on my roommate's computer with a net connection via UUCP (Hopefully SLIP eventually) and I'll run a remailer there, under my physical control. -- Sameer sameer at netcom.com From ebrandt at jarthur.Claremont.EDU Mon Sep 20 18:27:21 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Mon, 20 Sep 93 18:27:21 PDT Subject: Need to Declare Policies on Remailer Record-Keeping In-Reply-To: <9309202040.AA29073@netcom5.netcom.com> Message-ID: <9309210126.AA11150@toad.com> Tim said: > It would be nice if the operators of the current remailers made clear > their archiving/record-keeping policies on remailer traffic. Here's the policy paragraph from my remailer blurb: -------------------- Policy, security, and legal cruft: The remailer has the capability to log source and destination addresses, as well as full message text. This is presently turned off. If I need to debug some weirdness, though, I'll turn it on again. I cannot guarantee, for both technical and political reasons, that anonymous mail will be secure. In particular, I explicitly disclaim the security of messages which are in themselves harmful and illegal, such as extortion and libel. I will block mail from my remailer to any particular address upon request of its owner. I may request some form of verification, to thwart denial-of-service attacks based on this mail blocking. By sending a message through my remailer, you are trusting me, like it or not. I could be a sting operation, or a blackmailer gathering information -- it *will* happen eventually. If you do not trust me, ask someone you do trust to do the remailing. Please remember that anti-social behavior or truly excessive traffic through the remailer will probably cause my sysadmins to ask me to remove it. Thank you for being polite. Please ask me if you have any questions. ------------------------------ Addenda to the above: I do keep usage logs ("date >>log"), which perhaps I should mention. jarthur is not my machine (fortunately!), so it keeps mail logs and I can't do anything about it (unless we make the remailers avoid getting logged in the first place...). I'd like to run a personal linux box, but I really can't unless somebody would like to give me a second machine. The muttering about "disclaiming the security" of extortion threats is pretty much moot, because I can't do do any outing unless somebody says "I'm going to extort an upstanding citizen through your server; please turn logging on." Mail logs are a problem, because lots of machines keep them and most remops (uh, that coinage is a lose) can't fix this. I think that the user-mode orientation of the remailer package should extend to letting J. User install it and *have it be secure*, too. Really, anonymity with mail logs is security only through obscurity. I presume you can do socket coding in perl. It should be possible to have the remailer interpret mailings to "@" to mean "open a socket to the remailer on and dump the message to it." The remailers do their own mail handling; all the transport system does is dump it in their laps. To fix logging on the final transmission to the recipient would require batching, which if most people get sufficient traffic (I don't) might be preferable to this whole mess. Eli ebrandt at jarthur.claremont.edu From rjc at gnu.ai.mit.edu Mon Sep 20 18:30:01 1993 From: rjc at gnu.ai.mit.edu (Ray) Date: Mon, 20 Sep 93 18:30:01 PDT Subject: Anonymous Forwarding Software Available Message-ID: <9309210126.AA12586@geech.gnu.ai.mit.edu> I wrote some quickie installation docs and put a copy of my anonymous forwarding software in soda.berkeley.edu:pub/cypherpunks/incoming/aforward.shar If you don't know what the software is used for check the cypherpunks gopher for a file like "Forwarding for multiple accounts" -Ray p.s. I am not supporting it right now because of my workload. If it's bugged, wait for a new version. -- Ray Cromwell | Engineering is the implementation of science; -- -- EE/Math Student | politics is the implementation of faith. -- -- rjc at gnu.ai.mit.edu | - Zetetic Commentaries -- From baumbach at atmel.com Mon Sep 20 18:46:18 1993 From: baumbach at atmel.com (Peter Baumbach) Date: Mon, 20 Sep 93 18:46:18 PDT Subject: pgp by mail Message-ID: <9309210044.AA08240@bass.chp.atmel.com> Hello all, Would someone with full internet access please do a favor for those of us who only have email access. I am looking for a detailed list of ftp sites that carry pgp. I need directory names and exact file names. With this information I can write up some mail-ftp scripts to get the files. These mail-ftp servers take a while to respond, and they only allow one "ls" per message. Looking for the files is very inconvenient. I'll post the scripts (they are very simple) to the list and elsewhere. I'm looking for source and executables that run on IBM, Mac, SPARC, and Amiga. Specific pointers to documentation, FAQ, etc. is also useful. An example of using a mail-ftp server: To: FTPMAIL at decwrl.dec.com Subject: Any thing of interest to you connect ftp.the.site.with.the.goods cd /the/directory/with/the/files ls uuencode binary get the.file.I.want1 get the.file.I.want2 quit From MIKEINGLE at delphi.com Mon Sep 20 20:16:20 1993 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Mon, 20 Sep 93 20:16:20 PDT Subject: Public-Key Crypto Toolkit Message-ID: <01H36SZHSIAC8WX5BI@delphi.com> What we need is a toolkit which makes it easy to write public-key applications. This would be an easy interface to the routines in PGP. I was thinking of doing this in Clisp under Linux, since Lisp makes it easy to put together and take apart complex objects, and makes it easy to kick around objects of arbitrary size. Unfortunately Clisp does not seem to support calling C functions! Perhaps it could be hacked right into the Clisp source code, giving it a fast modmult, idea, md5, etc. Any ideas as to what language/method would be best for implementing a PK toolbox? This could really get the "Cypherpunks write code" ideal moving. Anyone want to help? It should not contain any cryptography in itself - you should link it with the crypto from pgp, optionally applying diffs to the source files first, so that there is no fear of distributing crypto or violating patents. --- MikeIngle at delphi.com Brought to you by AT&T ClipperPhones - reach out and tap someone! From mgream at acacia.itd.uts.edu.au Mon Sep 20 20:26:20 1993 From: mgream at acacia.itd.uts.edu.au (Matthew Gream) Date: Mon, 20 Sep 93 20:26:20 PDT Subject: Interse Message-ID: <9309210322.AA24032@acacia.itd.uts.EDU.AU> -- Matthew Gream,, M.Gream at uts.edu.au -- Consent Technologies, 02-821-2043. From mentor at indial1.io.com Mon Sep 20 21:00:01 1993 From: mentor at indial1.io.com (Loyd Blankenship) Date: Mon, 20 Sep 93 21:00:01 PDT Subject: Standard Headers for Anonymous Remailers Message-ID: <9309210352.AA18893@indial1.io.com> Cpunks: We've been kicking around the pros and cons of anonymous remailers here at io.com. One of the big problems is anonymous bombardment of a helpless newsgroup. This (and the problem of auto-screening anonymous mail) could be solved if there was a standard header keyword (or maybe even a new header field) that could be screened from a newsgroup. The group would have to be semi-moderated -- an automatic filter passes on all posts except those with the keyword in the appropriate header field. If anonymous posts aren't annoying enough to instigate the creation of such a filtered newsgroup, then they probably aren't enough of a problem in that group to worry about. Words such as "anon" and "anonymous" might occur naturally in the headers. I'd propose something like "ANONYPOST" or "ANONPOST" that isn't likely to occur in nature. Voluntary adoption of this type of standard by remailers would take away some of the ammo that the anti-anon frothers are shooting, and would go a long way toward improving the image of remailers in general. Comments? Loyd ************************************************************************* * Loyd Blankenship mentor at io.com ^ * * Steve Jackson Games CI$: [73407,515] / \ * * PO Box 18957 GEnie: SJGAMES / O \ * * Austin, TX 78760 /_____\ * * 512/447-7866 * ************************************************************************* From strick at versant.com Mon Sep 20 21:07:52 1993 From: strick at versant.com (strick -- henry strickland) Date: Mon, 20 Sep 93 21:07:52 PDT Subject: Public-Key Crypto Toolkit In-Reply-To: <01H36SZHSIAC8WX5BI@delphi.com> Message-ID: <9309210404.AA16790@versant.com> THUS SPAKE Mike Ingle : # Any ideas as # to what language/method would be best for implementing a PK toolbox? This # could really get the "Cypherpunks write code" ideal moving. Anyone want to # help? Yeah, let's write some code! "TCL" is my language of choice for this -- it was designed specifically for wrapping other libraries and embedding inside other tools. I've been wanting to build the crypto-toolkit, too, and have started with RSAREF wrappers. There's a nice TCP module for TCL that lets you implement clients and servers. There's also the "TK" X-windows toolkit, for seamless graphical interfaces to TCL stuff. Ftp to sprite.berkeley.edu and ftp down TCL or TK (which will include TCL). (A lot of people may suggest perl, but perl was designed with a different set of goals in mind.) strick strick at versant.com From ld231782 at longs.lance.colostate.edu Mon Sep 20 21:36:22 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Mon, 20 Sep 93 21:36:22 PDT Subject: FLASH - SUBPOENA SERVED Message-ID: <9309210432.AA07839@longs.lance.colostate.edu> From: paul at poboy.b17c.ingr.com (Paul Robichaux) > I wrote Grady Ward under separate cover about Bruce Schneier's > upcoming book, published by John Wiley & Sons.. Last I heard, its > title was "Practical Cryptography," and it's scheduled to hit the > streets around November 1st. > > The book includes source code for DES, RSA, DH, IDEA, and several > others (Snefru and Lucifer?). IMHO its most salient feature is the > inclusion of that source code _on a floppy._ FLASH: SUBPOENA SERVED ON BRUCE SCHNEIER, JOHN WILEY & SONS CYBERSPACE -- On April 1, 1994 Bruce Schneier and his book publisher John Wiley and Sons were served a subpoena for `any and all materials related to the national distribution of Julius Caesar code, in particular ROT13' by agents of the U.S. Cryptography Ideas & Other Miscellaneous Illegal Substances Control Police, Domestic Division (USCIOMISCPDD). B. Schneier has posted to Usenet newsgroup "alt.lawbreaking" previously regarding his intent to publish the book, and recently asked for people who would `be my drop shippers for Practical Cryptography, and smuggle ROT13 code out of the U.S., particularly to foreign national subversives while thumbing their nose at the NSA.' Some have suggested the National Spooks Anonymous (parent organization of USCIOMISCPDD, the White House, and Congress in that order of importance) may have been clued to the threat from their dual newsfeed and artificially unintelligent disinformation device, code named Sternlight. Sternlight denies the charge, calling it a `make-wrong, given the NSA can routinely multiply large numbers' but does claim to have ``unsurpassed Unintelligence Training from many years at a Fortune 500 Psychiatric Ward''. Colorado entrepreneur Phil Zimmerman, winner of the Nobel Prize for International Cryptographic Terrorism, Criminality, and Guerilla Warfare, speaking from exile in Switzerland, stated that he fully extended his personal `web of trust' in support of Schneier, and mailed him other private communications on a postcard: ``Would you like to buy some Pretty Good Snake Oil?'' Austin writer Grady Ward, author of the one-page pamphlet ``ROT0 and Other Neat USCIOMISCPDD-Approved Codes For Wholesome Fun and Entertainment'' branded Schneier an ``arrogant young troublemaker''. A central component of the relevant law related to the investigation comes from the International Traffic in Unpleasant and Distasteful Things Regulations, which prohibits import and export of ``blatantly unusual or unorthodox breakthroughs or techniques, derived from excessive ingenuity or creativity, particularly those with practical applications leading directly to ventures that are commercially profitable.'' Renowned experts such as D. Denning note the Regulations do allow exceptions for free export and import of `public domain' material, defining it as `any inert and useless mass with no significant value or purpose, such as air'. The act bars, without exception, ``trans-U.S.-border electricity flow structures for the purpose of communications, particularly wires, and any written or oral use of the term `cyberspace'.'' The Cypherpansies, a club dedicated to the discussion of cryptographic codes, other than those which scramble plaintext, in various implementations on abacus-based systems, as well as frequent tag team blindfolded messenger pigeon competitions, uniformly condemned Schneier's book, and praised the investigation: TM: ``The sky is falling! the redcoats are coming! man the battlestations! flush the toilets! I told you this would happen!'' LD: ``Sources say the grassy knoll is key.'' PM: ``That's a good point. But you're a yammering idiot.'' SB: ``Of course its ridiculous, but they did it because they're required to.'' HF: ``I'm not a lawyer, but I play one on the net.'' EH: ``will everyone just SHUT UP!'' The Electonic Frontier Federation, Milky Way Galaxy division, has announced their intent to defend Schneier in the case. Lawyer Mike Godwin indicates ``We plan to plead insanity.'' From greg at ideath.goldenbear.com Mon Sep 20 22:10:02 1993 From: greg at ideath.goldenbear.com (Greg Broiles) Date: Mon, 20 Sep 93 22:10:02 PDT Subject: Standard Headers for Anonymous Remailers In-Reply-To: <9309210352.AA18893@indial1.io.com> Message-ID: uunet!indial1.io.com!mentor (Loyd Blankenship) writes: > Cpunks: > We've been kicking around the pros and cons of anonymous remailers > here at io.com. One of the big problems is anonymous bombardment of a > helpless newsgroup. This (and the problem of auto-screening anonymous > mail) could be solved if there was a standard header keyword (or maybe > even a new header field) that could be screened from a newsgroup. The > group would have to be semi-moderated -- an automatic filter passes on > all posts except those with the keyword in the appropriate header field. Some people think that "the problem of auto-screening anonymous mail" refers to other folks' desire to screen anonymous mail. If a significant fraction of the net community responds to wider access to anonymity by filtering out anonymous mail, my prediction (and suggestion :) is that people who truly (a) wish to be heard, and (b) wish to be anonymous will resort to mail which is non-obviously anonymous. Forging mail in the names of actual persons, and using bits of real names to assemble real-looking pseudonyms (say, "Perry Detweiler"?) would seem to be two solutions. Posters of that flavor of anonymous mail might or might not make it clear that the posting isn't actually who it purports to be from. I think it's probably better for us to deal with this problem now, rather than trying to hide from it with more shell scripts. Anonymity and its connection with accountability, responsibility, and coercion is a social issue, not a technological one. Technological attempts to address that social issue (or ignore it) will fail. -- Greg Broiles greg at goldenbear.com Baked, not fried. From ld231782 at longs.lance.colostate.edu Mon Sep 20 22:26:23 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Mon, 20 Sep 93 22:26:23 PDT Subject: more musings Message-ID: <9309210522.AA08729@longs.lance.colostate.edu> Included: - why PGP, not Moby Crypto, is (probably) the focus - including more juicy rumors about the *overall* customs office investigation - I open my mailbag and talk about Bidzos & the ITAR again - points and questions about grand jury investigations in general * * * First, some (e.g. Steve Bellovin) have raised the point that Grady Ward just days ago announced on the newsgroups that he was looking for people to `drop ship' Moby Crypto to in apparent violation of the ITAR. Now, this does sound very incriminating and subversive, but the fact is that our legal system grinds with the utmost sluggishness, as one lately rather vocal cypherpunk (to say the least) pointed out. I think it is *highly* unlikely that these subpoenas were due directly to this *particular* statement at all. The grand jury has probably been convened weeks, or at least many days, ago. There has already probably been some deliberations just to get a basic familiarity with the case -- remember, these are regular citizens as jurors, right? surely, all this cryptography and export business sounds pretty abstruse, bizarre, and convoluted -- even to people who dwell on it daily! Furthermore, other clues I've come across suggest that the customs' office investigation or inquiry has been in progress for *many months* if not even a *year*, and that this grand jury convening and subpoena serving is simply the latest development. Not only that, but at least one other highly prominent and reputable cryptographic company *apparently* has been `visited' under the same general inquiry -- moreover, the agents were requesting information on *PGP*. And get this: there was supposedly some confusion over PGP (private software by PRZ) and the public company itself by the visiting agents! This from a *top* source: ``When they came to see us, they already had a lot of documents from the net, but I don't think they knew how to make sense of them.'' Again, *all* this supports the conjecture that *international distribution of PGP* is the primary target and Moby Crypto, G. Ward mostly secondary, or perhaps even just a bystander. We track this stuff every day, but we have to understand that to government bureacrats and the average citizen, ``any sufficiently advanced technology is indistinguishable from magic'' -- A. C. Clark -- and the details of the last few year's `cryptographic fault slips & earthquakes' are very formidable, overwhelming, and sometimes impenetrable even to experts. In fact, if the specifics of the E911 document were confusing to a jury, imagine them trying to grasp the epic tale of PGP, RSA, PKP, NSA, ITAR, ad infinitum ad nauseam... * * * I've been getting a wide variety of hot and emotional reaction lately, both public and private, directly or indirectly, by prominent heroes and lowly villains, both electronic back-pats and flames. The last, from someone I deeply respect: >what's going on? > >It feels like you're inviting a flame war not much unlike our >favorite-enemy David Sternlight. Yikes. My stomach turns. This was apparently in reaction (the sole one so far, a wretched return) to my report that Bidzos of PKP believed that software was *specifically exempt* from the `public domain' exception clauses of the ITAR, commenting on H. Finney's exceptional and thoroughly researched (but of course not exhaustively authoritative by admission) ITAR analysis posted herein. The point of my posting was: I grudgingly accede that Bidzos is an *extremely knowledgeable expert* of the *highest caliber* on the ITAR code, and others should recognize this too. His company and its army of lawyers deals with it daily. They have explored every nook and cranny. They live and die by it. (In fact, I've urged him to share the company's extremely valuable knowledge and experience in the area with EFF this week--perhaps there is something already going on, I don't know.) Hence, if software is `exempt' from `public domain' exceptions to the restrictions on cryptographic export, according to Bidzos, that's quite shocking. So far no one has responded. Is the claim groundless? Or is there something in the ITAR that supports it? Cypherpunk extraordinaire H. Finney has tracked this very closely in his posting, but did not note any such exception. (I'm still trying to track down Bidzos' posting that claimed that PGP export was illegal under the ITAR, as well as possible archives for the ITAR itself. I hope some cypherpunk hears the call.) * * * S. Steele of EFF & others have been kind enough to correct some of my misunderstandings about grand jury investigations. Since nobody else has previously volunteered any information, I will feel free to ignore rude flames criticizing me for its ``obviousness'', which for some unfathomable reason have increased tremendously lately. I'm unfazed because I find this all a great educational opportunity. First, I was grasping at straws (I knew it, but I just wanted to know what could be done). Of course there's no such thing as a `overbroad subpoena' (although some warrants are ruled that). The grand jury investigation is simply a fact-finding mission to determine whether indictments are necessary. This is a bit surprising -- In a grand jury hearing, e.g. what PRZ and G. Ward face on Wednesday, the person summoned is *not* entitled to an attorney. The hearings are broad in their scope. She notes that `information that would be excluded from evidence in a trial is perfectly proper to put before a grand jury.' I still wonder what kind of legal tactics are available at this point in investigations of this type to the subpoenaed. I would like some more information on the following: how are jurors on the grand jury selected? by the head Attorney of the State? what are his requirements and constraints in selecting them? Is there any kind of judge involved at this point? (That reminds me -- I wonder why California of all places is the site of the grand jury. What is the significance of that? it is not the location of either PGP or Grady Ward. Isn't PKP in California? just curious :) Secondly, under what situations does the State Prosecutor have the authority to convene a grand jury? can he convene them anytime there is some suspicion? here is a situation where there can be a burden on the `subjects' *prior* to even there being a court trial. Everyone has to fly to California in this case -- not quite as simple as paying a parking ticket (note: Grady Ward was subpoenaed to appear, but PRZ was not so far, only the president of ViaCrypt, Leonard Mikus, although at this point it seems *highly likely* PRZ will be subpoenaed). This is one of those situations & compromises in our judicial system wherein people have to sacrifice some rights just to exist in the system, without even being accused (I certainly acknowledge that these tradeoffs are crucial to law enforcement and a functional judicial system, but its a delicate balance). Also, I'm curious: what is known about previous Customs investigations of this type? have there ever been grand juries convened before for cryptographic inquiries? what were the circumstances and cases? is this a typical thing for the Customs Office to be doing, or is this current situation fundamentally novel? Somehow, I just can't picture the Customs Office regularly going about and investigating and hassling cryptography companies. From my point of view, the present situation appears extremely unique, to say the least. From ld231782 at longs.lance.colostate.edu Mon Sep 20 22:36:23 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Mon, 20 Sep 93 22:36:23 PDT Subject: Bidzos on PGP and ITAR verbatim Message-ID: <9309210531.AA09003@longs.lance.colostate.edu> Bidzos comments on PGP related to ITAR, from sci.crypt a while ago (not sure of date). Essential argument: it was illegally exported, and ITAR prohibits re entry of things illegally exported, therefore it is illegally imported. Relevant section, Software export: Section 123.2 of the ITAR reads: >"123.2 Imports. > >No defense article may be imported into the United States unless (a) >it was previously exported temporarily under a license issued by the >Office of Munitions Control; or (b) it constitutes a temporary >import/intransit shipment licensed under Section 123.3; or (c) its >import is authorized by the Department of the Treasury (see 27 CFR >parts 47, 178, and 179)." There is a section on `illegal export of unclassified technical data to foreign nationals' (paraphrase) and Bidzos claims it applies to PGP export. But he appears to me to be using a bit of sleight of hand to conflate this category with *cryptographic software* mentioned elsewhere (sections also as quoted also by H. Finney). I'll let others pick it apart for the loopholes. ===cut=here=== Date: Mon, 20 Sep 93 19:31:08 PDT Message-Id: <9309210231.AA16113 at RSA.COM> To: ld231782 at longs.lance.colostate.edu In-Reply-To: "L. Detweiler"'s message of Mon, 20 Sep 93 19:57:35 -0600 <9309210157.AA04992 at longs.lance.colostate.edu> Subject: PGP & ITAR Here's the ITAR part. (This was posted in 1992, so I don't know, since pgp has changed since then I understand, how it would apply.) Also, the ITAR has changed recently, and I haven't studied the changes to see how they would affect these comments. Risks of using pgp One should be careful about assuming that the documentation in electronically distributed software is accurate, especially where law is concerned. There are a few things the documentation for a program called "pgp" does not tell you about patent and export law that you should be aware of. Further, there are a number of claims and offered interpretations of patent and export law that are simply false. pgp seems to be an attempt to mislead netters into joining an illegal activity that violates patent and export law, letting them believe that they run no serious risk in doing so. EXPORT LAW pgp leads users to believe that it has circumvented export controls "...since it is not illegal to import..." You are led to believe that since you didn't import it, it's legal to use it. The "no import restrictions" claim has been made so many times, many people probably believe it. One would be well advised not to accept this legal opinion. While stated as if it were a well-known fact, the claim that "there are no import restrictions" is simply false. Section 123.2 of the ITAR (International Traffic in Arms Regulations) reads: "123.2 Imports. No defense article may be imported into the United States unless (a) it was previously exported temporarily under a license issued by the Office of Munitions Control; or (b) it constitutes a temporary import/intransit shipment licensed under Section 123.3; or (c) its import is authorized by the Department of the Treasury (see 27 CFR parts 47, 178, and 179)." Was pgp illegally exported? Was pgp illegally imported? Of course. It didn't export or import itself. pgp 1 was illegally exported from the U.S., and pgp 2, based on pgp 1, is illegally imported into the U.S. Is a license required? According to the ITAR, it is. 125.2 Exports of unclassified technical data. Paragraph (c) reads: "(c) Disclosures. Unless otherwise expressly exempted in this subchapter, a license is required for the oral, visual, or documentary disclosure of technical data to foreign nationals in connection with visits by U.S. persons to foreign countries, visits by foreign persons to the United States, or otherwise. A license is required regardless of the manner in which the technical data is transmitted (e.g., in person, by telephone, correspondence, electronic means, telex, etc.)." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What is "export?" Section 120.10, "Export," begins: "'Export' means, for purposes of this subchapter: ...(c) Sending or taking technical data outside of the United States in any manner except that by mere travel outside of the United States by a person whose technical knowledge includes technical data; or..." Crypto software is controlled by the ITAR. See Part 121, the Munitions List, includes Category XIII, of which paragraph (b) reads, in part, "...privacy devices, cryptographic devices and software (encoding and decoding), and components specifically designed or modified therefore,..." A further definition in 121.8, paragraph (f) reads: "Software includes but is not limited to the system functional design, logic flow, algorithms, application programs, ..." pgp encourages you to post it on computer bulletin boards. Anybody who considers following this advice is taking quite a risk. When you make a defense item available on a BBS, you have exported it. pgp's obvious attempts to downplay any risk of violating export law won't help you a bit if you're ever charged under the ITAR. Penalties under the ITARs are quite serious. The ITARs were clearly designed to put teeth into laws that make exporting munitions illegal. It's unfortunate that cryptography is on the munitions list. But it is. pgp is software tainted by serious ITAR violations. ------- End of Forwarded Message From wcs at anchor.ho.att.com Mon Sep 20 22:46:23 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Mon, 20 Sep 93 22:46:23 PDT Subject: MISC: thought for the day Message-ID: <9309210458.AA08302@anchor.ho.att.com> > In Starfleet, all communications are encrypted automatically. > Although there is no honor in knowledge gained through stolen > transmissions, some of our enemies have no honor. A true Klingon > does not "sneak"-he shouts into the face of his enemy. But I have > seen many types of dishonor, and so I am prepared for it. > -Lieutenant Worf,chief of security, U.S.S.Enterprise .... and of course > ``Gentlemen do not read each other's mail''. Henry Stimson, The classic Roman Republic policy on information from enemy traitors was to accept it, use it, kick the enemy's butt, and then kill the traitor. By the time of the Empire, haggling over price was a bit more flexible. After all, if you're trying to protect your own city, winning is everything. And if you're off trying to conquer other cities to increase the riches and power of the generals who run your army, honor's not a concept you want to over-analyze :-) For more precise references, and less cynicism, you'll need to contact my 8th grade Latin teacher... Pedantically, # Bill Stewart wcs at anchor.ho.att.com +1-908-949-0705 Fax-4876 # AT&T Bell Labs, Room 4M-312, Crawfords Corner Rd, Holmdel, NJ 07733-3030 From remailer at netcom.com Mon Sep 20 23:20:04 1993 From: remailer at netcom.com (remailer at netcom.com) Date: Mon, 20 Sep 93 23:20:04 PDT Subject: Master Key: A Clipper Story Message-ID: <9309210612.AA19084@mail.netcom.com> MASTER KEY ~~~~~~ ~~~ by Infocalypse an36586 at anon.penet.fi September 21, 2002 This file contains important information regarding the Skipjack standard encryption system. Please read this file through before coming to any conclusions. Please do not ask me who I am. I have no intention of revealing my identity. I will start at the beginning. The Skipjack encryption system, initially known as Clipper, was first publicly announced in mid- 1993. After an initial storm of controversy died down, escrow agents were selected and the chip went into production in early 1994. Several major hardware vendors used Skipjack, and sales began to accelerate in the third quarter of 1994 as business users recognized the advantages of the convenient, inexpensive, and highly secure system. By the first quarter of 1995, Mykotronx could no longer keep up with the orders, and demand was still increasing rapidly. Several other electronics companies came forward, arguing that they could manufacture Skipjack chips more cheaply than Mykotronx, in larger volume, and with at least equal security. The NSA hesitated to give more companies its classified algorithm, but at the same time, they certainly did not want Skipjack to die from lack of available hardware just as it was becoming a standard. After a delay and threats of restraint-of-trade lawsuits, NIST released a set of security requirements. Any company which met them could receive the classified algorithm and make Skipjack chips. Numerous companies jumped in immediately. By Christmas 1995, the price of Skipjack chips had fallen sharply. Secure telephones were rapidly becoming a consumer product, just as the telecom companies started their Christmas advertising drive. Remember these slogans? "This Christmas, Give The Gift Of Privacy. AT&T Secure Telephones!" "Motorola Secure Cellular Network. Because It's Nobody's Business But Yours!" The promotion worked - secure phones were the hottest-selling product of the season. At the start of 1996, there was an installed base of over ten million, with no end in sight. Companies were making secure faxes, secure modems, secure LAN's, and secure microwave systems. The long-awaited crypto revolution had begun, and NSA was thrilled. Skipjack would soon be used for all types of business communications as well as telephones - everything which needed protection could be taken care of with a single solution. At the time, I was a senior in college and working evenings for a company which had just received its security clearance. I did not have access to any classified data; my job was to operate and maintain their front-end system, which took orders, kept track of stock, etc. There was a separate, isolated LAN for the classified work of designing and programming chips. The company tried to follow all of the technical rules, but the people were hackers and businesspeople, not spooks. And most security problems are people problems. My boss did have a security clearance. He was working late one Friday on one of the classified machines used to write microcode. When everyone else had left, he asked me to fix a problem with the network. That was a violation of security, but I did know more about networks than he did, and all the classified data was supposed to be locked up for the weekend. The safe had a time lock, which could not be opened until Monday. My boss had made a mistake while he was logged in as root, and he did an excellent job of hosing the file server. He was not supposed to have the root password at all. He'd had an argument with his supervisor about computer access. The supervisor refused to give him the password, so he stole it. Now his ass was on the line - if the file server wasn't fixed by the next morning, he was history. He didn't exactly admit it all at once, but that's what happened. We took a look at the damage, and began the long, slow job of recreating the filesystems, reinstalling Unix, restoring the data from backup tapes, and, most importantly, hiding the evidence. By 8 o'clock, we were both starved. I was doing most of the work - he was watching, reading manuals, and sweating bullets - so he decided to go for food. While waiting for a backup tape to run, I opened the desk drawer out of boredom, and - whoops! - there was a manual stamped SECRET. Some programmer was using it to write the microcode for a new low- power CMOS Skipjack chip, and he hadn't locked it up. After all, this is a secure building. Nobody without a security clearance is even allowed in this room, right? So what's the big deal? People problems! I couldn't resist taking a look, and there was a complete description of the Skipjack algorithm, among other things, with each page marked SECRET at the top and bottom. I had about 20 minutes until my boss returned. There was a Xerox machine, warmed up and ready to go, in the next room. What would you do? So I stood there, turning pages and hitting the button, listening to my heart pound, waiting for the click of the outer door as my boss walked in. I wasn't hungry any more. If I heard that click, I had just enough time to toss everything behind the copier, run back to the workstation, and hope to put the manual back later. But there was no click. By the time my boss returned with a pizza, the copies were in my car and the manual was in the drawer. My appetite returned with a vengeance as the adrenaline wore off. By 2 am, the machine was restored to normal. My boss shook my hand and thanked me, and then I went home and passed out cold. The next day, I woke up around noon and took a look at my loot. The algorithm strongly resembles DES. It's a highly improved DES, of course, but the structure is similar. It uses 32 rounds, and an 80- bit key, and they process the key before using it to eliminate weak keys. I started coding it at home in C to hack around with, not having any particular plans as to what I'd do with it. I was just enjoying the thrill of having something few others had. The program worked, but it was horribly slow. Skipjack is optimized for a pipelined hardware implementation, using 32 processing elements, one for each round. Even a good software implementation is almost uselessly slow. Once I had the basic electronic-codebook function working, I started implementing the rest of the Skipjack protocol around it. After a month of on-and-off hacking, I had a complete software clone of a Skipjack chip, which could be assigned any serial number and device-unique key. Without the family key, however, there was no way to create a proper LEAF. The version of Skipjack in this file is much improved, but similar in structure, to the original. For a long time, that was all I did with it. Without hardware, it wasn't fast enough for a no-LEAF secure telephone. I scanned the copies I'd made, encrypted the image files, and made a bonfire with the paper copies. Not the kind of thing one should keep around. Then I started experimenting with a programming technique called genetic algorithms. These are algorithms which evolve their outputs by creating successively better results. Multiple results are generated and evaluated, the best are copied, the rest erased. The remaining ones are then "crossed", simulating sexual reproduction, and the cycle repeats. Looking for an application, I decided to see how far a genetic algorithm could go in attacking Skipjack. At the time, I'd have been thrilled if it broke one round. What happened next - I didn't do it! I didn't know then and don't know now how it works. Using keys as the strings my algorithm would create was no good. Genetic algorithms make incremental progress; with crypto, if one bit is off, it's useless. Instead, my strings were programs written in a little interpreted language, specifically designed for cryptography. The genetic algorithm would evolve programs. This approach has been used for various things in the past. I started out with less than a round, with only the first transformation of the first round. The genetic algorithm wrote a program to solve that, no problem. But as I made it harder, using more of the round, it failed to progress. So I tried something new: there are programs which clean up spaghetti code, making readable and usable code out of it. They are used to make 30-year-old Cobol maintainable. I used one to take the most successful programs which evolved, clean them up, and add them to the language itself as new commands. When it got to the second round, the blocks out of which those programs were built included the most successful methods used against the first round. This way the program could build on its own successes. The computer ran 24 hours a day, and it progressed as far as the fifth round. I was surprised that it worked at all, but I didn't know if five rounds was good or bad. There has never been any public research with Skipjack, but DES is much easier to break if fewer rounds are used, so I assumed I hadn't really done much. Before leaving for a weekend, I made several changes to the program: improvements to the crossover routines, removing old, nonuseful commands added by the evolver, and code which increased the difficulty, one piece of one round at a time, each time the programs were successful. There were a few other changes. There were also several bugs in the program, including at least one wild pointer which scrambled some of the evolved functions. How these bugs affected the ultimate outcome, I don't know. Something like Frankenstein's lightning, I suppose. When I got back Sunday evening, I turned on the monitor and couldn't believe it. It had gone through all 32 rounds - cracked the code! Impossible, had to be a program bug. So I encrypted some text using the function I'd written, fed it in, and went to bed. The next morning, I expected the program to be crashed. Instead, there was the key. Somehow, I don't have a clue how, the algorithms evolve to fit each piece of ciphertext. They go down, like a diver taking treasure from a sunken ship, and pull those patterns to the surface. I've never been able to trace it. All the data looks random, but the solution emerges in the end. Much like neural networks: they can solve a problem, but they can't tell you how they did it. That's one reason why people don't trust neural nets. The next day, I kept trying it with different pieces of text. Imagine opening your trunk and finding it stuffed with cash - I kept opening it and looking to see if the money was really there. Sometimes it was faster than others, but it always worked as long as there was a pattern to the plaintext. I started acquiring equipment and components. 32 RAM-based logic array chips, similar to PAL's but using SRAM instead of ROM. One for each round. These I connected to form the equivalent of a Skipjack chip, equally fast but fully controllable. A used minivan. Nonmetallic composites are popular for car bodies - they may stop a bullet, but radio signals go right through them. No need for visible antennas on the outside. A new 8-gigabyte hard drive. Plenty of RAM for a disk cache. A software encryption program - I wasn't about to use Skipjack, and my hard drive would need encrypting. A small microwave dish and receiver - they've replaced cable, carrying TV and all kinds of data transmissions. Encrypted with Skipjack, of course. By this time, mid-1997, Skipjack had already gone global. Most of the money transferred around the world moves by Skipjack. Almost all large corporations use it for their voice, data, and fax networks. It has been designed into the lowest levels of the new Information Superhighway under construction, and has replaced RIPEM as the official privacy standard on the Internet. Each country keeps escrows for all chips manufactured and used within its borders. These are used for national law enforcement. The United Nations has a master escrow, containing all of the keys in the world. This is used to police international terrorism, arms and drug trafficking, etc. There are, of course, very strict rules governing when and to whom the UN will release keys. This system works very well. It has put the squeeze on drug money like nothing that came before it, because the large cash transaction stands out in a world of electronic money. All major crimes are difficult - the Mafia is nearly extinct. ATM and credit card fraud are almost a thing of the past - the Skipjack smart card has replaced the mag stripe and the card number. New phones have a slot, rather than a built-in chip, allowing people to carry their identities wherever they go. I didn't counterfeit electronic money - that would eventually be noticed, and besides, I'm not a thief. Nor did I secretly transfer money to myself. I just drove to New York, one of many places where information worth billions of dollars moves everyday over microwave beams. Then I parked in the path of one, turned on my inverter - connected to four marine batteries; running out of power during a hot intercept is highly annoying - and powered up my scanner. Having cracked the family key, I could quickly extract the serial number from each transmission. The hardest part is deciding what, out of the gigabytes flowing by, to tap. Once I choose a transmission, I feed it to the genetic algorithm. If I get anything interesting, I keep that serial number, and I know to tap that chip again when I see the serial number. Perhaps I intercept the draft of your lousy quarterly earnings report, bouncing from one suit to another as they try to cover their asses. Then I sell your company short. Or if I intercept good sales figures, I buy your stock. Sometimes I buy options, although it's easier to lose your shirt that way. They aren't all winners - the market reacts strangely sometimes - but enough of them are to make me a millionaire in a couple of years. Besides, it wouldn't work if all my picks were accurate. Someone would get suspicious. I've really made very poor use of my luck. A corporation could have practically taken over the world. But it would have been detected eventually. By keeping it small and being careful, I've been successful. For the last five years, I've lived as a parasite, feeding on information and using it to my advantage. For a while, I went through a voyeuristic phase, driving down the freeway, tapping phone calls at random. That didn't stay interesting for very long; most phone calls are boring. So why am I revealing this now? Why would I give up my master key? Not willingly, I assure you. But I feel that I have no choice. Recently, there have been two unexplained crimes: large amounts of money have been electronically transferred from corporate accounts, simply vanishing. In both cases, the police have suspected an inside job. MIS and finance managers were arrested - and released, because there was absolutely no evidence against them. There was, in fact, no evidence at all. The money was just gone. The police may suspect an inside job, but I think otherwise. I am very familiar with such crimes, because I spent much of that first year planning them, thinking about how they could be accomplished. Someone else, I am convinced, has discovered the master key. I would suspect an organization, not an individual. Either they have corrupted the escrow system, or they have cracked the code too. And they do not intend to stop at personal wealth. From an offshore base, they could, in one day of frantic activity, hold the world economy hostage. Or they could drain us more slowly, over a period of a few weeks. The thefts were intended to provide them with capital and experience for what could be the greatest heist in the history of money. So what can I do to prevent this? I could go to the NCPI - the National Cryptography and Privacy Institute, formerly the NSA - and show them my system. They might throw me in the slammer for espionage and securities fraud. More likely, they would make me a deal - my freedom for my silence - and begin the long process of designing a new encryption algorithm. But they would not believe me when I told them that someone else had also cracked the code. The idea is almost too horrible for them to contemplate - the whole world runs on Skipjack - and without convincing evidence, there is no way they would believe me. I don't have any convincing evidence. Action has to be taken now, before it's too late, and there's only one way to cause that. Tell the secret. Publish the algorithm, publish the method of breaking it, and of course, publish this file, so people will understand why I did what I did. I will be flamed, called every name in the book and some that will be made up for the occasion. They may try to hunt me down. There will be chaos for a few days, maybe a few weeks. The world financial system will grind to a halt, as programmers work frantically around the clock. Software cryptography will have to be quickly installed, until a new hardware system can be designed. For now, incompatibility will return, efficiency will be reduced, and a lesson will be learned. Hopefully, the NCPI will not make the same mistake twice. Hopefully, they won't classify the algorithm next time. --==<< Infocalypse >>==-- (Binary file transmission follows this message) From STEAKMAN at delphi.com Tue Sep 21 00:16:25 1993 From: STEAKMAN at delphi.com (STEAKMAN at delphi.com) Date: Tue, 21 Sep 93 00:16:25 PDT Subject: PGP algorithm needed Message-ID: <01H3713O7L868WXNRP@delphi.com> I am currently working on an encryption program for the Apple II user's on the net (there's quite a few of us out there) but without the PGP algorithm it will be a useless utility. Can someone E-mail it to me, a long with an credits that should be included so as not to step on anyones toes. Thanks in advance... The SteakMan SteakMan at Delphi.Com Oh by the way, I had to drop from this list due to it's volume and my slailish 1200 baud modem snailish 1200 baud modem. Later D00dz From doug at netcom.com Tue Sep 21 00:17:55 1993 From: doug at netcom.com (Doug Merritt) Date: Tue, 21 Sep 93 00:17:55 PDT Subject: Master Key: A Clipper Story Message-ID: <9309210715.AA29447@netcom.netcom.com> > Somehow, I don't have a clue how, the algorithms >evolve to fit each piece of ciphertext. Several thoughts come to mind: - The difference between science fiction and fantasy can be very sharp. - If wishes were horses then beggars would ride. - Preaching to the choir is remarkably pointless. I would also add that genetic algorithms are much too nice to treat as mysterious magic that can solve any and all problems, but that's doubtless obvious. Doug From ld231782 at longs.lance.colostate.edu Tue Sep 21 00:42:55 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 21 Sep 93 00:42:55 PDT Subject: remailer ideas Message-ID: <9309210740.AA11569@longs.lance.colostate.edu> T.C. May requests information on operator's remailer policies. I would like to go a step further and suggest that *all* operators *standardize* on a single email address for policy queries, in ping-like fashion. the user just sends mail to policies at remailer.com and gets back the policies. Of course, maybe that's not the best name, because some names are fixed. So maybe a standard header field request syntax. This sheet returned should include all the information about headers and cryptographic use, too. I would like it to have *standard headings* across remailers. That is, it would list categories and the variations that the particular remailer implements. His list of points is a good place to start of policy headings. Off the top of my head - remailer address header syntax how to cut and paste headers pitfalls cryptography support additional features oversight & logging etc. I'd also like some *history* of the remailer. Whose code is it based on? what modifications have been added? how reliable is it? -- even a standard `uptime field' or `% lost messages' would be interesting. are there any `close calls' in shutting it down? what kind of support does the operator enjoy? (e.g. sysadmin, student acct, etc.) If anyone would like to come up with a comprehensive `boilerplate' document, that'd certainly be useful. I think all this could increase the `userfriendliness' of the remailers and ultimately there use signficantly. just a humble suggestion from a fellow cypherpunk. From tcmay at netcom.com Tue Sep 21 00:51:25 1993 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 21 Sep 93 00:51:25 PDT Subject: Standard Headers for Anonymous Remailers In-Reply-To: <9309210352.AA18893@indial1.io.com> Message-ID: <9309210748.AA05014@netcom5.netcom.com> Loyd Blankenship writes: > We've been kicking around the pros and cons of anonymous remailers > here at io.com. One of the big problems is anonymous bombardment of a > helpless newsgroup. This (and the problem of auto-screening anonymous > mail) could be solved if there was a standard header keyword (or maybe > even a new header field) that could be screened from a newsgroup. The > group would have to be semi-moderated -- an automatic filter passes on > all posts except those with the keyword in the appropriate header field. Which reminds me of something I forgot to mention in my post yesterday about remailer policies and the properties of "ideal mixes." Remailer bombing (by volume, not the content) can of course be solved by *digital postage*, the fee charged by a remailer. As with ordinary postage, this reduces junk mail somewhat. However, digital postage (and digital money in more general forms) is not available now. A remailer could sell lists of numbers that act as postage, using reputation/trust to "honor" them. (To avoid using them for tracing, the lists could be bought from others, or traded with others, or possibly even "blinded" a la Chaum. Digital postage is sufficiently low-value (money-wise) that not as much attention to detail is needed, at least not for trial use of "Pretty Good Digital Postage.") > Words such as "anon" and "anonymous" might occur naturally in > the headers. I'd propose something like "ANONYPOST" or "ANONPOST" that > isn't likely to occur in nature. > > Voluntary adoption of this type of standard by remailers would > take away some of the ammo that the anti-anon frothers are shooting, > and would go a long way toward improving the image of remailers in > general. > > Comments? I think it's a good idea. Eric Messick has already proposed replacing the message names in mail with something to maker traffic analysis harder. For anonymous postings to newsgroups, a prefix system voluntarily adopted by users is another approach, e.g., "ANON: The Virtues of Anonymity." It's doubtful that all users, or all remailers for that matter, will ever adopt the same conventions for signalling an anonymous message, so the problems will persist, albeit on a different scale. Long range, a combination of pay-for-what-you-use digital postage and "positive reputation filters" will be what a. keeps newsgroups from being flooded with anonymous posts, and b. allows readers to find the messages they want to read out of a huge pool of messages. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From catalyst-remailer at netcom.com Tue Sep 21 00:52:28 1993 From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com) Date: Tue, 21 Sep 93 00:52:28 PDT Subject: Master Key: A Clipper Story Message-ID: <9309210745.AA24335@mail.netcom.com> MASTER KEY ~~~~~~ ~~~ by Infocalypse an36586 at anon.penet.fi September 21, 2002 This file contains important information regarding the Skipjack standard encryption system. Please read this file through before coming to any conclusions. Please do not ask me who I am. I have no intention of revealing my identity. I will start at the beginning. The Skipjack encryption system, initially known as Clipper, was first publicly announced in mid- 1993. After an initial storm of controversy died down, escrow agents were selected and the chip went into production in early 1994. Several major hardware vendors used Skipjack, and sales began to accelerate in the third quarter of 1994 as business users recognized the advantages of the convenient, inexpensive, and highly secure system. By the first quarter of 1995, Mykotronx could no longer keep up with the orders, and demand was still increasing rapidly. Several other electronics companies came forward, arguing that they could manufacture Skipjack chips more cheaply than Mykotronx, in larger volume, and with at least equal security. The NSA hesitated to give more companies its classified algorithm, but at the same time, they certainly did not want Skipjack to die from lack of available hardware just as it was becoming a standard. After a delay and threats of restraint-of-trade lawsuits, NIST released a set of security requirements. Any company which met them could receive the classified algorithm and make Skipjack chips. Numerous companies jumped in immediately. By Christmas 1995, the price of Skipjack chips had fallen sharply. Secure telephones were rapidly becoming a consumer product, just as the telecom companies started their Christmas advertising drive. Remember these slogans? "This Christmas, Give The Gift Of Privacy. AT&T Secure Telephones!" "Motorola Secure Cellular Network. Because It's Nobody's Business But Yours!" The promotion worked - secure phones were the hottest-selling product of the season. At the start of 1996, there was an installed base of over ten million, with no end in sight. Companies were making secure faxes, secure modems, secure LAN's, and secure microwave systems. The long-awaited crypto revolution had begun, and NSA was thrilled. Skipjack would soon be used for all types of business communications as well as telephones - everything which needed protection could be taken care of with a single solution. At the time, I was a senior in college and working evenings for a company which had just received its security clearance. I did not have access to any classified data; my job was to operate and maintain their front-end system, which took orders, kept track of stock, etc. There was a separate, isolated LAN for the classified work of designing and programming chips. The company tried to follow all of the technical rules, but the people were hackers and businesspeople, not spooks. And most security problems are people problems. My boss did have a security clearance. He was working late one Friday on one of the classified machines used to write microcode. When everyone else had left, he asked me to fix a problem with the network. That was a violation of security, but I did know more about networks than he did, and all the classified data was supposed to be locked up for the weekend. The safe had a time lock, which could not be opened until Monday. My boss had made a mistake while he was logged in as root, and he did an excellent job of hosing the file server. He was not supposed to have the root password at all. He'd had an argument with his supervisor about computer access. The supervisor refused to give him the password, so he stole it. Now his ass was on the line - if the file server wasn't fixed by the next morning, he was history. He didn't exactly admit it all at once, but that's what happened. We took a look at the damage, and began the long, slow job of recreating the filesystems, reinstalling Unix, restoring the data from backup tapes, and, most importantly, hiding the evidence. By 8 o'clock, we were both starved. I was doing most of the work - he was watching, reading manuals, and sweating bullets - so he decided to go for food. While waiting for a backup tape to run, I opened the desk drawer out of boredom, and - whoops! - there was a manual stamped SECRET. Some programmer was using it to write the microcode for a new low- power CMOS Skipjack chip, and he hadn't locked it up. After all, this is a secure building. Nobody without a security clearance is even allowed in this room, right? So what's the big deal? People problems! I couldn't resist taking a look, and there was a complete description of the Skipjack algorithm, among other things, with each page marked SECRET at the top and bottom. I had about 20 minutes until my boss returned. There was a Xerox machine, warmed up and ready to go, in the next room. What would you do? So I stood there, turning pages and hitting the button, listening to my heart pound, waiting for the click of the outer door as my boss walked in. I wasn't hungry any more. If I heard that click, I had just enough time to toss everything behind the copier, run back to the workstation, and hope to put the manual back later. But there was no click. By the time my boss returned with a pizza, the copies were in my car and the manual was in the drawer. My appetite returned with a vengeance as the adrenaline wore off. By 2 am, the machine was restored to normal. My boss shook my hand and thanked me, and then I went home and passed out cold. The next day, I woke up around noon and took a look at my loot. The algorithm strongly resembles DES. It's a highly improved DES, of course, but the structure is similar. It uses 32 rounds, and an 80- bit key, and they process the key before using it to eliminate weak keys. I started coding it at home in C to hack around with, not having any particular plans as to what I'd do with it. I was just enjoying the thrill of having something few others had. The program worked, but it was horribly slow. Skipjack is optimized for a pipelined hardware implementation, using 32 processing elements, one for each round. Even a good software implementation is almost uselessly slow. Once I had the basic electronic-codebook function working, I started implementing the rest of the Skipjack protocol around it. After a month of on-and-off hacking, I had a complete software clone of a Skipjack chip, which could be assigned any serial number and device-unique key. Without the family key, however, there was no way to create a proper LEAF. The version of Skipjack in this file is much improved, but similar in structure, to the original. For a long time, that was all I did with it. Without hardware, it wasn't fast enough for a no-LEAF secure telephone. I scanned the copies I'd made, encrypted the image files, and made a bonfire with the paper copies. Not the kind of thing one should keep around. Then I started experimenting with a programming technique called genetic algorithms. These are algorithms which evolve their outputs by creating successively better results. Multiple results are generated and evaluated, the best are copied, the rest erased. The remaining ones are then "crossed", simulating sexual reproduction, and the cycle repeats. Looking for an application, I decided to see how far a genetic algorithm could go in attacking Skipjack. At the time, I'd have been thrilled if it broke one round. What happened next - I didn't do it! I didn't know then and don't know now how it works. Using keys as the strings my algorithm would create was no good. Genetic algorithms make incremental progress; with crypto, if one bit is off, it's useless. Instead, my strings were programs written in a little interpreted language, specifically designed for cryptography. The genetic algorithm would evolve programs. This approach has been used for various things in the past. I started out with less than a round, with only the first transformation of the first round. The genetic algorithm wrote a program to solve that, no problem. But as I made it harder, using more of the round, it failed to progress. So I tried something new: there are programs which clean up spaghetti code, making readable and usable code out of it. They are used to make 30-year-old Cobol maintainable. I used one to take the most successful programs which evolved, clean them up, and add them to the language itself as new commands. When it got to the second round, the blocks out of which those programs were built included the most successful methods used against the first round. This way the program could build on its own successes. The computer ran 24 hours a day, and it progressed as far as the fifth round. I was surprised that it worked at all, but I didn't know if five rounds was good or bad. There has never been any public research with Skipjack, but DES is much easier to break if fewer rounds are used, so I assumed I hadn't really done much. Before leaving for a weekend, I made several changes to the program: improvements to the crossover routines, removing old, nonuseful commands added by the evolver, and code which increased the difficulty, one piece of one round at a time, each time the programs were successful. There were a few other changes. There were also several bugs in the program, including at least one wild pointer which scrambled some of the evolved functions. How these bugs affected the ultimate outcome, I don't know. Something like Frankenstein's lightning, I suppose. When I got back Sunday evening, I turned on the monitor and couldn't believe it. It had gone through all 32 rounds - cracked the code! Impossible, had to be a program bug. So I encrypted some text using the function I'd written, fed it in, and went to bed. The next morning, I expected the program to be crashed. Instead, there was the key. Somehow, I don't have a clue how, the algorithms evolve to fit each piece of ciphertext. They go down, like a diver taking treasure from a sunken ship, and pull those patterns to the surface. I've never been able to trace it. All the data looks random, but the solution emerges in the end. Much like neural networks: they can solve a problem, but they can't tell you how they did it. That's one reason why people don't trust neural nets. The next day, I kept trying it with different pieces of text. Imagine opening your trunk and finding it stuffed with cash - I kept opening it and looking to see if the money was really there. Sometimes it was faster than others, but it always worked as long as there was a pattern to the plaintext. I started acquiring equipment and components. 32 RAM-based logic array chips, similar to PAL's but using SRAM instead of ROM. One for each round. These I connected to form the equivalent of a Skipjack chip, equally fast but fully controllable. A used minivan. Nonmetallic composites are popular for car bodies - they may stop a bullet, but radio signals go right through them. No need for visible antennas on the outside. A new 8-gigabyte hard drive. Plenty of RAM for a disk cache. A software encryption program - I wasn't about to use Skipjack, and my hard drive would need encrypting. A small microwave dish and receiver - they've replaced cable, carrying TV and all kinds of data transmissions. Encrypted with Skipjack, of course. By this time, mid-1997, Skipjack had already gone global. Most of the money transferred around the world moves by Skipjack. Almost all large corporations use it for their voice, data, and fax networks. It has been designed into the lowest levels of the new Information Superhighway under construction, and has replaced RIPEM as the official privacy standard on the Internet. Each country keeps escrows for all chips manufactured and used within its borders. These are used for national law enforcement. The United Nations has a master escrow, containing all of the keys in the world. This is used to police international terrorism, arms and drug trafficking, etc. There are, of course, very strict rules governing when and to whom the UN will release keys. This system works very well. It has put the squeeze on drug money like nothing that came before it, because the large cash transaction stands out in a world of electronic money. All major crimes are difficult - the Mafia is nearly extinct. ATM and credit card fraud are almost a thing of the past - the Skipjack smart card has replaced the mag stripe and the card number. New phones have a slot, rather than a built-in chip, allowing people to carry their identities wherever they go. I didn't counterfeit electronic money - that would eventually be noticed, and besides, I'm not a thief. Nor did I secretly transfer money to myself. I just drove to New York, one of many places where information worth billions of dollars moves everyday over microwave beams. Then I parked in the path of one, turned on my inverter - connected to four marine batteries; running out of power during a hot intercept is highly annoying - and powered up my scanner. Having cracked the family key, I could quickly extract the serial number from each transmission. The hardest part is deciding what, out of the gigabytes flowing by, to tap. Once I choose a transmission, I feed it to the genetic algorithm. If I get anything interesting, I keep that serial number, and I know to tap that chip again when I see the serial number. Perhaps I intercept the draft of your lousy quarterly earnings report, bouncing from one suit to another as they try to cover their asses. Then I sell your company short. Or if I intercept good sales figures, I buy your stock. Sometimes I buy options, although it's easier to lose your shirt that way. They aren't all winners - the market reacts strangely sometimes - but enough of them are to make me a millionaire in a couple of years. Besides, it wouldn't work if all my picks were accurate. Someone would get suspicious. I've really made very poor use of my luck. A corporation could have practically taken over the world. But it would have been detected eventually. By keeping it small and being careful, I've been successful. For the last five years, I've lived as a parasite, feeding on information and using it to my advantage. For a while, I went through a voyeuristic phase, driving down the freeway, tapping phone calls at random. That didn't stay interesting for very long; most phone calls are boring. So why am I revealing this now? Why would I give up my master key? Not willingly, I assure you. But I feel that I have no choice. Recently, there have been two unexplained crimes: large amounts of money have been electronically transferred from corporate accounts, simply vanishing. In both cases, the police have suspected an inside job. MIS and finance managers were arrested - and released, because there was absolutely no evidence against them. There was, in fact, no evidence at all. The money was just gone. The police may suspect an inside job, but I think otherwise. I am very familiar with such crimes, because I spent much of that first year planning them, thinking about how they could be accomplished. Someone else, I am convinced, has discovered the master key. I would suspect an organization, not an individual. Either they have corrupted the escrow system, or they have cracked the code too. And they do not intend to stop at personal wealth. From an offshore base, they could, in one day of frantic activity, hold the world economy hostage. Or they could drain us more slowly, over a period of a few weeks. The thefts were intended to provide them with capital and experience for what could be the greatest heist in the history of money. So what can I do to prevent this? I could go to the NCPI - the National Cryptography and Privacy Institute, formerly the NSA - and show them my system. They might throw me in the slammer for espionage and securities fraud. More likely, they would make me a deal - my freedom for my silence - and begin the long process of designing a new encryption algorithm. But they would not believe me when I told them that someone else had also cracked the code. The idea is almost too horrible for them to contemplate - the whole world runs on Skipjack - and without convincing evidence, there is no way they would believe me. I don't have any convincing evidence. Action has to be taken now, before it's too late, and there's only one way to cause that. Tell the secret. Publish the algorithm, publish the method of breaking it, and of course, publish this file, so people will understand why I did what I did. I will be flamed, called every name in the book and some that will be made up for the occasion. They may try to hunt me down. There will be chaos for a few days, maybe a few weeks. The world financial system will grind to a halt, as programmers work frantically around the clock. Software cryptography will have to be quickly installed, until a new hardware system can be designed. For now, incompatibility will return, efficiency will be reduced, and a lesson will be learned. Hopefully, the NCPI will not make the same mistake twice. Hopefully, they won't classify the algorithm next time. --==<< Infocalypse >>==-- (Binary file transmission follows this message) From ld231782 at longs.lance.colostate.edu Tue Sep 21 00:56:24 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 21 Sep 93 00:56:24 PDT Subject: Standard Headers for Anonymous Remailers In-Reply-To: <9309210352.AA18893@indial1.io.com> Message-ID: <9309210754.AA11724@longs.lance.colostate.edu> mentor at indial1.io.com (Loyd Blankenship) >We've been kicking around the pros and cons of anonymous remailers >here at io.com. One of the big problems is anonymous bombardment of a >helpless newsgroup. you are talking about a problem associated with a *mail to new gateway*. this is not the same as a *remailer*. In fact, the latter operators should not have to worry about the former. >This (and the problem of auto-screening anonymous >mail) could be solved if there was a standard header keyword (or maybe >even a new header field) that could be screened from a newsgroup.\ although I think the idea of anonymous identification tags in the header has `some' merit. but its an extremely problematic issue, because it could have the effect of censoring anonymous posting. the best goal is to allow the end user to make the decision, i.e. kill files, and *never* put any kind of a choke upstream that would prevent them from making that decision. hence, the solution is to have the mail-to-news gateway reject overly voluminous posting -- either posts that are too long, or too frequent posting from the same address or (the latter which of course can be thwarted to some degree) in overall frequency of accepting articles, such that some might get bounced back to the user if the site is being bombarded. of course, remailer operators have to guard against mail bombs too, but not in the overly sensitive, distributed way that NNTP servers do. From catalyst-remailer at netcom.com Tue Sep 21 01:00:05 1993 From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com) Date: Tue, 21 Sep 93 01:00:05 PDT Subject: Master Key: A Clipper Story Message-ID: <9309210753.AA24723@mail.netcom.com> MASTER KEY ~~~~~~ ~~~ by Infocalypse an36586 at anon.penet.fi September 21, 2002 This file contains important information regarding the Skipjack standard encryption system. Please read this file through before coming to any conclusions. Please do not ask me who I am. I have no intention of revealing my identity. I will start at the beginning. The Skipjack encryption system, initially known as Clipper, was first publicly announced in mid- 1993. After an initial storm of controversy died down, escrow agents were selected and the chip went into production in early 1994. Several major hardware vendors used Skipjack, and sales began to accelerate in the third quarter of 1994 as business users recognized the advantages of the convenient, inexpensive, and highly secure system. By the first quarter of 1995, Mykotronx could no longer keep up with the orders, and demand was still increasing rapidly. Several other electronics companies came forward, arguing that they could manufacture Skipjack chips more cheaply than Mykotronx, in larger volume, and with at least equal security. The NSA hesitated to give more companies its classified algorithm, but at the same time, they certainly did not want Skipjack to die from lack of available hardware just as it was becoming a standard. After a delay and threats of restraint-of-trade lawsuits, NIST released a set of security requirements. Any company which met them could receive the classified algorithm and make Skipjack chips. Numerous companies jumped in immediately. By Christmas 1995, the price of Skipjack chips had fallen sharply. Secure telephones were rapidly becoming a consumer product, just as the telecom companies started their Christmas advertising drive. Remember these slogans? "This Christmas, Give The Gift Of Privacy. AT&T Secure Telephones!" "Motorola Secure Cellular Network. Because It's Nobody's Business But Yours!" The promotion worked - secure phones were the hottest-selling product of the season. At the start of 1996, there was an installed base of over ten million, with no end in sight. Companies were making secure faxes, secure modems, secure LAN's, and secure microwave systems. The long-awaited crypto revolution had begun, and NSA was thrilled. Skipjack would soon be used for all types of business communications as well as telephones - everything which needed protection could be taken care of with a single solution. At the time, I was a senior in college and working evenings for a company which had just received its security clearance. I did not have access to any classified data; my job was to operate and maintain their front-end system, which took orders, kept track of stock, etc. There was a separate, isolated LAN for the classified work of designing and programming chips. The company tried to follow all of the technical rules, but the people were hackers and businesspeople, not spooks. And most security problems are people problems. My boss did have a security clearance. He was working late one Friday on one of the classified machines used to write microcode. When everyone else had left, he asked me to fix a problem with the network. That was a violation of security, but I did know more about networks than he did, and all the classified data was supposed to be locked up for the weekend. The safe had a time lock, which could not be opened until Monday. My boss had made a mistake while he was logged in as root, and he did an excellent job of hosing the file server. He was not supposed to have the root password at all. He'd had an argument with his supervisor about computer access. The supervisor refused to give him the password, so he stole it. Now his ass was on the line - if the file server wasn't fixed by the next morning, he was history. He didn't exactly admit it all at once, but that's what happened. We took a look at the damage, and began the long, slow job of recreating the filesystems, reinstalling Unix, restoring the data from backup tapes, and, most importantly, hiding the evidence. By 8 o'clock, we were both starved. I was doing most of the work - he was watching, reading manuals, and sweating bullets - so he decided to go for food. While waiting for a backup tape to run, I opened the desk drawer out of boredom, and - whoops! - there was a manual stamped SECRET. Some programmer was using it to write the microcode for a new low- power CMOS Skipjack chip, and he hadn't locked it up. After all, this is a secure building. Nobody without a security clearance is even allowed in this room, right? So what's the big deal? People problems! I couldn't resist taking a look, and there was a complete description of the Skipjack algorithm, among other things, with each page marked SECRET at the top and bottom. I had about 20 minutes until my boss returned. There was a Xerox machine, warmed up and ready to go, in the next room. What would you do? So I stood there, turning pages and hitting the button, listening to my heart pound, waiting for the click of the outer door as my boss walked in. I wasn't hungry any more. If I heard that click, I had just enough time to toss everything behind the copier, run back to the workstation, and hope to put the manual back later. But there was no click. By the time my boss returned with a pizza, the copies were in my car and the manual was in the drawer. My appetite returned with a vengeance as the adrenaline wore off. By 2 am, the machine was restored to normal. My boss shook my hand and thanked me, and then I went home and passed out cold. The next day, I woke up around noon and took a look at my loot. The algorithm strongly resembles DES. It's a highly improved DES, of course, but the structure is similar. It uses 32 rounds, and an 80- bit key, and they process the key before using it to eliminate weak keys. I started coding it at home in C to hack around with, not having any particular plans as to what I'd do with it. I was just enjoying the thrill of having something few others had. The program worked, but it was horribly slow. Skipjack is optimized for a pipelined hardware implementation, using 32 processing elements, one for each round. Even a good software implementation is almost uselessly slow. Once I had the basic electronic-codebook function working, I started implementing the rest of the Skipjack protocol around it. After a month of on-and-off hacking, I had a complete software clone of a Skipjack chip, which could be assigned any serial number and device-unique key. Without the family key, however, there was no way to create a proper LEAF. The version of Skipjack in this file is much improved, but similar in structure, to the original. For a long time, that was all I did with it. Without hardware, it wasn't fast enough for a no-LEAF secure telephone. I scanned the copies I'd made, encrypted the image files, and made a bonfire with the paper copies. Not the kind of thing one should keep around. Then I started experimenting with a programming technique called genetic algorithms. These are algorithms which evolve their outputs by creating successively better results. Multiple results are generated and evaluated, the best are copied, the rest erased. The remaining ones are then "crossed", simulating sexual reproduction, and the cycle repeats. Looking for an application, I decided to see how far a genetic algorithm could go in attacking Skipjack. At the time, I'd have been thrilled if it broke one round. What happened next - I didn't do it! I didn't know then and don't know now how it works. Using keys as the strings my algorithm would create was no good. Genetic algorithms make incremental progress; with crypto, if one bit is off, it's useless. Instead, my strings were programs written in a little interpreted language, specifically designed for cryptography. The genetic algorithm would evolve programs. This approach has been used for various things in the past. I started out with less than a round, with only the first transformation of the first round. The genetic algorithm wrote a program to solve that, no problem. But as I made it harder, using more of the round, it failed to progress. So I tried something new: there are programs which clean up spaghetti code, making readable and usable code out of it. They are used to make 30-year-old Cobol maintainable. I used one to take the most successful programs which evolved, clean them up, and add them to the language itself as new commands. When it got to the second round, the blocks out of which those programs were built included the most successful methods used against the first round. This way the program could build on its own successes. The computer ran 24 hours a day, and it progressed as far as the fifth round. I was surprised that it worked at all, but I didn't know if five rounds was good or bad. There has never been any public research with Skipjack, but DES is much easier to break if fewer rounds are used, so I assumed I hadn't really done much. Before leaving for a weekend, I made several changes to the program: improvements to the crossover routines, removing old, nonuseful commands added by the evolver, and code which increased the difficulty, one piece of one round at a time, each time the programs were successful. There were a few other changes. There were also several bugs in the program, including at least one wild pointer which scrambled some of the evolved functions. How these bugs affected the ultimate outcome, I don't know. Something like Frankenstein's lightning, I suppose. When I got back Sunday evening, I turned on the monitor and couldn't believe it. It had gone through all 32 rounds - cracked the code! Impossible, had to be a program bug. So I encrypted some text using the function I'd written, fed it in, and went to bed. The next morning, I expected the program to be crashed. Instead, there was the key. Somehow, I don't have a clue how, the algorithms evolve to fit each piece of ciphertext. They go down, like a diver taking treasure from a sunken ship, and pull those patterns to the surface. I've never been able to trace it. All the data looks random, but the solution emerges in the end. Much like neural networks: they can solve a problem, but they can't tell you how they did it. That's one reason why people don't trust neural nets. The next day, I kept trying it with different pieces of text. Imagine opening your trunk and finding it stuffed with cash - I kept opening it and looking to see if the money was really there. Sometimes it was faster than others, but it always worked as long as there was a pattern to the plaintext. I started acquiring equipment and components. 32 RAM-based logic array chips, similar to PAL's but using SRAM instead of ROM. One for each round. These I connected to form the equivalent of a Skipjack chip, equally fast but fully controllable. A used minivan. Nonmetallic composites are popular for car bodies - they may stop a bullet, but radio signals go right through them. No need for visible antennas on the outside. A new 8-gigabyte hard drive. Plenty of RAM for a disk cache. A software encryption program - I wasn't about to use Skipjack, and my hard drive would need encrypting. A small microwave dish and receiver - they've replaced cable, carrying TV and all kinds of data transmissions. Encrypted with Skipjack, of course. By this time, mid-1997, Skipjack had already gone global. Most of the money transferred around the world moves by Skipjack. Almost all large corporations use it for their voice, data, and fax networks. It has been designed into the lowest levels of the new Information Superhighway under construction, and has replaced RIPEM as the official privacy standard on the Internet. Each country keeps escrows for all chips manufactured and used within its borders. These are used for national law enforcement. The United Nations has a master escrow, containing all of the keys in the world. This is used to police international terrorism, arms and drug trafficking, etc. There are, of course, very strict rules governing when and to whom the UN will release keys. This system works very well. It has put the squeeze on drug money like nothing that came before it, because the large cash transaction stands out in a world of electronic money. All major crimes are difficult - the Mafia is nearly extinct. ATM and credit card fraud are almost a thing of the past - the Skipjack smart card has replaced the mag stripe and the card number. New phones have a slot, rather than a built-in chip, allowing people to carry their identities wherever they go. I didn't counterfeit electronic money - that would eventually be noticed, and besides, I'm not a thief. Nor did I secretly transfer money to myself. I just drove to New York, one of many places where information worth billions of dollars moves everyday over microwave beams. Then I parked in the path of one, turned on my inverter - connected to four marine batteries; running out of power during a hot intercept is highly annoying - and powered up my scanner. Having cracked the family key, I could quickly extract the serial number from each transmission. The hardest part is deciding what, out of the gigabytes flowing by, to tap. Once I choose a transmission, I feed it to the genetic algorithm. If I get anything interesting, I keep that serial number, and I know to tap that chip again when I see the serial number. Perhaps I intercept the draft of your lousy quarterly earnings report, bouncing from one suit to another as they try to cover their asses. Then I sell your company short. Or if I intercept good sales figures, I buy your stock. Sometimes I buy options, although it's easier to lose your shirt that way. They aren't all winners - the market reacts strangely sometimes - but enough of them are to make me a millionaire in a couple of years. Besides, it wouldn't work if all my picks were accurate. Someone would get suspicious. I've really made very poor use of my luck. A corporation could have practically taken over the world. But it would have been detected eventually. By keeping it small and being careful, I've been successful. For the last five years, I've lived as a parasite, feeding on information and using it to my advantage. For a while, I went through a voyeuristic phase, driving down the freeway, tapping phone calls at random. That didn't stay interesting for very long; most phone calls are boring. So why am I revealing this now? Why would I give up my master key? Not willingly, I assure you. But I feel that I have no choice. Recently, there have been two unexplained crimes: large amounts of money have been electronically transferred from corporate accounts, simply vanishing. In both cases, the police have suspected an inside job. MIS and finance managers were arrested - and released, because there was absolutely no evidence against them. There was, in fact, no evidence at all. The money was just gone. The police may suspect an inside job, but I think otherwise. I am very familiar with such crimes, because I spent much of that first year planning them, thinking about how they could be accomplished. Someone else, I am convinced, has discovered the master key. I would suspect an organization, not an individual. Either they have corrupted the escrow system, or they have cracked the code too. And they do not intend to stop at personal wealth. From an offshore base, they could, in one day of frantic activity, hold the world economy hostage. Or they could drain us more slowly, over a period of a few weeks. The thefts were intended to provide them with capital and experience for what could be the greatest heist in the history of money. So what can I do to prevent this? I could go to the NCPI - the National Cryptography and Privacy Institute, formerly the NSA - and show them my system. They might throw me in the slammer for espionage and securities fraud. More likely, they would make me a deal - my freedom for my silence - and begin the long process of designing a new encryption algorithm. But they would not believe me when I told them that someone else had also cracked the code. The idea is almost too horrible for them to contemplate - the whole world runs on Skipjack - and without convincing evidence, there is no way they would believe me. I don't have any convincing evidence. Action has to be taken now, before it's too late, and there's only one way to cause that. Tell the secret. Publish the algorithm, publish the method of breaking it, and of course, publish this file, so people will understand why I did what I did. I will be flamed, called every name in the book and some that will be made up for the occasion. They may try to hunt me down. There will be chaos for a few days, maybe a few weeks. The world financial system will grind to a halt, as programmers work frantically around the clock. Software cryptography will have to be quickly installed, until a new hardware system can be designed. For now, incompatibility will return, efficiency will be reduced, and a lesson will be learned. Hopefully, the NCPI will not make the same mistake twice. Hopefully, they won't classify the algorithm next time. --==<< Infocalypse >>==-- (Binary file transmission follows this message) From newsham at wiliki.eng.hawaii.edu Tue Sep 21 02:42:30 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Tue, 21 Sep 93 02:42:30 PDT Subject: Public-Key Crypto Toolkit Message-ID: <9309210942.AA18954@toad.com> > THUS SPAKE Mike Ingle : > # Any ideas as > # to what language/method would be best for implementing a PK toolbox? This > # could really get the "Cypherpunks write code" ideal moving. Anyone want to > # help? > > Yeah, let's write some code! > > "TCL" is my language of choice for this -- it was designed specifically > for wrapping other libraries and embedding inside other tools. good choice, I think a crypto library written for TCL or TCL/TK would be nice. > I've been wanting to build the crypto-toolkit, too, and have started with RSAREF wrappers. > > There's a nice TCP module for TCL that lets you implement clients and > servers. There's also the "TK" X-windows toolkit, for seamless graphical > interfaces to TCL stuff. > > Ftp to sprite.berkeley.edu and ftp down TCL or TK (which will include TCL). > (A lot of people may suggest perl, but perl was designed with a different > set of goals in mind.) I havent had alot of luck getting different add ons compiled for tcl/tk, perhaps because I use one of the newer versions of tcl, the tcp module was one of them. > strick > strick at versant.com What we need most of all is an interface. This is basically what you are proposing. Since tcl add-ons are usually written in C I think it would be best off to start with a C library calling interface. Once this is made, you could build a tcl shell (or a wish shell) on top of it. I expressed what I would like to see in a C library interface a few days ago. It would be based on PGP routines and the PGP "shell" would be re-implemented over it. I have gotten no feedback on the idea at all. Are there any members of the PGP team on this list? If not how could I get in touch with them? This is an idea I really would like to see done, and which would pave the way to coding alot of applications and interfaces to PGP. I would gladly work on such a project myself, but I am afraid if I do my code will be both un-exportable and non standard and will hence go unused. ... From hfinney at shell.portal.com Tue Sep 21 03:46:29 1993 From: hfinney at shell.portal.com (Hal Finney) Date: Tue, 21 Sep 93 03:46:29 PDT Subject: REMAIL: policy Message-ID: <9309210156.AA16050@jobe.shell.portal.com> Remailers: hfinney at shell.portal.com hal at alumni.caltech.edu I keep logs only of the date/time at which my remailers get used; no logging is kept of the message contents. I do this only to get a picture of the overall volume of messages passing through my remailer. The Unix systems on which I run these remailers may also do some logging; I haven't been able to determine exactly what is done. I presume this might include incoming and outgoing addresses as well as message date/time and possibly size. (I am familiar only with uucp mail and don't know where to look on these net-connected Unix systems for sendmail logs.) My account on alumni.caltech.edu is free, based on my membership in the school alumni association (for which I paid some $300 about fifteen years ago for a life membership). My account on shell.portal.com costs my about $20 a month in fixed costs, plus $2/hour connect charges which typically run another $30 a month or so. So I am paying these people quite a bit and I hope therefore that this will give me some bargaining strength if political problems arise from the remailers. However, due to the large number of users on these systems, there are many restrictions on my usage. I cannot leave daemon processes running, nor can I use at or cron to schedule periodic jobs. The nice thing about the current remailer scripts is that they can be triggered by incoming mail without having a high profile to system administrators. Both of these systems appear to be well connected on the net and are almost always available. Both support PGP encryption. I am hoping to add batch capabilities to the remailers soon, based on Karl's scripts. I also like Karl's suggestion to add message padding to outgoing messages. If this system were used in conjunction with batching then if all messages in a batch were outgoing-padded (undetectably) to the size of the largest message in the batch then there would be total hiding of the incoming-to-outgoing message mapping. Earlier I had assumed that both incoming and outgoing messages would have to be standardized in size but now I see that padding of outgoing-only messages would be sufficient. Hal Finney hfinney at shell.portal.com From hfinney at shell.portal.com Tue Sep 21 03:47:30 1993 From: hfinney at shell.portal.com (Hal Finney) Date: Tue, 21 Sep 93 03:47:30 PDT Subject: Timing of Moby subpoena Message-ID: <9309201606.AA24301@jobe.shell.portal.com> From: smb at research.att.com > Ward posted a note that (in essence) asked for help in evading the ITARs. Since Moby Crypto is, as I understand it, composed of material which is generally available all over the world, it may not be necessary that it be exported from the U.S. in order to exist in a foreign country. One should be careful about accusing others of conspiracy to violate the ITARs, even qualifying it with "in essence". > Face it -- if Ward *wanted* to generate a test > case, he couldn't have done a much better job; a private note to the > authorities could have been ``misfiled'', but an announcement to tens > of thousands of readers around the world? C'mon -- they may or may not > be stupid, and they may or may not be paranoid, but their entire raison > d'etre is to wield power, and Grady just slapped that authority in the > face. Spitting at your local traffic cop would have been a lot safer. The note that Steve is referring to is presumably this. Note the date: > Newsgroups: talk.politics.crypto > From: grady at netcom.com (Grady Ward) > Subject: Want to drop-ship Moby Crypto? > Message-ID: > Date: Tue, 14 Sep 1993 16:20:50 GMT > > Is there anyone receiving this feed outside the > United States who would like to act as my foreign > drop-ship agent for Moby Crypto? > [...] I think the relative timing of this announcement and the subpoena makes it questionable whether the subpoena was in response to this posting. According to Ward's later post: > Newsgroups: comp.org.eff.talk,sci.crypt,alt.security.pgp,talk.politics.crypto > From: grady at netcom.com (Grady Ward) > Subject: Re: *FLASH* Moby SUBPOENA served > Message-ID: > Date: Fri, 17 Sep 1993 06:51:11 GMT > [...] > At 10:30 PM EDT Thursday, 16 Sept 1993 Theodore R. Siggins, > special agent for the Department of Treasury, U.S. > Customs Service office of enforcement for > Austin, TX (512) 482-5502 served the following > subpoena: This is two days after Ward's message, which is pretty fast response for law enforcement. But this is the date of service. The subpoena had to be issued and signed before this. Did that occur after Ward's Sep 14 posting? It's not 100% clear, but what the subpoena itself, as posted by Grady, says is: > This subpoena is issued on application of the United States of America > Michael J. Yamaguchi > United States Attorney > > Assistant U.S. Attorney > William P. Keane > 280 S. First St., Suite 371 > San Jose, CA 95113 > (408) 291-7221 > s/a Robin Sterzer, Customs > 93-1348(SJ) 93-1(SJ) > > 9 September 1993 If Sep 9 is the date on which the subpoena was actually issued, this was five days before Grady Ward's post which supposedly triggered the subpoena. Unless the Feds are prescient, they must have been planning to subpoena Austin Code Works about Moby Crypto, PGP, and RSA long before Ward's post. Hal hfinney at shell.portal.com From pierre at shell.portal.com Tue Sep 21 03:47:58 1993 From: pierre at shell.portal.com (Pierre Uszynski) Date: Tue, 21 Sep 93 03:47:58 PDT Subject: Standard Headers for Anonymous Remailers Message-ID: <9309210809.AA08533@jobe.shell.portal.com> > From: mentor at indial1.io.com (Loyd Blankenship) > > One of the big problems is anonymous bombardment of a > helpless newsgroup. This (and the problem of auto-screening anonymous > mail) could be solved if there was a standard header keyword (or maybe > even a new header field) that could be screened from a newsgroup. > [Any thoughts?] Yeah, some thoughts, > From: greg at ideath.goldenbear.com (Greg Broiles) > > If a significant fraction > of the net community responds to wider access to anonymity by filtering out > anonymous mail, my prediction (and suggestion :) is that people [...] > will resort to mail which is non-obviously anonymous. The possibilities for 1) (more or less) anonymous posting, 2) forged headers, 3) general obnoxiousness 4) automatic abuse of netnews facilities, 5) secret or forged "identities", all already exist on netnews. Many have already been used in offensive action as in the following recent examples (I'd welcome more data and pointers about these and similar cases, and some of these may have been rumors only. I'm also sure some good ones happened before my time :-) 1) anonymous posting services (penet), 2) forged headers are very popular of course, and do not really surprise anybody anymore, 3) I'll avoid naming examples of direct obnoxiousness, thank you :-) 4) (semi-?)automatic newsgroup re-creation after rmgrouping (Becker), 4) post-moderation via cancel messages (who was that guy again?), 5) SRIA vote-taker, accused of being the same person as the main proponent of the group (with syslogs as evidence), 5) "It was not me, I left my terminal logged on..." 5) suspect votes from generic accounts, all posted at the same time... And some other mechanisms scream for new forms of abuse :-) It's amazing that everybody is resisting the temptation... The responses have been: - A few flame wars (some pretty entertaining), - The most exposed newsgroups, like religious groups, are systematically moderated (to improve signal to noise ratio, but also to try to prevent attacks), - The most obnoxious people have been posting away under their own name, proudly disdaining (that we know of) the possibilities of technology :-) - and overall, the net as we know it goes on, with just some minor flamage overhead. So, as you can see, I'm pretty optimistic (I actually found most of these actions at least interesting, if maybe ...errr... crude). I do not think you really want to go to the trouble of really preventing people from posting (more or less) anonymously if they want to simply because that's too much trouble. One the other hand, most offensive action on the net has in the past been proudly done under the perpetrator's real name, or under Real Thin disguise. Of course, if it's possible, it will happen, and so eventually netnews will have to shut down for a few days under an attack of the magnitude of the one that stroke down the Internet itself. And somebody will end up in court... It's not also that I deny groups the right to express their disgust towards anonymous posting, but rather that I think they are wasting their time until much more infrastructure is available for accountability (that may not be so far away, but that's a different story). A remailer "tag" would help (at least politically), but at this stage, would be deceiving in that it does not really solve any user's problem (if there ever was any). Still, delusion and all, it may make remailers more socially acceptable... errr... tolerable :-) It could also create a distinction between "nice" remailers (obediently tagged) and "naughty" remailers (proudly un-tagged). Pierre "What emphasys?". pierre at shell.portal.com From bart at netcom.com Tue Sep 21 05:20:08 1993 From: bart at netcom.com (Harry Bartholomew) Date: Tue, 21 Sep 93 05:20:08 PDT Subject: archie search on pgp Message-ID: <9309211217.AA25447@netcom3.netcom.com> In response to the request I ran a search on the UNL archie server to see how many locations had pgp. The count of all versions and devivatives like docs and shells is 556. There is quite a bit of obsolete stuff though. >grep pgp10 pgp.lst |wc 40 265 2593 >grep pgp20 pgp.lst |wc 54 363 3440 >grep pgp21 pgp.lst | wc 74 518 4767 >grep pgp22 pgp.lst | wc 153 951 9042 >grep pgp23 pgp.lst | wc 36 252 2313 From gtoal at an-teallach.com Tue Sep 21 05:56:29 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Tue, 21 Sep 93 05:56:29 PDT Subject: Standard Headers for Anonymous Remailers Message-ID: <9309211251.AA26597@big.l1135.att.com> In article <9309210809.AA08533 at jobe.shell.portal.com> pierre at shell.portal.com writes: > > of the net community responds to wider access to anonymity by filtering out > > anonymous mail, my prediction (and suggestion :) is that people [...] > > will resort to mail which is non-obviously anonymous. Just to let you know, this *is* happening. I got so pissed off at the postings here from anonymous remailers that I've now put them in my kill file. (I gate this stuff into a local newsgroup and read it with a newsreader). Actually it wasn't the content of the articles that narked me, it was that I actually wanted to *reply* to the authors. However the subjects were way too off-topic to be worth responding to in public, which is the only option the anonymous remailers allows. I've no objections (and haven't kill'd) articles from penet etc that I can reply to. I'm not entirely happy with the whole concept of 'hit&run' anonymous remailers - they're only good for throwaway comments on public lists, or whistleblowing. That's not how they're being used - they're forcing people to have private conversations in public lists like this, which I think is unfair to the rest of the list community - I'm *sure* it's contributed to the number of people dropping off this list lately. G -- Personal mail to gtoal at gtoal.com (I read it in the evenings) Business mail to gtoal at an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212 From gtoal at an-teallach.com Tue Sep 21 07:06:31 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Tue, 21 Sep 93 07:06:31 PDT Subject: Master Key: A Clipper Story Message-ID: <10565@an-teallach.com> For god's sake, how many copies of this trash are we going to get? If you're going to use anonymous remailers to mailbomb our list, at least learn to use them properly and just send us one copy! That makes three so far - two of them via the same remailer even! G PS To the person who was bragging about using a spelling checker to hide his anonymity, erm... have a closer look at your post, buddy! I don't think it would take more than 10 minutes with an index of all usenet postings over the last month or two to find you :) -- Personal mail to gtoal at gtoal.com (I read it in the evenings) Business mail to gtoal at an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212 From anon at avon.org Tue Sep 21 07:48:03 1993 From: anon at avon.org (smells huh?) Date: Tue, 21 Sep 93 07:48:03 PDT Subject: your mailRe: Re: your mail In-Reply-To: <9309202328.AA12607@soda.berkeley.edu> Message-ID: nobody at soda.berkeley.edu writes: > "spell") to remove more nuances. Next we need an > English-to-bland-English translator that smooths over individual > language features (unless you're practicing stegonagraphy, then you > want one that inserts them!) i just eliminate all my caps - the better to emulate a net.personality. and add expletives, grinning all the while. pardon the poor forgery From gnu Tue Sep 21 08:46:30 1993 From: gnu (John Gilmore) Date: Tue, 21 Sep 93 08:46:30 PDT Subject: Gopher access to Federal Register Message-ID: <9309211544.AA23924@toad.com> Gopher to gopher.internet.com, port 2002, and you will find the Federal Register online. For most documents, you can only get the first 100 lines, but the use of the indexes is free, and many documents are useful in this form. You can pay them for access to the full documents, but they prohibit republishing online -- though you're free to print the documents out. What heart these guys have! John From pmetzger at lehman.com Tue Sep 21 09:08:04 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 21 Sep 93 09:08:04 PDT Subject: Gopher access to Federal Register In-Reply-To: <9309211544.AA23924@toad.com> Message-ID: <9309211605.AA22029@snark.lehman.com> John Gilmore says: > Gopher to gopher.internet.com, port 2002, and you will find the Federal > Register online. For most documents, you can only get the first > 100 lines, but the use of the indexes is free, and many documents > are useful in this form. > > You can pay them for access to the full documents, but they prohibit > republishing online -- though you're free to print the documents out. > What heart these guys have! This can't be legal. You can copyright a collection, true, but you can't hold copyright on an element of a collection of public domain information. I'd check with a lawyer first, but I don't think they can actually legally stop you. Perry From 0005542837 at mcimail.com Tue Sep 21 10:46:32 1993 From: 0005542837 at mcimail.com (David Colston) Date: Tue, 21 Sep 93 10:46:32 PDT Subject: Source code Message-ID: <54930921171645/0005542837NA1EM@mcimail.com> In case any one is interested, I have the source code for a non-RSA public key system. I wrote it in Microsoft PDS 7.1, which is a version of quick basic. It does 1024 bit keys and I can out run PGP in Basic. If anyone out there is a semi-mathematical type, I will also furnish a paper on the subject. Since this is non-RSA and I'm sure everyone reading this is in the U.S., I don't think I'm involation of ITAR. Uncle Dave From ebrandt at jarthur.Claremont.EDU Tue Sep 21 10:47:38 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Tue, 21 Sep 93 10:47:38 PDT Subject: Standard Headers for Anonymous Remailers In-Reply-To: <10560@an-teallach.com> Message-ID: <9309211746.AA25747@toad.com> > From: gtoal at an-teallach.com (Graham Toal) > Actually it wasn't the content of the articles that narked me, it was > that I actually wanted to *reply* to the authors. However the subjects > were way too off-topic to be worth responding to in public, which is > the only option the anonymous remailers allows. Though it's a bit clunky to use, the present remailers do support return addressses. I will admit that I haven't seen anybody supply one. Eli ebrandt at jarthur.claremont.edu From greg at ideath.goldenbear.com Tue Sep 21 11:23:09 1993 From: greg at ideath.goldenbear.com (Greg Broiles) Date: Tue, 21 Sep 93 11:23:09 PDT Subject: Bidzos on PGP and ITAR verbatim In-Reply-To: <9309210531.AA09003@longs.lance.colostate.edu> Message-ID: "L. Detweiler" writes: > There is a section on `illegal export of unclassified technical data to > foreign nationals' (paraphrase) and Bidzos claims it applies to PGP > export. But he appears to me to be using a bit of sleight of hand to > conflate this category with *cryptographic software* mentioned > elsewhere (sections also as quoted also by H. Finney). If Bidzos is using the term "technical data" as it's defined in $120.21 of the ITAR, I think it's debatable. Can we come up with data to support that IDEA and RSA are "commonly taught .. in academia"? The public (and published) nature of both IDEA and RSA seems to place them far away from the general thrust of the "technical data" definition, which seems oriented towards preventing disclosure of data/information that's not available to the general public. Def'n follows: $120.21 Technical data. Technical data means, for purposes of this subchapter: (a) Classified information relating to defense articles and defense services; (b) Information covered by an invention secrecy order; (c) Information, in any form, which is directly related to the design, engineering, development, production, processing, manufacture, use, operation, overhaul, repair, maintenance, modification, or reconstruction of defense articles. This includes, for example, information in the form of blueprints, drawings, photographs, plans, instructions, computer software, and documentation. This also includes information which advances the state of the art of articles on > the U.S. Munitions List. This definition does not > include information concerning general scientific, > mathematical, or engineering principles commonly > taught in academia. It also does not include basic marketing information or general system descriptions of defense articles. [emphasis added, of course] I'm working my way through the ITAR and am going to leave the majority of Bidzos' message alone until I feel like I have a stronger grasp on the legal issues here. He did, however, say two things which look pretty shaky to me: > When you make a defense item available on a BBS, you have exported it. The definitions of export that I've seen have concerned transferring information or physical things, or providing services to, persons, corporations, or nations which are not U.S. citizens. They have not addressed placing these things where "foreign persons" might conceivably get them. Under Bidzos' interpretation, making RSAREF available via FTP sounds like export to me. My interpretation is based on ITAR; other relevant statutes may define it more broadly, but those definitions aren't relevant when talking about violations of the ITAR. > pgp is software tainted by serious ITAR violations. I interpret this to mean, assuming that Bidzos is right on all points, that: (1) all copies (and their descendants?) of PGP 1.0 which have been taken outside of the U.S. are "tainted" and cannot be re-imported legally; and (2) all copies (and their descendants?) of PGP 2.x which were written outside of the U.S. are "tainted" once they enter the U.S.; U.S. citizens will need to re-write (sigh) PGP 2.x inside the U.S., using the published algorithms for IDEA and RSA. I can't see any basis for saying that "PGP", a standard for interoperable crypto software, is tainted - only particlar implementations of that standard are, depending on who wrote them and what country the author is from, where the copy is located, and where it's been before. Surely Bidzos won't claim that RSA licensees in the U.S. are somehow "tainted" by the illegal export of other copies of RSA, hmm? -- Greg Broiles greg at goldenbear.com Baked, not fried. From klbarrus at owlnet.rice.edu Tue Sep 21 11:56:33 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Tue, 21 Sep 93 11:56:33 PDT Subject: GOPHER: now on port 70 Message-ID: <9309211852.AA14265@flammulated.owlnet.rice.edu> Cypherpunks, Chael has made the necessary changes, and the cypherpunks gopher now listens to port 70 as standard gophers do... So 'gopher chaos.bsu.edu' or 'gopher 147.226.53.28'. I will look into announcing the site to the gopher list maintainers at UMN; perhaps some sites that are able to look up chaos.bsu.edu consistently will consider including a pointer to us! Karl Barrus From derek at cs.wisc.edu Tue Sep 21 12:02:39 1993 From: derek at cs.wisc.edu (Derek Zahn) Date: Tue, 21 Sep 93 12:02:39 PDT Subject: Why RSA? Message-ID: <9309211900.AA15359@lynx.cs.wisc.edu> Is there some reason that we shouldn't pick a different public key encryption algorithm than RSA to use as a freely-available standard? The PGP docs imply that "almost" all practical such schemes are patented, implying that some are not. The legitimacy problems of PGP are a major roadblock to widespread use of encryption, IMO. Let's get something in the public domain! derek From ebrandt at jarthur.Claremont.EDU Tue Sep 21 12:06:34 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Tue, 21 Sep 93 12:06:34 PDT Subject: jarthur is running pgp 2.3 Message-ID: <9309211903.AA26864@toad.com> Just tested a 2.3-encrypted message through here, and it seems to be working. Share and enjoy. Eli ebrandt at jarthur.claremont.edu From tcmay at netcom.com Tue Sep 21 12:16:33 1993 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 21 Sep 93 12:16:33 PDT Subject: Master Key: A Clipper Story In-Reply-To: <9309210612.AA19084@mail.netcom.com> Message-ID: <9309211914.AA17965@netcom5.netcom.com> I enjoyed the Cypherpunk short story, "Master Key." Not perfect, maybe longer than some would like, but generally entertaining. It seems to me that writing scenarios for the future is a useful thing to do, allowing exploration of various developments in a fictional setting. This is a time-honored thing to do when new technologies appear, and is something I've been trying to do for several years now (writing a novel about the development of crypto anarchy, and have been--gulp!--since 1988...maybe someday, unless events overtake me). An editor might tighten up "Infocalypse"'s writing, and the whole idea that Skipjack will fall to genetic programming techniques seems to be a reach. But who knows....the truth is often stranger than fiction. And the transition to a Clipper world seems to happen a bit faster than I think is likely. But these are quibbles. Highlighting the "house of cards" effect in using a centralized, monolithically controlled crypto system (the Skipjack algorithm) is an important contribution. If the public is to understand the consequences of the kind of centralization favored by the Feds, e.g., Skipjack and the National Data Superhighway, then they'll need understandable pieces like this. As to the repeat mailing, this needs to be addressed by Infocalypse. Maybe he sent it once, didn't see it within some reasonable time, and sent it again. As to length, and the "Hey, I pay for my mail" comments, bear in mind that this story undoubtedly took Infocalypse a tremendous amount of time to craft, whereas many of the many "forwardings" we get here on this list are just as long and yet took almost no effort to send to the list. Thus, we should cut Infocalypse some slack. And congratulate him, in fact. Well done! -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From klbarrus at owlnet.rice.edu Tue Sep 21 12:21:33 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Tue, 21 Sep 93 12:21:33 PDT Subject: MAIL: anonymous, positive reputations Message-ID: <9309211918.AA17309@flammulated.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- Earlier, Graham mentioned some concerns about anonymous mail; specifically it isn't easy to respond to the author, most messages are off topic, etc. (hopefully not referring to my posts sent through remailers :-) on topics like the cypherpunks gopher and caching remailers...) And some people are asking about marking anonymous mail (gopher plug: check the article "Why Mark Anonymous Mail?" at the gopher site in the "Anonymous Mail" section, contributed by Hal Finney sometime ago). Currently, I sign my posts sent through anonymous remailer, sometimes including my address at the bottom of the post itself. I know others do this as well - Hal Finney, probably others I can't think of. I am working on (and off as time constraints crop up) a positive reputation scheme for anonymous mail. My stab at this is somewhat modest: a program that sifts through elm mail folders (similar to the elm frm command) and produces a formatted list containing message number, email address of author (frm sometimes reports name and I like email addresses instead), and subject. BUT, instead of printing email address, if the message is pgp signed, report the signature instead. Under this program, the fact that an anonymous remailer was used is somewhat transparent since you would see who signed the document sent through a remailer. This would allow somebody to build up a positive reputation attached to a pgp signature (which could be fairly anonymous) and possibly help guide anonymous mail kill file users. Naturally, it would be best if it were easy to respond to an anonymous mail, if this were incorporated into mail programs, etc. but I have two problems: time constraints, and disk quota (I can't lay out the source code for elm, pgp, whatever else). I'm to the point where the script I include below does what I want expect check for digital signatures on letters. Since there isn't a pgp library (yet), the next step will be difficult since I'd rather not pipe the message through pgp just to get the signature, although for testing I'll implement something in the next few weeks. Here is the script: if anybody has input, speak up! I named it scan after the mh command it is a poor imitation of. Usage: 'scan foldername returns a formatted list of mail in the folder "foldername" Ug, I see an improvement I will make tonight: using getenv() to get my home directory instead of plugging it in directly: - ----------8< cut here >8---------- #!/usr/local/bin/perl #report email address and subject of messages in an elm folder #frm sometimes reports name and not email address - not that I # guarantee this works in all cases #simple version of mh scan command #Karl L. Barrus chdir "/home/klbarrus/Mail" || die "Can't cd to ~/Mail\n"; while (@ARGV) { $file = shift @ARGV; if (-T $file) { if (-z $file) { #zero length folders with no messages print "Folder $file has no messages\n"; } elsif (!open(FOLDER, "/home/klbarrus/Mail/$file")) { print STDERR "Can't open $file\n"; } else { $state = 1; #Look for a new message $num = 0; while () { if (/^From[^:]/) { #Delimits a new message $num++; $from = ""; $subject = ""; $state = 2; #Look for From: and Subject: } if ($state == 2) { #Already found a message; looking for headers /^Subject: (.*)/ && ($subject = $1); #match subject /^From: (.+)/ && ($from = $1); #match "From: add" /^From: (.+) <(.+)>/ && ($from = $2); #match "From: name " /^From: (.+) \((.+)\)/ && ($from = $1); #match "From: add (name)" if ($from ne "" && $subject ne "") { #found both headers $state = 1; #go back to looking for message delimiter write; } } } } } elsif (-d $file) { print STDERR "$file is a directory\n"; } } exit; format STDOUT_TOP = From nowhere at bsu-cs.bsu.edu Tue Sep 21 12:36:35 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Tue, 21 Sep 93 12:36:35 PDT Subject: Cypherpunks & GOPHER In-Reply-To: <9309182215.AA01627@flammulated.owlnet.rice.edu> Message-ID: <9309211935.AA13896@bsu-cs.bsu.edu> > >I'm running the gopher site at chaos.bsu.edu, thanks to Chael Hall, >who graciously donated an account to me to be used for any and all ^^^ ^^^ ^^^ >projects. This is something I've been wanting to do for quite some ^^^^^^^^ >time but have been unable to. But now I have an account and a >sympathetic system administrator...! Hmmm... In other words, everything that you have suggested so far has been alright with me. But a project to render the Internet useless would not be okay. >Chaos.bsu.edu is 147.226.53.28, and the port is 2000. That is port >2000 and not the usual port 70 - when Chael and I have some more time >I will ask him to perform the various and necessary incantations >(chown) and I'll move it to the usual place. It has been moved to port 70 like all other gopher sites. You should be able to do 'gopher 147.226.53.28' or 'gopher chaos.bsu.edu' now. Once again, anyone who wants an account on here, apply for one by telnetting to chaos.bsu.edu (147.226.53.28) and logging in as guest. -- Chael Hall nowhere at bsu-cs.bsu.edu 00CCHALL at BSUVC.BSU.EDU nowhere at chaos.bsu.edu chall at bsu.edu From pmetzger at lehman.com Tue Sep 21 12:46:34 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 21 Sep 93 12:46:34 PDT Subject: Why RSA? In-Reply-To: <9309211900.AA15359@lynx.cs.wisc.edu> Message-ID: <9309211943.AA22383@snark.lehman.com> Derek Zahn says: > > Is there some reason that we shouldn't pick a different > public key encryption algorithm than RSA to use as a > freely-available standard? The PGP docs imply that "almost" > all practical such schemes are patented, implying that > some are not. All are patented in so far as one of the patents covers ALL public key schemes. Some, like Rabin's scheme, have possible technical advantages over RSA. (For the curious, Rabin's scheme is provably equivalent to factoring, whereas RSA is not. Rabin's scheme is, however, vulnerable to chosen plaintext attacks, but adding things like initialization vectors stops that from being a problem.) Perry From gnu Tue Sep 21 12:47:39 1993 From: gnu (John Gilmore) Date: Tue, 21 Sep 93 12:47:39 PDT Subject: crypto import In-Reply-To: <9309201128.AA29694@toad.com> Message-ID: <9309211947.AA27682@toad.com> > if a law was broken. And Sternlight is right -- if they decide to indict, > they may throw in charges of importing IDEA ... THERE IS NO LAW AGAINST THE IMPORT OF CRYPTOGRAPHY! How many times does this idiocy have to be squashed? John PS: I heard a rumor it's against the law to breathe. From smb at research.att.com Tue Sep 21 13:27:40 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 21 Sep 93 13:27:40 PDT Subject: crypto import Message-ID: <9309212027.AA28484@toad.com> > if a law was broken. And Sternlight is right -- if they decide to i ndict, > they may throw in charges of importing IDEA ... THERE IS NO LAW AGAINST THE IMPORT OF CRYPTOGRAPHY! How many times does this idiocy have to be squashed? Perhaps not now, but the statutory and regulatory provisions exist: >From the ITAR: 120.1 -- General authorities and eligibility. (a) Section 38 of the Arms Export Control Act (22 U.S.C. 2778) authorizes the President to control the export and import of defense articles and defense services. 120.5 -- Relation to regulations of other agencies. If an article or service is covered by the U.S. Munitions List, its export is regulated by the Department of State, except as indicated otherwise in this subchapter. For the relationship of this subchapter to regulations of the Department of Commerce, the Department of Energy and the Nuclear Regulatory Commission, see ^U 123.20 of this subchapter. The Treasury Department controls permanent imports of articles and services covered by the U.S. Munitions Import List from foreign countries by persons subject to U.S. jurisdiction (31 CFR part 505). 123.2 -- Import jurisdiction. The Department of State regulates the temporary import of defense articles. Permanent imports of defense articles into the United States are regulated by the Department of the Treasury (see 27 CFR parts 47, 178 and 179). etc. I confess that I don't happen to have a copy of the Munitions Import List. Are you certain that crypto gear isn't on it? Are you certain it wasn't added last week? Or next? But the same authority -- dubious though it may be -- that lets them ban export of crypto would let them ban import if they chose to try. John PS: I heard a rumor it's against the law to breathe. Only if there's a coded message in the timing. From marc at GZA.COM Tue Sep 21 13:30:09 1993 From: marc at GZA.COM (Marc Horowitz) Date: Tue, 21 Sep 93 13:30:09 PDT Subject: Master Key: A Clipper Story In-Reply-To: <9309211914.AA17965@netcom5.netcom.com> Message-ID: <9309212027.AA09946@dun-dun-noodles.aktis.com> >> An editor might tighten up "Infocalypse"'s writing, and the whole idea >> that Skipjack will fall to genetic programming techniques seems to be >> a reach. But who knows....the truth is often stranger than fiction. It was once said to me by a writer friend that the key to good science fiction is to choose one absurdity, and build logically on that. Consider that faster-than-light travel is an absurdity today. That doesn't stop good SF from being based on it. That's what makes it "fiction" after all. The point of the story is that if Key Escrow falls, the results could be catastrophic. How it falls is a plot device; the technical merit is not of intrinsic importance. >> Well done! I agree! Marc From banisar at washofc.cpsr.org Tue Sep 21 13:46:35 1993 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Tue, 21 Sep 93 13:46:35 PDT Subject: NIST Comment Deadline Message-ID: <00541.2831472385.5544@washofc.cpsr.org> NIST Comment Deadline The September 28 deadline for the submission of comments on NIST's proposal to establish the "Skipjack" key-escrow system as a Federal Information Processing Standard (FIPS) is rapidly approaching. The full text of the NIST Federal Register notice follows. CPSR is urging all interested individuals and organizations to express their views on the proposal and to submit comments directly to NIST. Comments need not be lengthy or very detailed; all thoughtful statements addressing a particular concern will likely contribute to NIST's evaluation of the key-escrow proposal. The following points could be raised about the NIST proposal (additional materials on Clipper and the key escrow proposal, including comments already submitted to NIST, may be found at the CPSR ftp site, cpsr.org /cpsr/crypto/clipper): * The potential risks of the proposal have not been assessed and many questions about the implementation remain unanswered. The NIST notice states that the current proposal "does not include identification of key escrow agents who will hold the keys for the key escrow microcircuits or the procedures for access to the keys." The key escrow configuration may also create a dangerous vulnerability in a communications network. The risks of misuse of this feature should be weighed against any perceived benefit. * The classification of the Skipjack algorithm as a "national security" matter is inappropriate for technology that will be used primarily in civilian and commercial applications. Classification of technical information also limits the computing community's ability to evaluate fully the proposal and the general public's right to know about the activities of government. * The proposal was not developed in response to a public concern or a business request. It was put forward by the National Security Agency and the Federal Bureau of Investigation so that these two agencies could continue surveillance of electronic communications. It has not been established that is necessary for crime prevention. The number of arrests resulting from wiretaps has remained essentially unchanged since the federal wiretap law was enacted in 1968. * The NIST proposal states that the escrow agents will provide the key components to a government agency that "properly demonstrates legal authorization to conduct electronic surveillance of communications which are encrypted." The crucial term "legal authorization" has not been defined. The vagueness of the term "legal authorization" leaves open the possibility that court- issued warrants may not be required in some circumstances. This issue must be squarely addressed and clarified. * Adoption of the proposed key escrow standard may have an adverse impact upon the ability of U.S. manufacturers to market cryptographic products abroad. It is unlikely that non-U.S. users would purchase communication security products to which the U.S. government holds keys. Comments on the NIST proposal should be sent to: Director, Computer Systems Laboratory ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Written submissions must be received by September 28, 1993 (CPSR asked NIST that provisions be made to allow for electronic submission of comments, but the agency recently rejected that suggestion). Please also send copies of your comments on the key escrow proposal to CPSR for inclusion in the CPSR Internet Library, our ftp site. Copies should be sent to . ================================================================= FEDERAL REGISTER VOL. 58, No. 145 DEPARTMENT OF COMMERCE (DOC) National Institute of Standards and Technology (NIST) Docket No. 930659-3159 RIN 0693-AB19 A Proposed Federal Information Processing Standard for an Escrowed Encryption Standard (EES) 58 FR 40791 Friday, July 30, 1993 Notice; request for comments. SUMMARY: A Federal Information Processing Standard (FIPS) for an Escrowed Encryption Standard (EES) is being proposed. This proposed standard specifies use of a symmetric-key encryption/decryption algorithm and a key escrowing method which are to be implemented in electronic devices and used for protecting certain unclassified government communications when such protection is required. The algorithm and the key escrowing method are classified and are referenced, but not specified, in the standard. This proposed standard adopts encryption technology developed by the Federal government to provide strong protection for unclassified information and to enable the keys used in the encryption and decryption processes to be escrowed. This latter feature will assist law enforcement and other government agencies, under the proper legal authority, in the collection and decryption of electronically transmitted information. This proposed standard does not include identification of key escrow agents who will hold the keys for the key escrow microcircuits or the procedures for access to the keys. These issues will be addressed by the Department of Justice. The purpose of this notice is to solicit views from the public, manufacturers, and Federal, state, and local government users so that their needs can be considered prior to submission of this proposed standard to the Secretary of Commerce for review and approval. The proposed standard contains two sections: (1) An announcement section, which provides information concerning the applicability, implementation, and maintenance of the standard; and (2) a specifications section which deals with the technical aspects of the standard. Both sections are provided in this notice. DATES: Comments on this proposed standard must be received on or before September 28, 1993. ADDRESSES: Written comments concerning the proposed standard should be sent to: Director, Computer Systems Laboratory, ATTN: Proposed FIPS for Escrowed Encryption Standard, Technology Building, room B-154, National Institute of Standards and Technology, Gaithersburg, MD 20899. Written comments received in response to this notice will be made part of the public record and will be made available for inspection and copying in the Central Reference and Records Inspection Facility, room 6020, Herbert C. Hoover Building, 14th Street between Pennsylvania and Constitution Avenues, NW., Washington, DC 20230. FOR FURTHER INFORMATION CONTACT: Dr. Dennis Branstad, National Institute of Standards and Technology, Gaithersburg, MD 20899, telephone (301) 975-2913. SUPPLEMENTARY INFORMATION: This proposed FIPS implements the initiative announced by the White House Office of the Press Secretary on April 16, 1993. The President of the U.S. approved a Public Encryption Management directive, which among other actions, called for standards to facilitate the procurement and use of encryption devices fitted with key-escrow microcircuits in Federal communication systems that process sensitive, but unclassified information. Dated: July 26, 1993. Arati Prabhakar, Director.(NIST) ---------------------------------------------------- Federal Information Processing Standards Publication XX 1993 XX Announcing the Escrowed Encryption Standard (EES) Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. Name of Standard: Escrowed Encryption Standard (EES). Category of Standard: Telecommunications Security. Explanation: This Standard specifies use of a symmetric-key encryption (and decryption) algorithm and a Law Enforcement Access Field (LEAF) creation method (one part of a key escrow system) which provide for decryption of encrypted telecommunications when interception of the telecommunications is lawfully authorized. Both the algorithm and the LEAF creation method are to be implemented in electronic devices (e.g., very large scale integration chips). The devices may be incorporated in security equipment used to encrypt (and decrypt) sensitive unclassified telecommunications data. Decryption of lawfully intercepted telecommunications may be achieved through the acquisition and use of the LEAF, the decryption algorithm and escrowed key components. To escrow something (e.g., a document, an encryption key) means that it is "delivered to a third person to be given to the grantee only upon the fulfillment of a condition" (Webster's Seventh New Collegiate Dictionary). A key escrow system is one that entrusts components of a key used to encrypt telecommunications to third persons, called key component escrow agents. In accordance with the common definition of "escrow", the key component escrow agents provide the key components to a "grantee" (i.e., a government agency) only upon fulfillment of the condition that the grantee properly demonstrates legal authorization to conduct electronic surveillance of communications which are encrypted using the specific device whose key component is requested. The key components obtained through this process are then used by the grantee to reconstruct the device unique key and obtain the session key (contained in the LEAF) which is used to decrypt the telecommunications that are encrypted with that device. The term, "escrow", for purposes of this standard, is restricted to the dictionary definition. The encryption/decryption algorithm has been approved for government applications requiring encryption of sensitive unclassified telecommunications of data as defined herein. The specific operations of the algorithm and the LEAF creation method are classified and hence are referenced, but not specified, in this standard. Data, for purposes of this standard, includes voice, facsimile and computer information communicated in a telephone system. Telephone system, for purposes of this standard, is limited to systems circuit-switched up to no more than 14.4 kbs or which use basic-rate ISDN, or to a similar grade wireless service. Data that is considered sensitive by a responsible authority should be encrypted if it is vulnerable to unauthorized disclosure during telecommunications. A risk analysis should be performed under the direction of a responsible authority to determine potential threats and risks. The costs of providing encryption using this standard as well as alternative methods and their respective costs should be projected. A responsible authority should then make a decision, based on the risk and cost analyses, whether or not to use encryption and then whether or not to use this standard. Approving Authority: Secretary of Commerce. Maintenance Agency: Department of Commerce, National Institute of Standards and Technology. Applicability: This standard is applicable to all Federal departments and agencies and their contractors under the conditions specified below. This standard may be used in designing and implementing security products and systems which Federal departments and agencies use or operate or which are operated for them under contract. These products may be used when replacing Type II and Type III (DES) encryption devices and products owned by the government and government contractors. This standard may be used when the following conditions apply: 1. An authorized official or manager responsible for data security or the security of a computer system decides that encryption is required and cost justified as per OMB Circular A- 130; and 2. The data is not classified according to the National Security Act of 1947, as amended, or the Atomic Energy Act of 1954, as amended. However, Federal departments or agencies which use encryption devices for protecting data that is classified according to either of these acts may use those devices also for protecting unclassified data in lieu of this standard. In addition, this standard may be adopted and used by non- Federal Government organizations. Such use is encouraged when it provides the desired security. Applications: Devices conforming to this standard may be used for protecting unclassified communications. Implementations: The encryption/decryption algorithm and the LEAF creation method shall be implemented in electronic devices (e.g., electronic chip packages) that can be physically protected against unauthorized entry, modification and reverse engineering. Implementations which are tested and validated by NIST will be considered as complying with this standard. An electronic device shall be incorporated into a cyptographic module in accordance with FIPS 140-1. NIST will test for conformance with FIPS 140-1. Cryptographic modules can then be integrated into security equipment for sale and use in an application. Information about devices that have been validated, procedures for testing equipment for conformance with NIST standards, and information about obtaining approval of security equipment are available from the Computer Systems Laboratory, NIST, Gaithersburg, MD 20899. Export Control: Implementations of this standard are subject to Federal Government export controls as specified in title 22, Code of Federal Regulations, parts 120 through 131 (International Traffic of Arms Regulations -ITAR). Exporters of encryption devices, equipment and technical data are advised to contact the U.S. Department of State, Office of Defense Trade Controls for more information. Patents: Implementations of this standard may be covered by U.S. and foreign patents. Implementation Schedule: This standard becomes effective thirty days following publication of this FIPS PUB. Specifications: Federal Information Processing Standard (FIPS XXX)(affixed). Cross Index: a. FIPS PUB 46-2, Data Encryption Standard. b. FIPS PUB 81, Modes of Operation of the DES c. FIPS PUB 140-1, Security Requirements for Cryptographic Modules. Glossary: The following terms are used as defined below for purposes of this standard: Data-Voice, facsimile and computer information communicated in a telephone system. Decryption-Conversion of ciphertext to plaintext through the use of a cryptographic algorithm. Device (cryptographic)-An electronic implementation of the encryption/decryption algorithm and the LEAF creation method as specified in this standard. Digital data-Data that have been converted to a binary representation. Encryption-Conversion of plaintext to ciphertext through the use of a cryptographic algorithm. Key components-The values from which a key can be derived (e.g., KU sub 1 + KU sub 2). Key escrow -A process involving transferring one or more components of a cryptographic key to one or more trusted key component escrow agents for storage and later use by government agencies to decrypt ciphertext if access to the plaintext is lawfully authorized. LEAF Creation Method 1-A part of a key escrow system that is implemented in a cryptographic device and creates a Law Enforcement Access Field. Type I cryptography-A cryptographic algorithm or device approved by the National Security Agency for protecting classified information. Type II cryptography-A cryptographic algorithm or device approved by the National Security Agency for protecting sensitive unclassified information in systems as specified in section 2315 of Title 10 United State Code, or section 3502(2) of Title 44, United States Code. Type III cryptography-A cryptographic algorithm or device approved as a Federal Information Processing Standard. Type III(E) cryptography-A Type III algorithm or device that is approved for export from the United States. Qualifications. The protection provided by a security product or system is dependent on several factors. The protection provided by this standard against key search attacks is greater than that provided by the DES (e.g., the cryptographic key is longer). However, provisions of this standard are intended to ensure that information encrypted through use of devices implementing this standard can be decrypted by a legally authorized entity. Where to Obtain Copies of the Standard: Copies of this publication are for sale by the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When ordering, refer to Federal Information Processing Standards Publication XX (FIPS PUB XX), and identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS in current catalogs and other issuances. Payment may be made by check, money order, deposit account or charged to a credit card accepted by NTIS. Specifications for the Escrowed Encryption Standard 1. Introduction This publication specifies Escrowed Encryption Standard (EES) functions and parameters. 2. General This standard specifies use of the SKIPJACK cryptographic algorithm and the LEAF Creation Method 1 (LCM-1) to be implemented in an approved electronic device (e.g., a very large scale integration electronic chip). The device is contained in a logical cryptographic module which is then integrated in a security product for encrypting and decrypting telecommunications. Approved implementations may be procured by authorized organizations for integration into security equipment. Devices must be tested and validated by NIST for conformance to this standard. Cryptographic modules must be tested and validated by NIST for conformance to FIPS 140-1. 3. Algorithm Specifications The specifications of the encryption/decryption algorithm (SKIPJACK) and the LEAF Creation Method 1 (LCM-1) are classified. The National Security Agency maintains these classified specifications and approves the manufacture of devices which implement the specifications. NIST tests for conformance of the devices implementing this standard in cryptographic modules to FIPS 140-1 and FIPS 81. 4. Functions and Parameters 4.1 Functions The following functions, at a minimum, shall be implemented: 1. Data Encryption: A session key (80 bits) shall be used to encrypt plaintext information in one or more of the following modes of operation as specified in FIPS 81: ECB, CBC, OFB (64) CFB (1, 8, 16, 32, 64). 2. Data Decryption: The session key (80 bits) used to encrypt the data shall be used to decrypt resulting ciphertext to obtain the data. 3. Key Escrow: The Family Key (KF) shall be used to create the Law Enforcement Access Field (LEAF) in accordance with the LEAF Creation Method 1 (LCM-1). The Session Key shall be encrypted with the Device Unique Key and transmitted as part of the LEAF. The security equipment shall ensure that the LEAF is transmitted in such a manner that the LEAF and ciphertext may be decrypted with legal authorization. No additional encryption or modification of the LEAF is permitted. 4.2 Parameters The following parameters shall be used in performing the prescribed functions: 1. Device Identifier (DID): The identifier unique to a particular device and used by the Key Escrow System. 2. Device Unique Key (KU): The cryptographic key unique to a particular device and used by the Key Escrow System. 3. Cryptographic Protocol Field (CPF): The field identifying the registered cryptographic protocol used by a particular application and used by the Key Escrow System (reserved for future specification and use). 4. Escrow Authenticator (EA): A binary pattern that is inserted in the LEAF to ensure that the LEAF is transmitted and received properly and has not been modified, deleted or replaced in an unauthorized manner. 5. Initialization Vector (IV): A mode and application dependent vector of bytes used to initialize, synchronize and verify the encryption, decryption and key escrow functions. 6. Family Key (KF): The cryptographic key stored in all devices designated as a family that is used to create the LEAF. 7. Session Key (KS): The cryptographic key used by a device to encrypt and decrypt data during a session. 8. Law Enforcement Access Field (LEAF): The field containing the encrypted session key and the device identifier and the escrow authenticator. 5. Implementation The Cryptographic Algorithm and the LEAF Creation Method shall be implemented in an electronic device (e.g., VLSI chip) which is highly resistant to reverse engineering (destructive or non- destructive) to obtain or modify the cryptographic algorithms, the DID, the KF, the KU, the EA, the CPF, the operational KS, or any other security or Key Escrow System relevant information. The device shall be able to be programmed/personalized (i.e., made unique) after mass production in such a manner that the DID, KU (or its components), KF (or its components) and EA fixed pattern can be entered once (and only once) and maintained without external electrical power. The LEAF and the IV shall be transmitted with the ciphertext. The specifics of the protocols used to create and transmit the LEAF, IV, and encrypted data shall be registered and a CPF assigned. The CPF shall then be transmitted in accordance with the registered specifications. The specific electric, physical and logical interface will vary with the implementation. Each approved, registered implementation shall have an unclassified electrical, physical and logical interface specification sufficient for an equipment manufacturer to understand the general requirements for using the device. Some of the requirements may be classified and therefore would not be specified in the unclassified interface specification. From catalyst at netcom.com Tue Sep 21 13:51:35 1993 From: catalyst at netcom.com (Scott Collins) Date: Tue, 21 Sep 93 13:51:35 PDT Subject: REMAIL: policy Message-ID: <9309212043.AA26897@newton.apple.com> What follows is the policy for the remailer running at catalyst at netcom.com as of 21 Sept 1993: - 1 - I don't normally keep logs because (a) I lack the time to examine them; (b) I lack the space to keep them; and (c) frankly, I would rather _not_ know. If some exceptional situation requires it, I will temporarily log to resolve that situation. - 2 - I will block remailing to a given address on request and proof of identity by the owner. I run a remailer because I believe privacy is an inaliable human right. However, "Your right to swing your fist ends where my nose begins!". I will not condone, promote or aid the violation of other human rights in the name of privacy. Because I don't keep logs, I can do no more than block (nor would I wish to), although, see - 1 -. - 3 - I do not own the machine my remailer is running on. In fact it is a commercial system. Be nice. If they ask me to stop running my remailer on their system... I will. Additionally, you implicitly accept all the risks associated with trusting somebody elses machine. - 4 - I don't read mail that goes through my remailer _BUT_ it is my personal account, and personal mail addressed to me passes through it, therefore, if a message doesn't look like it contains remailer commands, the remailer assumes it must be to me and I get it. I read all mail that is addressed to me. The consequence is that poorly addressed messages intended to be remailed will be read by me. I will throw these messages away without responding, correcting, or forwarding them, as soon as I realize they were to have been remailed. Be aware that this can happen. I'm sure there is some threshold beyond which the content would force me to action in some way. What the content, threshold and possible actions are, I do not know. Protect yourself from this result by using multiple remailers and encrypting at each stage. - 5 - I am an engineer. I like to play. I probably cannot stop myself from constantly tweaking and growing the remailer code. It is, after all, an expermental system. The remailer you use today may not be the same one you get tomorrow. - 6 - I am a human being and suffer from all the associated frailties. When someone points a gun (actually or metaphorically) at me or my family, I must almost certainly comply with that entities wishes. I do NOT advocate law breaking and will comply with the law to the extent required and enforced; e.g., if the FBI comes to my door and says: "start logging your remailer, or shut it down" ("shut it down" might only be inferred ), then it is likely that I will comply to the extent required and enforced. - 7 - As with my kids: I reserve the right to change the rules at any time and for any reason; though I seldom exercise this right to explicitly revoke previously explicitly granted freedoms. - 8 - I run this remailer as a personal activity. It is in no way associated with my place of employment, my employer or the activities I engage in on the behalf of my employer. I run it out of a personal account on a commercial system that I pay for with my own money. If you have problems with the remailer, please talk to me first. If we can't resolve it, of course you can always report it to NetCom. - 9 - Finally, be aware that I am not _providing_ privacy. I am allowing it. That is, _you_ are the caretaker of your rights and must actively seek to protect them. I will help, but that is all I can do. If you wish to protect your privacy, I urge you to learn how and why these remailers (and other associated tools) work so that you can use them to the best advantage. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2B Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From derek at cs.wisc.edu Tue Sep 21 13:52:42 1993 From: derek at cs.wisc.edu (Derek Zahn) Date: Tue, 21 Sep 93 13:52:42 PDT Subject: Why RSA? Message-ID: <9309212049.AA00561@lynx.cs.wisc.edu> First, the ViaCrypt version: I realize that it is legal. It's also very expensive when compared to the price of email readers/composers that people normally use (often weighing in at about $50 / seat). A $200 add-on is not likely to be universally accepted. It's as if somebody had patented car door locks and claimed that $40,000 was a reasonable price to have them included on a $10,000 car. I'm not complaining about the price; people can charge whatever they want for their products. However it does seem kind of high, creating market pressure... that market pressure surfaces in messages like this one and hopefully someday competing products from somebody. Perry Metzger: > All are patented in so far as one of the patents covers ALL public key > schemes. Some, like Rabin's scheme, have possible technical advantages > over RSA. I am just beginning to study the mathematics behind public key crypto (got Simmons's _Contemporary Cryptology_ from the library this morning), but I haven't seen anything about what exactly this means (that is, I haven't been able to "look it up"). I was under the impression that many people participated in the development of P.K.Crypto... how can somebody patent all of their work? Don't these kind of patents apply only to specific algorithms? Begging the indulgence of this list, two more questions: * is there a reference I can read that covers the scope of public key crypto patents? * in broad terms, what would I have to do to develop an algorithm that works from a user's perspective like p.k.c. (ie public/private keys, the central functional point of all the wonderful schemes based on pkc) but doesn't violate patents? Thanks! derek From khijol!erc at apple.com Tue Sep 21 13:56:35 1993 From: khijol!erc at apple.com (Ed Carp) Date: Tue, 21 Sep 93 13:56:35 PDT Subject: Why RSA? In-Reply-To: <9309211943.AA22383@snark.lehman.com> Message-ID: > Derek Zahn says: > > > > Is there some reason that we shouldn't pick a different > > public key encryption algorithm than RSA to use as a > > freely-available standard? The PGP docs imply that "almost" > > all practical such schemes are patented, implying that > > some are not. > > All are patented in so far as one of the patents covers ALL public key > schemes. Some, like Rabin's scheme, have possible technical advantages > over RSA. How about that public key scheme they came up with in Australia a while back? And why should RSA's patent be so construed as to cover ALL public key schemes? Because Jim Bidzos says so? -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From pmetzger at lehman.com Tue Sep 21 14:10:11 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 21 Sep 93 14:10:11 PDT Subject: Why RSA? In-Reply-To: Message-ID: <9309212105.AA22690@snark.lehman.com> Ed Carp says: > > Derek Zahn says: > > > > > > Is there some reason that we shouldn't pick a different > > > public key encryption algorithm than RSA to use as a > > > freely-available standard? The PGP docs imply that "almost" > > > all practical such schemes are patented, implying that > > > some are not. > > > > All are patented in so far as one of the patents covers ALL public key > > schemes. Some, like Rabin's scheme, have possible technical advantages > > over RSA. > > How about that public key scheme they came up with in Australia a while > back? I don't know why I should trust it, and there are schemes I do trust available that work fine, like Rabin's or even RSA. > And why should RSA's patent be so construed as to cover ALL public > key schemes? Because Jim Bidzos says so? No, because the patent says so. The patent might be overbroad -- indeed, I'd say that it is, but the only way to get it thrown out is to have it reexamined or get the courts to toss it. If you have several hundred thousand dollars available I'll gladly arrange to have this done. Perry From pmetzger at lehman.com Tue Sep 21 14:12:41 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 21 Sep 93 14:12:41 PDT Subject: Why RSA? In-Reply-To: <9309212049.AA00561@lynx.cs.wisc.edu> Message-ID: <9309212109.AA22702@snark.lehman.com> Derek Zahn says: > I was under the impression that > many people participated in the development of P.K.Crypto... > how can somebody patent all of their work? Three people essentially were involved -- Diffie, Helman, and Merkle. Two of them (I forgot which) filed a patent on the idea itself. > Don't these > kind of patents apply only to specific algorithms? It can be easily argued that at the time the patent was filed algorithm patents were impermissable, and it can also be argued that the patent was overbroad. However, no one has ever tried to challenge the patent properly. It would be a very expensive proposition. > * in broad terms, what would I have to do to develop an > algorithm that works from a user's perspective like > p.k.c. (ie public/private keys, the central functional > point of all the wonderful schemes based on pkc) but > doesn't violate patents? My interpretation is that there isn't anything you could do that wouldn't be seen to violate the patents. Personally, I feel the patents are invalid. Care to donate enough money to challenge them? Perry From cme at ellisun.sw.stratus.com Tue Sep 21 14:17:42 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Tue, 21 Sep 93 14:17:42 PDT Subject: Master Key: A Clipper Story Message-ID: <9309212114.AA10366@ellisun.sw.stratus.com> >Message-Id: <9309212027.AA09946 at dun-dun-noodles.aktis.com> >Date: Tue, 21 Sep 1993 16:27:24 -0400 >From: Marc Horowitz >>> Well done! > >I agree! Yes -- only -- I wish there were more than 1/2 sentence on breaking into the escrow agencies. That's clearly where the first break would be. From marc at GZA.COM Tue Sep 21 14:23:09 1993 From: marc at GZA.COM (Marc Horowitz) Date: Tue, 21 Sep 93 14:23:09 PDT Subject: Why RSA? In-Reply-To: <9309212049.AA00561@lynx.cs.wisc.edu> Message-ID: <9309212121.AA10002@dun-dun-noodles.aktis.com> >> * is there a reference I can read that covers the scope of >> public key crypto patents? One of the PKP patents (don't remember which) covers the concept of the encryption and decryption keys being different. The RSA algorithm (covered under a separate patent) is one way to implement this idea. >> * in broad terms, what would I have to do to develop an >> algorithm that works from a user's perspective like >> p.k.c. (ie public/private keys, the central functional >> point of all the wonderful schemes based on pkc) but >> doesn't violate patents? Write your code, sell it, wait for PKP to sue you, challenge them in court, and win. The problem here is that PKP has algorithmic patents (which many people think should never have been valid in the first place) which are very broad (covering pretty much all PKC) and cover ideas which some people think are "obvious" (making them theoretical unpatentable). However, once a patent is granted, the only way to get it thrown out is to challenge it in court. This is very expensive. So expensive that Uncle "Infinite Pockets" Sam himself didn't want to try to free their own algorithm from PKP, and instead licensed it to them exclusively (or so they claimed). PKP's patents have never been tested in court. This means that they *may be* rotten to the core. But before you try to sell your own PKC-based system, make sure you have a bank account and an army of lawyers as big as Jim's. The other answer to this question is "leave the US". This has nothing to do with ITAR. The PKP patents, for various reasons, only apply to the US. Marc From marc at GZA.COM Tue Sep 21 15:00:13 1993 From: marc at GZA.COM (Marc Horowitz) Date: Tue, 21 Sep 93 15:00:13 PDT Subject: Bidzos on PGP and ITAR verbatim In-Reply-To: Message-ID: <9309212157.AA10055@dun-dun-noodles.aktis.com> >> If Bidzos is using the term "technical data" as it's defined in $120.21 >> of the ITAR, I think it's debatable. Can we come up with data to support >> that IDEA and RSA are "commonly taught .. in academia"? > the U.S. Munitions List. This definition does not > include information concerning general scientific, > mathematical, or engineering principles commonly > taught in academia. It also does not include basic Well, I learned about the RSA algorithms in 18.063 (Introduction to Algebraic Systems), which is a required mathematics course at MIT for an undergraduate CS degree. It is normally taken by sophomores and juniors. MIT isn't exactly a "common" school, but it's certainly academia. Unfortunately, there is no textbook for this course. Public Key Cryptosystems are also discussed in the textbook (Introduction to Algorithms, Corman/Leiserson/Rivest, MIT Press) for 6.046 (Introduction to Algorithms), but are not discussed extensively in the class. As I know foreign nationals who have graduated, they must have taken these courses. Marc From pmetzger at lehman.com Tue Sep 21 15:13:11 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 21 Sep 93 15:13:11 PDT Subject: Bidzos on PGP and ITAR verbatim In-Reply-To: <9309212157.AA10055@dun-dun-noodles.aktis.com> Message-ID: <9309212210.AA22904@snark.lehman.com> Marc Horowitz says: > >> If Bidzos is using the term "technical data" as it's defined in $120.21 > >> of the ITAR, I think it's debatable. Can we come up with data to support > >> that IDEA and RSA are "commonly taught .. in academia"? > > Well, I learned about the RSA algorithms in 18.063 (Introduction to > Algebraic Systems), which is a required mathematics course at MIT for > an undergraduate CS degree. I learned about lots of this stuff in an advanced course in cryptography taught by Zvi Galil and some of his students and colleagues (like Stu Haber and Joan Feigenbaum) at Columbia. I suspect that there is an academic discipline here (lots of PhDs specializing in cryptography) and papers and academic journals and conferences make it fairly clear that this data is common in academia. Perry From fnerd at smds.com Tue Sep 21 15:32:45 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Tue, 21 Sep 93 15:32:45 PDT Subject: Subjects in anon msgs Message-ID: <9309212218.AA09396@smds.com> Someone writes: > What do you put in the Subject: line of an encrypted or anonymous > message? > > We need something standard to prevent traffic analysis on this field. ... Isn't it okay to have the subject appear in the last hop, according to a :: field in the second-to-last message? ::Remail-with-Subject: All Right Bugsy Lets Get Down To Brass Tacks With remailers that unencrypt at each hop, this doesn't seem a problem to me. With remailers that accept unencrypted input, this is no more of a steganoweakness than the body of the message already is. -fnerd at smds.com From sommerfeld at orchard.medford.ma.us Tue Sep 21 15:36:38 1993 From: sommerfeld at orchard.medford.ma.us (Bill Sommerfeld) Date: Tue, 21 Sep 93 15:36:38 PDT Subject: Bidzos on PGP and ITAR verbatim In-Reply-To: Message-ID: <199309212037.QAA00299@orchard.medford.ma.us> If Bidzos is using the term "technical data" as it's defined in $120.21 of the ITAR, I think it's debatable. Can we come up with data to support that IDEA and RSA are "commonly taught .. in academia"? The RSA public key algorithm is taught at MIT in the math course 18.063, which is required for an undergraduate computer science degree. That's one data point... - Bill From newsham at wiliki.eng.hawaii.edu Tue Sep 21 16:30:11 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Tue, 21 Sep 93 16:30:11 PDT Subject: Bidzos on PGP and ITAR verbatim In-Reply-To: <199309212037.QAA00299@orchard.medford.ma.us> Message-ID: <9309212329.AA01621@toad.com> > > If Bidzos is using the term "technical data" as it's defined in $120.21 > of the ITAR, I think it's debatable. Can we come up with data to support > that IDEA and RSA are "commonly taught .. in academia"? > > The RSA public key algorithm is taught at MIT in the math course > 18.063, which is required for an undergraduate computer science > degree. > > That's one data point... > > - Bill It was taught in one of my digital design classes as an example of why (and how) we need modular arithmetic circuitry, and how it is made. If it is taught in such a non-related class what does that say to the commonness of it? From nate at VIS.ColoState.EDU Tue Sep 21 17:26:39 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Tue, 21 Sep 93 17:26:39 PDT Subject: Coding vs. Raving.... please don't fight amongst yourselves!! In-Reply-To: <9309191818.AA08784@snark.lehman.com> Message-ID: <9309220023.AA05337@nagel.VIS.ColoState.EDU> [much bickering between Perry and Detweiler deleted] OK, why don't you guys bounce flaming email back and forth between yourselves after the first volley... So that everyone knows, Perry wants us to shut up and write code, and Detweiler wants us to get up and fight... Well, do both... Perry, you write some really awesome code, and Detweiler and some others will go off and investigate what they feel to be important... If Perry does not want to listent to Detweiler's calls to action, don't - just delete the message and move on. We need to recognize that some of us are prone to get agitated more easily than others are, but that's OK... we all want basically the same thing. What we want done will never get done if all of us write code, and it won't get done if we all rant and rave, either. Just don't fucking bicker about wether we should investigate things or write code. It's getting annoying! -nate -- +-------------------------------------------------------------------- | Nate Sammons email: nate at VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate at monet.VIS.ColoState.Edu for my PGP key | #include | Always remember "Brazil" +----------------------+ From pmetzger at lehman.com Tue Sep 21 17:36:39 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 21 Sep 93 17:36:39 PDT Subject: Coding vs. Raving.... please don't fight amongst yourselves!! In-Reply-To: <9309220023.AA05337@nagel.VIS.ColoState.EDU> Message-ID: <9309220032.AA23618@snark.lehman.com> nate at vis.colostate.edu says: > Well, do both... Perry, you write some really awesome code, > and Detweiler and some others will go off and investigate what > they feel to be important... If Perry does not want to listent to > Detweiler's calls to action, don't - just delete the message and > move on. Its not as simple as that. Phil Zimmermann has explicitly asked, on advice of his attorneys, that people stay calm on this and not start spewing accusations out or agitating so as not to cause harm to his case. Detweiler thinks he's "helping" even though Phil and others don't want his help and feel that they could end up in jail as a result of it. Perry From zeek at bongo.cc.utexas.edu Tue Sep 21 18:21:40 1993 From: zeek at bongo.cc.utexas.edu (Zeek) Date: Tue, 21 Sep 93 18:21:40 PDT Subject: New York Times: Federal Inquiry on Software... Message-ID: <199309220117.AA11227@bongo.cc.utexas.edu> ---------------------------- The New York Times Tuesday, September 21, 1993 Business Day ---------------------------- Federal Inquiry on Software Examines Privacy Programs By John Markoff SAN FRANCISCO, Sept. 20 - In a Government investigation with implications for free speech and privacy in the information age, a Federal grand jury in San Jose, Calif., has issued subpoenas to two software publishers selling versions of a program that protects the privacy of electronic mail and other computer data. The investigation appears to focus on whether the program has been illegally exported in violation of State Department regulations that control the sale of weapons and other technologies whose export the Government believes may compromise national security. The relevance of such regulations in the post-cold war era is the topic of growing debate in Washington, where communications and computer executives plan to testify before Congress on Wednesday. [Page C3.] The software program, known as Pretty Good Privacy, or P.G.P., was written several years ago by an independent programmer in response to Federal threats to crack down on the distribution of encryption software which is used to protect computer data by converting them into secret code. No one can read the encoded information without access to mathematical keys - one that is publicly known, a second known only to the recipient of the coded message. The program has since been freely distributed around the world, used on thousands of personal computers and work stations. Receiving the Federal subpoenas were Viacrypt, a Phoenix company that plans to sell a licensed version of P.G.P., and Austin Code Works of Austin, Tex., which is selling a version of P.G.P. for other software developers to incorporate their own programs. The grand jury subpoenas, which the companies received Sept. 9, ordered them to supply all correspondence and records related to the international distribution of P.G.P. and other information related to computer cryptography. A Customs Department official refused to comment on the case today. William P. Keane, the assistant United States attorney who signed the subpoenas, confirmed that there was a grand jury investigation, but said he could not comment. Both publishers said they had no plans to sell their products abroad. "I think they're more concerned with our intentions than what we've done," said Leonard Mikus, president of Viacrypt, which is a division of the software company Lemcom Systems Inc. of Phoenix. "They're on a fishing expedition, but this could become a landmark case that sets the limits that distinguish between electronic and conventional publishing." Battling the N.S.A. The investigation is the latest round in a growing battle in recent years between the National Security Agency and a variety of groups in this country, including high-technology companies, computer researchers and civil libertarians, over the role of coding software in protecting computer data. The N.S.A., whose role is to monitor electronic communications around the world, has consistently acted to block the adoption of new technologies that would make its mission more difficult. But the widespread availability of high-speed digital communication links and inexpensive personal computers may make it impossible to enforce technology restrictions in the future - as the widespread international dissemination of P.G.P. has already indicated. President Clinton alluded to the problems of controlling distribution of software technology in a speech last week promoting the North American Free Trade Agreement. "Nothing we do in this great capital can change the fact that factories or information can flash across the world, that people can move money around in the blink of an eye," the President said. "Nothing can change the fact that technology can be adopted, once created, by people all across the world and then rapidly adapted in new and different ways by people who have a little different take on the way that technology works." Question of Legality Government regulations, enforced by the State Department, make it illegal to export cryptographic software without a special munitions export license issued for weapons sales. Those restrictions have angered many computer industry executives who argue that encryption software is the crucial technology underlying a variety of information-age services, ranging from secure electronic mail to computerized payment of bills. Last year, a number of United States software companies, represented by the Software Publishers Association, a trade group, struck a deal with the N.S.A. permitting them to export software that contained coding functions. Those codes, however, are believed to be easily cracked by the N.S.A. The P.G.P. software under investigation is thought to defy most N.S.A. code-cracking efforts. The legitimacy of the export regulations is also disputed by legal scholars who argue that they restrict freedom of speech. "There is a First Amendment right to speak in a encrypted way," said Eben Moglen, a professor of law and legal history at Columbia University who is familiar with the case. "The right to speak P.G.P. is like the right to speak Navajo. The Government has no particular right to prevent you from speaking in a technical manner even if it is inconvenient for them to understand." Protection from Code-Breaking P.G.P. has been controversial since it was written by the programmer, Philip Zimmerman, because it uses a coding formula that many researchers believe powerful enough to protect information from even the National Security Agency's high-speed code-cracking computers. The formula was developed by three well known computer scientists: Ronald Rivest, Adi Shamir, and Leonard Adelman. -------------- From ebrandt at jarthur.Claremont.EDU Tue Sep 21 18:27:46 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Tue, 21 Sep 93 18:27:46 PDT Subject: Bidzos on PGP and ITAR verbatim In-Reply-To: <9309212329.AA01621@toad.com> Message-ID: <9309220126.AA03184@toad.com> > It was taught in one of my digital design classes as an example > of why (and how) we need modular arithmetic circuitry, and how > it is made. If it is taught in such a non-related class what does > that say to the commonness of it? Similarly, it was taught in an advanced discrete math course at the Univ. of Massachusetts as an application of the Chinese-remainder bignum system we'd been working with. Eli ebrandt at jarthur.claremont.edu From frissell at panix.com Tue Sep 21 19:16:41 1993 From: frissell at panix.com (Duncan Frissell) Date: Tue, 21 Sep 93 19:16:41 PDT Subject: Health Security Card Message-ID: <199309220212.AA26308@panix.com> Senator Harris Wafford (sp?) on Larry King Live just flashed a mockup of the Health Security Card. It is white. It has a red, white, and blue flag on it. It looks like it has a 7 digit number on it in the EIN split pattern 99 99999. It was hard to count digits though. It might have 9 digits rather than 7. Wafford did use the term "smartcard." I'm sure Willy will feature one in his speech tomorrow night. Duncan Frissell "Where's your Health Security Smartcard." "Sorry, I'm don't believe in that sort of thing. I'm an anarchist. You know, that's an alternative life style sort of like sodomy. They're starting to teach it in the schools and everything." --- WinQwk 2.0b#0 From doug at netcom.com Tue Sep 21 19:46:42 1993 From: doug at netcom.com (Doug Merritt) Date: Tue, 21 Sep 93 19:46:42 PDT Subject: Bidzos on PGP and ITAR verbatim In-Reply-To: Message-ID: <9309220242.AA15993@netcom4.netcom.com> >Similarly, it was taught in an advanced discrete math course at the Since no one else has mentioned it...the NSA tried to head off the original publication of public key cryptography, threatening star chambers, national security directives, and jail terms. This was thwarted by profs at a hundred colleges across the U.S. immediately assigning the algorithm as homework to every software class they were teaching at the same time, thus rather letting the cat out of the bag. The NSA then backed off, and publications followed. The material has been a natural part of certain courses ever since, depending on tastes of the prof. Part of the above story I experienced directly, since I was at Berkeley at the time, and other parts I heard from Ralph Merkle, who was either still there or had just gone to Stanford...I can't recall which. So if someone is collecting stories about the commonality of teaching such things, I imagine there must be some hundreds of thousands of eye witness reports. I implemented a 512 bit pubkey algorithm for kicks on a Z80 CPM system around 1982 based on a paper in the open literature that aimed at non-mathematicians and gave details such as efficient GCD algorithms. There cannot be any question about how widely known these techniques are. Doug From ld231782 at longs.lance.colostate.edu Tue Sep 21 19:47:47 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 21 Sep 93 19:47:47 PDT Subject: (1) PRZ excluded (2) PM vs. LD (3) grand jury procedure Message-ID: <9309220241.AA11556@longs.lance.colostate.edu> I was thinking. What is the significance that PRZ was not actually cited in any subpoena so far? This is very puzzling. It seems to contradict the theory that the investigation is primarily PGP oriented. On one hand, we might attribute it to the idea that the grand jury & the Attorneys don't have a very clear idea of what exactly is going on with PGP anyway, which would fit in with some of the tidbits I've posted. The president of ViaCrypt *was* subpoenaed -- but he has only been in associated with PGP for a few weeks, since the commercial announcement. But, still, how could they *not* query PRZ if they are inquiring on PGP? This is what I call a `conspicuous omission'. Also, the targeting of ViaCrypt and not PRZ directly is very interesting to contemplate. It definitely suggests that the move of PGP to a commercial company was critical in the timing of the subpoenas. Was it critical in convening a grand jury in the first place? what is it about the situation that caused action after a company was involved? are relevant laws only applicable to companies, not individuals? surely not, but there is very likely something going on here beneath the surface. (BTW, let the record show I have only replied directly to PM's voluminous onslaught of public flames [to say nothing of my vast, superb private collection] in one message on the list, which I think is sufficient [or more precisely, nothing could be sufficient, but it is the minimum]. If there is any `bickering' going on beyond this, it is only the reader's fertile imagination that I was *engaged* [*targeted*? definitely]. Or, feel free to cite the messages to contradict me, in email. I say all this only because I fear I am becoming a symbol in everyone's psyche of any message that challenges PM, no matter who wrote it, quite to the contrary of actual developments.) Here's a bit more which is helpful in describing a grand jury investigation (although I'd like to see more) from someone who gives me too much credit :) ===cut=here=== Date: Tue, 21 Sep 1993 11:49:33 -0400 From: [...] To: ld231782 at longs.lance.colostate.edu Subject: Re: more musings You are absolutely right about the Grand Jury proceedings. They are simply a fact finding venture. They are secret hearings and I doubt that Phil Zimmerman will even be able to talk about the proceedings after they are done. In addition to this, you are also correct that attorneys are not permitted inside the grand jury hearing (although the witness may leave the room to confer with the attorney). Once inside the room, you will only have the Grand Jury (of 23 people I believe) and the D.A. While it may seem nice to believe that Phil Zimmerman will be able to make a grand Perry Mason like speech in front of the Grand Jury. In reality, he will be under the control of the D.A. and will probably not have much of a chance to say much of anything except to answer the questions of the D.A. On the last point, yes you are also right, since the Grand Jury is NOT a criminal trial. Any evidence that would normally be held as illegally obtained, or just generally inadmissable in court (ie. hearsay) is perfectly acceptable for a Grand Jury, and I'm sure that it will be used. The grand jury's only purpose is to pass either an indictment (called a True Bill ) or no indictment, they are not there to determine guilt. From ld231782 at longs.lance.colostate.edu Tue Sep 21 20:17:47 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 21 Sep 93 20:17:47 PDT Subject: the $64K question? In-Reply-To: Message-ID: <9309220314.AA12039@longs.lance.colostate.edu> FTP site for complete ITAR is: ripem.msu.edu:/pub/crypt/docs/itar-july-93.txt. sci.crypt archives are there also. Thanks to M. Riordan for this valuable service. I also understand that D. Bernstein may have helped in getting the ITAR on specifically. Both are sci.crypt FAQ contributors & maintainers. * * * greg at ideath.goldenbear.com (Greg Broiles) quotes an *extremely* interesting section of the ITAR, perhaps the *critical section* for this issue at hand. But he seemed to skip right over a critical piece. The thread, as it stands: we have seen the ITAR sections that bar disclosure (export) of `technical data' to `foreign nationals' and sections that state that anything illegally exported cannot be legally imported, and now we find technical data defined as: $120.21 Technical data. Technical data means, for purposes of this subchapter: (a) Classified information relating to defense articles and defense services; (b) Information covered by an invention secrecy order; (c) Information, in any form, which is directly related to the design, engineering, development, production, processing, manufacture, use, operation, overhaul, repair, maintenance, modification, or reconstruction of defense articles. This includes, for example, information in the form of blueprints, drawings, 1 photographs, plans, instructions, computer software, 1 and documentation. This also includes information which advances the state of the art of articles on 2 the U.S. Munitions List. This definition does not 2 include information concerning general scientific, 2 mathematical, or engineering principles commonly 2 taught in academia. It also does not include basic marketing information or general system descriptions of defense articles. *wow* -- we find that (1) `computer software and documentation' `related to [verb1,verb2,verb3 ad infinitum] of defense articles' is *banned*. but in the same paragraph, (2) `general scientific or commonly taught mathematical or engineering principles' are *not* banned. Surely, (1) is the clause that Bidzos would claim applies -- restricting the export of technical data in the form of software. The $64K Question: Is PGP `computer software related to defense' or `technical documentation encompassing general scientific & engineering principles'? so, likely, that paragraph will be the focus of attention, and perhaps the fulcrum of the case, for both the prosecution and defense, of a hypothetical trial. another point to make: the naive prejudices of those who crafted this list are apparent as being from the agency-which-will-remain-anonymous-but-has-the-initials-NSA. They seem to think that `defense articles' and `general scientific, mathematical, and engineering principles' are mutually exclusive. Hee, hee. They might as well just have a law that bans `everything we don't approve of' with no loss of ambiguity. G.B. again >The definitions of export that I've seen have concerned transferring >information or physical things, or providing services to, persons, >corporations, or nations which are not U.S. citizens. They have not >addressed placing these things where "foreign persons" might conceivably >get them. another *very* critical aspect of the case, noted also by H. Finney and others. I have a theory about this (surprise! :) Bidzos indicated how the ITAR is very recent. It appears to be being updated all the time. This is a bit scary how easy it is for `the powers that be' (the most verminous expression, hence my use) to slip in to modifications to the ITAR. I wonder how much these various paragraphs have changed between versions of the ITAR -- I suspect that if we looked at it in a linear historical progression, we would find an increasing desperation in the writing, representing the futile attempt to encompass all the data leaking all over cyberspace, like trying to hold onto a handful of greased vibrating marbles, or chain down electrons. This is another `conspicuous omission' that suggests the likelihood that it is `in the works' to get in clauses that *specifically address* the concept of `broadcast' of information similar to an FTP site, perhaps even underway at this moment in the labyrinthine catacombs of our government. * * * My sincere thanks to everyone who has contributed to the ITAR analysis associated with the case dispassionately. We shouldn't delude ourselves in thinking all this is happening in anything other than a mailing list vacuum, and the EFF/PRZ laywers (`the Professionals') surely have entirely different perspectives on the matter, but for me at least I find it extraordinarily educational and intellectually stimulating -- in a sort of depraved way. On the other hand, reading between the lines of our comments, the ITAR itself is probably close to the most totalitarian document our country has yet produced. It is sort of like `constitutional antimatter'. Look at how pliant this enterprise-constricting law is to burdensome and insideous modifications, in total defiance of open and public legislative procedure! The people that are *experts* on it can't keep up with all the shadowy knob-twiddling. In restricting *technical data* to `foreign nationals' (the latter phrase a rather atrocious coinage in itself) we seem to find the same institutionalized paranoia against the spread of simple *information* that was associated with copier machines in the cold-war-era Soviet Union. The irony is that to a totalitarian state, that paranoia is not comical -- it is entirely justified and critical to its self preservation. From 72114.1712 at CompuServe.COM Tue Sep 21 20:18:16 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Tue, 21 Sep 93 20:18:16 PDT Subject: PGP IN SF CHRONICLE Message-ID: <930922031058_72114.1712_FHF61-1@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Punksters, Remind me someday to explain why I think there are only 10-20 million people in the world, max. One "proof" is all the "coincidences" we experience. Anyway, here's another one. Because I have written for MONDO 2000, WIRED and FUTURE SEX, a friend sent me a newspaper clipping about some new culture and technology oriented magazines. She thought I should try to crack them. FAST COMPANY sounded interesting, so I called the column's writer to find out where it is published. We talked for a while and he mentioned he had an article in today's paper about the PGP indictments, Phil Zimmermann, etc. Hey, there are no accidents. If I'm lyin' I'm flyin'. The article was neutral to sympathetic. The factual content was okay-doke except for one misguided reference to "cypherfreaks." Oh well, what's in a name? The article was on the first page of the business section of the 21 September San Francisco Chronicle. "Cypherfreak" John Gilmore got in some good quotes. S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ld231782 at longs.lance.colostate.edu Tue Sep 21 20:37:47 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 21 Sep 93 20:37:47 PDT Subject: the public key minefield In-Reply-To: <9309212049.AA00561@lynx.cs.wisc.edu> Message-ID: <9309220335.AA12499@longs.lance.colostate.edu> derek at cs.wisc.edu (Derek Zahn) >* in broad terms, what would I have to do to develop an > algorithm that works from a user's perspective like > p.k.c. (ie public/private keys, the central functional > point of all the wonderful schemes based on pkc) but > doesn't violate patents? others have well addressed how patent issues are involved in this. but this appears to be a simple technical question on one level. What does it take to come up with a good public key system? Answer: far more than you would think. RSA for example has gained its current degree trust only after about a decade and a half of careful and intense scrutiny in the literature, with many new caveats and modifications invented along the way. Furthermore, the mathematical & computational journals are strewn with failed attempts at getting a workable public key system by the most brilliant experts in the field (actually, in many fields). In particular, there was a lot of excitement about Knapsack cyphers, related to something called the Subset Sum problem, and a flurry of papers proposed, broke, and refined subsequent variations. Currently it appears to have really gotten a stake through its heart from the last authoritative paper (who?). (I would be curious for more details from the academically adept.) The rewards to a public key system are enormous, but the obstacles are tremendous as well. just getting a good *theoretical* model is very difficult, as the above attests. Then, this theoretical model has to be *efficient* when encoded in an algorithm -- another big stumbling block. Then, in the real world of ugly litigation, it has to tiptoe around the field of all the national and international patents, and, ahem, byzantine export laws. A very grim picture currently, in many ways, and to a large degree why RSA--and PGP/PRZ-- are so celebrated. Hopefully the future holds something less bleak. note: the new sci.crypt FAQ will have a much-improved section on public key cryptography. watch for it on the newsgroup or rtfm.mit.edu:/pub/usenet/news-answers/cryptography-faq if you want it right away. From pmetzger at lehman.com Tue Sep 21 20:46:43 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 21 Sep 93 20:46:43 PDT Subject: a horrible conspiracy revealed! In-Reply-To: <9309220241.AA11556@longs.lance.colostate.edu> Message-ID: <9309220341.AA23923@snark.lehman.com> "L. Detweiler" says: > I was thinking. What is the significance that PRZ was not actually > cited in any subpoena so far? This is very puzzling. It seems to I wonder what the significance of L. Detweiler's name is? Obviously its a Germanic name. Perhaps he's a Nazi... in fact, he might be the > contradict the theory that the investigation is primarily PGP oriented. > On one hand, we might attribute it to the idea that the grand jury & reincarnation of all Nazis, somehow having been transfered into a single body via the transmigration of souls. We certainly know from > the Attorneys don't have a very clear idea of what exactly is going on > with PGP anyway, which would fit in with some of the tidbits I've open yogic literature that the transmigration of souls is possible. Then there is his mysterious first name, which, as we know, starts > posted. The president of ViaCrypt *was* subpoenaed -- but he has only > been in associated with PGP for a few weeks, since the commercial with an "L", which is the first letter in the name "Lucifer" too, which is both a cryptosystem AND the name of the Lord of Hell. Could > announcement. But, still, how could they *not* query PRZ if they are > inquiring on PGP? This is what I call a `conspicuous omission'. this possibly be a coincidence? No way! In fact, I suspect that the people who developed it at IBM must in fact be Satanists, as is > Also, the targeting of ViaCrypt and not PRZ directly is very > interesting to contemplate. It definitely suggests that the move of PGP evinced by fact that "IBM" is a three letter acronym, and "GOD" is a three letter word, but "IBM" is certainly not "GOD", and what could be > to a commercial company was critical in the timing of the subpoenas. > Was it critical in convening a grand jury in the first place? what is further from GOD than the devil! Perhaps, in fact, this is a conspiracy between the minions of Satan and the transmigrated souls of > it about the situation that caused action after a company was involved? > are relevant laws only applicable to companies, not individuals? surely the Nazis I mentioned earlier! Then there is the odd coincidence of no one ever having seen "L. Detweiler" and Jim Bidzos' mother in the same > not, but there is very likely something going on here beneath the surface. > > (BTW, let the record show I have only replied directly to PM's place at once. Could this possibly be a coincidence? I doubt it. I suspect that the Grey Aliens may be involved in this, having failed in > voluminous onslaught of public flames [to say nothing of my vast, > superb private collection] in one message on the list, which I think is their attempt to capture Contraterra by placing it in an equilateral relationship with earth and Jupiter, it appears that they have decided > sufficient [or more precisely, nothing could be sufficient, but it is > the minimum]. If there is any `bickering' going on beyond this, it is instead to kidnap Jim Bidzos' mother and brainwash her into thinking she was "L. Detweiler"! She may not even know she is being used this > only the reader's fertile imagination that I was *engaged* [*targeted*? > definitely]. Or, feel free to cite the messages to contradict me, in way! I still, however, don't quite yet know how this meshes with the Nazis and the satanists, but I've been rifling through the garbage > email. I say all this only because I fear I am becoming a symbol in > everyone's psyche of any message that challenges PM, no matter who cans behind the Seeley Wintersmith Mudd building at Miskatonic University, and I'm certain that the papers may show up any day now > wrote it, quite to the contrary of actual developments.) which prove the links between these nefarious forces. From honey at citi.umich.edu Tue Sep 21 20:47:47 1993 From: honey at citi.umich.edu (peter honeyman) Date: Tue, 21 Sep 93 20:47:47 PDT Subject: the $64K question? Message-ID: <9309220347.AA05149@toad.com> > This definition does not > include information concerning general scientific, > mathematical, or engineering principles commonly > taught in academia. as a matter of fact, i am teaching a graduate course in cryptography this semester and am using pgp as a pedagogical tool. peter From newsham at wiliki.eng.hawaii.edu Tue Sep 21 21:10:13 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Tue, 21 Sep 93 21:10:13 PDT Subject: a horrible conspiracy revealed In-Reply-To: <9309220341.AA23923@snark.lehman.com> Message-ID: <9309220409.AA05518@toad.com> > > > "L. Detweiler" says: > > I was thinking. What is the significance that PRZ was not actually > > cited in any subpoena so far? This is very puzzling. It seems to > > I wonder what the significance of L. Detweiler's name is? Obviously > its a Germanic name. Perhaps he's a Nazi... in fact, he might be the [...] What was the point of this letter? Is this example output of a new stegonagrphy program you just wrote? where can I get it? Do you know mr. subliminal from saturday night live? Can I meet him? Can I have a porsche ? From trestrab at GVSU.EDU Tue Sep 21 21:13:17 1993 From: trestrab at GVSU.EDU (BETH TRESTRAIL) Date: Tue, 21 Sep 93 21:13:17 PDT Subject: Source code Message-ID: <9308227486.AA748681677@GVSU.EDU> I would be interested in taking a look at the source for the encryption program you mentioned in your post. Thanks. I would also be interested in your paper on the subject. Jeff trestrab at gvsu.edu From ld231782 at longs.lance.colostate.edu Tue Sep 21 21:36:43 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 21 Sep 93 21:36:43 PDT Subject: list split? Message-ID: <9309220433.AA13611@longs.lance.colostate.edu> this has been discussed a long time ago, but there is definitely some serious volume lately on the list. of course, its been a problem for as long as I can remember. I still like the mailing list flavor vs. a newsgroup, but the piles are really deep recently. (right now some people are thinking `of all the people to point this out' or `some nerve' :) anyway, here's what I propose. I think a split to mailing lists cpunk-remailers (policies, modifications, etc.) cpunk-code (PGP, encryption software, phones, etc.) cpunk-issues (Clipper, PGP investigation, etc.) cpunk-announce (news articles, fwds from elsewhere on internet services, etc. -- very low volume) would probably come pretty close to chopping up the current traffic in popular ways. NOTE! since meta list discussions like this generate a notorious amount of traffic, *please* DO NOT POST to the list on this subject immediately. Send your mail to list moderator hughes at soda.berkeley.edu, who just recently complained about the volume and urged that things be kept to private mail. If EH does not want to do this, let him speak up and say so and let the froth awash us on the list instead. But maybe he could come to some kind of conclusion from the email and describe a course of action. IMHO, a split is the most pragmatic approach to dealing with the volume, and we really should be a bit embarrassed not to have done it before. now, of course, the major headache for EH is that he currently has to handle subscription requests manually. So I wonder if he would like to explore automated list software, of which there is a great deal. Like EH I'm genuinely concerned about the really high-class people that are finding no signals in the noise, despite their basic. The attrition is really a pity. From miron at extropia.wimsey.com Tue Sep 21 21:52:48 1993 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Tue, 21 Sep 93 21:52:48 PDT Subject: REMAIL: policy In-Reply-To: <9309210156.AA16050@jobe.shell.portal.com> Message-ID: <1993Sep22.035655.320@extropia.wimsey.com> -----BEGIN PGP SIGNED MESSAGE----- My remailer: remail at extropia.wimsey.com My policy: - - Logs are kept, encrypted with my public key. IF you trust me, and you trust PGP, this should be no problem. Logs are deleted once every two weeks. - - Encryption is required with my remailer. - - I own the machine extropia.wimsey.com. - - I am outside the U.S. (in Canada). - -- Miron Cuperman | NeXTmail/Mime ok Unix/C++/DSP, consulting/contracting | Public key avail AMIX: MCuperman | Laissez faire, laissez passer. Le monde va de lui meme. -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLJ/M6pNxvvA36ONDAQFR/QP+JWqR58p1n9m0u3Mv/eD+pi2ISC0+RlXk F/UPm3JMcOTfIAhCbTIPT/nDnzPfqoOGPh8toCFt0T7pEvGC54+Smute9RwlxxYB wYFJlxGgiCzRALTEZVIzR3iwUi1pzlcJFDn3NmvMkQowV8Q57ECU0FjrW3PXyAz5 ynTBO5yqpvc= =P3Qw -----END PGP SIGNATURE----- From ld231782 at longs.lance.colostate.edu Tue Sep 21 22:56:45 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 21 Sep 93 22:56:45 PDT Subject: NYT article - WOW Message-ID: <9309220552.AA15068@longs.lance.colostate.edu> Markoff has written a BRILLIANT article. Virtually all the facts are right on, and he dances around the technical issues expertly, cutting to the core. This is FANTASTIC fodder for the cypherpunk cause! Probably just what PRZ dreamed of when he first wrote PGP :) Does anyone know Markoff's email address? Some minor idiosyncrasies, though. >Receiving the Federal subpoenas were Viacrypt, a Phoenix company >that plans to sell a licensed version of P.G.P., and Austin Code >Works of Austin, Tex., which is selling a version of P.G.P. for >other software developers to incorporate their own programs. Say what? this is false, from what I understand. *Maybe* `selling a version of RSA'? There is a rumor that G. Ward intended to include PGP in distribution disks, unconfirmed. But so far it appears there is very little related between G. Ward and PGP. >The >grand jury subpoenas, which the companies received Sept. 9 from what I can figure out so far, ViaCrypt got theirs on Tuesday, G. Ward on Thursday. This from their online statements. But it could have happened on the same day. Note that getting *served* a subpoena on the same day is very interesting -- if they were just dated on the same day and received at different times, that would be more realistic. If they were *served* simultaneously, that implies some kind of systematic coordination. Did somebody want to make sure that both places were hit exactly at the same time? Did they anticipate the rapid-fire explosion in cyberspace that would ensue? Remember, the grand jury is in California -- it would take some planning to have the summons *received* simultaneously. Don't they have to be delivered in person by agents? >Both publishers said they had no plans to sell their products >abroad. hee, hee. I wonder what Austin Code Works would think of G. Ward's Usenet postings... Pres. Leonard Mikus of ViaCrypt >"They're on a fishing expedition [...] hm, I wonder where I saw that term used before? >President Clinton alluded to the problems of controlling >distribution of software technology in a speech last week promoting >the North American Free Trade Agreement. > >"Nothing we do in this great capital can change the fact that >factories or information can flash across the world, that people >can move money around in the blink of an eye," the President said. >"Nothing can change the fact that technology can be adopted, once >created, by people all across the world and then rapidly adapted in >new and different ways by people who have a little different take >on the way that technology works." holy *cow* -- this sounds like something John Barlow of EFF would write! he almost appears to be alluding to *digital cash*! Obviously, Mr. President forgot to clear his remarks with the NSA first! Saying things like this, perhaps we should start a cypherpunk feed to president at whitehouse.com! cypherpunks, who'd ever have thought we'd have something from Mr. President for our signatures?! `technology rapidly adapted in new and different ways by people who have a little different take on the way that technology works' -- this is virtually from the Cypherpunk Charter. GAD! >"There is a First Amendment right to speak in a encrypted way," >said Eben Moglen, a professor of law and legal history at Columbia >University who is familiar with the case. "The right to speak >P.G.P. is like the right to speak Navajo. The Government has no >particular right to prevent you from speaking in a technical manner >even if it is inconvenient for them to understand." wow, this is *awesome* press. First time I've seen the constitutional aspect of cryptography dealt with. Markoff has got to be my absolute favorite writer. this is all what is called `bitter joy' ... From nobody at soda.berkeley.edu Tue Sep 21 23:00:15 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Tue, 21 Sep 93 23:00:15 PDT Subject: Sorry about that... Message-ID: <9309220556.AA24109@soda.berkeley.edu> Aargggh! Sorry about the multiple postings of Master Key. The mailer here has been very strange lately. Sometimes it's down, and when it comes back up, things which were sent get sent again... --==<< Infocalypse >>==-- From bart at netcom.com Wed Sep 22 00:50:16 1993 From: bart at netcom.com (Harry Bartholomew) Date: Wed, 22 Sep 93 00:50:16 PDT Subject: minor address correction Message-ID: <9309220747.AA18138@netcom5.netcom.com> Forwarded message: > Date: Tue, 21 Sep 93 21:35:16 -0600 > From: "L. Detweiler" ... > > note: the new sci.crypt FAQ will have a much-improved section on public > key cryptography. watch for it on the newsgroup or > rtfm.mit.edu:/pub/usenet/news-answers/cryptography-faq if you want it right away. > > You'll do better in: /pub/usenet-by-group/news.answers/cryptography-faq" is current directory. ^^^^^^^^^^^^^^^ ^ From greg at ideath.goldenbear.com Wed Sep 22 01:10:15 1993 From: greg at ideath.goldenbear.com (Greg Broiles) Date: Wed, 22 Sep 93 01:10:15 PDT Subject: the $64K question? In-Reply-To: <9309220314.AA12039@longs.lance.colostate.edu> Message-ID: "L. Detweiler" writes: > *wow* -- we find that (1) `computer software and documentation' > `related to [verb1,verb2,verb3 ad infinitum] of defense articles' is > *banned*. but in the same paragraph, (2) `general scientific or > commonly taught mathematical or engineering principles' are *not* > banned. Surely, (1) is the clause that Bidzos would claim applies -- > restricting the export of technical data in the form of software. ITAR seems to contemplate (at least) two different classes of things relevant here: "defense articles" and "technical data". While RSA and IDEA implementations may well escape being technical data by way of the academic exemption, they are pretty clearly defense articles. $121.1 General. The United States Muntions List. (a) The following articles, services, and related technical data are designated as defense articles and defense services pursuant to sections 38 and 47(7) of the Arms Export Control Act (22 USC 2778 and 2794(7)). Changes in designations will be published in the Federal Register. [ . . .] (c) [. . .] Category XIII - Auxiliary Military Equipment (b) Information Security Systems and equipment, cryptographic devices, software, and components, specifically designed or modified therefore, including: (1) Cryptographic (including key management) systems, equipment, assemblies, modules, integrated circuits, components or software with the capability of maintaining secrecy or confidentiality of information or information systems, except cryptographic equipment of software as follows: (long list of narrow applications of crypto deleted, none seem relevant.) (2) [Crypto systems making use of spread spectrum tech.] (3) Cryptanalytic systems, equipment, assemblies, modules, integrated circuits, components, or software. (4) [Systems for multiuser security of B2 or better, or certification software] (5) Ancillary equipment specifically designed or modified for paragraphs (b) (1), (2), (3), (4), or (5) of this category; [. . .] [end of quoted ITAR text] Sorry if the subdivisions/deleted text there is confusing - will snarf the full ITAR text tomorrow, perhaps it'll be more nicely formatted. -- Greg Broiles greg at goldenbear.com Baked, not fried. From msattler at netcom.com Wed Sep 22 01:11:47 1993 From: msattler at netcom.com (msattler at netcom.com) Date: Wed, 22 Sep 93 01:11:47 PDT Subject: Stunned and amazed Message-ID: <9309220809.AA09150@netcom.netcom.com> >Perry Metzger >Puzzled and incredulous I'm not one to snivel about bandwidth ('cause I think the Internet can deal with a lot more text messages from us to ourselves), but the kind of thing that's gotten Perry in the state he's in reminds me of a time-honored way of dealing with trivial, nonsensical, toxic waste messages: IGNORE THEM AND THEY'LL GO AWAY. It's the attention that's craved. We now return you to your insightful cypherpunks list, already in progress. :-) M ----------------------------------------------------------------------------- Michael S. Sattler msattler at netcom.com +1 (415) 358-3058 Digital Jungle Software Encrypt now; ask me how. (finger for PGP key) "Don't Panic!" -- Douglas Adams "Don't Panic. Stay Cool." -- PRZ From gg at well.sf.ca.us Wed Sep 22 03:13:26 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 22 Sep 93 03:13:26 PDT Subject: Master Key: A Clipper Story Message-ID: <93Sep22.031023pdt.14635-2@well.sf.ca.us> This is odd,... I never got the original posting; if anyone can email it to me I'd be thrilled (gg at well.sf.ca.us)... thanks- -gg From gtoal at an-teallach.com Wed Sep 22 03:52:55 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Wed, 22 Sep 93 03:52:55 PDT Subject: New York Times: Federal Inquiry on Software... Message-ID: <10791@an-teallach.com> In article <199309220117.AA11227 at bongo.cc.utexas.edu> zeek at bongo.cc.utexas.edu writes: > ---------------------------- > The New York Times > Tuesday, September 21, 1993 > Business Day > ---------------------------- > > Federal Inquiry on Software Examines Privacy Programs > > By John Markoff John Markoff regularly writes good and informed articles that he has clearly researched (if that's the right word) by reading usenet and possibly lists like this one. Yet I've *never* seen the guy post. John, if you're reading this, drop me a line to say hello just so I have your email address, in case I ever want to mail you something. Graham -- Personal mail to gtoal at gtoal.com (I read it in the evenings) Business mail to gtoal at an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212 From gtoal at an-teallach.com Wed Sep 22 04:41:51 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Wed, 22 Sep 93 04:41:51 PDT Subject: a horrible conspiracy revealed! Message-ID: <10842@an-teallach.com> In article <9309220341.AA23923 at snark.lehman.com> pmetzger at lehman.com writes: > I wonder what the significance of L. Detweiler's name is? Obviously > its a Germanic name. Perhaps he's a Nazi... in fact, he might be the I sincerely *hope* this article was a forgery, otherwise Perry you're digging yourself a big credibility hole. Drop it, please. G -- Personal mail to gtoal at gtoal.com (I read it in the evenings) Business mail to gtoal at an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212 From pmetzger at lehman.com Wed Sep 22 04:46:52 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 22 Sep 93 04:46:52 PDT Subject: a horrible conspiracy revealed In-Reply-To: <9309220406.AA06728@lehman.com> Message-ID: <9309221143.AA28956@snark.lehman.com> Timothy Newsham says: > > > > > > "L. Detweiler" says: > > > I was thinking. What is the significance that PRZ was not actually > > > cited in any subpoena so far? This is very puzzling. It seems to > > > > I wonder what the significance of L. Detweiler's name is? Obviously > > its a Germanic name. Perhaps he's a Nazi... in fact, he might be the > [...] > > What was the point of this letter? Is this example output of a > new stegonagrphy program you just wrote? where can I get it? > Do you know mr. subliminal from saturday night live? Can I meet > him? Can I have a porsche ? If I told you what the point was, there would be no point in having written it. Perry From 0005542837 at mcimail.com Wed Sep 22 06:38:28 1993 From: 0005542837 at mcimail.com (David Colston) Date: Wed, 22 Sep 93 06:38:28 PDT Subject: PKZ and NON-RSA Message-ID: <60930922131606/0005542837NA1EM@mcimail.com> When I posted the offer for source code to a non-RSA public key yesterday, little did I know that I would be beseiged by requests. I will therefore send the paper on the matter to cypherpunks and ask that anyone wanting a copy of the source send me a floppy. Any size or density is okay. As a preamble to this paper, I'd like to note why and how it was developed. After the first release of PGP, Phil told me he was worried about using RSA. I offered to come up with another scheme and originally designed a version of Rabin. I asked Phil to post a copy of that paper on sci.crypt since I do not have internet access. There were few responces, none of which attacked the safety of the method, but mainly stated that it was a version of Rabin. Nothing was ever done with that proposal. A year latter, 2.0 PGP was due to be released and I came up with the current public key system. Again, Phil ignored it. Posts on sci.crypt were totally ignored by anyone with the ability to judge the math. Phil was then approached by the customs folks and I recieved a call from him in December of last year. By that time I was tired of waiting around for Phil and had coded QPK (Quick Public Key) in PDS 7.1. At any rate, I suggested that Phil foward a copy of the program to RSA and see if they would challenge that program in court. He declined. It became apparant that Phil wanted to stick with the original RSA concept and would refuse to do anything with another approach, although he did stick an bite in 2.1 to flag an encryption as being non-RSA. At any rate, I believe that RSA would not attempt to defend the original public key patent in court, since it smacks of over kill. They attempt in the RSA pattent to claim any encryption method involving a polynomial modulo another number. This is clearly prior art, since Ceaser used m+1 mod n as an encrytion method. The program I generated has been posted on Compuserve, Bix, and GEnie for over a year with no feed back from anyone, even though I am resonably sure that RSA is aware of its existance. They have not challenged it because there has been no publicity. I would welcome a court challenge on the whole idea of crypto patents. The customs thing is meerly a way for RSA to challenge Phil and scare off others while avoiding a test of their patents. The "paper" follows. FOR THE MATHEMATICALLY ORIENTED - HOW A QUICK PUBLIC KEY WORKS. Math notation: + plus - minus +- plus or minus * multiplication / division ^ exponent <> unequal = equals == congruent < less than > greater than INT truncated integer round SQR square root ( open expression ) close expression x^-1 modulo p the multiplicative inverse of x in the field of p x... y the range of values XOR exclusive or N a number equal to P times Q, where P and Q are prime Variables in capital letters are permanent and those in small letters are temporary. BACKGROUND Because the "secret key" function of many public keys methods are so slow, most cryptographers use these functions only to "boot strap" into a conventional key system, which is faster to send the actual message. Most of the conventional key systems use comparatively small numbers in relation to the size of the public N as a "random seed number". The holder of the secret key may actually have a larger amount of computer time to decipher the starting point of the conventional algorithm than to decipher the actual message. It would seem to be a good idea, if a public key function could take advantage of the actual message size required to speed up the public key process. The range of message sizes is described below, but generally speaking we a discussing messages less than SQR(Q) in actual size. Imagine a series of related equations modulo a prime, P. These equations have the formula ((e * e + e)/2 * L + C) modulo P. The value, C, is a constant determined by the rule (L - 1) * (1 / (2 * L)) modulo P == C. For L = 1, C = 0. Therefore, if L is known, the expression ((e * e + e)/2) modulo P may be determined, even if e is unknown. Each value of L has an area or series of areas, in which the value of e becomes discoverable, WITHOUT resorting to a modular square root. ie. Let r == ((e * e + e)/2 * L + C) modulo P. If e is in the correct range relative to L, then (r * L * 8 + (L - 2) * (L - 2)) will have an integer square root and the value, e, may be determined with ease. The range of values of e, for any value of L, which have this property and the location of those values vary greatly. The following illustrates a public key approach for L = 12, but other values of L may also be used. Perhaps I should also note that the particular L, which a secret key holder uses need not be public knowledge, but is not all that sensitive. ESTABLISHING A QUICK PUBLIC KEY (Q.P.K.) BASED ON L = 12 A person wishing to receive public messages, which he/she alone can decrypt calculates N = P * Q. Where P and Q are a randomly selected prime numbers, Q being the larger. A == (11 * 24^-1 ) modulo Q B == (2 * A) modulo Q D = Q - B If D > (Q - 1)/2 then set D = Q - D - 1. F = (Q - 1)/2 - D NOTE: We may chose to use the F for all of the following calculations instead of D. This applies to no value of L lower than 12 and F is not valid for most sequences higher than 12. F may be an even safer value to use, for reasons which are too long to discuss here. L is NOT super-sensitive information. Let Y1 ... Y2 be a range of numbers with in the limits: (D - k) and (D + k), where k = INT(SQR(2 * Q / 12)). Y1 may be randomly selected from any point in this range, but Y2 may not be larger than (D + k), and Y2 - Y1 is the maximum message size. A message range for N, public information, is then created by using Chinese remainder theorem to find the modular intersection Q == Y1 and P == x, x being a random number in the range x > 0, x < P. This intersection is called S. A check is made to verify the following: A' = (11 * 24^-1) modulo N B' == (2 * A') modulo N D' = N - B' If D' > (N - 1)/2 then Set D' = N - D' - 1 NOTE: P, Q, D, F, Y1, Y2, k, A, AND B are secret values. Q.P.K. ENCRYPTION A public key for short messages consists of S and N. To send a Message the sender calculates: e = (S + Message) ((e * e + e)/2) modulo N == Cipher Q.P.K. DECRYPTION t == Cipher modulo Q f == (t * 12 + A) modulo Q g = SQR(f * 8 * 12 + 100) NOTE: If g is NOT an integer value, the message is rejected as invalid. If g modulo (2 * L) <> (L - 2) then Q is repetitively added to g until g modulo (2 * L) == (L - 2). z = (g - 10)/24 e == ((B - 1) + z) modulo Q If e > (Q - 1)/2 then set e = (Q - 1) - e. Message = e - Y1 For other values of L: A == ((L - 1) * 2^-1* L^-1)) modulo Q k = INT(SQR(2 * Q / L)) NOTE: If L = 1 then D = 0 and the message range is 1... k. If L = 2 then the message range is D... (Q - 1)/2 and these values modulo Q are already perfect squares < Q. f == (t * L + A) modulo Q g = SQR(f * 8 * L + (L - 2) ^ 2) z = (g - (L - 2)/(L * 2)) If anyone wants the source code for this drop a disk to: Colston & Associates 5111 Rogers Ave. Suite 507 Fort Smith, AR 72903 From b44729 at achilles.ctd.anl.gov Wed Sep 22 06:48:30 1993 From: b44729 at achilles.ctd.anl.gov (Samuel Pigg) Date: Wed, 22 Sep 93 06:48:30 PDT Subject: a horrible conspiracy revealed! In-Reply-To: <10842@an-teallach.com> Message-ID: <9309221345.AA08006@achilles.ctd.anl.gov> >>>>> On Wed, 22 Sep 93 11:34:49 GMT, gtoal at an-teallach.com (Graham Toal) said: Graham> In article <9309220341.AA23923 at snark.lehman.com> pmetzger at lehman.com writes: > I wonder what the significance of L. Detweiler's name is? Obviously > its a Germanic name. Perhaps he's a Nazi... in fact, he might be the Graham> I sincerely *hope* this article was a forgery, Graham> otherwise Perry you're digging yourself a big Graham> credibility hole. Drop it, please. I guess you didn't get it huh? I'm really sick of the flame wars on here, but this one had me laughing on the floor. But then again, PERHAPS it *WAS* a forgery.. by the BACKBONE cabal... in COLLABORATION with THE masons AND the ILLUMINATI!!!!!!!! AND.... (insert some more paranoid conspiracy rantings with every other word in all caps and wildly excessive exclamation points....) ... in an EFFORT the DISCREDIT the MOVEMENT!!!! Let us RALLY together BROTHERS to FIGHT the EVIL conspiracy that THREATENS our very LIVES!!!!!!! (BEFORE its too LATE!) Oh yes.. I agree.. we should split this list.. into: cypherpunks-list (original charter) and cypherparanoid-list (for those that want to robo-repost articles from other newsgroups with paranoid comments.) -Sam (no smiley) From koontzd at lrcs.loral.com Wed Sep 22 07:21:53 1993 From: koontzd at lrcs.loral.com (David Koontz ) Date: Wed, 22 Sep 93 07:21:53 PDT Subject: crypto import Message-ID: <9309221417.AA28415@nebula.lrcs.loral.com> >123.2 -- Import jurisdiction. > The Department of State regulates the temporary import of defense articles. > Permanent imports of defense articles into the United States are regulated by > the Department of the Treasury (see 27 CFR parts 47, 178 and 179). Mayhaps this explains why the Treasury is involved with Grady/Zimmerman From gtoal at an-teallach.com Wed Sep 22 07:37:59 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Wed, 22 Sep 93 07:37:59 PDT Subject: a horrible conspiracy revealed! Message-ID: <9309221433.AA25846@an-teallach.com> > I wonder what the significance of L. Detweiler's name is? Obviously > its a Germanic name. Perhaps he's a Nazi... in fact, he might be the Graham> I sincerely *hope* this article was a forgery, Graham> otherwise Perry you're digging yourself a big Graham> credibility hole. Drop it, please. I guess you didn't get it huh? I'm really sick of the flame wars on here, but this one had me laughing on the floor. No, I did get the joke, I just didn't think it was funny. I *do* remember the thread some time ago of Perry being accused of being a Nazi because a well- known Illinois Nazi has the same surname. I meant he was losing credibility for indulging in childish games, not for meaning whatever he said literally. I'd rather the pair of them just let it drop, instead of trying to outsmart each other. G From paul at poboy.b17c.ingr.com Wed Sep 22 07:53:00 1993 From: paul at poboy.b17c.ingr.com (Paul Robichaux) Date: Wed, 22 Sep 93 07:53:00 PDT Subject: Public-Key Crypto Toolkit In-Reply-To: <01H36SZHSIAC8WX5BI@delphi.com> Message-ID: <199309221449.AA29478@poboy.b17c.ingr.com> I'd really like to see the toolkit in plain ol' C. I realize that other languages and systems have great advantages over C, but C is portable beyond belief. It would be nice to have something built & documented like RSAREF but with the capabilities of PGP (plus D-H exchange) built in. It would probably see widespread and immediate adoption. -Paul -- Paul Robichaux, KD4JZG | "Change the world for a better tomorrow. But perobich at ingr.com | watch your ass today." - aaron at halcyon.com Intergraph Federal Systems | Be a cryptography user- ask me how. From still at kailua.colorado.edu Wed Sep 22 07:56:53 1993 From: still at kailua.colorado.edu (James Still) Date: Wed, 22 Sep 93 07:56:53 PDT Subject: Former S.O.F. Editor Supports PGP in Newspaper Message-ID: <2CA074F8@kailua.colorado.edu> Local boy makes good at home. The Federal Grand Jury's PGP/RSA test case, as reported in the NYT has hit full circle here in Boulder. Boulder's own Paul Danish (former editor and writer for Soldier of Fortune magazine, based in Boulder) has come out in support of PGP/privacy issues with an excellent op-ed piece in today's Colorado Daily. The Colorado Daily is read by over 50,000 students, fac/staff and residents of Boulder and the Univ. of Colorado. Danish's piece does an amazing job of backgrounding the issues, presenting them in layman's terms, and he even goes into the Clipper chip proposal. Could it be that the NSA/U.S. Customs investigation is causing a huge backlash of public support in favor of PGP? From jrk at sys.uea.ac.uk Wed Sep 22 08:00:18 1993 From: jrk at sys.uea.ac.uk (Richard Kennaway) Date: Wed, 22 Sep 93 08:00:18 PDT Subject: META: Re: a horrible conspiracy revealed! Message-ID: <26826.9309221459@s5.sys.uea.ac.uk> I was about to do an ::exclude on this thread, when I realised that it was the cypherpunks list and not the extropians. Any chance of cypherpunks running the extropian list software? Or maybe it does already? -- ____ Richard Kennaway __\_ / School of Information Systems Internet: jrk at sys.uea.ac.uk \ X/ University of East Anglia uucp: ...mcsun!ukc!uea-sys!jrk \/ Norwich NR4 7TJ, U.K From wcs at anchor.ho.att.com Wed Sep 22 08:06:53 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Wed, 22 Sep 93 08:06:53 PDT Subject: Why RSA? Message-ID: <9309212347.AA26247@anchor.ho.att.com> Derek writes: > First, the ViaCrypt version: I realize that it is legal. > It's also very expensive when compared to the price of If you buy it now, it's $100; even $199 is within the realm of what corporate customers consider non-annoying, especially since volume discounts kick in very rapidly. (Q5 = $120 each, Q20 = $83 ea, Q50+ = negotiable.) $100 is within my pain threshhold, and that of most serious non-student cypherpunks, though I'd be much happier at $49.95, and I'd guess they'd get more up-front cypherpunk revenue. I'm not sure the legalities of buying ViaCrypt PGP and then using the latest off-the-net version with trustable source and fewer bugs, but I'd feel better about that than just using PGP without a license. I don't know if ViaCrypt includes any distinguishing features that let you tell a ViaCrypt PGP message from a Real PGP message - they could do subtle stuff like make the session keys all include some checksum (e.g. be a multiple of N mod M), or crude stuff like put "Version 2.3ViaCrypt" in the headers, which would let them detect non-ViaCrypt PGP users. I assume not, but I haven't seen it. > * is there a reference I can read that covers the scope of > public key crypto patents? Basically, there are the patents themselves. Check your favorite FTP sites, including rsa.com, and ask your favorite mathematically-trained patent lawyer how realistic the claims are and how much broad the interesting ones are. > * in broad terms, what would I have to do to develop an > algorithm that works from a user's perspective like > p.k.c. (ie public/private keys, the central functional > point of all the wonderful schemes based on pkc) but > doesn't violate patents? To avoid patent problems, either get a license from PKP, or do any implementations outside the US (it's ok to use the math as math, you just can't apply it for encrypting stuff), or work for the U.S. government which gets use of at least RSA free. If you develop a new public-key algorithm that's any good, PKP may be willing to make a deal with you. # Bill Stewart wcs at anchor.ho.att.com +1-908-949-0705 Fax-4876 # AT&T Bell Labs, Room 4M-312, Crawfords Corner Rd, Holmdel, NJ 07733-3030 # # goin' where the climate suits my clothes .... From pmetzger at lehman.com Wed Sep 22 08:16:53 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 22 Sep 93 08:16:53 PDT Subject: Public-Key Crypto Toolkit In-Reply-To: <199309221449.AA29478@poboy.b17c.ingr.com> Message-ID: <9309221511.AA29362@snark.lehman.com> Paul Robichaux says: > I'd really like to see the toolkit in plain ol' C. I realize that > other languages and systems have great advantages over C, but C is > portable beyond belief. I agree. By having a good toolkit in C, we'd have an easy time not just prototyping applications but building real and portable ones. I'd suggest that a streams mechanism, so you could attach various processes to a bunch of data in sequence the way unix filters work, would also be nice. That way sequences like compress -- des -- tran -- des -- idea -- radix-64ify could be really easily built. Perry From khijol!erc at apple.com Wed Sep 22 08:41:53 1993 From: khijol!erc at apple.com (Ed Carp) Date: Wed, 22 Sep 93 08:41:53 PDT Subject: a horrible conspiracy revealed! In-Reply-To: <9309221433.AA25846@an-teallach.com> Message-ID: > > I wonder what the significance of L. Detweiler's name is? Obviously > > its a Germanic name. Perhaps he's a Nazi... in fact, he might be the > > Graham> I sincerely *hope* this article was a forgery, > Graham> otherwise Perry you're digging yourself a big > Graham> credibility hole. Drop it, please. > > I guess you didn't get it huh? > I'm really sick of the flame wars on here, but this one had me laughing > on the floor. > > No, I did get the joke, I just didn't think it was funny. I *do* remember the I didn't think it was funny, either - regardless of the motivation. It was a rude comment, regardless of the context. I think someone owes someone else an apology... -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From 0005542837 at mcimail.com Wed Sep 22 09:06:54 1993 From: 0005542837 at mcimail.com (David Colston) Date: Wed, 22 Sep 93 09:06:54 PDT Subject: Why no publication? Message-ID: <72930922153527/0005542837NA4EM@mcimail.com> Carl, I have not published for several reasons. The main one is that I have no academic creditials. My masters is in Rehab Counseling. I haven't had a math course since high school in 1964. I am mainly self taught in the area of math and crypto, but have had a lot of assistance from Charlie Merritt and Joel Benston. They were two of the 3 authors of Dedicate 32, the first public key crypto program for the PC, which was released in the early 80's. As I have noted, the paper was sent to sci.crypt by PKZ. /s From mbl at ml7694a.leonard.american.edu Wed Sep 22 09:20:18 1993 From: mbl at ml7694a.leonard.american.edu (Matthew B. Landry) Date: Wed, 22 Sep 93 09:20:18 PDT Subject: NYT article - WOW Message-ID: <9309221619.AA16509@toad.com> "L. Detweiler" writes: >write! he almost appears to be alluding to *digital cash*! Obviously, >Mr. President forgot to clear his remarks with the NSA first! Saying He doesn't have to clear it with the spooks first. _They_ work for _him_! Maybe we'll all get really lucky and have someone in charge who realizes that. (Personally, I'm not holding my breath, but there's always some hope.) -- Matthew B. Landry ml7694a at american.edu (Finally!) mbl at ml7694a.leonard.american.edu From doug at netcom.com Wed Sep 22 09:26:54 1993 From: doug at netcom.com (Doug Merritt) Date: Wed, 22 Sep 93 09:26:54 PDT Subject: Why no publication? In-Reply-To: <0005542837@mcimail.com> Message-ID: <9309221623.AA25473@netcom2.netcom.com> David Colston <0005542837 at mcimail.com> said: > I have not published for several reasons. The main one is that >I have no academic creditials. That is not generally required for publication; what counts is whether the submitted paper follows the norms. In some instances referees may want to see that the paper has the support of someone else in the field who is known or at a known institute to save themselves wasted time, if the paper is novel and would require nontrivial time to check, but that's easy enough to obtain. Page fees can often be waived, too, when someone doesn't have a grant or institution to pay them. Doug From broitman at bucrf4.bu.edu Wed Sep 22 10:46:55 1993 From: broitman at bucrf4.bu.edu (Jeff Broitman) Date: Wed, 22 Sep 93 10:46:55 PDT Subject: NY Times Article... Message-ID: <9309221741.AA21943@bucrf4.bu.edu> Could someone post the entire article (that is if you have nothing else to do with your time....) -jZb %#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#% Internet:broitman at koala.bu.edu J.Z.Broitman broitman at radon.bu.edu Dept. of Chemistry broitman at carbon.bu.edu Boston University broitman at xenon.bu.edu Snail:42 Maynard St. W.Newton MA. 02165 %#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#% From tcmay at netcom.com Wed Sep 22 10:50:18 1993 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 22 Sep 93 10:50:18 PDT Subject: META: Re: a horrible conspiracy revealed! In-Reply-To: <26826.9309221459@s5.sys.uea.ac.uk> Message-ID: <9309221747.AA27907@netcom5.netcom.com> > I was about to dFrom owner-cypherpunks Wed Sep 22 11:13:30 1993 Received: by toad.com id AA18101; Wed, 22 Sep 93 11:11:55 PDT Received: by toad.com id AA18098; Wed, 22 Sep 93 11:11:39 PDT Return-Path: Received: from maspar.MasPar.COM ([192.84.231.1]) by toad.com id AA18094; Wed, 22 Sep 93 11:11:37 PDT Received: from armada by maspar.MasPar.COM (5.65/Ultrix3.0-C) id AA10975; Wed, 22 Sep 1993 11:10:30 -0700 Received: by armada.MasPar.Com (5.57/Ultrix2.0-B) id AA27989; Wed, 22 Sep 93 11:09:51 -0700 Received: from cleo by argosy.MasPar.COM (5.65/Ultrix2.4-C) id AA00472; Wed, 22 Sep 1993 11:09:50 -0700 Received: by cleo.MasPar.Com (5.57/Ultrix2.4-C) id AA14353; Wed, 22 Sep 93 11:09:48 -0700 Date: Wed, 22 Sep 93 11:09:48 -0700 From: freeman at MasPar.COM (Jay R. Freeman) Message-Id: <9309221809.AA14353 at cleo.MasPar.Com> To: broitman at bucrf4.bu.edu, cypherpunks at toad.com Subject: Re: NY Times Article... Oops, mismanaged mailer ... -- Jay Freeman From freeman at MasPar.COM Wed Sep 22 11:13:00 1993 From: freeman at MasPar.COM (Jay R. Freeman) Date: Wed, 22 Sep 93 11:13:00 PDT Subject: NY Times Article... Message-ID: <9309221809.AA14350@cleo.MasPar.Com> > Now, the real question is, will those who still call themselves "post- > human" in a million years have learned much worthwhile since the > extinction of homo sapiens? :) Fellow post-Australopithecines, how goes it? 8:) -- Jay Freeman From derek at cs.wisc.edu Wed Sep 22 11:18:00 1993 From: derek at cs.wisc.edu (Derek Zahn) Date: Wed, 22 Sep 93 11:18:00 PDT Subject: Why RSA? Message-ID: <9309221814.AA23907@balder.cs.wisc.edu> First, my sincere gratitude for the replies to my queries regarding public key cryptography patents. To pay back such generosity, I will summarize. Also, I have done a little more digging and will present my findings, even though those findings include more questions! My original question was why cypherpunks don't just pick some non-RSA public key algorithm to achieve widespread distribution of cryptographic tools. My contention is that for such widespread distribution to occur, the price must be small in comparison to the average user's electronic communication outlay, and the tools must be beyond reproach legally so that it can be distributed by commercial email tool providers in a form that is elegantly integrated into the user's environment. My mother will not fetch, install, and configure PGP, though she might pay $10 - $20 more for an email product with "privacy enhancements". My reading of the comp.patents FAQ leads me to understand that any use of PGP by an individual in the U.S. is in violation of U.S. law (though the chances of being prosecuted are vanishingly small). Cypherpunks probably don't care too much about that, but the masses waiting for conversion probably do. The reasons for the desirability of widespread public key tools are obvious, even without considering the collapse of governments. For example, digital signatures can be used to authenticate electronically-distributed software upgrades, and so on (but this is all old hat to the folks on this list!). Unfortunately, as Perry Metzger pointed out: > All are patented in so far as one of the patents covers ALL public key > schemes. Some, like Rabin's scheme, have possible technical advantages > over RSA. First, a note: "Rabin's scheme" is (as Perry said) the one provably linked to factoring (a major advance!) and I assume it's the one implemented in RPEM. According to the RIPEM FAQ, PKP squashed that development by claiming that their patents were broad enough to cover Rabin's scheme, and the effort was abandoned "for pragmatic reasons" (another example of how superior technology can be suppressed by monopolies). Now, I've looked a little further into the patent issue, and I remain kind of confused. I went to the library and read the four patents in question (but only made a hardcopy of the first chronologically). I found the documents difficult to understand (for legal rather than crypto-tech reasons). All four applications were made in 1977-1978, and the patents were granted variously from 1980-1984. The earliest one has Hellman, Diffie, and Merkle as inventors; the second just Hellman and Merkle. Both are assigned to Stanford University. It seems to me that one of these is the one that covers, broadly, public key cryptography -- presumably the earliest one (4,200,770), since it has all three major players as inventors and the language of the eight claims seems to be rather broad (though only the second patent, 4,218,582, has the phrase "public key" in its title). Patent 4,405,829, granted in 1983, is for the RSA algorithm [footnote: the RSA patent apparently celebrated its tenth birthday two days ago; was there a party?]. There is no overlap between this patent's inventors and assignees and the earlier more general patent. Here's a question for somebody in the know: if the earlier patents cover all public key cryptography and RSA is a public key system, isn't it in violation of the earlier broader patent? Does PKP pay license fees to Stanford, or were they granted exclusive rights by Stanford as well as MIT? Similarly, apparently a public-key scheme called Warlock has been granted patent protection. How is this possible if somebody else holds patents covering all of public key encryption? If I understand patents correctly (hah!) they last for 17 years from the time they are granted. This means that the earliest public key patent will expire in about 3.5 years. After that presumably there will be no restrictions on new public key systems. The RSA patent would expire in 2000. If somebody could clarify which patent is the "broad" public key patent, I'd appreciate it (even with them right in front of me, I can't tell)! My guess is that it would have to be either 4,200,770 or 4,218,582 -- if it's the latter, how did Merkle get squeezed out of inventorship? Respondents to my initial questions pointed out that the patents may be over-broad and could be challenged on those grounds; given the history of how public key crypto was invented, it seems to me that it would be difficult to contend that the idea is obvious (Simmons says that the idea "stunned" the crypto community) -- but I'm no lawyer, and I'll leave that issue to those with more skill, brains, and money than me! For now, then, my conclusion is that for four more years at least, licensing RSA from PKP is probably the only viable commercial option for companies who wish to give their users public key crypto capabilities. It seems that the designers of Internet Privacy Enhanced Mail (PEM) agreed with this assessment, as they took the unusual step of including proprietary RSA in their standard. For their part, in RFC 1170, PKP states: "We assure the interested parties that Public Key Partners will comply with all of the policies of ANSI and the IEEE concerning the availability of licenses to practice this art. Specifically, in support of any RSA signature standard which may be adopted, Public Key Partners hereby gives its assurance that licenses to practice RSA signatures will be available under reasonable terms and conditions on a non-discriminatory basis." That sounds good -- but is troublingly vague. I have stated earlier what *I* think is are "reasonable terms" for the inclusion of a minor feature like PEM-compliance in an email processing system, but I don't get to decide that. If anybody knows more specifically how the standards bodies interpreted "reasonable", please let me know. As I am contemplating developing a PEM-compliant product, I will be writing to PKP to discuss licensing arrangements, but information from others (best: expressed publicly) would be helpful. If RSA is the only game in town, let's at least be clear about the price of admission. There seems to be a chance that manufacturing PGP-aware products (but not distributing PGP itself) could slide by, but it could also be interpreted as "inducement to infringe" which would apparently be actionable. The second point in my earlier message, largely obsoleted by the answer to the first, involved the development of new public key systems. Given that selling or otherwise using or distributing a new system now would invite litigation, the question is rather moot, but I'd like to thank L. Detweiler and P. Metzger for their comments on the all-important issue of trusting new algorithms. Finally, I suppose that it's always possible to come up with some radically new encryption technique that could be used to support authentication and yet have nothing to do with public key crypto... but I'm not holding my breath. Regarding the recent proposals for the construction of a toolkit, I'm all in favor and would personally welcome the opportunity to contribute to such an effort as a hands-on supplement to my crypto education. I have extensive experience with C and C++, and am VERY familiar with TCL (pronounced 'tickle', for those not in the know). A good start would be a clear statement of purpose. If this "Why RSA" thread has been too basic and has caused frustration for that reason, please forgive me. I have learned a great deal, and I hope that somebody somewhere else has profited as well. derek From baumbach at atmel.com Wed Sep 22 11:23:31 1993 From: baumbach at atmel.com (Peter Baumbach) Date: Wed, 22 Sep 93 11:23:31 PDT Subject: the public key minefield Message-ID: <9309221759.AA09589@bass.chp.atmel.com> > derek at cs.wisc.edu (Derek Zahn) > >* in broad terms, what would I have to do to develop an > > algorithm that works from a user's perspective like > > p.k.c. (ie public/private keys, the central functional > > point of all the wonderful schemes based on pkc) but > > doesn't violate patents? L. Detweiler writes: > others have well addressed how patent issues are involved in this. but > this appears to be a simple technical question on one level. What does > it take to come up with a good public key system? How about a poor public key system? What is the simplest public key system you can invent, if you didn't care that it is trivial to break? If the NSA can crack RSA, does that change the fact that it is a pkc? message=99 public_key= 1/3 private_key= 3 encrypted_message= message * public_key message= encrypted_message * private_key Would PKP reading of their patent claims cover this pkc? Seems overbroad! Peter Baumbach baumbach at atmel.com From strick at versant.com Wed Sep 22 12:06:56 1993 From: strick at versant.com (strick -- henry strickland) Date: Wed, 22 Sep 93 12:06:56 PDT Subject: Public-Key Crypto Toolkit In-Reply-To: <9309221511.AA29362@snark.lehman.com> Message-ID: <9309221906.AA03782@versant.com> THUS SPAKE "Perry E. Metzger" : # # Paul Robichaux says: # > I'd really like to see the toolkit in plain ol' C. I realize that # > other languages and systems have great advantages over C, but C is # > portable beyond belief. It should be at two layers. TCL (pronounced "tickle") is merely a layer on top of C. (By the way, GENERIC TCL is Plain Old C, and Portable Beyond Belief. A lot more portable than mediocre C. GENERIC TCL is an #ifdef that shuts off all commands that use any operating system services (besides malloc() and free()) -- it's merely a string-based language interpreter, with designed with friendly conventions for adding new commands that are wrappers of C API. Supplement GENERIC TCL with some stdio.h routine wrappers (fopen, fclose, fgets, fputs), and you'll be happy. Compiled instantly on my macintosh, even.) # I agree. By having a good toolkit in C, we'd have an easy time not # just prototyping applications but building real and portable ones. Yes, you want a complete C api. I don't argue against that. First you assemble your C API at a complete layer. It'll look a lot like the RSAREF API. In fact, the RSAREF portion of it *will be* the RSAREF API. You see, RSAREF already is a crypto toolkit. Not as full as you may like, but enough to do most basic public-key-cryptosystem stuff. The reference implementations of MD2 and MD5 are also part of the C toolkit API. And the bignumber packages. We've already got *lots* of these. But have you tried using RSAREF API to do anything? C API are a notorious pain in the butt to use -- allocating & deallocating memory, twiddling bits, writing functions to copy one data format to another, etc. They're the reason we're not writing code! When you elevate to a "scrypting" language, it becomes really easy (even fun) to experiment and hack stuff together. # I'd suggest that a streams mechanism, so you could attach various # processes to a bunch of data in sequence the way unix filters work, # would also be nice. That way sequences like # # compress -- des -- tran -- des -- idea -- radix-64ify # # could be really easily built. Yes, but now you just suggested Shell and Streams rather than C as the easy-to-use interface into this kit. You've rejected then rediscovered the reason for a "scrypting" language. I think you don't yet understand how TCL is used. You'll be much more productive in TCL than hacking weird data flows and futzing with temporary files and klutzy syntax and counting your nested escape and quote characters in Shell. (Most shell things are not one simple pipe from front to end.) There's still a time and a place for shell stuff -- fortunately there (finally) is a standard "tclsh" unix (or POSIX) main.c that you can use to mix your TCL scripts with Unix Shell scripts. (You could do it before, but it was more of a "test" program or homegrown driver than part of a standard main.c) ANYWAY -- I should quit ranting and Just Start Writing Code. Unfortunately I'll be out of town till early October.... Perhaps I can suggest some specs before then. _ menya zavoot cmpuk strick at versant.com TCL is available via ftp from sprite.berkeley.edu and is freely distributable. UNIX is a registered trademark of whomever bought it last. From frissell at panix.com Wed Sep 22 12:20:19 1993 From: frissell at panix.com (Duncan Frissell) Date: Wed, 22 Sep 93 12:20:19 PDT Subject: News You Can Use Message-ID: <199309221916.AA17396@panix.com> AP 09/21 0844 Encryption Software Copyright, 1993. The Associated Press. All rights reserved. SAN JOSE, Calif. (AP) -- A federal grand jury is investigating exports of a controversial computer program in a case that could affect how software is distributed worldwide. U.S. Customs officials asked for an investigation into ViaCrypt of Phoenix and Austin Code Works of Austin, Texas, and the companies' plans for foreign distribution of software, including PGP, a program that turns data into an indecipherable code using encryption technology. William Keane, an assistant U.S. attorney, confirmed that an investigation is continuing, but declined to comment on the case. The PGP program has been distributed worldwide over computer networks by some computer enthusiasts who oppose the U.S. government's trade regulations on encryption. The National Security Agency, which monitors international communications, has supported strict encryption technology export regulations, arguing that it would be difficult to keep tabs on hostile governments and foreign terrorists. But opponents say the restrictions hurt sales and violate the First Amendment that protects the right to publish information about encryption. "I wrote PGP to make democracy healthier. I didn't do it to make money," said Philip Zimmermann, a computer consultant who developed PGP. "We believe everything we are doing is above board and well within the law," said ViaCrypt president Leonard Mikus. He said the company had no intentions of violating export regulations. WP (Washington Post) 09/18 Encryption Program Stirs Security Debate By John Mintz and John Schwartz Washington Post Staff Writers Computer industry officials and civil-liberties activists are launching new attacks on the Clinton administration's plan to make the so-called clipper computer chip the national standard for encrypting, or scrambling, data and voice communications. Under the clipper plan announced this year by the Clinton White House, police agencies that receive court authorization for a wiretap to intercept encrypted communications would then need the technological cooperation of two independent "escrow" agents to crack the code. Earlier this week administration officials told congressional staff members that the two escrow agents will be officials of two government agencies: the Commerce Department's National Institute of Standards and Technology (NIST), and a non-law enforcement section of the Treasury Department that has not been selected. Yesterday industry and civil-liberties groups criticized that selection because they said NIST and Treasury are not independent, but arms of the same federal government that could some day be called upon to listen in on their communications. Douglas Miller, government affairs representative of the Software Publishers Association, made up of U.S. software firms, said his group has "grave doubts" that foreign corporations will encrypt their communications with the clipper chip because "the U.S. government holds the key." A main reason the administration is promoting clipper is that the U.S. National Security Agency, the super-secret code-breaking agency, wants to discourage use of highly capable, non-clipper encryption programs that are becoming increasingly popular but that the NSA can't pierce. Industry officials for years have regarded NIST as a stalking horse for the NSA. Jerry Berman, director of the Washington office of the Electronic Frontier Foundation, which promotes public-interest causes in technology-policy areas, said NIST is "so close to the NSA that it can't give the public comfort that this is a true escrow system." John Podesta, assistant to the president and a key White House staff member on this issue, said such objections are "a phony issue." "We clearly are looking for procedures and escrow agents that would maintain privacy and confidentiality and security of the keys," Podesta said. "Cryptography lends itself to a certain degree of paranoia." Kate Martin, director of the Center for National Security Studies of the American Civil Liberties Union, mocked use of the term "escrow" in this case. An escrow agent is someone who is independent of two parties potentially in conflict, like a settlement attorney at a real estate closing, she said. "As long as the escrow agents are government agencies, it's misleading to call them that," she said. "The government doesn't have a fiduciary obligation to the people whose (communications) keys it holds," but only to the government. "The whole idea continues to be structurally flawed," said Bruce Heiman, attorney for the Business Software Alliance, a group of top U.S. software firms, such as Microsoft, Novell, Lotus and Apple. Companies and individuals who transmit secure information "will have serious doubts about the integrity of the system." Since the government currently prevents the export of many powerful U.S.-made encryption techniques, the administration's attempts to promote its clipper chip "will discourage use of encryption, period, or hand over the market for encryption to foreigners." When one listens to an encrypted conversation, it sounds like a crackle or buzz. Under the plan, every law-enforcement agency will have a special personal computer or "black box" to descramble that crackle, but the device will work only when they have been given a special key from the escrow agents. When police get a judge's permission to intercept an encrypted conversation or stream of computerized data, they would use the box to determine the special encryption identifier or label assigned to that particular encryption device. A detective would notify NIST and Treasury that he or she has permission to listen in on the party. NIST and Treasury would have a list of the secret encryption key numbers - extremely long lists of 0s and 1s - for every encryption device sold in the United States. NIST and Treasury would find the appropriate one on the list, and then they would send the needed key number to the police over telephone lines. The police would then insert that decoder number into the black box to tap the phone line in question. The ACLU's Martin said the government, given lists of secret encryption numbers, "has an enormously greater ability to eavesdrop than it's ever had." Government officials deny that. Duncan Frissell The $1 Trillion/year Health Security Act of 1993, the most expensive government program in the hisotry of mankind. --- WinQwk 2.0b#0 From Eric.K.Kuecherer at Dartmouth.EDU Wed Sep 22 12:31:56 1993 From: Eric.K.Kuecherer at Dartmouth.EDU (Eric K. Kuecherer) Date: Wed, 22 Sep 93 12:31:56 PDT Subject: No Subject Message-ID: <5412341@blitzen.Dartmouth.EDU> Please remove me from the list. -kuech- From accom!erc%accom at uunet.UU.NET Wed Sep 22 13:42:00 1993 From: accom!erc%accom at uunet.UU.NET (Ed Carp) Date: Wed, 22 Sep 93 13:42:00 PDT Subject: Why RSA? Message-ID: <9309222034.AA10004@accom.accom.com> > My > reading of the comp.patents FAQ leads me to understand > that any use of PGP by an individual in the U.S. is in > violation of U.S. law (though the chances of being > prosecuted are vanishingly small). I doubt it - the reason why is because under patent law, ther is an exclusion granted for educational, research, or experimental purposes. So, if you're using PGP to make money, you are in violation of PKP's patents (assuming they are, in fact PKP's patents to begin with and that Stanford and MIT had the right to reassign exclusive rights to something that was developed with public funds) and they would be quite right (legally speaking) to come and sue your ass off. ;) > in violation of the earlier broader patent? Does PKP pay license > fees to Stanford, or were they granted exclusive rights by Stanford > as well as MIT? I doubt that this would stand up in court. Universities often grant development and marketing rights to patents for stuff developed by them, but I seriously doubt that this is what either the original drafters of the patent laws or Stanford had in mind when they granted rights to PKP to develop and market the stuff. -- Ed From newsham at wiliki.eng.hawaii.edu Wed Sep 22 13:50:21 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Wed, 22 Sep 93 13:50:21 PDT Subject: Why RSA? In-Reply-To: <9309221814.AA23907@balder.cs.wisc.edu> Message-ID: <9309222048.AA20361@toad.com> > Regarding the recent proposals for the construction of a toolkit, > I'm all in favor and would personally welcome the opportunity to > contribute to such an effort as a hands-on supplement to my > crypto education. I have extensive experience with C and C++, > and am VERY familiar with TCL (pronounced 'tickle', for those > not in the know). A good start would be a clear statement of > purpose. purpose: to make routines implemented and implemented well within the PGP program available to programmers. future purpose: to make a general purpose library of routines helpful in implementing various crypto systems and protocols. plan: Take the PGP source and rip it apart into tiny pieces and put it back together in an organized way. Change the Makefile structure to build various libraries and isolate the main user interface routines into a seperate group of files. Basically a restructuring of PGP that will provide various intermediate libraries that may be used by other programers for linking within their program. *IF* this becomes part of the standard PGP distribution all non-portable code will be rewritten for various platforms and you will be able to find a lib for just about any platform you are coding or porting to. I havent read through the PGP code myself, but I suggest at least libraries for the random number routines (including the system-specific keyboard routines for getting random seeds), a library for the RSA and IDEA routines, and a library of the lower-than-RSA math routines. After this is done then various projects such as a tcl shell can be written on top of the libraries. If the library is successful then various additions can be made to it to make it a true crypto library rather than just a PGP library. This could also benefit PGP if it is changed to allow various crypto systems. The benefits of this approach are many: When implementing PGP front ends you usually dont want the normal PGP front end at all, and would rather just re-write your own on top of the PGP code. When you are coding simple crypto libraries (like 'link' and 'Circ') it is nice to have a drop-in cryptosystem library. The advantages to import- export are nice as well, you can write code that has no crypto code in it at all and let the users grab the crypto library to compile. > > derek > From warlord at MIT.EDU Wed Sep 22 14:20:21 1993 From: warlord at MIT.EDU (Derek Atkins) Date: Wed, 22 Sep 93 14:20:21 PDT Subject: Why RSA? In-Reply-To: <9309222048.AA20361@toad.com> Message-ID: <9309222117.AA01001@toxicwaste.MEDIA.MIT.EDU> > plan: Take the PGP source and rip it apart into tiny pieces > and put it back together in an organized way. Change the > Makefile structure to build various libraries and isolate > the main user interface routines into a seperate group of > files. Basically a restructuring of PGP that will provide > various intermediate libraries that may be used by other programers > for linking within their program. If you plan to do this yourself, I can guarantee you, 100%, that *NONE* of your work will go into the next release of PGP! The work you suggest is underway. Please be patient, for if you did look at the PGP code, you would see what spaghetti it really is! If you remain patient, and wait for the next release, then maybe things will be a lot better for you!) ---A concerned citizen who hates people who re-invent the wheel or duplicate others' efforts!!! -derek From derek at cs.wisc.edu Wed Sep 22 14:26:59 1993 From: derek at cs.wisc.edu (Derek Zahn) Date: Wed, 22 Sep 93 14:26:59 PDT Subject: Toolkit In-Reply-To: <9309222117.AA01001@toxicwaste.MEDIA.MIT.EDU> Message-ID: <9309222124.AA24232@balder.cs.wisc.edu> > If you plan to do this yourself, I can guarantee you, 100%, that > *NONE* of your work will go into the next release of PGP! > > The work you suggest is underway. Please be patient, for if you > did look at the PGP code, you would see what spaghetti it really > is! If you remain patient, and wait for the next release, then > maybe things will be a lot better for you!) Well, this highlights an issue -- should a Toolkit be based on PGP or RSAREF? If the releasers of PGP are disinclined toward the project, perhaps RSAREF would make more sense (though I suppose that depends on how much cypherpunks hate RSAREF). > -derek derek (er, damn, the *other* derek) From warlord at MIT.EDU Wed Sep 22 14:48:04 1993 From: warlord at MIT.EDU (Derek Atkins) Date: Wed, 22 Sep 93 14:48:04 PDT Subject: Toolkit In-Reply-To: <9309222124.AA24232@balder.cs.wisc.edu> Message-ID: <9309222144.AA01084@toxicwaste.MEDIA.MIT.EDU> > Well, this highlights an issue -- should a Toolkit be based > on PGP or RSAREF? If the releasers of PGP are disinclined > toward the project, perhaps RSAREF would make more sense > (though I suppose that depends on how much cypherpunks hate > RSAREF). No, you misunderstand. The "releasers of PGP" are ***NOT*** disinclined towards the project. They are implementing your suggestions for the next release!!!!! The next release will, short of actually BUILDING the library, have a set of functions that a programmer can use to access the crypto routines and let anyone, for example, put a front end on the pgp system!!! No, the PGP implementors are not ignoring you. Rather, they are in the process of doing just as you have asked, and have been doing so for some months now. If you start work with the current (2.3A) PGP release, then you will just be re-implementing something that the PGP developers have been working on for a long time! As I said, be patient. What you want is right around the corner, but if you jump out too soon, you might get hit by that proverbial truck which is right in front of it!!!! It will come to you soon enough!! > > -derek > > derek > (er, damn, the *other* derek) -derek Damn, this is confusing!!! ;-) From mdiehl at triton.unm.edu Wed Sep 22 14:48:37 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 22 Sep 93 14:48:37 PDT Subject: a horrible conspiracy revealed! In-Reply-To: Message-ID: <9309222145.AA23428@triton.unm.edu> According to Ed Carp: > > > I wonder what the significance of L. Detweiler's name is? Obviously > > > its a Germanic name. Perhaps he's a Nazi... in fact, he might be the > > Graham> I sincerely *hope* this article was a forgery, > > Graham> otherwise Perry you're digging yourself a big > > Graham> credibility hole. Drop it, please. > > I guess you didn't get it huh? > > I'm really sick of the flame wars on here, but this one had me laughing > > on the floor. >>No, I did get the joke, I just didn't think it was funny. I *do* remember the > I didn't think it was funny, either - regardless of the motivation. It was a > rude comment, regardless of the context. I think someone owes someone else > an apology... Ditto! I also propose that the next person who continues this thread gets sent a flame-mail from everyone else on this list who thinks this is silly. So how about it? J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From danodom at matt.ksu.ksu.edu Wed Sep 22 14:52:00 1993 From: danodom at matt.ksu.ksu.edu (Dan Odom) Date: Wed, 22 Sep 93 14:52:00 PDT Subject: IDEA implementation Message-ID: <9309222148.AA02182@matt.ksu.ksu.edu> With all this talk about various libraries going on, I figure I might as well ask this: Is there an implementation of IDEA that will let me do something like this: encryptedbuf = encypher (databuf, buflen, passphrase); Where the arguments mean the obvious, and databuf can be of arbitrary length? If not, I may do it, but I wouldn't want to duplicate efforts :-) -- Dan Odom danodom at matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS PGP key by finger or request. From judic at netcom.com Wed Sep 22 18:53:40 1993 From: judic at netcom.com (Judi Clark) Date: Wed, 22 Sep 93 18:53:40 PDT Subject: reporter seeking interview subjects Message-ID: <9309230151.AA05313@netcom.netcom.com> >In <93Sep17.230857pdt.14382-4 at well.sf.ca.us>, Matt Binder wrote... >> Hi, my name is Matt Binder. Please help me... >> I'm a radio reporter in the SF Bay area working on a series >> of pieces about invasions of privacy in the computer age. I'm >> looking for interesting "case studies" that I can use to horrify >> my listeners out of their complacency. > >I think it's really important that if you're looking to shock your audience >that you also show a glimpse of not only the "light at the end of the >tunnel" but also a glimpse of the reasons that people would be better off >making a dash for the end of the tunnel than trying to run back to the >tunnel's start. Otherwise, you're just fueling the anxieties of countless >luddites and techonophobes. > >> My most immediate need is >> to find someone whose medical records were used (perused!) > Thanks, Stig, for forwarding this for my "more immediate attention." Matt, I agree with Stig that it's important not to horrify anyone out of anything unless you also give them something concrete that they can do about it. In most cases, invasions of privacy aren't something empowering, nor can most people do anything about them but know and worry. I don't find this too constructive. There are a couple of stories that you might be interested in, in any case. One is that San Francisco (and other counties across the state) is testing a plan to fingerprint all General Assistance recipients. You can get testimony from hearings conducted earlier this year from a friend of mine, Jim Davis . I know that CPSR in Berkeley is planning on holding a meeting in late October to explore and talk more about this issue. Fingerprinting will be on the November ballot, btw. Second, the state has had a database system designed to track all recipients of state money. That is, if a day care center receives any state aid, all the kids go into the database. (They can't be removed, once added, until they turn 18 and file a petition with the state.) State aid is another part of this package, as are jail participants, and other state-oriented program participants. You can see this is just a short step from adding tax-payers, businesses, and everyone else that has anything to do with the state... The scary part of the above story, in case that wasn't enough, is that state hospitals and medicaid recipients are also in the database. The idea is that if a patient goes to another county, they can get consistent care, and not be able to "double-dip" from state agencies. Of course, that also means that many state agencies have access to confidential medical info about a lot of people (who, by nature of their being on the state's systems, are powerless). Furthermore, the designer of this system hasn't shown any priority or sophistication in creating levels of security so that people that aren't supposed to have access really don't. A friend just reminded me that there was a radio program on recently, This Week in California (KQED) which talked about the Alameda Co. system. This is an expensive system, and they didn't find any evidence of fraud. Good luck with your stories. I hope this gives you something to start with. yours in scary things, judi From mdiehl at triton.unm.edu Wed Sep 22 21:23:07 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 22 Sep 93 21:23:07 PDT Subject: Why RSA? In-Reply-To: <9309222048.AA20361@toad.com> Message-ID: <9309230419.AA14209@triton.unm.edu> According to Timothy Newsham: > > > Regarding the recent proposals for the construction of a toolkit, > > I'm all in favor and would personally welcome the opportunity to > > contribute to such an effort as a hands-on supplement to my > > crypto education. I have extensive experience with C and C++, > > and am VERY familiar with TCL (pronounced 'tickle', for those > > not in the know). A good start would be a clear statement of > > purpose. I'd also like to help. I'm pretty good with C. And I'm finishing my BS in Mathematics. I'm no expert,(yet) but I'd love to learn. BTW, I did get an 'A' in Numerical Computation. ;^) Lagers, J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From remail at tamsun.tamu.edu Wed Sep 22 21:37:05 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Wed, 22 Sep 93 21:37:05 PDT Subject: nonrandom string Message-ID: <9309230431.AA13921@tamsun.tamu.edu> > Return-Path: <@CORNELLC.cit.cornell.edu:cjl at micro.med.cornell.edu> > Date: Mon, 20 Sep 93 17:02:49 EDT > From: cjl at micro.med.cornell.edu (Chris Leonard) > To: cypherpunks at toad.com > Subject: nonrandom string > > > I address this to the list at large hoping that one or more of you can > explain something unusual that I observed. A friend of mine and I have been > using PGP for several months and I just recently noted that in at least three > of the recent posts to me that the first 18 characters of the encrypted > message were identical. The first words of the plaintexts were not identical > and so I assume that these characters are something else, perhaps the stuffer > that I have heard mention of on this list. This repeating string is of > concern for obvious reasons (e.g. so much for anonymity), and I would like to > understand the cause of its recurrence. > > Please post to me and I will post a precis of the most reasonable suggestions. This is normal. PGP labels each message with a byte that defines its type (for messages between people this is a byte that indicates that what follows is public key encrypted) followed by type dependant information. Among the things in the first bunch of bytes are the KeyID (low order 64 bits, so this is eight of the bytes you see) of the destination's key. If you are always sending to the same person (i.e., the same key) these will always be the same. From rjc at gnu.ai.mit.edu Wed Sep 22 21:48:07 1993 From: rjc at gnu.ai.mit.edu (Ray) Date: Wed, 22 Sep 93 21:48:07 PDT Subject: META: Re: a horrible conspiracy revealed! In-Reply-To: <9309221747.AA27907@netcom5.netcom.com> Message-ID: <9309230444.AA13578@geech.gnu.ai.mit.edu> Timothy C. May () writes: > > > > I was about to do an ::exclude on this thread, when I realised that it was > > the cypherpunks list and not the extropians. Any chance of cypherpunks > > running the extropian list software? Or maybe it does already? > > > > -- ____ > > Richard Kennaway __\_ / School of Information Systems > > The "Extropians list software" is not currently being run on the > Cypherpunks list, nor any other list. The software was developed by > Ray Cromwell and Harry Shapiro, and was based apparently on original > list software developed by Perry Metzger (yes, our own Perry). Actually the code was developed from scratch except for Perry's "X-Extropian-Date" and header format. Perry's code with minor modification (message numbers, configuration files, and digestification) form the old list software. This would still be good software to run Cypherpunks off of. Atleast it would add a Reply-To: line. > Ray is on our list, Harry once was (haven't seen him post lately, > so...), and Perry of course is. They may comment also. > > The software allows a variety of modes, special commands, etc. One > such command is: > > ::exclude user foobar.baz.edu > > Eric Hughes is aware of the Extropians list software and mentioned > recently that is may be released a la GNU, that is, available. The list software still isn't ready for general usage yet. I still haven't finished the remote list administration system, the "moderated threads" I talked about, or most importantly, the docs. As a consequence, I would have to give extensive support to anyone running it. Which is fine as long as they are willing to pay me. > On the other hand, the Extropians would like defray their development > costs, so they are considering various ideas. I'm sure Ray and Harry > can comment. Yes. I am mainly trying to defray the cost of devoting time from my school work to development/support and what I could be earning if I had a real job. However, I doubt Harry/ExI is going to sell the software since it's too much of a hassle. The major cost for them is the cost of running the list from a commercial unix site. (we have to pay for CPU/Disk space/mail bandwidth) One of the neat things we are thinking of doing is digicash. Each user incurs a $5-10 cost for their yearly use of the list. Then there are the special features our software offers (which require a lot of CPU) A current proposal is to charge a subscription fee (~$5-10) per year and give each user electronic money and an account. List operations bill you and mail requires digital postage. Users are free to trade their cash on the "free market" within the list or on the HEX Exchange, etc. To prevent list admins from monitoring the motion of e-money, some form of Chaum-like cash could be used. This provides a real backing for digicash which is the "goods and services" of the list software. Theoretically, my software can network allowing users to spend their cash anywhere it is used. (e.g. spend cash on cypherpunks or extropians list operations assuming cypherpunks was running my software) I'm assuming none of this is illegal. I'll talk more about this in the future when it comes even close to being implemented. Right now it is just an idea "on the table." -- Ray Cromwell | Engineering is the implementation of science; -- -- EE/Math Student | politics is the implementation of faith. -- -- rjc at gnu.ai.mit.edu | - Zetetic Commentaries -- From ld231782 at longs.lance.colostate.edu Wed Sep 22 22:23:08 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Wed, 22 Sep 93 22:23:08 PDT Subject: P. Wayner on CSSPAB meeting Message-ID: <9309230520.AA18417@longs.lance.colostate.edu> an eternity ago in cyberspatial time (a few days ago in real time) P. Wayner posted some comments about the latest CSSPAB meeting. He hasn't appeared to have gotten any direct feedback on the list to that report, which I think is a pity, because he's one of the few cypherpunk `infiltrators' not only consistently attending important national government meetings, but conscientiously reporting them on the list (which involves a significant amount of labor) often to no reward but flames! (there's been quite a bit of indirect reaction to the `software Skipjack CRADA proposal he illuminated.) Anyway, my personal thanks! Cypherpunks, its in these kinds of reports that very important clues of future NSA directions are buried, and I'll start off with a gem: >A group of computer scientists from NIST came to discuss their plan >for the Federal Criteria for secure systems and the new "Common >Criteria" that may emerge. This is an updated version of the old >Orange Book classification scheme of C2 and B1 and stuff like that. >The scientists said the draft is being finished but it isn't ready >for release. But now, they're working on "Something Better." This >is a new plan to standardize the grading of secure systems with >other countries and evolve a "Common Criteria." In general, the >board groused about the fact that the public and industry have never >been invited to give comments during the process. The summary >of this talk is: "We might be able to tell you something someday." `other countries'? `Common Criteria'? holy cow, this is something *very big* in the works. The U.S. can barely figure out its *own* cryptographic policies, and imagine the sheer logistical nightmare of trying to come to an agreement between the most isolated and imperious agencies! I suspect GCHQ (Britain's NSA) would be involved in this at least. (There is a very cozy relationship between NSA and GCHQ that Kahn was harassed for revealing in _CodeBreakers_.)What other agencies? Mr. GraveDigger, the man in charge of NSA's Key Escrow: >He filled the hour with more descriptions with all of the restrictions >that they place on wiretaps at the Justice department. Once again, I >found myself wondering why they are going through so much trouble >over something that just seems to cause them grief. The taps cost >money. They divert manpower. Etc. Yet, the FBI and the rest of the >community is willing to go through a full court press on this topic. >The taps are essential in crime encapsulated in conversations (i.e. >influence peddling, bribery). but this only suggests how much of a crutch they have become for these agencies. They are terrified of losing this tool, for which they have come to rely on disproportionately. They have come to associate their job security with wiretapping -- a very dangerous proposition for freedom. >Some people from the Social Security Agency came to tell the board >about their internal security procedures that they use to track down >people inside the agency generating information for outsiders like >private detectives. They routinely run sting operations where they >call up information brokers and ask them to get a Social Security >file for an individual. Then they watch for accesses to that record >and flag the miscreant. fascinating. has this ever been noted before? the IRS would have benefited from this a few months ago. Or, on second thought, nevermind! all the tax evaders on the list will object to the IRS getting any help! >Dorothy Denning came to say that there was no final report from the >outside team performing an outside review of the Clipper algorithm. >In general, she said that the comments have been favorable to their >work. Several members of the board questioned the independence of the >review given that it was done at the NSA using NSA's computers and >NSA's programmers. They also wondered about the depth of the review >because it was apparent that Denning leaned heavily on the NSA's >analysis. reassuring to hear Dingaling is still alive and plugging away... I wonder what her next Lead Balloon will be? [EFF's Digital Privacy & Security Working Group] >The group feels that it can accept >Clipper if any participation in the key escrow program is completely >volutary. They proposed to test the administration's committment >to volunteerism by noting whether they relaxed export requirements. >To me, the statement was little more than a political gambit. All >of the companies involved in the DPSWG really, really, really want >export restrictions eased. So they offered their support for >Clipper as a quid pro quo. Let us export anything (not just Clipper) >and we'll support it. This is a very interesting stance, and IMHO not a bad tradeoff, if `support' means `lack of active attack and criticism'. But the NSA would never agree to this in a cyberspatial lifetime. We *still* don't even have any substantial promise that Clipper is guaranteed to be voluntary, let alone export restrictions relaxed. (Hypocritically, the announcements have always touted Clipper as Voluntary, the last redeeming feature cited by scoundrels like Dingaling and Sternlight, without ever guaranteeing it, and potentially even hiding the plan of *revoking* that aspect.) The plan, very likely, is quite to the contrary: increase market penetration of Clipper to the point that restricting other cryptography in subtle and insideous ways becomes possible. And I'm still waiting for the announcement in blaring fanfare that Clipper-based hardware can be freely exported, nothing else. I think its close on the horizon. Once they get chips that work :) [crafting official group report] >Most of the board wanted to say that the Clipper chip was >a pain in the neck that wasn't worth the trouble [...] >The fight seemed to break down between government employees and >non-government employees. Those outside the government kept arguing >for stronger language and those inside kept saying things like, >"But expensive relative to what? We don't have any concrete cost >estimates." hee, hee. the U.S. Civilization in a microcosm. From tigger at indirect.com Wed Sep 22 23:28:09 1993 From: tigger at indirect.com (Jiva De Voe) Date: Wed, 22 Sep 93 23:28:09 PDT Subject: Bill O Rights Message-ID: <199309230624.AA17149@indirect.com> Lil while back someone posted something about "Our rights are dropping like flies" aboiut various violations of the Bill Of Rights.. could someone re-email that to me? Thanks! :) From karn at qualcomm.com Thu Sep 23 01:03:46 1993 From: karn at qualcomm.com (Phil Karn) Date: Thu, 23 Sep 93 01:03:46 PDT Subject: more than spread spectrum In-Reply-To: <9309150353.AA06198@ellisun.sw.stratus.com> Message-ID: <9309230800.AA10225@servo> This idea of setting up your own independent network isn't as far fetched as it sounds, at least in a relatively local area with critical mass. The router nodes already exist, in the form of my own TCP/IP code for the PC, or any of several other packages including the various freeware UNIX clones. Radio transmission equipment operating under Part 15 of the FCC rules is already available. Under Part 15, you don't need a license; the radio transmitter does have to be "type accepted" by the FCC but since you buy that as a prepackaged box you don't have to worry about it. The section of Part 15 that is particularly interesting is either 15.247 or 15.249 (can't remember which). It allows you to run up to 1 watt of power, quite a bit for an unlicensed service, on any of several "ISM" (aka "garbage") bands as long as you use spread spectrum with a minimum processing gain of 10dB. The most popular is 902-928 Mhz, with another band in the vicinity of 2450 Ghz coming up fast. Ahthough most Part 15 equipment is designed primarily for use within office environments, it can be and is used over point-to-point paths of 5-10 km with the proper directional antennas. Although Part 15 users are not allowed to cause harmful interference and must accept interference from other users (microwave ovens generally operate on 2450 Mhz), in practice these nets seem to work pretty well if they're properly engineered. Besides, the inherent distributed redundancy available in a packet network should be able to compensate for momentary outages due to interference. Unlike the amateur service, which has some particularly draconian "acceptable use" policies (despite a recent liberalization, encryption is still illegal), there are *no* restrictions on the use of Part 15 equipment. Encryption is not only legal, some boards have hardware encryption support (e.g., the NCR Wavelan has a DES chip). This particular board operates at 2 megabits/sec on the 902-928 Mhz band with 250 mW of power. There is an even more interesting development in the works: "data PCS". In essence, this is "Part 15" style operation on dedicated spectrum, i.e., new spectrum in the 1.8-2.2 Ghz band that will not have to be shared. The specific intent of data PCS is to allow users to build their own ad-hoc networks without having to rely on the facilities of (and pay money to) carriers such as telephone companies. Phil From hfinney at shell.portal.com Thu Sep 23 04:07:12 1993 From: hfinney at shell.portal.com (hfinney at shell.portal.com) Date: Thu, 23 Sep 93 04:07:12 PDT Subject: Propriety of crypto on Munitions List Message-ID: <9309230510.AA06305@jobe.shell.portal.com.shell.portal.com> In U.S. v Martinez, Elizabeth Martinez and her fiance were convicted of violating the Arms Export Control Act by exporting cryptographic hardware, namely "Videocipher II" video descrambling devices. (I believe these are used to descramble satellite TV broadcasts of HBO and other networks.) Defendants appealed, asking the court to overturn their conviction on the grounds that "the inclusion of 'cryptographic devices and software (encoding and decoding)' on the [Munitions] list is overbroad because this heading includes items already in the public domain whose dissemination would pose no security threat, and which lack any characteristic that is inherently or predominantly military." The 11th circuit appellate court rejected this argument in 904 F2d 601. The court decided that the question of whether an item properly belongs on the Munitions List is inherently political and is excluded from judicial review. "The question whether a particular item should have been placed on the Munitions List possesses nearly every trait that the Supreme Court has enumerated traditionally renders a question 'political'.... No satisfactory or manageable standards exist for judicial determination of the issue, as defendants themselves acknowledge the disagreement among experts as to whether Videocipher II belongs on the List.... Neither the courts nor the parties are privy to reports of the intelligence services on which this decision, or decisions like it, may have been based.... The consequences of uninformed judicial action could be grave." In these days of judicial activism, it is ironic that one time when civil libertarians might wish the court to take a hand and reverse a decision made by the other branches of government, the court chooses not to do so. Shortly before this decision was issued, the AECA was amended by adding the following section, 22 USC 2778(h): "The designation by the President (or by an official to whom the President's functions under subsection (a) have been duly delegated), in regulations issued under this section, of items as defense articles or defense services for purposes of this section shall not be subject to judicial review." So Congress and the court agree that the propriety of an item's placement on the Munitions List is not a matter for the courts to decide. There appears to be little chance that any prosecution for AECA violations will result in the judical removal of cryptographic equipment from the Munitions List. Hal Finney hfinney at shell.portal.com From hfinney at shell.portal.com Thu Sep 23 04:08:11 1993 From: hfinney at shell.portal.com (hfinney at shell.portal.com) Date: Thu, 23 Sep 93 04:08:11 PDT Subject: First amendment and ITARs Message-ID: <9309230510.AA06301@jobe.shell.portal.com.shell.portal.com> In U.S. v Posey, 864 F2d 1487, the defendant was convicted of violating the Comprehensive Anti-Apartheid Act ("CAAA") and the Arms Export Control Act ("AECA") by sending design documents relating to the C-130 aircraft to South Africa. Posey obtained these documents from the U.S. government via the Freedom of Information Act. The U.S. government agreed that these documents were technically public domain within the meaning of the ITAR's. However, the CAAA, which applies only to exports to South Africa, does not contain the "public domain" exemption that the AECA (which applies to exports in general) does. The recent grand jury action regarding PGP appears to involve possible violations of the AECA. Posey appealed on several grounds, one of which was that these Acts violated his first amendment rights, since the information was, after all, freely available. The court rejected this argument, with a lengthy (and, to my mind, somewhat confused) discussion, which is worth repeating: VII. FIRST AMENDMENT Appellant's final argument is that the First Amendment bars the government from restricting the export of information that is already available to the public. He insists that the data he sent abroad was available under the Freedom of Information Act, and therefore could be legally obtained by virtually everyone in the world. He contends that the First Amendment prohibits the application of the AECA and CAAA to the export of such publicly available information. Our Court has already considered and rejected this argument. In United States v. Edler Industries, 579 F2d 516 (9th Cir. 1978), we rejected an essentially identical challenge to the predecessor of the AECA. The defendant was convicted of exporting certain manufacturing designs that were on the Munitions List but were not classified. He challenged his conviction on First Amendment grounds, arguing that the government could not constitutionally prohibit the export of techno- logical data that was widely distributed within the United States. In rejecting that claim, we explained that even assuming that the First Amendment offers some protection to the dissemination of technical data, the government has a strong interest in regulating the export of military information: The federal government undeniably possesses the power to regulate the international arms traffic.... As a necessary incident to the power to control arms export, the President is empowered to control the flow of information concerning the production and use of arms. The authority to regulate arms traffic would be of negligible practical value if it encompassed only the exportation of particular military equipment but not the exportation of blueprints specifying the construction of the very same equipment. 579 F2d at 520. We accordingly concluded that the government could permissibly restrict the flow abroad of data included in the Munitions List. 579 F2d at 521. Finally, we held that the government's power to issue such restrictions was not affected by the domestic availability of the regulated data: Given the unquestionable legitimacy of the national interest in restricting the dissemination of military information, the claim of public availability in the United States is not a defense recognized by the Constitution. 579 F2d at 522. Appellant attempts to distinguish Edler from the present case by pointing out that the exported data in Edler was "cutting edge" technology and was not widely used in this country. [Citation]. Whether or not this was factually true of the technology at issue in Edler, however, the Edler decision clearly assumed for purposes of its decision that the material was extensively available in the United States. See 579 F2d at 518, 522. Moreover, we believe Edler should not be read as permitting the govern- ment to restrict the export of only that information which is not widely available domestically. Under appellant's reading of Edler, if the government wished to prevent technical data from being sent to foreign powers, it would be required to suppress the information alto- gether, at home as well as abroad. This outcome would blur the fact that national security concerns may be more sharply implicated by the export abroad of military data than by the domestic disclosure of such data. Technical data that is relatively harmless and even socially val- uable when available domestically may, when sent abroad, pose unique threats to national security. It would hardly serve First Amendment values to compel the government to purge the public libraries of every scrap of data whose export abroad it deemed for security reasons necessary to prohibit. We conclude that appellant's conviction does not violate the First Amendment. (Hal speaking again here.) The thing I find somewhat ironic about this decision is this last paragraph. The court is saying that if the First Amendment implied that domestically available information could be exported, then the government might have to restrict domestically available information. But, this ignores the fact that the AECA already contains an explicit exemption for public domain information. So, the court is going to some length in this last paragraph to consider an argument which is mooted by the public domain exemption in the AECA. And in fact, as we have seen, at least one government official is daring to argue that this provision of the AECA does in fact give the U.S. government the power to keep Munitions List information out of public libraries! In any case, this decision and the earlier one it quotes both represent rejections by the 9th circuit appellate court (which includes California, where the grand jury investigations are taking place) of the argument that the ITARs infringe on First Amendment rights. This will make it more difficult to use the First Amendment defense in any new charges of arms export violations. Hal Finney hfinney at shell.portal.com From gtoal at an-teallach.com Thu Sep 23 05:07:14 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Thu, 23 Sep 93 05:07:14 PDT Subject: Forwarded Article Message-ID: <11181@an-teallach.com> This article was forwarded to you by gtoal at an-teallach.com (Graham Toal): --------------------------------- cut here ----------------------------- Newsgroups: mail.cypher Received: from post.demon.co.uk by mailhost.an-teallach.com with SMTP id AA11163 ; Thu, 23 Sep 93 12:41:47 GMT Received: from relay2.uu.net by post.demon.co.uk id aa07673; 23 Sep 93 9:14 BST Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19504; Thu, 23 Sep 93 04:09:31 -0400 Received: by toad.com id AA29715; Thu, 23 Sep 93 01:03:46 PDT Received: by toad.com id AA29712; Thu, 23 Sep 93 01:03:11 PDT Return-Path: Received: from qualcomm.com ([129.46.62.22]) by toad.com id AA29707; Thu, 23 Sep 93 01:03:08 PDT Received: from servo.qualcomm.com by qualcomm.com; id AA27850 sendmail 5.65/QC-main-2.1 via SMTP Thu, 23 Sep 93 01:00:40 -0700 for cypherpunks at toad.com Received: by servo; id AA10225 sendmail 5.67/QC-subsidiary-2.1 Thu, 23 Sep 93 01:00:39 -0700 for cypherpunks at toad.com Date: Thu, 23 Sep 93 01:00:39 -0700 From: Phil Karn Message-Id: <9309230800.AA10225 at servo> To: cme at ellisun.sw.stratus.com Cc: cypherpunks at toad.com In-Reply-To: Carl Ellison's message of Tue, 14 Sep 93 23:53:23 EDT <9309150353.AA06198 at ellisun.sw.stratus.com> Subject: more than spread spectrum This idea of setting up your own independent network isn't as far fetched as it sounds, at least in a relatively local area with critical mass. The router nodes already exist, in the form of my own TCP/IP code for the PC, or any of several other packages including the various freeware UNIX clones. Radio transmission equipment operating under Part 15 of the FCC rules is already available. Under Part 15, you don't need a license; the radio transmitter does have to be "type accepted" by the FCC but since you buy that as a prepackaged box you don't have to worry about it. The section of Part 15 that is particularly interesting is either 15.247 or 15.249 (can't remember which). It allows you to run up to 1 watt of power, quite a bit for an unlicensed service, on any of several "ISM" (aka "garbage") bands as long as you use spread spectrum with a minimum processing gain of 10dB. The most popular is 902-928 Mhz, with another band in the vicinity of 2450 Ghz coming up fast. Ahthough most Part 15 equipment is designed primarily for use within office environments, it can be and is used over point-to-point paths of 5-10 km with the proper directional antennas. Although Part 15 users are not allowed to cause harmful interference and must accept interference from other users (microwave ovens generally operate on 2450 Mhz), in practice these nets seem to work pretty well if they're properly engineered. Besides, the inherent distributed redundancy available in a packet network should be able to compensate for momentary outages due to interference. Unlike the amateur service, which has some particularly draconian "acceptable use" policies (despite a recent liberalization, encryption is still illegal), there are *no* restrictions on the use of Part 15 equipment. Encryption is not only legal, some boards have hardware encryption support (e.g., the NCR Wavelan has a DES chip). This particular board operates at 2 megabits/sec on the 902-928 Mhz band with 250 mW of power. There is an even more interesting development in the works: "data PCS". In essence, this is "Part 15" style operation on dedicated spectrum, i.e., new spectrum in the 1.8-2.2 Ghz band that will not have to be shared. The specific intent of data PCS is to allow users to build their own ad-hoc networks without having to rely on the facilities of (and pay money to) carriers such as telephone companies. Phil --------------------------------- cut here ----------------------------- From nowhere at bsu-cs.bsu.edu Thu Sep 23 05:28:12 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Thu, 23 Sep 93 05:28:12 PDT Subject: Red Ryder decoder rings declared illegal (fwd) Message-ID: <9309231227.AA04430@bsu-cs.bsu.edu> I apologize if this has already been posted to the list, as I have been extremely busy the past couple of days and have not had the luxury of reading every message that has been posted. If this is old news -- sorry. ,-) Begin excerpted message --------------------------- > Subject: Cu Digest, #5.74 - More on Moby Crypto ------------------------------ Date: Tue, 21 Sep 1993 21:13:17 GMT From: Grady Ward Subject: File 2--NEW State Dept FLASH on Moby Clipper (Grady Ward) (please edit follow-ups) In a fresh (to me, stunning) development, the Austin Code Works received a letter today (Tuesday 9/21/93) from the State Department, Bureau of Politico Military Affairs, Office of Defense Trade Controls advising them, in part, of their need to register as an International Arms Trafficker *even if* their crypto material is intended solely for *domestic* publication, regardless of whether they are selling executables, source, descriptions, algorithms of any crypto (and presumably viral detection) software or documentation, as defined by ITAR. This requirement literally implies that a Cereal manufacturer is required to register as an arms trafficker if it wants to include a secret de/coder ring in the box, has a cardboard outline of a de/coder printed on the box, or even a description how to construct or use a de/coder ring. Complete text of the letter follows: (State Department Seal) United States Department of State Bureau of Politico-Military Affairs Office of Defense Trade Controls Washington, D.C. 20522-0602 AUG 31 1993 Austin Code Works 11100 Leafwood Lane Austin, TX 78750-3587 Dear Sir: It has come to the attention of this office that your company is making cryptographic source code and technical data available for commercial export claiming a technical data exemption from the International Traffic in Arms Regulations. Cryptographic software, including source code, is a munitions article as defined in 22 CFR # 120.1, category XIII(b). Further, the exemptions listed in 22 CFR # 125.4 for technical data do not apply to cryptographic software and source code. A valid Department of State license is required to export cryptographic source code. As such, it would be a violation of the International Traffic in Arms Regulations to export cryptographic source code without a valid Department of State export license. We take this opportunity of advise you that any company or individual who engages in the United State in the business of either manufacturing or exporting defense articles or furnishing defense services is required to register for a fee with the Office of Defense Trade Controls (DTC) pursuant to 22 U.S.C. # 2778(b)(1)(A) and 22 C.F.R. Part 122. Furthermore, the export of such defense articles and related technical data must be licensed by the Department of State in accordance with 22 U.S.C # 2778(b)(1)(B)(2) and 22 D.F.R. Parts 120-130 (International Traffic in Arms Regulations). A booklet entitled "REGISTRATION: The First Step in Defense Trade" is enclosed. If you are unsure whether an article is on the U.S. Munitions List, you may send five (5) copies of descriptive literature about the product and request a commodity jurisdiction determination from this office according to 22 C.F.R # 120.5 of the ITAR. If you have any questions regarding the matters discussed in this letter, please do not hesitate to contact this office at (703) 875-6650. Sincerely, (signed) Clyde G. Bryant, Jr., Chief Compliance and Enforcement Branch ++++++++++++++++ I guess this means that all FTP sites who implement the GET command and have anything to do with crypto or viral detection, including RFCs, overviews or discussions of specific techniques or algorithms, etc. must be registered as International Arms Traffickers *even if* they disallow all but domestic FTP connections. What to do now. My advice to this new twist of the NSA and State Department regulating activities *within* the United States is twofold: (1) GET and FAMILIARIZE yourself with PGP sources or other crypto options NOW and upload it to your local BBS (if you deem it still legal for you to do these things) and (2) Consider supporting the Electronic Freedom Foundation. PGP sites: black.ox.ac.uk (129.67.1.165) src.doc.ic.ac.uk (146.169.2.1) ftp.demon.co.uk (158.152.1.65) ghost.dsi.unimi.it (149.132.2.1) nic.funet.fi (128.214.6.100) soda.berkeley.edu (128.32.149.19) Electronic Freedom Foundation 1001 G Street, NW Suite 950 East Washington, D.C. 20001 202/347-5400 voice 202/393-5509 FAX FTP ftp.eff.org End excerpted message ------------------------------ From 0005542837 at mcimail.com Thu Sep 23 05:57:14 1993 From: 0005542837 at mcimail.com (David Colston) Date: Thu, 23 Sep 93 05:57:14 PDT Subject: QPK, SOURSE, FTP Message-ID: <64930923123646/0005542837NA3EM@mcimail.com> Hi, I do agree with your concepts for a public key voice system. I don't think Joel will be up to speed for a long time. Re: SOURCE CODE I will snail mail you the Call Security source and exe's today. You should have them by tomorrow or Saturday. Please post them on an FTP, so that any of the cypherpunks can get a copy. TO ALL EAVES DROPPERS If you need the source snail mailed to you, then send a floppy any size to: Colston & Associates 5111 Rogers Ave. Suite 507 Fort Smith, AR 72903 I'll stand good the return postage, but the disks will help out. From karn at qualcomm.com Thu Sep 23 06:38:13 1993 From: karn at qualcomm.com (Phil Karn) Date: Thu, 23 Sep 93 06:38:13 PDT Subject: First amendment and ITARs In-Reply-To: <9309230510.AA06301@jobe.shell.portal.com.shell.portal.com> Message-ID: <9309231334.AA13005@servo> Hal, Many thanks for posting those opinions. It doesn't look good at first glance. On the other hand, there are some differences with the present case. Here there is no question that the technical data on which PGP was based is already extremely widespread around the world, so there is a question about whether the form (algorithm description vs source code) makes a difference. And there's a question about whether it's enough to simply make something available for FTP within the US to get in trouble, and if so, how one reconciles this with the First Amendment. Phil From gtoal at an-teallach.com Thu Sep 23 07:53:15 1993 From: gtoal at an-teallach.com (Graham Toal) Date: Thu, 23 Sep 93 07:53:15 PDT Subject: Apologies for brain-damaged mailer failure! :-( Message-ID: <9309231448.AA05746@an-teallach.com> Sorry folks - I forwarded an article from this group to my wife that's relevant to her work, and it appears to have been sent to the people in the To: line contained in the article body rather than in the address I asked to send it to. This is almost certainly because I'm beta-testing a new local version of snews (a DOS newsreader) and I think I've just found its first major bug :-( Sincere apologies and I'll be *much* more careful in future what I do with this version of the newsreader. Meanwhile, excuse me while I step next door and beat up a certain programmer :-) Graham From koontzd at lrcs.loral.com Thu Sep 23 07:57:15 1993 From: koontzd at lrcs.loral.com (David Koontz ) Date: Thu, 23 Sep 93 07:57:15 PDT Subject: Propriety of crypto on Munitions List Message-ID: <9309231453.AA29903@nebula.lrcs.loral.com> >From: hfinney at shell.portal.com >In U.S. v Martinez, Elizabeth Martinez and her fiance were convicted >of violating the Arms Export Control Act by exporting cryptographic >hardware, namely "Videocipher II" video descrambling devices. I would guess that they have good grounds for an appeal now that the ITAR has been changed to except the VideocypherII (unless they were exporting studio or professional quality equipment): FEDERAL REGISTER VOL. 58, No. 139 Rules and Regulations DEPARTMENT OF STATE Bureau of Politico-Military Affairs 22 CFR Parts 120, 121, 122, 123, 124, 125, 126, 127, 128, and 130 [Public Notice 1832] Amendments to the International Traffic in Arms Regulations Part II 58 FR 39280 DATE: Thursday, July 22, 1993 ... Enumeration of Articles 121.1 -- General. The United States munitions list. (a) The following articles, services and related technical data are designated as defense articles and defense services pursuant to sections 38 and 47(7) of the Arms Export Control Act (22 U.S.C. 2778 and 2794(7)). Changes in designations will be published in the Federal Register. Information and clarifications on whether specific items are defense articles and services unde this subchapter may appear periodically in the Defense Trade News published by the Center for Defense Trade. ... Category XIII-Auxiliary Military Equipment (a) Cameras... (b) Information Security Systems and equipment, cryptographic devices, software, and components specifically designed or modified therefor, including: (1) Cryptographic (including key management) systems, equipment, assemblies, modules, integrated circuits, components or software with the capability of maintaining secrecy or confidentiality of information or information systems, except cryptographic equipment and software as follows: ... (viii) Limited to receiving for radio broadcast, pay television or similar restricted audience television of the consumer type, without digital encryption and where digital decryption is limited to the video, audio or management functions. (The VideocypherII falls here) What were the dates of the conviction and appellate court decisions? From doug at netcom.com Thu Sep 23 08:32:16 1993 From: doug at netcom.com (Doug Merritt) Date: Thu, 23 Sep 93 08:32:16 PDT Subject: more than spread spectrum Message-ID: <9309231528.AA25859@netcom2.netcom.com> Phil Karn said: >This idea of setting up your own independent network isn't as far fetched >as it sounds, at least in a relatively local area with critical mass. A little while ago I mentioned an SF Bay Area grass roots internet connection project. When I talked to Qarin about it almost 1.5 years ago, I'd thought that she was proposing an actual independent network beginning in Santa Cruz, which is why I brought it up. However apparently it is simply a connection to existing sub-Inets. After chasing down some leads, Tom Jennings' .vacation notice says to contact John Gilmore regarding SF area Little Garden business while Tom is away. This naturally leads me to suspect that everyone here except me is already well acquainted with all this...I've no idea what's going on with Little Garden myself. I like Phil's ideas, just for the record. :-) Anyway, here's what I found on the Santa Cruz project, as long as I've got it lying around. P.S. The following does not include some rumors I heard some months ago, that this project ran into opposition from commercial Internet providers around here. It also says nothing about Qarin's radio wave internet link ideas, so maybe that fell through. ---------------------- Item 1 of 2 --------------------------- >From netcomsv!darkstar.UCSC.EDU!injectnews 20 Sep 93 23: 11 PDT Wed Sep 22 18:55:52 PDT 1993 From: matthew kaufman Newsgroups: scruz.sysops Subject: Santa Cruz Community Internet (scruz-net) STATUS UPDATE Date: 20 Sep 1993 23:18:03 -0700 Organization: University of California, Santa Cruz Santa Cruz Community Internet (scruz-net) 903 Pacific Ave. #203-A Santa Cruz, CA 95060 (408) 426-6771 [for now...until new line is installed] matthew at echo.com, queue at echo.com, garlick at echo.com SEPTEMBER 20, 1993 STATUS UPDATE Summary: Full speed ahead. Full Service Begins November 1st. - We now have an office leased for the hub. Address is above. This is also our new mailing address. - We have ordered the 56kbps digital line to Mtn. View. - RGNet (formerly TLG, The Little Garden) has signed their agreement with Sprint for a new Internet feed. They will switch to Sprint on or about November 1st, coincident with our beginning of full service. - scruz-net has a registered domain name for our hub equipment and FTP/name servers (scruz.net) - scruz-net has a Class B IP address space to be used to provide IP addresses to sites that haven't already obtained an IP address (165.227.x.x) (initial sites... your IP address will be assigned this week) - Santa Cruz Community Internet (scruz-net) is now a registered fictitous business name. We also have a City of Santa Cruz business license. We are a partnership. - We have a checking account, so all the founding connection checks have been deposited. - We have some of the equipment required (donated and/or loaned), and we will be purchasing the rest over the next few weeks. - We will be obtaining a pager so that we can be contacted 24hrs in case of network problems. Latest timeline: October 1 - we move equipment into office space and begin wiring everything up. October 13 - 56kbps line installation should be complete. October 15 - Testing begins. We bring up 56kbps connection to Mountain View, begin software configuration of routers and terminal servers. Sites which want to participate in initial testing can start dropping off their modems and we'll assign phone lines. Full IP routing will NOT be in effect, but you (and we) will be able to test SLIP/PPP software, failure recovery, local routing. Initial sites: before connecting, you'll need to sign an actual agreement, which we're writing up. November 1 - Sprint begins routing our addresses to RGnet, who then routes them to us. Full operation begins. Any sites which have paid initial fees can begin full operation. (Note that this item depends upon the Sprint-RGnet arrangement) December 1 - First monthly payment due for connected sites. Thanks to the 9 people who've already gotten us checks for their initial connection, and the 3 whose checks we'll have soon. Without your commitment we wouldn't have been able to get started. Anyone else who wants to be included in the initial startup, you're welcome to join... a check for $406 to "scruz-net" will sign you up for a 14.4kbps connection. (That's $250 startup, $70 for the first month, $70 for the phone line at our end, and $16 for the first month of phone service at our end... you provide both modems, phone line at your end, and all equipment at your end needed for a SLIP/PPP connection). After this, fees are $86/month ($70 for IP, $16 for phone at our end. Faster connections (56kbps leased line, 128kbps over ISDN) are available... just ask. -Matthew Kaufman Qarin Van Brink Tim Garlick matthew at echo.com queue at echo.com garlick at echo.com ---------------------- Item 2 of 2 --------------------------- >From matthew at klinzhai.echo.com Wed Sep 22 23:11:09 1993 Date: Wed, 22 Sep 93 23:14:34 PDT From: matthew at klinzhai.echo.com (matthew kaufman) To: doug at netcom.com Subject: Re: Santa Cruz Community Internet (scruz-net) STATUS UPDATE well, the best source of information is to just ask us questions. The most interesting piece of information that someone who wants to start something similar should know is that there's a group like us in the Bay Area (San Francisco, Palo Alto and Mountain View) called The Little Garden, and they're in fact who we're working with to get IP connectivity to Santa Cruz. The contact person for that is Tom Jennings (tomj at wps.com) If they want to do something substantially south of Mountain View, it might be cheaper to connect to us, or perhaps we could work out an arrangement to reduce the digital line charges somehow, so definitely they should keep in touch with us as well. -matthew From nowhere at bsu-cs.bsu.edu Thu Sep 23 09:17:17 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Thu, 23 Sep 93 09:17:17 PDT Subject: No Subject Message-ID: <9309231614.AA16610@bsu-cs.bsu.edu> OK, now for something completely different: A few years back, a sculpture was created and presented to the CIA by an artist who inscribed the base of the work with a cyphertext. He refused to tell anyone what it said, but I think he later acquiesced and told the DCI. Has anyone heard anything more about this? Was the cypher cracked? From frissell at panix.com Thu Sep 23 09:28:16 1993 From: frissell at panix.com (Duncan Frissell) Date: Thu, 23 Sep 93 09:28:16 PDT Subject: Your signature line Message-ID: <199309231624.AA11164@panix.com> A response to my .sig forwarded to the list because this is a "hot" issue with cypherpunk implications. My improved HSA93 .sig: "The $1,000,000,000,000 a year Health Security Act of 1993 -- the most expensive government program in the history of mankind." The response: W >1 Trillion 1993-dollars is about 300 billion 1980-dollars - how much W >was the government spending then? I don't think prices have increased by more than 300% since 1980. General price inflation during most of the 80s was in the 4% or lower range per year. During the '80s, the Fed and State governments spent about 40% of the US health care dollars. Total 1992 spending public & private was circa $850 billion. Which would make government spending about $350 billion which I think it was. By January 1, 1997 when HSA93 is due to take full effect, health spending including inflation and the $70-$100 Billion in extra annual spending Slick Willie has plotted will push annual health spending up to circa $1,000,000,000,000.00 per annum. Granted, my .sig is marketing puffery. Note it does *not* say that the government will spend $1x10^12, but since the *program* is designed to encompass the whole health "system" it is correct to characterize the cost (to someone) of the program as $1x10^12 per year. They want the credit, they deserve the blame. W >World War II was much more expensive - maybe fewer direct dollars W >(even inflation-adjusted), but the cost in human lives was W >staggering, and even if you only value those lives in terms of lost W >earnings and losses to the market from lost consumption, that's a huge W >cost. (Don't know what it is, but it's likely to be much larger than W >the $1T/year times the 2-3 more years before Clinton gets thrown out on W >his ear :-) WWII was over in 5 years. HSA93 (like a baseball game) *could* go on forever. Also, we don't know how many people have died because of medical regulation (though, of course, medical regulation is larger in scope even than HSA93). Could be more than WWII. I don't expect the system to last that long, however. Duncan Frissell "If they want a name give them a name, if they want an address give them an address, if they want an SSN give them an SSN, if they want a Health Security Smartcard programmed with your entire medical and psychiatric history + xrays + CAT scans + MRIs + your genotype; give them a puddle of melted aluminum." --- WinQwk 2.0b#0 From mentor at indial1.io.com Thu Sep 23 09:38:55 1993 From: mentor at indial1.io.com (Loyd Blankenship) Date: Thu, 23 Sep 93 09:38:55 PDT Subject: problems? Message-ID: <9309231632.AA09393@indial1.io.com> I've received no list traffic for 3 days. Is it live, memorex, or a problem with my address? Loyd -- ************************************************************************* * Loyd Blankenship mentor at io.com ^ * * Steve Jackson Games CI$: [73407,515] / \ * * PO Box 18957 GEnie: SJGAMES / O \ * * Austin, TX 78760 /_____\ * * 512/447-7866 * ************************************************************************* From hfinney at shell.portal.com Thu Sep 23 10:20:32 1993 From: hfinney at shell.portal.com (Hal Finney) Date: Thu, 23 Sep 93 10:20:32 PDT Subject: Mail outage Message-ID: <9309231643.AA28704@jobe.shell.portal.com.shell.portal.com> My remailer at hfinney at shell.portal.com is apparently unable to receive mail today and last night. I have complained to customer service about this and hopefully the problem will be resolved soon. Hal Finney hfinney at shell.portal.com From frissell at panix.com Thu Sep 23 11:28:56 1993 From: frissell at panix.com (Duncan Frissell) Date: Thu, 23 Sep 93 11:28:56 PDT Subject: Propriety of crypto on Mu Message-ID: <199309231825.AA00822@panix.com> H>So Congress and the court agree that the propriety of an item's H>placement on the Munitions List is not a matter for the courts to H>decide. There appears to be little chance that any prosecution for AECA H>violations will result in the judical removal of cryptographic equipment H>from the Munitions List. However, cryptographic software being writings not equipment could be protected. Thanks for your postings Hal but I note that the Supremes haven't spoken yet. Even though it is tough to get a grant of cert, if we were able to a different result might occur. Note that in a number of "regulatory" first amendment cases, the appeals courts decided in favor of the government while the Supremes voted unanimously in favor of freedom of communication. Sometimes you have to make it up the ladder. Two examples (sans names because I'm doing this from memory): The Newsletter Case of 1985. SEC tried for years to get investment newsletters to register as security advisors. They picked a good test case. Man was barred from security industry for perfidity kept running newsletters, SEC sued to force registration (which would have been rejected), SEC lost at trial, C of A went for the government, Supremes voted 8-0 for the defendent. Minnesota or Wisconsin case -- man speaks at public hearing held by school board, State Labor Commissioner sues him for "unfair labor practice", he is a teacher and they accused him of 'negotiating with his employer outside of the collective bargaining process,' he loses at every level until he wins unanimously at State Supreme Court Level. It ain't over 'till it's over. Why don't UK companies produce PGP software for sale in the US? They couldn't be reached as easily. Duncan Frissell A little war poetry for our current war: (brought to you as a public service by Frissell & Associates, Privacy Consultants) "FOR ALL WE HAVE AND ARE" 1914 by You Know Who FOR all we have and are, For all our children's fate, Stand up and take the war. The Hun is at the gate! Our world has passed away, In wantonness o'erthrown. There is nothing left to-day But steel and fire and stone! Though all we knew depart, The old Commandments stand:-- "In courage keep your heart, In strength lift up your hand." (cont in next msg) --- WinQwk 2.0b#0 From frissell at panix.com Thu Sep 23 11:30:16 1993 From: frissell at panix.com (Duncan Frissell) Date: Thu, 23 Sep 93 11:30:16 PDT Subject: Regulating the Nets Message-ID: <199309231825.AA00814@panix.com> A talk.politics.crypto post of mine forwarded because of my ego: T >I can't imagine any combination of events or circumstances which would T >keep the government out of the net.regulation business if they want to T >get in, Watch. We already know how to set up an "enterprise" network that excludes anyone the operators wish to exclude. We also know how to encrypt the traffic such that only authorized persons can read it. We also know how to do traffic mixes that make tracing difficult or impossible. And, finally, we know how to do this offshore, or in other countries, or using split processes running on different (or virtual networked) machines in many different locations at the same time. These virtual processes can shift around the physical world on a random basis. Rather difficult to regulate particularly since loads of people will be able to make their money while living anywhere on earth. In any (changing) jurisdiction. T >and I really don't see what private financing has to do with it It does provide a little more flexibility plus lower costs and better service. This would speed up the networking process. But you're right, we can use the National Information Infrastructure for our own purposes if we like. T >The net will be kept free of idiotic restrictions only if the T >majority of people want it kept that way and see to it the government T >hears them, and financing doesn't have much to do with it. The views of the majority (or the minority) are relevant only if someone can figure out a way to regulate the beast in the first place. Not a non-trivial problem. T >Do you really think Time-Warner management has a vision of a high T >bandwidth two-way communications network in which individual artists T >could offer their productions to the public in competition with the T >mindless network bilge? Or is it more likely Time-Warner imagines a T >future in which they have a stranglehold on a big chunk of the net and T >take the lions share of any profit associated with information that T >flows over it, I don't know what TW "imagines" but the competition -- Continental Cable -- is already planning to put 10 mbps Internet connections into the homes of any subscribers that want it by the end of 1994. They will not be controlling content. IBM was not able to kill "open systems" either. T >I can certainly speculate about which path is most likely to occur T >without any government interference with the be-all end-all cure-all T >magic bullet of the pure libertarian free market. You must realize by looking around you that there is no noticeable increase in obedience to authority going on. Even with decent enforcement techniques, the government will have a hard time controlling the nets. People will just choose to disobey as they increasingly do in other areas of their lives these days. In the *absence* of decent regulatory tools, obedience will be even lower. What are the powerful regulatory techniques that will bring the nets to heel? What is the government's magic bullet? Duncan Frissell You don't have to be nice to nation states you meet on the way up if you're not coming back down. --- WinQwk 2.0b#0 From mjr at TIS.COM Thu Sep 23 11:53:17 1993 From: mjr at TIS.COM (mjr at TIS.COM) Date: Thu, 23 Sep 93 11:53:17 PDT Subject: DES binaries for Mac - Message-ID: <10409.9309231849@otter.TIS.COM> I'm looking for DES encryption software for a Mac that can read cbc-encrypted data created with the "des" command on a UNIX box. I found one version of DES for Macs (powers-MacDES.sit.hqx) that appears to do DES properly but uses the resource fork in some way such that it won't try to decrypt files it didn't create. Anyone out there a Mac wizard who can point me at a compatible binary? I've no access to a compiler, and I'm under too tight a schedule to port something myself. Please, buddy, can you spare some crypto? mjr. From klbarrus at owlnet.rice.edu Thu Sep 23 12:17:20 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Thu, 23 Sep 93 12:17:20 PDT Subject: MAIL: positive reputations Message-ID: <9309231913.AA10882@arcadien.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- Earlier, I mentioned my stab at a positive reputation scheme for anonymous mail. I made some changes to the script I posted earlier (which I discovered was truncated because of a lone period on a line - PERL's marker for ending a format specifier). The script sifts through an elm folder, reporting message number, email address of author, and subject. When a pgp signed message is found, it sends the message through pgp, extracting the signature and reports that instead. (At the moment I'm not sure what happens if the public key needed to verify the signature isn't on your keyring, or if a signature is bad). Positive reputations, digital postage, and easier methods for replying are a solution for the "how to mark anonymous mail" question which crops up from time to time. That is, you don't mark anonymous mail - instead, in the future, mail readers will be capable of getting the digital signature from a mail message and reporting it, of replying to anonymous mail, etc. I mean, who wrote the message is what you are really interested in, now so much how it got to you (via anonymous remailing chains, etc.). Positive reputations and digital postage are more appealing to me because I'm a "purist" - I'm more interested in "pulling it off" (anonymous mail) than in other concerns. Marking anonymous mail with certain subject headers and so forth is an unacceptable solution to me. Now, there isn't a requirement that the signature on the message be for a "real" person - a good positive reputation system would allow a person to adopt a pseudonym (ala Demosthenes and Locke in Card's _Ender's Game_) and speak via that pseudonym. When you read your mail and you note messages are from "Demosthenes" and you agree with the opinions expressed, you will mentally note that Demosthenes is intelligent, and be willing to read further message. On the other hand, if you feel Locke is an idiot, you will skip messages, or set your advanced email filters to reject the messages. I thought about a possible real life example, and this came to mind: suppose David Sternlight, heartened by a legal PGP, decided he was going to blow off USENET and instead participate here, on cypherpunks. He knows that for many, merely seeing the email address "strnlght at netcom.com" will cause a variety of reactions :-). So he could form a pseudonym for himself and participate, allowing himself to start afresh. Following is the script. It is inefficient (the while loop that drives the thing needs massive reworking, pgp is called to get a signature from a document) but eventually these will be fixed (I'll rewrite the loop, a pgp library will be made available). Plus, as I said above, I'm not sure what happens with bad signatures or missing public keys. Also, to prevent some mailer from truncating this post, I'll move the formatting period over by a space - this will cause a "format not terminated" error if you try to run this script without moving the period back! Here's how I use it: scan cypher where cypher is an elm mail folder. I get back a report that looks like this: 1 collins at newton.apple.com blank lines v. the remailer 2* Karl L. Barrus 8-------------------- #!/usr/local/bin/perl #report email address and subject of messages in an elm folder #frm sometimes reports name and not email address - not that I # guarantee this works in all cases #if the message is pgp signed, report signature instead of address #simple version of mh scan command #Karl L. Barrus ($name,$passwd,$uid,$gid,$quota,$comment,$gcos,$dir,$shell)=getpwuid($<); chdir "$dir/Mail" || die "Can't cd to ~/Mail\n"; while (@ARGV) { $file = shift @ARGV; if (-T $file) { if (-z $file) { #zero length folders with no messages print "Folder $file has no messages\n"; } elsif (!open(FOLDER, "./$file")) { print STDERR "Can't open $file\n"; } else { $state = 1; #Look for a new message $num = 0; while () { #this whole loop need massive reworking!!! if ($state == 1) { #Delimits a new message $num++; $from = ""; $subject = ""; $sig = ""; $state = 2; #Look for From: and Subject: } if ($state == 2) { #Already found a message; looking for headers /^Subject: (.*)/ && ($subject = $1); #match subject /^From: (.+)/ && ($from = $1); #match "From: add" /^From: (.+) <(.+)>/ && ($from = $2); #match "From: name " /^From: (.+) \((.+)\)/ && ($from = $1); #match "From: add (name)" if ($from ne "" && $subject ne "") { #found both headers $state = 3; #look for possible pgp signed message } } if ($state == 3) { #Found a message, found headers, look for pgp if (/^-----BEGIN PGP SIGNED MESSAGE-----$/) { $sig = "*"; $temp = "./.tmp_" . $num . "_" . $$; $tempsig = "./.tmp_sig_" . $num . "_" . $$; open (OUT1, "> $temp"); $state = 4; #write out pgp signed message to a file } } if ($state == 4) { #writing pgp signed message to a file print OUT1 $_; if (/^-----END PGP SIGNATURE-----$/) { close (OUT1); system ("$dir/bin/pgp -f < ./$temp 1>/dev/null 2>$tempsig"); open (PGPOUT, $tempsig); while () { /^Good signature from user "(.+)"\.$/ && ($from = $1); } close (PGPOUT); unlink $temp, $tempsig; } } if ($state >= 3 && /^From[^:]/) { $state = 1; #go back to looking for a new message write; } } } } elsif (-d $file) { print STDERR "$file is a directory\n"; } } exit; format STDOUT = @###@<@<<<<<<<<<<<<<<<<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< $num, $sig, $from, $subject . - --------------------8< cut here >8-------------------- ^--- remember to move this back a space! -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLKH09IOA7OpLWtYzAQH7mwP/QsgQ9cbj8lPIu0o9eLzH38JFCP948DNO NnoUdoyk+gJtx6ohIyv6uWmX3sDh5ACDTd9SyT91XbyuHz/dWBCMYGY8S1hfvsJG JhK1Dr3p5PubS/neHro1cYR33Ex2QbZ/NNBgKPNpPF+lPg2RcO7WWpL8kFofD/Cs HCakIr/s0SE= =A69F -----END PGP SIGNATURE----- From dsobel at washofc.cpsr.org Thu Sep 23 14:23:59 1993 From: dsobel at washofc.cpsr.org (David Sobel) Date: Thu, 23 Sep 93 14:23:59 PDT Subject: NIST Explains Clipper "Revi Message-ID: <00541.2831649112.5583@washofc.cpsr.org> NIST Explains Clipper "Review" The National Institute of Standards and Technology (NIST) has clarified the role of five experts selected by the agency to evaluate the government's Clipper Chip proposal and the underlying SKIPJACK cryptographic algorithm. In a recent letter to the CPSR Washington Office, NIST asserts that the panel was not established to provide "advice or recommendations" to the government. Rather, according to NIST, the reason for convening the group was "to provide the opportunity for independent experts to satisfy themselves as to the strength and effectiveness of the algorithm in order to encourage widespread acceptance of it in the marketplace." NIST concludes that the panel's evaluation therefore falls outside the scope of the Federal Advisory Committee Act, which opens the work of advisory panels to public scrutiny. In response to CPSR's request for documents relevant to the panel's review, the agency reveals that NIST has no records which were made available to or prepared for the five experts for the purpose of enabling them to evaluate the Clipper Chip proposal. Any such records would be in the possession of the National Security Agency, where all activities related to the work of the experts were conducted. This disclosure provides further confirmation that NSA, and not NIST, is the driving force behind the Clipper proposal, despite NIST's public role as the "proposing" agency. The only NIST document released to CPSR is a copy of the invitation sent to the five experts who participated in the evaluation. That letter describes the "key escrow" system and states that the escrowed keys will be made available "only to authorized government officials under proper legal authorizations, usually a court order." This language -- "usually a court order" -- suggests that there will be instances in which the escrow keys will be provided to government agents without presentation of a judicial warrant. The government has never clearly defined what will constitute "legal authorization" under the Clipper system. David L. Sobel CPSR Legal Counsel From ld231782 at longs.lance.colostate.edu Thu Sep 23 14:47:23 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 23 Sep 93 14:47:23 PDT Subject: H. Finney: #1 Cyberspatial Lawyer Message-ID: <9309232142.AA11493@longs.lance.colostate.edu> I'm truly in awe. H. Finney gets my vote as Cypherpunk of the Week for uncovering all this dazzlingly appropos information. [U.S. vs. Posey decision] >Technical data that is relatively harmless and even socially val- > uable when available domestically may, when sent abroad, pose unique > threats to national security. gad -- they simply don't understand that cyberspace has no boundaries, subject to the same delusions of the NSA. Maybe they should read that extraordinary quote by Mr. President uncovered by Markoff. >In any case, this decision and the earlier one it quotes both represent >rejections by the 9th circuit appellate court (which includes California, >where the grand jury investigations are taking place) of the argument >that the ITARs infringe on First Amendment rights. This will make it more >difficult to use the First Amendment defense in any new charges of arms >export violations. either that, or we're TAKING THIS TO THE SUPREME COURT! hee, hee. for the mentally challenged, that's *satire*, folks, don't get excited. From Lyle_Seaman at transarc.com Thu Sep 23 15:12:23 1993 From: Lyle_Seaman at transarc.com (Lyle_Seaman at transarc.com) Date: Thu, 23 Sep 93 15:12:23 PDT Subject: Propriety of crypto on Mu In-Reply-To: <199309231825.AA00822@panix.com> Message-ID: Duncan Frissell writes: > Note that in a number of "regulatory" first amendment cases, the appeals > courts decided in favor of the government while the Supremes voted > unanimously in favor of freedom of communication. Sometimes you have to > make it up the ladder. Pardon my cynicism, but I think I know why. These little judges really, really, want to be appointed Supremes. So they aren't likely to rule in a fashion which will threaten the potential interests of a current or future US president. Since the natural goal of government is to accrue power, there seems to be a safe prediction of what those future interests will be. Lyle Transarc 707 Grant Street 412 338 4474 The Gulf Tower Pittsburgh 15219 From an12070 at anon.penet.fi Thu Sep 23 15:37:23 1993 From: an12070 at anon.penet.fi (S. Boxx) Date: Thu, 23 Sep 93 15:37:23 PDT Subject: CPSR NIST info Message-ID: <9309232231.AA22024@anon.penet.fi> David Sobel >This disclosure provides further confirmation that NSA, and not >NIST, is the driving force behind the Clipper proposal, despite >NIST's public role as the "proposing" agency. SURPRISE! ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From newsham at wiliki.eng.hawaii.edu Thu Sep 23 16:12:24 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Thu, 23 Sep 93 16:12:24 PDT Subject: DC nets for network access? Message-ID: <9309232311.AA11880@toad.com> DC Nets allow a single person to talk in a group of people without giving away the identity of the talker. Telnet servers are programs that are easily set up from a user account that allow a you to connect in to and then back out of a machine with little or no logging. Would it be possible/practical to marry these two concepts? Make a network of clients who wish to have anonymous access at some point or another and ahve them transmit information by using a DC-NET protocol and then having a listener which is a telnet server and allows connections to the outside world. The biggest problem I see is 'sessioning', keeping data originating from one user seperate from data originating from another user without giving away the users identity. If data is allowed to mix then there will be a resulting security problem of course. Any comments? From baumbach at atmel.com Thu Sep 23 17:37:25 1993 From: baumbach at atmel.com (Peter Baumbach) Date: Thu, 23 Sep 93 17:37:25 PDT Subject: First amendment and ITARs Message-ID: <9309232336.AA10998@bass.chp.atmel.com> > The federal government undeniably possesses the power to regulate the > international arms traffic.... As a necessary incident to the power > to control arms export, the President is empowered to control the > flow of information concerning the production and use of arms. The > authority to regulate arms traffic would be of negligible practical > value if it encompassed only the exportation of particular military > equipment but not the exportation of blueprints specifying the > construction of the very same equipment. > > 579 F2d at 520. We accordingly concluded that the government could > permissibly restrict the flow abroad of data included in the Munitions > List. 579 F2d at 521. Finally, we held that the government's power > to issue such restrictions was not affected by the domestic availability > of the regulated data: > > Given the unquestionable legitimacy of the national interest in > restricting the dissemination of military information, the claim of > public availability in the United States is not a defense recognized > by the Constitution. I question the legitimacy of ITAR. There, it is no longer unquestioned. Which enumerated power of the congress is the president enforcing here? Raise all possible questions at the earliest convenience. It is the responsibility of your adversary, not the court, to argue the otherside. Justice is supposed to be blind. Anything else would IMHO be denial of due proccess, and should be overturned on appeal on those grounds. Peter Baumbach baumbach at atmel.com From ld231782 at longs.lance.colostate.edu Thu Sep 23 18:14:02 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 23 Sep 93 18:14:02 PDT Subject: Front Line Dispatch -or- Conspiracy Theories on the PTB Message-ID: <9309240110.AA16875@longs.lance.colostate.edu> Here is an update on recent and past developments. - Why PRZ was not subpoenaed - Clarifications on the NYT article - simultaneous serve dates? - The Grady Ward PGP connection - the Scarlet Letter - Conclusion - EFF and *your* support PRZ unsubpoenaed so far ---- First, in the message I posted to the cypherpunk list that PM transformed into one of the most side-splittingly hilarious, foaming, delirious flames I've ever had the joy to experience, there were some misleading comments, and I'm rather surprised that no one has noticed and chastised me for them, publicly or privately. (In this way PM succeeded precisely in his intent of distracting attention from the actual contents, in a rather pitiably desperate way.) However, I do have to admit that it was probably my weakest posting here on the affair -- nevertheless, I was actually quite dazzled by the ensuing fireworks, which IMHO comprise the most spectacular flame war I've ever seen on the list, and I'd *not* have done anything differently knowing this in retrospect! (And this characteristically prolix commentary is my tribute in response!) Anyway, I've been relying on `cyberspatial connections' (email & the phone, and *many* key people) *intensely* lately as a tool to crystallize my thoughts and further The Cause. Let me post some clarifications. First, I said, >What is the significance that PRZ was not actually >cited in any subpoena so far? This is very puzzling. It seems to >contradict the theory that the investigation is primarily PGP oriented. Actually, what I meant was this: why do the subpoenas ask representatives to appear who have very little personal knowledge of the situation: ``how could they *not* query PRZ if they are inquiring on PGP''? The Austin Code Works one is not even directed to anyone in particular (!) but to the `custodian of records'. And as I noted the ViaCrypt one is directed to the president, Leonard Mikus -- who of course would be extremely knowledgeable of the recent ViaCrypt deal, but virtually *entirely clueless* as to the original PGP distribution (happening over 2 *years* ago!). The ViaCrypt subpoena of course *does* mention PRZ repeatedly. Here are the two side by side for comparison. I got this from Current Underground Digest: [Viacrypt] >"Any and all >correspondence, contracts, payments, and records, including those >stored as computer data, involving international distribution related >to ViaCrypt, PGP, Philip Zimmermann, and anyone or any entity acting >on behalf of Philip Zimmermann for the time period June 1, 1991 to the >present." [Moby Crypto] >Any and all correspondence, contracts, payments, and record, >including those stored as computer data, relating to the >international distribution of the commercial product "Moby >Crypto" and any other commercial product related to PGP and RSA >Source Code for the time period June 1, 1991 to the present. The letter I quoted in my own, from the person describing grand jury investigations, erroneously implied that Phil Zimmermann was subpoenaed, which regrettably my own report above it confused as well. Phil Zimmermann, to this point, has *not* been subpoenaed. I think the simple answer to this curiosity is as follows, and is not idle speculation but cuts to the core of the case and the intentions of those behind it. As indicated, I have heard indications that the subpoenas are only the latest development in a customs investigation that perhaps extends up to many months or even over a *year* in span. Very likely PRZ has been contacted on a previous occasion. The primary focus of these subpoenas is *records*, not *testimony*. Possibly, the investigation has already exhaustively uncovered testimony short of written records. In fact, this suggests a model `ladder of severity' of an investigation of this type, of which there appears to be almost no historical precedent, but this might serve as in the future: (1) start with queries to people involved, with no warrants. Maximize the information obtained. track down all leads to people mentioned freely. (2) When this has been exhausted, possibly, attempt to gain any records available without a warrant. (3) If no directly incriminating evidence has been obtained to this point, but there is still some prod to go further (more on this later), convene the grand jury. (4) subpoena (a) documents and (b) witnesses. Now, in (4), if significant oral accounts had already been obtained *freely*, the former (a) is more important than the latter (b) at that stage. Or, it might be that the investigators thought that a mere subpoena for records would be less explosive than one for documents. Also, it is definitely less of a burden on some people (the Austin Code Works `records custodian' notwithstanding). These are all plausible conjectures of the inquiry situation at this point in the case. NYT article & the simultaneous date? --- >From the CuD account, I have pieced together the following, which forms part of a letter I hope will be accepted by one of the premier online electronic computer journals (watch for it!): >As reported in many places, such as Current Underground Digest, New >York Times (Sept 21) and on AP, subpoenas were served on >representatives from the companies ViaCrypt and Austin Code Works for >materials related to a grand jury investigation in California >associated with the U.S. Customs Office. Both warrants are dated 9 >Sept., but were served and received two days apart (contrary to the NYT >account), with the ViaCrypt on Tues 14 Sept and ACW on Thur 16 Sept [...] I've talked to J. Markoff (the NYT writer) and he's indicated that the following statement in the article >The >grand jury subpoenas, which the companies *received* Sept. 9 (my emphasis) was based on the date *on* the subpoenas, not their actual `serving time'. (Note: subpoenas are delivered by government agents, not the post office.) Markoff also misspelled Zimmermann's name with one 'n', a pitfall I must confess my own guilt on occasion! Finally, I have to admit now that theories about a `coordinated simultaneous attack' in expectation of the `cyberspatial reaction' are not supported by this datum. This is not to say it was not on the minds of `the powers that be', which I will henceforth coin the PTB, and let it serve as the hypothetical TLA responsible for all *unsolved* conspiracies in existence. (Note that the expression is not my own but the abbreviation is.) The PGP connection --- Finally, I also wrote, an eternity ago in cyberspatial time (EA in CT): >Rumor: Moby Crypto was targeted because G. Ward intended to include PGP >on distribution disks. The investigation is primarily PGP oriented, and >G. Ward is just a bystander who got caught up. PRZ & PGP is the essential target. G. Ward has just confirmed this to me directly. Since he's referring to public Usenet postings, I'm going to quote him: Date: Thu, 23 Sep 93 05:50:13 -0700 Message-Id: <9309231250.AA17688 at netcom6.netcom.com> >I believe that I did announce on sci.crypt that my >Moby Crypto tutorial was to contain a full source >to PGP as an excellent example of a full crypto and >digital signature application. > >Because I do not have a license from PK partners, I >was careful to document their patent rights and to only >publish the source (and I got two patent attorneys opinions >that source is not infringing as long as it wasn't >just an attempt at evasion). also, I asked cypherpunks to find this message. so far, no bites. I would figure it would have *really* stood out, but no one seems to remember it. This is *prime* material for us to pore over. We can determine how fast someone may have reacted if we know the date of his message. Now, call me a conspiracy theorist, but personally, this statement, taken along with the subpoenas and the glaring NSA pokes G. Ward has been the butt end of as reported on Usenet crypto groups and alluded here, is all perhaps the strongest indication I've ever seen that the NSA (the most common PTB) is directly monitoring newsgroups -- not only monitoring, but beginning to respond directly to taunts. The Scarlet Letter --- I'll have much more to say about the latest letter bestowed on Grady later. The major point I want to make here is to tie it in with the current investigation. First of all, it now implicates fairly high levels of the State Department and the Office of Defense and Trade controls as being engaged in all this as well. Secondly, it gives us some EXTREMELY valuable intelligence on which of our interpretations of the ITAR are relevant, and how the PTB (synonymous with The Enemy here) interprets them. There are *direct references* of sections, and I'm just salivating for the next H. Finney posting to rebut their fantasies: >Further, >the exemptions listed in 22 CFR # 125.4 for technical data do >not apply to cryptographic software and source code. The most EXTRORDINARY section, upon which Grady Ward bases his claims that this appears to be a DOMESTIC CONSTRICTION of cryptographic knowledge dissemination: >We take this opportunity of advise you that any company or >individual who engages in the United State in the business of >either manufacturing or exporting defense articles or >furnishing defense services is required to register for a fee >with the Office of Defense Trade Controls (DTC) pursuant to 22 >U.S.C. # 2778(b)(1)(A) and 22 C.F.R. Part 122. The apparent claim is that mere *U.S. `manufacturing' alone* (*not* any trans-border condition such as export or import) requires `registration for a fee' -- this is tantamount, in the case of cryptography, to PRIVACY LICENSES. HORRORS! This appears to be an extraordinarily audacious, egregious, and perhaps a WHOLLY UNTENABLE interpretation of the ITAR by the PTB. Here G. Ward's comical vision of Cereal Decoder Ring Registration reaches the depths of irony and absurdity -- and the heights of our anxiety and apprehension. BTW, I've come to the conclusion that we could not have *wished* for better `victims' in a lifetime. If we are going to win anything for `the cause' from all this, Phil Zimmerman and Grady Ward are the greatest shining heroes we have to offer in this affair, which is going to turn out, desperately hopefully, as the Two Davids vs. Goliath, and not the latest human sacrifice to the PTB. Conclusion --- What does all this mean to the spread of cryptography? Its far too premature to comment authoritatively. Instead I wrote the `Schneier Satire' because I'm *extremely* concerned by all these recent developments. I think they respresent a desperate struggle by the NSA to minimize the *future* spread of cryptographic ideas and implementations through any government agencies available, particularly in the *domestic* U.S. arena. PGP to this point has been `out of the bag' but not in a potentially enormous *commercial* way. Apparently, the ViaCrypt agreement shifted the `institutional paranoia' into high gear of the extraordinary future potential of PGP and public, widespread cryptography. This represents a fundamental policy change from `benign neglect' to `active harassment' and perhaps, more melodramatically, *attack*. The Zimmermann-Ward affair is going to be a critical keystone to future developments in cryptographic freedom, in either limiting and checking this latest alarming manifestation of the severe, constricting, repressive influence of the NSA, or in heralding a new, basic, bold expansion of it. EFF and *your* support --- It greatly pains me to have to bring this up, but I've received multiple top confirmations that EFF is `less than fully engaged' on this for a variety of practical reasons. In particular, it is not possible for them to provide attorneys or financial support at this early stage. I fully believe they are wholly committed to the overall battle, but have talked to key observers who are disenchanted and even alienated by their lukewarm response so far. I hope something beneficial to everyone and "The Crypto Cause" can stabilize as soon as possible. In the meantime, I'm going to close with H. Kennedy's beconing call in Current Underground Digest: ===cut=here=== Date: Tue, 21 Sep 1993 05:36:08 GMT From: hugh at GARGOYLE.UCHICAGO.EDU(Hugh Miller) Subject: File 1--Phil Zimmerman Comments on Encryption Flap Phil asked me to forward this to the Digest. It points up the problems of keeping _ANYTHING_ secret in the electronic world (unless, of course, it is SECURELY encrypted \;-}). It is more or less self-explanatory. Let me square his remark at the end, though: whatever happens, Phil is facing some pretty vast legal bills. Now is the time for all of us who favor crypto for the masses to pony up and put our wallets where our mouths are. I pledge $100 NOW, and challenge every one of you to match or exceed me. I'll keep it up until Phil's out of the hole. ($100 on a regular basis is a lot of money on an assistant professor's salary with 3 kids.) Examine your conscience and write that check. Pronto. Hugh Miller Asst. Prof. Dept. of Philosophy Loyola University Chicago Date--Sun, 19 Sep 1993 13:38:44 -0500 From--Philip Zimmermann Subject--Zimmermann statement on PGP investigation [...] I understand that the issues involved in this investigation are of the greatest importance and transcend my personal interests. Even so, I would rather not turn an investigation into a full-scale federal prosecution. I ask that everyone keep in mind that the government's resources are limitless and that mine are not. Speaking of resources, many of you have offered help, and I am grateful. Those wishing to contribute financially or otherwise should contact either me or Philip L. Dubois, Esq., at dubois at csn.org or by phone at 303-444-3885 or by mail at 2305 Broadway, Boulder, CO, 80304. Mr. Dubois has just got on the Internet and is still learning how to use it. Donated funds will be kept in a trust account, and all contributions will be accounted for. If this whole thing somehow goes away with money left in the account, the balance will be refunded to contributors in proportion to the amounts of their contributions. From msattler at netcom.com Thu Sep 23 18:57:26 1993 From: msattler at netcom.com (msattler at netcom.com) Date: Thu, 23 Sep 93 18:57:26 PDT Subject: Why RSA? Message-ID: <9309240153.AA14374@netcom.netcom.com> >I don't know if ViaCrypt includes any distinguishing features >that let you tell a ViaCrypt PGP message from a Real PGP message - >they could do subtle stuff like make the session keys all >include some checksum (e.g. be a multiple of N mod M), >or crude stuff like put "Version 2.3ViaCrypt" in the headers, >which would let them detect non-ViaCrypt PGP users. >I assume not, but I haven't seen it. PRZ has specifically said that it is his intention to have no difference between the output of the PGP and ViaCrypt so that users of the free-ware version can't be ferreted out. ----------------------------------------------------------------------------- Michael S. Sattler msattler at netcom.com +1 (415) 358-3058 Digital Jungle Software Encrypt now; ask me how. (finger for PGP key) "Don't Panic!" -- Douglas Adams "Don't Panic. Stay Cool." -- PRZ From ld231782 at longs.lance.colostate.edu Thu Sep 23 19:50:32 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 23 Sep 93 19:50:32 PDT Subject: the PTB etc. - errata Message-ID: <9309240247.AA20262@longs.lance.colostate.edu> I wrote: >Or, it might be that the investigators thought that a mere >subpoena for records would be less explosive than one for documents. That should read: Or, it might be that the investigators thought that a mere subpoena for records would be less explosive than one for key witnesses & testimony. And to anticipate questions in email, >This is >not to say it was not on the minds of `the powers that be', which I >will henceforth coin the PTB, and let it serve as the hypothetical TLA >responsible for all *unsolved* conspiracies in existence. TLA is a silly self-referential term: Three Letter Acronym. From ld231782 at longs.lance.colostate.edu Thu Sep 23 22:03:30 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 23 Sep 93 22:03:30 PDT Subject: on the `R' in `RSA' In-Reply-To: <9309221814.AA23907@balder.cs.wisc.edu> Message-ID: <9309240500.AA23031@longs.lance.colostate.edu> derek at cs.wisc.edu (Derek Zahn) posted a conscientious summary of comments on the development of public key cryptographic techniques, a subject discussed with a particular urgency and irony lately. I'd like to comment on one paragraph: >Respondents to my initial questions pointed out that the patents >may be over-broad and could be challenged on those grounds; given >the history of how public key crypto was invented, it seems to >me that it would be difficult to contend that the idea is obvious >(Simmons says that the idea "stunned" the crypto community) -- but >I'm no lawyer, and I'll leave that issue to those with more skill, >brains, and money than me! Public key cryptography is not just a `stunning' idea -- it is fundamentally revolutionary, because it solves `cryptography's catch-22'. This is a paragraph from a tentative version of the cryptography faq (not available yet): === 6.2. How does public-key cryptography solve cryptography's Catch-22? In a classic cryptosystem, if you want your friends to be able to send secret messages to you, you have to make sure nobody other than them sees the key K. In a public-key cryptosystem, you just publish X, and you don't have to worry about spies. Hence public key cryptography `solves' one of the most vexing problems of all prior cryptography: the necessity of establishing a secure channel for the exchange of the key. To establish a secure channel one uses cryptography, but private key cryptography requires a secure channel! In resolving the dilemma, public key cryptography has been considered by many to be a `revolutionary technology,' representing a breakthrough that makes routine communication encryption practical and potentially ubiquitous. === Public key cryptography also represents a throbbing, excruciating, perhaps even *deadly* black eye for the NSA. The subject is given a brief treatment in the final chapter of _Puzzle_Palace_ by Bamford, all that was evident in 1980 (very close to its inception), but at even that early time it was regarded as `stunning'. That chapter also notes how the NSA had viewed with increasing desperation the academic community's increasing interest in cryptographic research, and this manifested itself in an atmosphere of increased tension between researchers and the agency, such that the latter attempted to stifle the former at the patent office and the journal submission boxes in outrageous and insideous ways -- P. Karn had a delicious expression for this a long time ago on the list, something like `poking from the shadows'. In addition to this, handfuls of scattered cryptographic enterprises and budding entrepreneurs have been harassed as well. This always happens behind the facade of some other government agency. In fact, many victims battled for a long time before they even discoverd the NSA was behind their sorry, wretched plight or dismal failures. Maybe a term better connoting the NSA's true unique depravity in our free society would be `shadow molesting'. The NSA was fundamentally in fear of, and continues to be terrified by and repress, new discoveries that would render old cryptographic ciphers breakable or yield new unbreakable ones, either outside of its control. Nowhere else than in the NSA or cryptography itself are doctrines regarding `security in obscurity', and `information is power', more tenaciously held, or more prominent. Only in cryptography is the mere *knowledge* of an efficient factoring algorithm paramount and priceless -- in mathematics it would only be a curiosity. But beyond this, public key cryptography in general and the RSA algorithm in particular represent an *extraordinary* breakthrough in cryptographic research that apparently caught the NSA totally unaware and off guard. It may have been a very humbling experience for the agency, which has sought the `cream of the crop' in engineers, technicians, mathematicians and theorists, spending tens of billions of dollars a year for decades to cultivate its own secret research, to find that it had been outdone in a few years of intense and focused outside research (I have the opinion that the NSA did *not* discover it secretly, others may differ--it would be interesting to analyze their reaction to try to determine that aspect in particular). Public key cryptography is a `stunning' testament to the power and tradition of open dialog in scientific research, and the fundamentally lackluster performance of any government agency, no matter how well funded or tightly coordinated, in comparison to the combined, vast, disconnected, worldwide talent and ingenuity that feeds voraciously off open scientific journals. Public key cryptography stands in bold, victorious defiance of NSA suppression. The final point to make is that RSA and public key systems have led to an amazing cornucopia of scientific results and spurred other critical mathematical theories. In particular the field of *complexity theory* has been to a large part driven directly by questions associated with public key cryptography. The unsolved perplexities in cryptographic research seem to cut to the core of the frontiers of interesting mathematical and computational ideas, such as factoring, that the world's foremost minds have grappled with for millenia -- Gauss, Fermat, Euler, et. al. (with new modern heroes). Cryptographic algorithms embodied in RSA in particular represent one of the most beautiful examples of the interplay between theoretical and practical science. What other program in the world simultaneously utilizes Fermat's Little Theorem to test for primes and guarantees privacy to multitudes in daily email? By the way, D. Zahn's `Simmons' reference above may be to the following (if he pointed out what it was, I missed it): [SIM91] G. Simmons (ed.), Contemporary Cryptology: the Science of Information Integrity. IEEE press, 1991. I'd also be interested in hearing of any other accounts that match my own passion for the subject :) Also, if others have any educated opinion, evidence, or theories of whether public key crypto was *undiscovered* by the NSA prior to the publication of Diffie and Hellman and RSA, I'd read them with great fascination. Note that this is *not* quite the same as `attempts to bar its publication' although those are always eye opening as well. p.s. feel free to redistribute this anywhere, but email me where you sent it. From sameer at soda.berkeley.edu Fri Sep 24 00:02:30 1993 From: sameer at soda.berkeley.edu (Sameer Parekh) Date: Fri, 24 Sep 93 00:02:30 PDT Subject: PGP question Message-ID: <9309240659.AA18309@soda.berkeley.edu> I have run into a rather embarrasing problem with PGP. I accidentally deleted the secret key to my cory remailer. Luckily, I have kept a backup of all my remailer keys in a safe place, so I still have it. Unfortunately, I can't figure out how to extract the cory secret key from the keyring containing the secret keys for my other remailers. pgp -kx and pgp -kr work quite fine for the public keys, but I can't get them to work for the secret keys. (All 6 keys were on the same keyring.) Any help? (Because of this problem, PGP on cs60a-qu at cory.eecs.berkeley isn't working-- if you want to do pGP through one of my remailers, use sameer at soda.berkeley.edu or sameer at netcom.com) From jrk at sys.uea.ac.uk Fri Sep 24 01:47:32 1993 From: jrk at sys.uea.ac.uk (Richard Kennaway) Date: Fri, 24 Sep 93 01:47:32 PDT Subject: Source for MacPGP2.3? Message-ID: <18823.9309240844@s5.sys.uea.ac.uk> I have MacPGP 2.3 (the Macintosh application). From what ftp site can I obtain the source? soda only has Mac source for 2.2. -- ____ Richard Kennaway __\_ / School of Information Systems Internet: jrk at sys.uea.ac.uk \ X/ University of East Anglia uucp: ...mcsun!ukc!uea-sys!jrk \/ Norwich NR4 7TJ, U.K. From nowhere at bsu-cs.bsu.edu Fri Sep 24 03:43:32 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Fri, 24 Sep 93 03:43:32 PDT Subject: NIST Explains Clipper "Review" (fwd) Message-ID: <9309241042.AA17103@bsu-cs.bsu.edu> In case you haven't heard: To: Cypherpunks Date: Thu, 23 Sep 1993 16:51:12 EST Subject: NIST Explains Clipper "Revi NIST Explains Clipper "Review" The National Institute of Standards and Technology (NIST) has clarified the role of five experts selected by the agency to evaluate the government's Clipper Chip proposal and the underlying SKIPJACK cryptographic algorithm. In a recent letter to the CPSR Washington Office, NIST asserts that the panel was not established to provide "advice or recommendations" to the government. Rather, according to NIST, the reason for convening the group was "to provide the opportunity for independent experts to satisfy themselves as to the strength and effectiveness of the algorithm in order to encourage widespread acceptance of it in the marketplace." NIST concludes that the panel's evaluation therefore falls outside the scope of the Federal Advisory Committee Act, which opens the work of advisory panels to public scrutiny. In response to CPSR's request for documents relevant to the panel's review, the agency reveals that NIST has no records which were made available to or prepared for the five experts for the purpose of enabling them to evaluate the Clipper Chip proposal. Any such records would be in the possession of the National Security Agency, where all activities related to the work of the experts were conducted. This disclosure provides further confirmation that NSA, and not NIST, is the driving force behind the Clipper proposal, despite NIST's public role as the "proposing" agency. The only NIST document released to CPSR is a copy of the invitation sent to the five experts who participated in the evaluation. That letter describes the "key escrow" system and states that the escrowed keys will be made available "only to authorized government officials under proper legal authorizations, usually a court order." This language -- "usually a court order" -- suggests that there will be instances in which the escrow keys will be provided to government agents without presentation of a judicial warrant. The government has never clearly defined what will constitute "legal authorization" under the Clipper system. David L. Sobel CPSR Legal Counsel From mjr at TIS.COM Fri Sep 24 06:52:37 1993 From: mjr at TIS.COM (mjr at TIS.COM) Date: Fri, 24 Sep 93 06:52:37 PDT Subject: NIST Explains Clipper "Review" In-Reply-To: <1838400006@igc.apc.org> Message-ID: <12104.9309241348@otter.TIS.COM> One thing that occurs to me: rather than arguing Clipper's technical merits, or whether or not it's Big Brother and therefore evil, we should be making the press aware of the fact that Clipper is going to cost major $$ for the taxpayers. This will be reflected in terms of increased cost on consumer electronics, and in the cost of administration of the key escrow system. Since both agencies for the escrow will be government, the taxpayers are going to bear the entire burden of the very complex (and presumably expensive) escrow management. Our CEO, Steve Walker, has asked how many court ordered wire taps are performed anually. Apparently, the number is very low (under 1,000) - we must question the cost effectiveness of a measure designed to protect wiretapping at a cost of hundreds of millions of dollars, when apparently wiretapping is not that important a tool in the arsenal of law enforcement. Recently, at the NCSC conference, a Mr. Brooks from NSA spoke on the Clipper panel, and stated proudly that they had been working hard on clipper for over 3 years. Unfortunately, NSA's budget is classified, so we'll never find out how much this B1-bomber of telecommunications has already cost the taxpayer, but we need to bring the potential expense involved to the attention of our various representatives. In a time when people are losing their jobs and government is trying desperately to cut costs, we must ask ourselves if it would be more cost effective to spend the hundreds of millions of dollars clipper will cost the taxpayer on hiring more police officers, or on social programs. I don't believe that our elected representatives or the non-technical press understand the issues behind key escrow. We need to make them understand that effectively clipper means that the consumer will pay more for certain forms of electronics, that the taxpayer will pay more for administering programs of questionable usefulness, and that the government is using covert budgets to subsidize an attempt to compete in the telecommunications business. Our elected representatives and the press understand $300 government toilet seats. Perhaps we need to come up with a nice name for clipper. Rather than calling it the "big brother chip" perhaps we should call it the "B1 bomber of data communications" or point out that it is really an implicit tax on telecommunications. mjr. [PS - these are my personal opinions] From smb at research.att.com Fri Sep 24 08:27:38 1993 From: smb at research.att.com (smb at research.att.com) Date: Fri, 24 Sep 93 08:27:38 PDT Subject: the public key minefield Message-ID: <9309241526.AA24310@toad.com> > derek at cs.wisc.edu (Derek Zahn) > >* in broad terms, what would I have to do to develop an > > algorithm that works from a user's perspective like > > p.k.c. (ie public/private keys, the central functional > > point of all the wonderful schemes based on pkc) but > > doesn't violate patents? L. Detweiler writes: > others have well addressed how patent issues are involved in this. b ut > this appears to be a simple technical question on one level. What do es > it take to come up with a good public key system? How about a poor public key system? What is the simplest public key system you can invent, if you didn't care that it is trivial to break? If the NSA can crack RSA, does that change the fact that it is a pkc? message=99 public_key= 1/3 private_key= 3 encrypted_message= message * public_key message= encrypted_message * private_key Would PKP reading of their patent claims cover this pkc? Seems overbr oad! No, because of the language in the patent which requires that it be infeasible to find the deciphering key from the enciphering key. Here's the claim, from patent 4218582, that covers all of public key cryptography: 1. In a method of communicating securely over an insecure communication channel of the type which communicates a message from a transmitter to a receiver, the improvement characterized by: providing random numbers at the receiver; generating from said random numbers a public enciphering key at the receiver; generating from said random numbers a secret deciphering key at the receiver such that the secret deciphering key is directly related to and computationally infeasible to generate from the public enciphering key; communicating the public enciphering key from the receiver to the transmitter; processing the message and the public enciphering key at the transmitter and generating an enciphered message by an enciphering transformation, such that the enciphering transformation is easy to effect but computationally infeasible to invert without the secret deciphering key; transmitting the enciphered message from the transmitter to the receiver; and processing the enciphered message and the secret deciphering key at the receiver to transform the enciphered message with the secret deciphering key to generate the message. From smb at research.att.com Fri Sep 24 08:28:37 1993 From: smb at research.att.com (smb at research.att.com) Date: Fri, 24 Sep 93 08:28:37 PDT Subject: Why RSA? Message-ID: <9309241524.AA24281@toad.com> Let me try to answer some of these questions by giving a broad overview of patent law. I'm not a lawyer, but I've spent a lot of time talking to lawyers about patents during the last several years, and about what they are and aren't. First of all, a patent is (theoretically) a contract between an inventor and society. In return for the inventor teaching everyone about the new idea, he or she gets a monopoly on use of that idea for a limited period (normally 17 years in the U.S.). Patents cover the right to build, make, import, or even *use* the protected idea. A patent is *not* a license to do something. Rather, it is the right to prevent others from doing it. Thus, if I invented the pencil, and you invented the eraser, neither of us could make a pencil+eraser without permission from the other. Patent infringement is not a crime; you cannot go to jail for it. It is a civil offense, and the patent holder has to sue you for infringing. You can get a patent for things that are new, useful, and non-obvious. All three criteria must be satisfied. Note specifically that a new use for an old idea is patentable. R, S, and A did not patent particular equations; rather, they patented certain specific uses for those equations. If you can find a new use for them, you're home free. (I and a colleague almost did that. We came up with a new application for them, and we felt that the security of our scheme would be strengthened tremendously by the work that's gone into RSA. However, our application was just different enough that I managed to crack it. Sigh. But better that I cracked it before publishing...) For our purposes, a patent consists of two major parts. The first is more or less a technical paper; this is what you're supposed to learn from. Some of the language is rather stylized, but for the most part it will be comprehensible to someone who understands the field. The second part is the ``claims''; these are written in very dense legalese, and are supposed to delimit exactly what's new. You infringe a patent if your activity includes all of the elements of any one claim. Writing good claims is at the heart of a patent attorney's skills. You want to claim as much as you possibly can, even if you think some of it is worthless -- but you have to make sure that what you claim doesn't include prior art. In the RSA patent, for example, almost every claim speaks of both encryption and decryption. The idea of mine that I alluded to involved encryption only; thus, it did not fall within the scope of all but one of the RSA claims. For various other reasons, it didn't fall within the scope of the other one. > All are patented in so far as one of the patents covers ALL public k ey > schemes. Some, like Rabin's scheme, have possible technical advantag es > over RSA. First, a note: "Rabin's scheme" is (as Perry said) the one provably linked to factoring (a major advance!) and I assume it's the one implemented in RPEM. According to the RIPEM FAQ, PKP squashed that development by claiming that their patents were broad enough to cover Rabin's scheme, and the effort was abandoned "for pragmatic reasons" (another example of how superior technology can be suppressed by monopolies). Well, Rabin's scheme has other problems as well, including the lack of an unambiguous decryption algorithm. You get a few answers, one of which will be correct. Under patent law, though, the ``superior'' technology hasn't been suppressed. Rather, Rabin would need a license from RSA (and Diffie-Hellman) to practice his invention. And he couldn't have come up with his idea unless RSA had been published. Now, I've looked a little further into the patent issue, and I remain kind of confused. I went to the library and read the four patents in question (but only made a hardcopy of the first chronologically). I found the documents difficult to understand (for legal rather than crypto-tech reasons). All four applications were made in 1977-1978, and the patents were granted variously from 1980-1984. The earliest one has Hellman, Diffie, and Merkle as inventors; the second just Hellman and Merkle. Both are assigned to Stanford University. It seems to me that one of these is the one that covers, broadly, public key cryptography -- presumably the earliest one (4,200,770), since it has all three major players as inventors and the language of the eight claims seems to be rather broad (though only the second patent, 4,218,582, has the phrase "public key" in its title). Patent 4,405,829, granted in 1983, is for the RSA algorithm [footnote: the RSA patent apparently celebrated its tenth birthday two days ago; was there a party?]. There is no overlap between this patent's inventors and assignees and the earlier more general patent. Here's a question for somebody in the know: if the earlier patents cover all public key cryptography and RSA is a public key system, isn't it in violation of the earlier broader patent? Does PKP pay license fees to Stanford, or were they granted exclusive rights by Stanford as well as MIT? As I explained above, a patent does not infringe per se. However, practicing RSA would indeed require a license from Stanford. But both Stanford and MIT assigned exclusive licensing rights to those patents to Public Key Partners, a deal which arguably violates the antitrust laws. (Down, libertarians, down. I know you don't believe in such things...) Anyway, patent 4200770 claims virtually all mechanisms for public key distribution or exchange systems. Exponential key exchange is the particular example given; it's claimed, too. Patent 4218582 claims all of public-key cryptography. The knapsack system was the particular system given; it was claimed, as well. I should note here -- to patent something, while you don't (as a rule) have to build it, you do have to show that it's buildable. If there's any doubt, the patent examiner can order you to produce one. This is used to deal with perpetual motion machines and the like. The concept of public key cryptography couldn't have been patented without a working example. And, while knapsack systems were subsequently cracked, at the time the patent was issued there were no (publicly) known attacks. Similarly, apparently a public-key scheme called Warlock has been granted patent protection. How is this possible if somebody else holds patents covering all of public key encryption? If I understand patents correctly (hah!) they last for 17 years from the time they are granted. This means that the earliest public key patent will expire in about 3.5 years. After that presumably there will be no restrictions on new public key systems. The RSA patent would expire in 2000. If somebody could clarify which patent is the "broad" public key patent, I'd appreciate it (even with them right in front of me, I can't tell)! My guess is that it would have to be either 4,200,770 or 4,218,582 -- if it's the latter, how did Merkle get squeezed out of inventorship? Have a look at "The first ten years of public key cryptography", Diffie, W., Proceedings of the IEEE 76:5, 1988, pp 560-577. Respondents to my initial questions pointed out that the patents may be over-broad and could be challenged on those grounds; given the history of how public key crypto was invented, it seems to me that it would be difficult to contend that the idea is obvious (Simmons says that the idea "stunned" the crypto community) -- but I'm no lawyer, and I'll leave that issue to those with more skill, brains, and money than me! There was some question of prior art published more than one year before the patent was filed. See "Multi-user cryptographic techniques", Diffie and Hellman, AFIPS Proceedings 45, pp109-112, June 8, 1976. The patent apparently contains some language explaing why that doesn't count, and in particular because there was no demonstration that it was even possible to build such a thing as a public key cryptosystem. From jazz at hal.com Fri Sep 24 08:37:37 1993 From: jazz at hal.com (Jason Zions) Date: Fri, 24 Sep 93 08:37:37 PDT Subject: P. Wayner on CSSPAB meeting Message-ID: <9309241531.AA13351@jazz.hal.com> Mr. "Hyperbole-R-Us" Detweiller said: >>A group of computer scientists from NIST came to discuss their plan >>for the Federal Criteria for secure systems and the new "Common >>Criteria" that may emerge. This is an updated version of the old >>Orange Book classification scheme of C2 and B1 and stuff like that. >>The scientists said the draft is being finished but it isn't ready >>for release. But now, they're working on "Something Better." This >>is a new plan to standardize the grading of secure systems with >>other countries and evolve a "Common Criteria." In general, the >>board groused about the fact that the public and industry have never >>been invited to give comments during the process. The summary >>of this talk is: "We might be able to tell you something someday." > >`other countries'? `Common Criteria'? holy cow, this is something *very >big* in the works. The U.S. can barely figure out its *own* >cryptographic policies, and imagine the sheer logistical nightmare of >trying to come to an agreement between the most isolated and imperious >agencies! It's a shame you understand so little of this. The "Federal Criteria" they're discussing are the Trusted Computer Security Evaluation Criteria, or TCSEC. This is also called the "Orange Book", since it was published in an orange cover. It's a purely-US DOD document that defines various levels of computer security - you remember, C2, B1, B3, all that stuff. It talks about Mandatory Access Controls, Discretionary Access Controls, Auditing, Authentication, etc. Cryptography as such is not addressed by the TCSEC. I believe the TCSEC discusses cryptographic authentication techniques in an abstract manner, but not even to the degree of naming any. The UK and other European countries have their equivalent to the TCSEC. The security levels have different names, and the included features differ slightly. The EC recognized that this difference in nomenclature and definitions would act as a barrier to free trade, so they began a program to harmonize these definitions. The "Common Criteria" would take this EC stuff beyond Europe into the US, allowing vendors of secure systems to get them rated once and sell them in a bunch of countries instead of building country-specific secure systems as they are required to do today. Another aspect of the Common Criteria is that they are expected to be a little more commercial in focus. The TCSEC and its counterparts were generally developed by the Defense organizations within their respective countries of origin; the focus of control and security reflects the needs of the developing organizations. Commercial users have been complaining for years that the TCSEC et al don't meet their needs in a useful and flexible manner; one desired goal for the Common Criteria is to meet this need. Cryptography is almost completely unrelated to the actual criteria themselves. Cryptography is one possible implementation mechanism for several of the capabilities required by the TCSEC and its successors; it is not the only such mechanism. The TCSEC does not prescribe or proscribe implementation technology. > I suspect GCHQ (Britain's NSA) would be involved in this at >least. (There is a very cozy relationship between NSA and GCHQ that >Kahn was harassed for revealing in _CodeBreakers_.)What other agencies? The TCSEC and Common Criteria are really being developed by various Defense agencies; in the US, NIST is also involved, as I suppose DIN, BSI, AFNOR, etc. are. NSA is uninterested in making systems secure; their job is to break them anyway. Since the TCSEC doesn't specify mechanism, it's at too abstract a level for NSA to tamper with. There are no boogie men from the Spy House involved here, at least in the US. You can sleep well again. Jason Zions From smb at research.att.com Fri Sep 24 08:40:38 1993 From: smb at research.att.com (smb at research.att.com) Date: Fri, 24 Sep 93 08:40:38 PDT Subject: on the `R' in `RSA' Message-ID: <9309241539.AA24457@toad.com> I'd also be interested in hearing of any other accounts that match my own passion for the subject :) Also, if others have any educated opinion, evidence, or theories of whether public key crypto was *undiscovered* by the NSA prior to the publication of Diffie and Hellman and RSA, I'd read them with great fascination. NSA claims to have developed public-key cryptography about ten years before the public discovery. See @article{Diffie88, author = {Whitfield Diffie}, journal = {Proceedings of the IEEE}, month = {May}, number = {5}, pages = {560--577}, title = {The First Ten Years of Public Key Cryptography}, volume = {76}, year = {1988} } a paper I hightly recommend to this entire list. From emv at mail.msen.com Fri Sep 24 10:17:39 1993 From: emv at mail.msen.com (emv at mail.msen.com) Date: Fri, 24 Sep 93 10:17:39 PDT Subject: Beavis and Butthead on cryptography Message-ID: FYI. --Ed To: emv at mail.msen.com Cc: tritan at MIT.EDU, online-world at media.mit.edu, privacy at media.mit.edu Subject: Re: pgp gets hit by Feds Date: Fri, 24 Sep 93 12:39:27 -0400 From: castillo at media.mit.edu If this PGP case ever goes to trial it might just end once and for all the idiocy of the US gov't trying to prevent the rest of the world from reading what's already been published. Butthead: uh huh...uh huh...say Beevis, do you think they have computers in Europe? Beevis: huh huh...huh huh...Nope, they don't have phones either...huh huh Butthead: So, uh huh...this PGP thing is gonna stay in America? Beevis: uh huh...yeah, that's right...uh huh...right here...huh huh Butthead: Encryption is cool. Beevis: Yeah. ------- End of Forwarded Message From sameer at netcom.com Fri Sep 24 11:40:39 1993 From: sameer at netcom.com (Sameer Parekh) Date: Fri, 24 Sep 93 11:40:39 PDT Subject: cs60a-qu@cory.eecs.berkeley PGP back in operation Message-ID: <9309241837.AA14986@netcom.netcom.com> Thanks for the help with PGP. My cory remailer is again working with PGP encryption. -- Sameer sameer at netcom.com From newsham at wiliki.eng.hawaii.edu Fri Sep 24 11:42:40 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Fri, 24 Sep 93 11:42:40 PDT Subject: P. Wayner on CSSPAB meeting In-Reply-To: <9309241531.AA13351@jazz.hal.com> Message-ID: <9309241842.AA27176@toad.com> > The TCSEC and Common Criteria are really being developed by various Defense > agencies; in the US, NIST is also involved, as I suppose DIN, BSI, AFNOR, > etc. are. NSA is uninterested in making systems secure; their job is to > break them anyway. Since the TCSEC doesn't specify mechanism, it's at too > abstract a level for NSA to tamper with. > > There are no boogie men from the Spy House involved here, at least in the > US. You can sleep well again. I wouldnt exactly say that (although I doubt the NSA's involvement here is shady). The NCSC which came out with the original Trusted Criterion (rainbow books including the orange book) is stationed at Fort Meade MD. (oddly enough right by NSA). If you get information sent to you from the NCSC sometimes the return address will say NSA on it instead of NCSC. If you read through the schedule of any of the conferences they put on you will see a good percentage of people with NSA next to their names. The NSA *does* have alot of interests in trusted systems and making systems secure. They are the national *Security* Agency. While half of the people at the NSA are working on how to break other peoples security there is still a good fraction of them learning how to make their own systems safe. > Jason Zions From derek at cs.wisc.edu Fri Sep 24 11:50:39 1993 From: derek at cs.wisc.edu (Derek Zahn) Date: Fri, 24 Sep 93 11:50:39 PDT Subject: Patents Message-ID: <9309241847.AA28116@balder.cs.wisc.edu> Cypherpunks: Too often in email fora, when a substantive discussion results in the presentation of interesting material, no effort is made to integrate the result into a form that will be useful beyond the heat of the exchange. For this reason, I will impose once more upon the bandwidth of Cypherpunks with a rewrite of my previous mini-essay. Because of the effort and generosity of many correspondents, I hope that some of the clueless parts have had clues plugged in. Rather than equivocating, which is my usual practice when not entirely certain of what I'm saying, I state some "facts" quite plainly here because equivocation is kind of annoying to everybody. If anybody notices that I'm "full of it" in some way, please let me know... I have no desire to mislead or cause confusion. Special thanks to: E. Carp L. Detweiler P. Metzger smb at research.att.com MOTIVATION: Starting with a premise that widespread use of Public-Key Cryptography (PKC) would be in some sense a Good Thing (and for our purposes here ignoring the interesting and spirited reasons for *why* PKC is so cool), newbie Cypherpunks may well wonder how this can be achieved. My purpose here is not to complain about restrictions or wonder about alternate worlds without those restrictions; rather it's an attempt to assess what the restrictions are and what their practical implications are. The important fact of life in this area is that PKC has been granted patent protection and is proprietary technology. Exclusive licensing rights to PKC and its dominant embodiment, the RSA algorithm, have been assigned to Public Key Partners (PKP). PATENT PROTECTION: smb at research.att.com explained patents (only excerpts are quoted here): > ... a patent is (theoretically) a contract between an inventor > and society. In return for the inventor teaching everyone about the > new idea, he or she gets a monopoly on use of that idea for a limited > period (normally 17 years in the U.S.). > Patents cover the right to build, make, import, or even *use* the > protected idea. ... A patent is *not* a license to do something. > Rather, it is the right to prevent others from doing it. > For our purposes, a patent consists of two major parts. The first is > more or less a technical paper; this is what you're supposed to learn > from. ... The second part is the ``claims''; these are written in very dense > legalese, and are supposed to delimit exactly what's new. You infringe > a patent if your activity includes all of the elements of any one > claim. ... you have to make sure that what your claim doesn't include > prior art. There are four patents of primary interest (I mention three because I'm not certain what 4,424,414 [1984] is all about): 4,200,770, granted 1980. This patent (smb again:) " claims virtually all mechanisms for public key distribution or exchange systems. Exponential key exchange is the particular example given; it's claimed, too." This patent has Diffie, Hellman, and Merkle as inventors. Diffie and Hellman working together, and Merkle working independently, came up with the ideas behind PKC. The patent was assigned to Stanford University. Since with PKC keys can be broadcast without requiring a secure channel, it offers obvious advantages for key distribution. 4,218,582, granted 1980. It (smb:) "claims all of public-key cryptography. The knapsack system was the particular system given; it was claimed, as well." Hellman and Merkle are the inventors on this patent, also assigned to Stanford. From reading Diffie's "The First Ten Years of Public Key Cryptography," I get the impression that Diffie was not on this patent because Hellman and Merkle together devised the "trapdoor knapsack" that was the particular system illustrating PKC. At some financial cost to Merkle in lost bets, that particular PKC system was broken, but that is only a historical footnote. 4,405,829, granted 1983. This patent is for the RSA algorithm, and has Rivest, Shamir, and Adleman as inventors. This patent was assigned to MIT. Diffie calls RSA "the single most spectacular contribution to public key cryptography" and it is an un-"broken" complete public key cryptosystem. RSA is the overwhelmingly dominant PKC system. The difficulty of breaking RSA has not been proven equal to the difficulty of factoring the product of two large prime numbers, which would be desirable because it would preclude some cracking scheme coming in from nowhere (we'll say that factoring is "somewhere" because it's commonly studied). Rabin has come up with a RSA variant that is equivalent to factoring, but has other technical problems. IMPLICATIONS Because PKP has been assigned all licensing rights to these patents, which cover all of PKC to one extent or another, we are not at present free to code up and sell PKC tools without licensing the technology from PKP -- at least not without risk of a lawsuit. Some people believe that one or more of the patents are invalid in some way. A patent must be for something new, useful, and non-obvious. Given that PKC is useful, the other two criteria could be challenged: * perhaps the ideas could be described as obvious * perhaps prior art could be demonstrated, so that the patented inventions aren't really "new". Such an effort would cost a great deal of money and is uncertain of success. Other efforts to get around the PKP monopoly are possible. One idea would be to claim an "experimental use exemption", an unclear way of legitimately ignoring a patent for personal experimental use (see the comp.patents FAQ for more information on this and other patent issues). Another idea is simply to ignore the patent. PKP would have to sue the infringer, an expensive and time-consuming process and probably not worthwhile for some small infringements -- but it's probably very unwise to try making any money this way! Another legal route would be to claim that the assignment of rights by MIT and Stanford to PKP violate anti-trust laws. Users of the wonderful "underground" program PGP presumably are doing so with the "experimental use" idea or the "ignore the patent" idea in mind. While this has caused some friction, it appears not to be very dangerous for individual users. The final approach to an end-run around the patents is to wait. The broad PKC patents expire in less than four years, which should allow non-RSA PKC schemes to be developed and sold without restriction. However, it is important not to underestimate the difficulties of doing this. Solid efficient PKC schemes are most definitely not trivial to devise, and an extended period of evaluation by professional cryptologists is probably required in order to convince users that the scheme offers good security. The RSA patent expires in 2000. The straightforward approach, and the only practical one for small-time entrepreneurs wanting to develop PKC products now, is to strike a deal with PKP for the use of RSA (as ViaCrypt has done for the "legit" version of PGP). It seems that the designers of Internet Privacy Enhanced Mail (PEM) agreed with this assessment, as they took the unusual step of including proprietary RSA in their standard. For their part, in RFC 1170, PKP states: "We assure the interested parties that Public Key Partners will comply with all of the policies of ANSI and the IEEE concerning the availability of licenses to practice this art. Specifically, in support of any RSA signature standard which may be adopted, Public Key Partners hereby gives its assurance that licenses to practice RSA signatures will be available under reasonable terms and conditions on a non-discriminatory basis." The exact meaning of "reasonable terms and conditions" is not clear. For evidence we can look at the ViaCrypt product, which is apparently available for less than $50 in quantity. Since it includes the extensive facilities of PGP, as well as support overhead, in addition to the cost of the RSA license. Standards (for example, PGP and PEM) are key to widespread use of PKC. It appears unlikely that standards will go to something besides RSA any time in the near future. The final option is to invent some new revolutionary technique, to amaze and delight Cypherpunks everywhere. Please do. Good luck. REFERENCES sci.crypt FAQ: information about PKC comp.patents FAQ: information about patents RIPEM FAQ: stuff about PKP stopping developement of an implementation of Rabin's scheme Diffie, W.: "The First Ten Years of Public Key Cryptography", chapter 3 of: G. Simmons (ed.), Contemporary Cryptology: the Science of Information Integrity. IEEE press, 1991. which might be the same as: "The first ten years of public key cryptography", Diffie, W., Proceedings of the IEEE 76:5, 1988, pp 560-577. Cypherpunks list archive (there is one, right?): many interesting comments, often highly-clued. derek From cme at ellisun.sw.stratus.com Fri Sep 24 12:17:41 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Fri, 24 Sep 93 12:17:41 PDT Subject: NIST's call for comments Message-ID: <9309241911.AA16528@ellisun.sw.stratus.com> cpsr.org's archive of comments is looking mighty thin, this close to the deadline. Is no one writing to NIST? ..or just not copying CPSR? /cpsr/crypto/clipper/call-for-comments: total 64 -rw-r--r-- 1 cpsr 1000 2574 Sep 24 16:09 campbell_comments.txt -rw-r--r-- 1 cpsr 1000 3221 Aug 24 21:46 denn_comments.txt -rw-r--r-- 1 cpsr 1000 22895 Sep 24 16:10 ellison_comments_may_93.txt -rw-r--r-- 1 cpsr 1000 6079 Aug 19 13:32 howland-comments -rw-r--r-- 1 cpsr 1000 2286 Aug 21 15:08 mcallister-comments -rw-r--r-- 1 cpsr 1000 1955 Aug 24 21:54 nate_comments.txt -rw-r--r-- 1 cpsr 1000 21934 Aug 19 13:33 notice-for-comments -rw-r--r-- 1 cpsr 1000 1536 Sep 24 16:10 oram-comments.txt -rw-r--r-- 1 cpsr 1000 1295 Sep 24 16:11 riordan-comments.txt ..and I've just mailed them my comments for this round, yet to show up in this directory. - Carl From peb at PROCASE.COM Fri Sep 24 13:30:40 1993 From: peb at PROCASE.COM (Paul Baclace) Date: Fri, 24 Sep 93 13:30:40 PDT Subject: NIST Explains Clipper "Review" Message-ID: <9309242026.AA02558@banff.procase.com> An economic analysis would indeed be useful, especially if it led to poll-type question like "Would you be willing to pay $100 extra for a cellular phone to get secure communications that allowed government wiretaps?" Or as a sound bite: "At $100M+ a year, consumers and businesses are subsidizing government wiretapping at the minimum cost of $100,000 for each wiretap." At that price, the government might as well give $100k to the suspects under the condition that they stop doing whatever is considered illegal. ;^) Paul E. Baclace peb at procase.com From wcs at anchor.ho.att.com Fri Sep 24 14:07:43 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Fri, 24 Sep 93 14:07:43 PDT Subject: NIST Comment Deadline - FAX NUMBER Message-ID: <9309241727.AA01768@anchor.ho.att.com> I called the person below; the person who answered the phone said that the director is James Burrows, and his fax is 1-301-948-1784. Branstad's fax is 948-1233. ------------- ADDRESSES: Written comments concerning the proposed standard should be sent to: Director, Computer Systems Laboratory, ATTN: Proposed FIPS for Escrowed Encryption Standard, Technology Building, room B-154, National Institute of Standards and Technology, Gaithersburg, MD 20899. FOR FURTHER INFORMATION CONTACT: Dr. Dennis Branstad, National Institute of Standards and Technology, Gaithersburg, MD 20899, telephone (301) 975-2913. From ssimpson at eff.org Fri Sep 24 14:40:39 1993 From: ssimpson at eff.org (Sarah L Simpson) Date: Fri, 24 Sep 93 14:40:39 PDT Subject: ACTIVIST ALERT Message-ID: <199309242135.AA11095@eff.org> ACTIVIST ALERT - The Government Is Messin' With Your Privacy! Computer Professionals for Social Responsibility (CPSR) posted the following call for comments to the Net. As the deadline for comments on the proposed Escrow Encryption Standard (CLIPPER/SKIPJACK) looms near, EFF wholeheartedly supports CPSR's work to bring attention to the proposal and encourages everyone who reads this to respond with comments. We have added a sample letter and additional information at the end of the CPSR post. ==================== text of CPSR post ==================== Call for Clipper Comments The National Institute of Standards and Technology (NIST) has issued a request for public comments on its proposal to establish the "Skipjack" key-escrow system as a Federal Information Processing Standard (FIPS). The deadline for the submission of comments is September 28, 1993. The full text of the NIST notice follows. CPSR is urging all interested individuals and organizations to express their views on the proposal and to submit comments directly to NIST. Comments need not be lengthy or very detailed; all thoughtful statements addressing a particular concern will likely contribute to NIST's evaluation of the key-escrow proposal. The following points could be raised about the NIST proposal (additional materials on Clipper and the key escrow proposal may be found at the CPSR ftp site, cpsr.org): * The potential risks of the proposal have not been assessed and many questions about the implementation remain unanswered. The NIST notice states that the current proposal "does not include identification of key escrow agents who will hold the keys for the key escrow microcircuits or the procedures for access to the keys." The key escrow configuration may also create a dangerous vulnerability in a communications network. The risks of misuse of this feature should be weighed against any perceived benefit. * The classification of the Skipjack algorithm as a "national security" matter is inappropriate for technology that will be used primarily in civilian and commercial applications. Classification of technical information also limits the computing community's ability to evaluate fully the proposal and the general public's right to know about the activities of government. * The proposal was not developed in response to a public concern or a business request. It was put forward by the National Security Agency and the Federal Bureau of Investigation so that these two agencies could continue surveillance of electronic communications. It has not been established that is necessary for crime prevention. The number of arrests resulting from wiretaps has remained essentially unchanged since the federal wiretap law was enacted in 1968. * The NIST proposal states that the escrow agents will provide the key components to a government agency that "properly demonstrates legal authorization to conduct electronic surveillance of communications which are encrypted." The crucial term "legal authorization" has not been defined. The vagueness of the term "legal authorization" leaves open the possibility that court- issued warrants may not be required in some circumstances. This issue must be squarely addressed and clarified. * Adoption of the proposed key escrow standard may have an adverse impact upon the ability of U.S. manufacturers to market cryptographic products abroad. It is unlikely that non-U.S. users would purchase communication security products to which the U.S. government holds keys. Comments on the NIST proposal should be sent to: Director, Computer Systems Laboratory ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Submissions must be received by September 28, 1993. CPSR has asked NIST that provisions be made to allow for electronic submission of comments. Please also send copies of your comments on the key escrow proposal to CPSR for inclusion in the CPSR Internet Library, our ftp site. Copies should be sent to . =================== end of CPSR post =================== EFF joins with CPSR in urging you to send your comments to NIST as soon as possible. To help get your creative juices flowing, we're attaching a sample letter. You will probably want to personalize any letter you actually send. And because time is so tight, EFF has set up an Internet address where you can send your electronic comments in lieu of mailing them through the U.S. Postal Service. Send your letters to: cryptnow at eff.org We will be printing out all letters and hand-delivering them before the deadline, so please make sure to send us any letter you want included no later than 8pm on Monday, September 27. If you would like additional background materials, you can browse the pub/EFF/crypto area of our anonymous ftp site (ftp.eff.org). The original solicitation of comments can be found there and is called NIST-escrow-proposal. DO NOT WAIT TO WRITE YOUR COMMENTS! TIME IS SHORT! ====================== <> <> <> <> <> National Institute for Standards and Technology (NIST) ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Mr. Director: I am writing to oppose the Proposed Federal Information Processing Standard (FIPS) for and Escrowed Encryption Standard, docket # 930659-3159. Encryption is vital for the protection of individual privacy in the Information Age. As more and more personal information flows around electronic networks, we all need strong encryption to safeguard information from unwanted intrusion NIST should not be moving forward with technical standards specification until critical policy decisions are made. These policy issues include: o Continued Legal Use of All Forms of Encryption: When the Clinton Administration announced the Clipper Chip, it assured the public that this would be a purely voluntary system. We must have legal guarantees that Clipper isn't the first step toward prohibition against un-escrowed encryption. o Legal Rights of Escrow Users: If people choose to deposit their keys with the government or any other escrow agent, they must have some legal recourse in the event that those keys are improperly released. The most recent draft of the escrow procedures specifically states, however: "These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired." Leaving users with no recourse will discourage use of the system and is a tacit acceptance of unscrupulous government behavior. o Open Standards: People won't use encryption unless they trust it. Secret standards such as Clipper cannot be evaluated by independent experts and do not deserve the public trust. In addition, the current proposed technical standard is incomplete. It should not be approved until futher comment on the complete proposal is possible o Operating Procedures Unclear: The full operating procedures for the escrow agents has yet to be issued. Public comment must be sought on the complete procedures, not just the outline presented in the draft FIPS. Even the government-selected algorithm review group has declared that it needs more information on the escrow process. o Identity of Escrow Agents: The identity of one or both of the escrow agents has not been firmly established. o Algorithm Classified: Asking for comments on an algorithm that is classified makes a mockery of citizen participation in government decision-making. NIST will be involved in making many critical decisions regarding the National Information Infrastructure. The next time NIST solicits public comments, it should be ready to accept reply by electronic mail in addition to paper-based media. Sincerely, <> <> ****************************** Sarah L. Simpson Membership Coordinator Electronic Frontier Foundation 1001 G Street, NW Suite 950 East Washington, DC 20001 202/347-5400 tel 202/393-5509 fax From baumbach at atmel.com Fri Sep 24 16:07:46 1993 From: baumbach at atmel.com (Peter Baumbach) Date: Fri, 24 Sep 93 16:07:46 PDT Subject: the public key minefield Message-ID: <9309242227.AA11743@bass.chp.atmel.com> [my silly public key example deleted] > No, because of the language in the patent which requires that it be > infeasible to find the deciphering key from the enciphering key. Here's > the claim, from patent 4218582, that covers all of public key cryptography: > > 1. In a method of communicating securely over an insecure communication > channel of the type which communicates a message from a transmitter to > a receiver, the improvement characterized by: > providing random numbers at the receiver; > generating from said random numbers a public enciphering key at the > receiver; > generating from said random numbers a secret deciphering key at the > receiver such that the secret deciphering key is directly related to > and computationally infeasible to generate from the public enciphering > key; > communicating the public enciphering key from the receiver to the > transmitter; > processing the message and the public enciphering key at the > transmitter and generating an enciphered message by an enciphering > transformation, such that the enciphering transformation is easy to > effect but computationally infeasible to invert without the secret > deciphering key; > transmitting the enciphered message from the transmitter to the > receiver; and > processing the enciphered message and the secret deciphering key at > the receiver to transform the enciphered message with the secret > deciphering key to generate the message. Doesn't a patent have to have enough information for a person skilled in the art to construct a prototype? I publish for the first time here my invention. I will patent it within a years time. Striped Vegetables ---- This isn't enough for anyone to do anything. If I were more specific, I might have something patentable, but then by claims wouldn't be as broad. If you figured out how to make an anti-gravity device. That device would be patentable. The concept of "anti-gravity" device is not patentable. If I could duplicate the effect of your anti-gravity device without using any of the same novel mechanisms. My device would be separately patentable. Peter Baumbach baumbach at atmel.com From charliemerritt at BIX.com Fri Sep 24 18:50:41 1993 From: charliemerritt at BIX.com (charliemerritt at BIX.com) Date: Fri, 24 Sep 93 18:50:41 PDT Subject: QPK SOURCE ONLINE Message-ID: <9309242146.memo.17966@BIX.com> Cypherpunks: I now have David Colston's [5542837 at mcimail.com] source code for "CALL SECURITY". I also have the IBM PC executables. CALL SECURITY is an implementation of David's QPK (quick public key) algorithm. If you are on BIX I can E-mail to you with binary attachments, please specify which files. I am not sure how to get this to an FTP, BIX doesn't have FTP posting yet. I know it is done from BIX, help is welcome. So, I will make this software available on my PC this *WEEKEND ONLY* The purpose is to S P R E A D this stuff around. Please upload to an FTP, BBS or what-have-you. SEC_SRC.EXE 64668 bytes self extracting source code SEC_RUN.EXE 278542 bytes self extracting RUN TIME EXECUTABLES (PC) 2400 baud only 8n1 zmodem, ymodem, xmodem You will connect with Telix "qdhost" script. Enter full name (chrs (space) chrs) please be truthful Password is QPK (in caps) Phone (501) 839-8579 Voice (501) 839-3543 I do not run a BBS, forget these numbers after this week end United States calls only, honor system, please. email charliemerritt at bix.com From MIKEINGLE at delphi.com Fri Sep 24 20:24:28 1993 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Fri, 24 Sep 93 20:24:28 PDT Subject: Clipper takes another hit... Message-ID: <01H3CEGQ0YCI987NKX@delphi.com> Looks like the Clipper fan club is growing by leaps and bounds... PC/Computing, October 1993 Page 468 (opposite inside back cover). Note: _abc_ indicates italics. Illustration: several computers with keyholes in the screens. Clinton's smiling face rises from the White House, as a long arm reaches out with a key... ----------------------------------------------------------------- Penn Jillette Subterranean Clipper Chip Blues "Phone's tapped anyway." So do it for Dylan and for Jefferson (Airplane, Starship, and Thomas). I'VE NEVER HAD a sip of alcohol, nor any recreational drugs (not one puff to uninhale), but, being 38 years old, I feel I was part of the hippie culture. I was young and rural in the sixties, but my formative years were spent listening to music created by people who chased the muse down many chemical alleys. Top 40 radio blared that the government wasn't to be trusted. Dylan sang "Phone's tapped anyway," and his inflection said that was a bad thing. But even as I was sucking up the culture, my skeptical side said that all the "Tin soldiers and Nixon's coming..." stuff might be a little dramatic. Romanticizing living outside the law, coupled with the physiological effect of drugs, might be making these artists a little paranoid, a little nutty. The joke was kinda on me. Paranoid or not, John Lennon _was_ on Nixon and FBI hate lists, the Vietnam War probably _was_ a very bad idea, and the Watergate break-in and subsequent cover-up really _did_ happen. No government is to be trusted. I could have gotten a stronger lesson from the founding fathers, but they didn't have any records out. "You say you want a revolution?"..."The government that governs least governs best." Clinton is younger than any Rolling Stone (unless they replace Bill Wyman with a new bass player from his ex-wife's generation). It would seem that Bill _Jefferson_ Clinton would share the mistrust of Big Brother that we tapped our collective foot to. But remember, he's not Bob Dylan and Neil Young - he's Kenny G and Fleetwood Mac. Watch him. Willy picked up Bush's evil encryption Clipper Chip fascist football and ran with it ("Meet the new boss - same as the old boss"). The Clipper Chip is supposed to give us more privacy, which we need. An ex-friend of mine taped Madonna talking to her business manager on her cordless phone, and some punk ("punk" in the prison sense) broke into my Internet account and read my mail. The Clipper Chip, which was designed by government engineers, would be used to scramble and decode information so that only the addressee could read it. The government would sell this chip below market value (some people believe they'd be getting something for nothing; some people believe Elvis put syringes in Pepsi), and we'd all have cheap privacy. Oh, by the way ("The large print giveth, the small print taketh away"), the government would keep all the keys so they could eavesdrop on might-be-bad-guys (with a subpoena, of course). _What?!_ The antl-Clipper Chip people sent me megs and megs of reasons why the Clipper Chip sucks (the information on how it works is kept secret, so private scientists wouldn't be able to check for mistakes; trade with other countries would be difficult; how safe could the codes be kept?; and so on). Big cheese computer people yapped against it, and it got shot down the first time around on the legislation front. On the tech front, there is a great cypherpunk ("punk" in the rock and roll sense) alternative called Pretty Good Privacy, which is nongovernment and free. One of my math-hip friends explained public-key encryption to me, and it's pretty thinking; I'll try to explain it in a future column. There was even talk of making private encryption illegal (an evil idea, pure and simple). The more research I did, the simpler it got. You have inalienable rights including life, liberty, and the pursuit of happiness. That's it. We have a right to communicate with anyone we choose without anyone listening in. The government works for us. Power to the people. ----------------------------------------------------------------- Wow. One of the better anti-Clipper flames I've seen so far. Simple and to the point. Repost this one everywhere. Technical question: from what I've read, Clipper is only a single- key system, basically an 80-bit super-DES. So when you hit the SECURE button on your AT&T ClipperPhone, how do the phones exchange session keys? DH exchange or something similar? Is this implemented in the Clipper chip itself, or in external hardware? Is the format standardized? If not, there will be plenty of interoperability problems with the first generation of phones. For that matter, there will probably be problems even if it is standardized. Will it work over a standard phone line? If so, the phone must be using data compression and a 14.4 modem or something. They'd have to use forward error correction, too, because a 1-bit error would cause, upon decryption, at least an 8-byte error burst. That's a very noticeable click at 6-8KHz sampling rate. I haven't been able to get any details. I called Mykotronx and they told me that the app notes weren't ready yet, and offered to put me on a waiting list for them. From tcmay at netcom.com Sat Sep 25 00:35:48 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 25 Sep 93 00:35:48 PDT Subject: Contributions to Zimmermann--Where?? Message-ID: <9309250733.AA09491@netcom5.netcom.com> I'm preparing to write out a check for the Phil Zimmermann defense fund (lawyers, fees, even in advance of an indictment, and hopefully to head one off), but I seem to have lost the address of the lawyers--this was in a posting in the last couple of days here. (I also looked in various threads in sci.crypt, talk.politics.crypto, etc., but I can't seem to find it.) So, I'd appreciate it if someone could send it to me, or, even better, post it again on the List....sort of a reminder that this case means a lot to our future. If Phil--who appears to be the main target, never mind that the _document subpoena_ was not directed at him this time around--is successfully indicted, sent to trial, etc., then this will have a chilling effect on others. I'll have more to say about this after I've actually put my check in the mail. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From bart at netcom.com Sat Sep 25 08:40:49 1993 From: bart at netcom.com (Harry Bartholomew) Date: Sat, 25 Sep 93 08:40:49 PDT Subject: Phil Zimmermans's statement (reposted) Message-ID: <9309251540.AA27069@netcom5.netcom.com> Date--Sun, 19 Sep 1993 13:38:44 -0500 From--Philip Zimmermann <prz at columbine.cgd.ucar.edu> Subject--Zimmermann statement on PGP investigation Some of you may have received my Internet message of a couple of days ago about the ongoing U.S. Customs investigation of the exportation of PGP, which has now progressed to the level of Federal Grand Jury subpoenas. This earlier message was intended by me for distribution to a very small group of friends who previously communicated their concern about me and the investigation and asked to be kept informed. I did not send the message to anyone outside this group. Unfortunately, I did not adequately assert my desire that the message not be further disseminated. It appears that the message has gone completely public. This was not my intention. My lawyer, Phil Dubois, has been in touch with the Assistant U.S. Attorney (William Keane) assigned to the investigation. We have no reason to believe that Mr. Keane is anything other than a professional and reasonable person. He made it clear that no decision has been made regarding any prosecution of anyone for any offense in this matter. Such decisions will not be made for some time, perhaps several months. Mr. Keane also made clear his willingness to listen to us (me and my lawyer) before making any decision. It appears that both Mr. Keane's mind and the lines of communication are open. My fear is that public dissemination of my message will close the lines of communication and put Mr. Keane into an irretrievably adversarial position. Such a result would not serve any of our interests. My lawyer tells me that nothing irritates a prosecutor more than being the subject of what he perceives to be an orchestrated publicity campaign. He also tells me that his nightmares involve FOAs (Friends Of the Accused), invariably people with good intentions, doing things on their own. I understand that the issues involved in this investigation are of the greatest importance and transcend my personal interests. Even so, I would rather not turn an investigation into a full-scale federal prosecution. I ask that everyone keep in mind that the government's resources are limitless and that mine are not. Speaking of resources, many of you have offered help, and I am grateful. Those wishing to contribute financially or otherwise should contact either me or Philip L. Dubois, Esq., at dubois at csn.org or by phone at 303-444-3885 or by mail at 2305 Broadway, Boulder, CO, 80304. Mr. Dubois has just got on the Internet and is still learning how to use it. Donated funds will be kept in a trust account, and all contributions will be accounted for. If this whole thing somehow goes away with money left in the account, the balance will be refunded to contributors in proportion to the amounts of their contributions. This message can be widely circulated on public forums. Philip Zimmermann prz at acm.org 303 541-0140 ------------------------------ From nate at VIS.ColoState.EDU Sat Sep 25 11:20:52 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Sat, 25 Sep 93 11:20:52 PDT Subject: a picture of the Clipper? Message-ID: <9309251817.AA06585@monet.VIS.ColoState.EDU> I seem to remember there being a picture of the clipper chip in Popular Science or something.... does anyone remember where this picture is? -nate -- +-------------------------------------------------------------------- | Nate Sammons email: nate at VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate at monet.VIS.ColoState.Edu for my PGP key | #include <std.disclaimer> | Always remember "Brazil" +----------------------+ From upham at cs.ubc.ca Sat Sep 25 11:55:51 1993 From: upham at cs.ubc.ca (Derek Upham) Date: Sat, 25 Sep 93 11:55:51 PDT Subject: The "mpack" MIME encoder has just been released. Message-ID: <199309251855.AA22173@grolsch.cs.ubc.ca> The newsgroup comp.sources.reviewed has just released the sources to "mpack", a utility for encoding binary files into a MIME-compliant format, then mailing them to recepients or posting them to a newsgroup. "munpack", a utility for decoding the files, is also included. The package is supposed to work on MS-DOS and MacOS systems (and it's quite small), so people playing with PGP might be able to get some use out of it. Derek (the other other Derek) Derek Lynn Upham University of British Columbia upham at cs.ubc.ca Computer Science Department ============================================================================= "Ha! Your Leaping Tiger Kung Fu is no match for my Frightened Piglet Style!" From zeek at bongo.cc.utexas.edu Sat Sep 25 12:55:53 1993 From: zeek at bongo.cc.utexas.edu (Zeek) Date: Sat, 25 Sep 93 12:55:53 PDT Subject: Help Needed: PGP SIGNED MESSAGE Message-ID: <199309251952.AA03277@bongo.cc.utexas.edu> {{ Please excuse the interruption. I'm having problems signing a text message with my secret key and creating output that leaves the text message as is but with an ascii signature at the bottom. Or rather, I don't want the message encrypted, I just want the nifty sig attached and email-able. {{ I've done this before using some combination of -sat or something similar but I have since forgotten. This is a rather embarrassing question, I know it has to be a simple switch in the syntax but I spent 2 hours last night and 1 hour this morning trying to figure the damn thing out... learned a few interesting things along the way. Any help would be greatly appreciated. Please reply to me rather than the list. Thank you, -z (kevink) From nowhere at bsu-cs.bsu.edu Sat Sep 25 14:30:53 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Sat, 25 Sep 93 14:30:53 PDT Subject: Clipper and Crayolas Message-ID: <9309252132.AA27777@bsu-cs.bsu.edu> On Sat, 25 Sep 1993 12:17:32 -0700 (MDT), <uunet!VIS.ColoState.EDU!nate> wrote - > I seem to remember there being a picture of the clipper chip > in Popular Science or something.... does anyone remember > where this picture is? I know this is not what you're looking for, but I'm in a very strange mood today: Date: Mon, 19 Apr 93 9:21:53 EDT Organization: FIRST, The Forum of Incident Response & Security Teams Subject: Slide presented at White House briefing on Clipper Chip Note: The following material was handed out a press briefing on the Clipper Chip on 4/16. Chip Operation Microchip User's Message +----------------------+ ------------------> | | 1. Message encrypted | Encryption Algorithm | with user's key | | | Serial # | 2. User's key encrypted | |--> with chip unique key | Chip Unique Key | User's Encryption | | 3. Serial # encrypted Key | Chip Family Key | with chip family key ------------------> | | | | +----------------------+ For Law Enforcement to Read a Suspect's Message 1. Need to obtain court authorized warrant to tap the suspect's telephone. 2. Record encrypted message 3. Use chip family key to decrypt chip serial number 4. Take this serial number *and* court order to custodians of disks A and B 5. Add the A and B components for that serial number = the chip unique key for the suspect user 6. Use this key to decrypt the user's message key for this recorded message 7. Finally, use this message key to decrypt the recorded message. From zeek at bongo.cc.utexas.edu Sat Sep 25 15:25:53 1993 From: zeek at bongo.cc.utexas.edu (Zeek) Date: Sat, 25 Sep 93 15:25:53 PDT Subject: Thanx 4 the help! (PGP SIGNED MESSAGE) Message-ID: <199309252224.AA11815@bongo.cc.utexas.edu> Wait!! Ok, I've got it! "pgp -sta +clearsig=on <file>" ! Big thanks to those of you that refreshed my memory. bye. -z (kevink) From bradleyr at ucsu.Colorado.EDU Sat Sep 25 17:35:53 1993 From: bradleyr at ucsu.Colorado.EDU (BRADLEY ROBERT WESTON) Date: Sat, 25 Sep 93 17:35:53 PDT Subject: hi Message-ID: <Pine.3.07.9309251802.A3388-a100000@ucsu.Colorado.EDU> Hi. I don't know if this address connects to anyone or anything, but I am giving it a shot. I saw an article in Wired and then another one in the 25th anniversary edition of Whole Earth, and wanted to get in touch with you all. #1 Thanks for exisiting....... I am real glad someone is on the side of the angels technologically #2 Please put me on a list to get news. I prowl the newsnet very occasionally, but I don't have a lot of time to do so and I am still climbing up the looooong learning curve of internet. I am quite willing to pay for good info feed from you. #3 Please help me get a clean copy of PGP. I guess thats all I want to throw out unencrypted.....thanks...I want to help. Wes Bradley The return address is my e-mail address at university of colorado where I am a student in aerospace engineering. Thanks again. From ferguson at fiber.sprintlink.net Sat Sep 25 18:05:52 1993 From: ferguson at fiber.sprintlink.net (Paul Ferguson x2044) Date: Sat, 25 Sep 93 18:05:52 PDT Subject: A simpler way Message-ID: <9309260103.AA05850@fiber.sprintlink.net> -----BEGIN PGP SIGNED MESSAGE----- On Sat, 25 Sep 1993 17:24:16 -0500 (CDT), Zeek <uunet!bongo.cc.utexas.edu!zeek> writes - > Wait!! > > Ok, I've got it! "pgp -sta +clearsig=on <file>" ! > > Big thanks to those of you that refreshed my memory. I can make life much easier for you simply by mentioning the fact that you can add the line: clearsig = on to your CONFIG.TXT file (Drive:\path\PGP\config.txt). Once you add this line (note to dox writers: add it to the next version release, especially as a #commented line in the default config), then you won't have to worry about adding that pesky argument on the command line ever again! Cheers, Paul Ferguson | "Laws are dumb in the midst of arms." Mindbank Consulting Group | (Silent enim leges inter arma.) Fairfax, Virginia USA | fergp at sytex.com | - Cicero, Pro Milone The future is now. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLKR3DpRLcZSdHMBNAQGUugP+JzDE7Z2seyxPHCifwud75qfYjwqk36Z9 ylGvyL+7pF4wL/tYWZTHx9/7yyH8qetd+L29jtu5m5GBDbfL+CIh6ArC+NeW33BM llyAgJAgcnGxX+NmvPcR74nXxG0/e2cwGwwRv1ad+wPOpcpSVkKA0acAbM9i/Adp MewUG3i9D5c= =I5Y9 -----END PGP SIGNATURE----- From smb at research.att.com Sat Sep 25 18:35:52 1993 From: smb at research.att.com (smb at research.att.com) Date: Sat, 25 Sep 93 18:35:52 PDT Subject: the public key minefield Message-ID: <9309260135.AA12967@toad.com> Doesn't a patent have to have enough information for a person skilled in the art to construct a prototype? I publish for the first time here my invention. I will patent it with in a years time. Striped Vegetables ---- This isn't enough for anyone to do anything. If I were more specific, I might have something patentable, but then by claims wouldn't be as broad. If you figured out how to make an anti-gravity device. That device would be patentable. The concept of "anti-gravity" device is not patentable. If I could duplicate the effect of your anti-gravity device without using any of the same novel mechanisms. My device would be separately patentable. You seem to have missed my earlier summary of how patents are structured. A separate part of the patent from the claims describes how to build the claimed device. The claims aren't supposed to. From frc%bwnmr4 at harvard.harvard.edu Sat Sep 25 19:00:57 1993 From: frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) Date: Sat, 25 Sep 93 19:00:57 PDT Subject: PGP Docs Message-ID: <9309260158.AA11772@bwnmr4.harvard.edu> Punks, Does anyone have Postscript or preferably RTF versions of the PGP Docs? I poked around on soda for them but I didn't see any. FRC (please reply direct.. I hate to use the list for this myself.) From nate at VIS.ColoState.EDU Sat Sep 25 20:40:58 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Sat, 25 Sep 93 20:40:58 PDT Subject: Picture of a REAL clipper chip? Message-ID: <9309260340.AA08355@monet.VIS.ColoState.EDU> Is there a picture of a REAL clipper chip out there anywhere? Someone pointed out that the picture in PopularScience may not be the real thing, just some other chip made by Mykotronics. -nate -- +-------------------------------------------------------------------- | Nate Sammons email: nate at VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate at monet.VIS.ColoState.Edu for my PGP key | #include <std.disclaimer> | Always remember "Brazil" +----------------------+ From gg at well.sf.ca.us Sun Sep 26 01:50:58 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Sun, 26 Sep 93 01:50:58 PDT Subject: saturation tactics? Message-ID: <93Sep26.015035pdt.14005-3@well.sf.ca.us> In a discussion on the Well, some folks were speculating about the idea of lots and lots of people & companies applying for those arms export licenses, on the basis that they *might* sell crypto to a foreigner, or *might* go on an overseas business trip with their laptop with a crypto program on it, etc. This is a great case of an old protest tactic which we used to call "saturation," which involves lots and lots of people scrupulously obeying an unfair or controversial law to the point where it starts to swamp the system. Seeme like it might be worth looking into. Any comments...? -gg From cdodhner at indirect.com Sun Sep 26 02:10:59 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Sun, 26 Sep 93 02:10:59 PDT Subject: saturation tactics? In-Reply-To: <93Sep26.015035pdt.14005-3@well.sf.ca.us> Message-ID: <199309260908.AA07538@indirect.com> > In a discussion on the Well, some folks were speculating about the idea of > lots and lots of people & companies applying for those arms export licenses, > on the basis that they *might* sell crypto to a foreigner, or *might* go on > an overseas business trip with their laptop with a crypto program on it, > etc. This is a great case of an old protest tactic which we used to call > "saturation," which involves lots and lots of people scrupulously obeying an > unfair or controversial law to the point where it starts to swamp the > system. > > Seeme like it might be worth looking into. Any comments...? > > -gg Sounds good to me. If anybody out there is knowledgeable enough to write an initial form letter I'd be thrilled to paraphrase and send one in, as well as persuading as many of my friends and aquaintences as possible to respond, as I did with the NIST application for license to use DSA etc... BTW, I have never received any response or aknowledgement from NIST regarding my application... Do you think that means that it was accepted? <G> Happy Hunting, -Chris. ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner at indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" "If guns are outlawed, only the government will have guns." -E. Abbey My opinions are shareware. For a registered copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------ From cdodhner at indirect.com Sun Sep 26 03:05:54 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Sun, 26 Sep 93 03:05:54 PDT Subject: Big Brother Inside Stickers Message-ID: <199309261001.AA11080@indirect.com> Cypherpunks, Although it seems the clipper chip's start-of-production date has been delayed, it appears to me at least that it's eventual implimentation is inevitable, and close at hand. At that time, a little civil disobediance may be in order. I have made arrangements to produce 8,800 (that's the minimum, I don't think we'll use more than that) "Big Brother Inside(tm)" stickers for the price of 137.95, including shipping and handleing, etc. I am of course quite willing to send quantities of stickers for free to those that want them, however donations to defray my costs would be _greatly_ appreciated, and will allow me to start putting out my Cypherpunks teeshirt much sooner <hint hint> ;) The stickers are one inch by one inch square, made of clear vinal with a dark blue foreground (If there is a consensus that the foreground should be some other color I'll change that) and I'm useing the _Excellent_ Logo designed by Matt Thomlinson <phantom at u.washington.edu>. If you would like some stickers, email me with the approximate number of stickers you would like, your input on the foreground color, your snailmail address, and how much money (if any) you plan to send me. Assumeing I get a few offers for contributions (like I said, if you don't have the money I'll send 'em to you anyway) I'll send in the order now, and trust that the checks (or cash, or other forms of income) will show up. My next project is a CP tshirt. On the front will be "Cypherpunks: There's Safety in Numbers." and on the back:"Big, Big, _PRIME_ Numbers!". (Sorry, I forgot who suggested that one... :} ) and in the background will be a wraparound extended-tcmay-style list of related words and ideas. For about triple the regular price you can get your pgp public key in RAD64 format on the back also. Sounds crowded, but I think it'll work ok. Don't hold your breath for it though, I expect at least a month before I get around to that. BTW, although I am open to sugestions (In EMAIL please, not on the list) for the tshirt, in the end if you don't like my ideas, just make your own. This weekend I have two days off IN A ROW! (sunday+monday) so I am planning to try building a little truely random number generator with a serial port connection. Anybody who has serious suggestions or advice please email me. And last but certainly not least... My Remailer policy is as follows: 1) I don't read mail that goes through my remailer. None. 2) I have been keeping logs on the remailer in a failed effort to fix the encrypted message handleing, but I have mostly given up until I have a chance to learn PERL better so those logs will be removed and turned off before I send this message. 3) In otherwords, no logs are being kept (by me) 4) The computer the account is on does not belong to me, however the sysadmins know of the remailer and have agreed to refer any complaints they receive back to me. If they ask me to remove it, I will do so. 5) Any list shorter than five items is stupid. Well, that about wraps things up for now. Happy Hunting, -Chris. ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner at indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" "If guns are outlawed, only the government will have guns." -E. Abbey My opinions are shareware. For a registered copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------ From rarachel at ishara.poly.edu Sun Sep 26 14:46:03 1993 From: rarachel at ishara.poly.edu (A1 ray arachelian (library)) Date: Sun, 26 Sep 93 14:46:03 PDT Subject: saturation tactics? In-Reply-To: <93Sep26.015035pdt.14005-3@well.sf.ca.us> Message-ID: <9309261741.AA09655@ishara.poly.edu> HEy, there was a recent 20/20 story on something like this. Basically the inmates in a lot of jails were swamping the legal system with bogus lawsuits. Some included were: the right to sacrifice animals due to religion, the right to get to watch TV, and have a roast duck dinner every night also due to religion. Some were even more on the far side. One guy sued the jail for now allowing him to run a drug trafficking business out of his cell. All of these get thrown out, but the cost to the legal system is a few thousand per case! This stuff can be >VERY< effective. Mind you these guys didn't always do whatever they were granted a right to, they were just badgering the hell out of the legal systems in their states. From cdodhner at indirect.com Sun Sep 26 14:56:02 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Sun, 26 Sep 93 14:56:02 PDT Subject: Big Brother Inside Stickers Message-ID: <199309262154.AA12746@indirect.com> Ok, so far I have orders for 2450 stickers and statements indicateing $65 in donations. I'll send the order in tomorrow morning. Note that if no more orders come in I'll have 6350 stickers on my hands and not much to do with them (I plan on keeping at least 250, maybe 500 for personal use. Another 1000 could be distributed localy. That still leaves 4850 stickers.) and I'll be about 75$ in the hole (however that's not a .big. stress on my finances for now). So if you want stickers I've got plenty to give away, and if you have any cash with my name on it, well, I won't argue. I have received a couple of encrypted messages that I beleive are sticker orders, give me a few hours to decrypt and respond to those. Dito with those requesting that I sign stuff. Also remember I need your address in order to send you anything. My address for contributions is Chris 14079 North 34th Place Phoenix, Arizona 85032 Happy Hunting, -Chris ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner at indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" "If guns are outlawed, only the government will have guns." -E. Abbey My opinions are shareware. For a registered copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------ From bobi at vswr.sps.mot.com Mon Sep 27 06:41:13 1993 From: bobi at vswr.sps.mot.com (Bob Izenberg) Date: Mon, 27 Sep 93 06:41:13 PDT Subject: QPK SOURCE ONLINE Message-ID: <9309271336.AA23661@vswr.sps.mot.com> # The purpose is to S P R E A D this stuff around. Please # upload to an FTP, BBS or what-have-you. # # SEC_SRC.EXE 64668 bytes self extracting source code # SEC_RUN.EXE 278542 bytes self extracting RUN TIME EXECUTABLES (PC) I've downloaded these. To where shall I ftp them? If someone's already done so, then never mind. Bob -- ============================================================================== Bob Izenberg voice phone: 512-891-8680 Motorola RISC Software bobi at vswr.sps.mot.com ============================================================================== From mpjohnso at nyx.cs.du.edu Mon Sep 27 07:36:14 1993 From: mpjohnso at nyx.cs.du.edu (Michael Johnson) Date: Mon, 27 Sep 93 07:36:14 PDT Subject: saturation tactics? In-Reply-To: <93Sep26.015035pdt.14005-3@well.sf.ca.us> Message-ID: <Pine.3.05.9309270849.C26891-a100000@nyx> On Sun, 26 Sep 1993, George A. Gleason wrote: > > In a discussion on the Well, some folks were speculating about the idea of > lots and lots of people & companies applying for those arms export licenses, > on the basis that they *might* sell crypto to a foreigner, or *might* go on > an overseas business trip with their laptop with a crypto program on it, > etc. This is a great case of an old protest tactic which we used to call > "saturation," which involves lots and lots of people scrupulously obeying an > unfair or controversial law to the point where it starts to swamp the > system. > > Seeme like it might be worth looking into. Any comments...? Sounds expensive at $1,000 per five years per license. Got any cheaper ideas, like writing to your Congress person and the President? From smb at research.att.com Mon Sep 27 07:51:13 1993 From: smb at research.att.com (smb at research.att.com) Date: Mon, 27 Sep 93 07:51:13 PDT Subject: An amusing coincidence Message-ID: <9309271448.AA11858@toad.com> The name of the official Russian news agency is -- Itar-TASS. What a lovely pair of names.... From ssteele at eff.org Mon Sep 27 08:16:13 1993 From: ssteele at eff.org (Shari Steele) Date: Mon, 27 Sep 93 08:16:13 PDT Subject: Wiretap Article by Dorothy Denning Message-ID: <199309271512.AA00839@eff.org> Hi everyone. Dorothy Denning sent me a rather lengthy article entitled, "Wiretap Laws and Procedures: What Happens When the U.S. Government Taps a Line," which she wrote with Don Delaney of the NYS Police, John Kay of the Monmouth County (NJ) Prosecutor's office, and Alan McDonald of the FBI. I'm willing to send a copy to this list, but I wanted to make sure that I'm not in violation of list ettiquette to send a long (2 e-mail messages) post. What's the proper course of conduct here? Shari From bobi at vswr.sps.mot.com Mon Sep 27 08:21:19 1993 From: bobi at vswr.sps.mot.com (Bob Izenberg) Date: Mon, 27 Sep 93 08:21:19 PDT Subject: QPK source and binaries on ftp.uu.net Message-ID: <9309271517.AA23812@vswr.sps.mot.com> # The purpose is to S P R E A D this stuff around. Please # upload to an FTP, BBS or what-have-you. # # SEC_SRC.EXE 64668 bytes self extracting source code # SEC_RUN.EXE 278542 bytes self extracting RUN TIME EXECUTABLES (PC) I've just ftp'd them (as sec_src.exe and sec_run.exe) to ftp.uu.net:/tmp . Bob -- ============================================================================== Bob Izenberg voice phone: 512-891-8680 Motorola RISC Software bobi at vswr.sps.mot.com ============================================================================== From chaos at aql.gatech.edu Mon Sep 27 08:46:14 1993 From: chaos at aql.gatech.edu (Paul Goggin) Date: Mon, 27 Sep 93 08:46:14 PDT Subject: QPK sources and binaries Message-ID: <9309271545.AA12881@toad.com> I have just added, sec_run.exe sec_src.exe to a more permanent position than /tmp. It is available from the aql.gatech.edu archive under /pub/crypto/applications/qpk. Enjoy. -- R O All Comments Copyright by | Technofetisht A N Paul S. Goggin (1993) | Cypher, Cyber, Chaos V Information Broker | Ergoflux, Interzone E chaos at aql.gatech.edu | Carpe Diem: Stop the Clipper wiretap chip Finger account for latest _Phrack_ | Public Key: PGP and RIPEM available For anonymous communication:---> anon32940 at anon.penet.fi ------------------------------------------------------------------------------ Title 18 USC 2511 and 18 USC 2703 Protected -- Monitoring Absolutely Forbidden From psionic at wam.umd.edu Mon Sep 27 09:11:14 1993 From: psionic at wam.umd.edu (Bill I. Gerrent) Date: Mon, 27 Sep 93 09:11:14 PDT Subject: sec.program Message-ID: <199309271607.AA26189@rac2.wam.umd.edu> The quick public key program sec_run.exe and sec_src.exe have been FTP'd to wuarchive.wustl.edu /pub/MSDOS_UPLOADS/misc sec_run.exe sec_src.exe ============================================================================= /// | psionic at wam.umd.edu | Fight the WIRETAP CHIP!! Ask me how! __ /// C= | -Craig H. Rowland- | \\\/// Amiga| PGP Key Available | The U.S. Government doesn't trust its \/// 1200 | By Request. | own citizens. ============================================================================= From geoffw at nexsys.net Mon Sep 27 09:16:14 1993 From: geoffw at nexsys.net (Geoff White) Date: Mon, 27 Sep 93 09:16:14 PDT Subject: Wiretap Article by Dorothy Denning Message-ID: <9309271553.AA00476@nexsys.nexsys.net> > From toad.com!owner-cypherpunks at cdp.igc.org Mon Sep 27 08:42:26 1993 > Return-Path: <ssteele at eff.org> > Date: Mon, 27 Sep 1993 11:12:44 -0400 > To: cypherpunks at toad.com > From: ssteele at eff.org (Shari Steele) > Subject: Wiretap Article by Dorothy Denning > Content-Length: 499 > X-Lines: 10 > Status: RO > > Hi everyone. > Dorothy Denning sent me a rather lengthy article entitled, "Wiretap Laws > and Procedures: What Happens When the U.S. Government Taps a Line," which > she wrote with Don Delaney of the NYS Police, John Kay of the Monmouth > County (NJ) Prosecutor's office, and Alan McDonald of the FBI. I'm willing > to send a copy to this list, but I wanted to make sure that I'm not in > violation of list ettiquette to send a long (2 e-mail messages) post. > What's the proper course of conduct here? > Shari > > I'd definitely like to se it. From ferguson at fiber.sprintlink.net Mon Sep 27 09:21:14 1993 From: ferguson at fiber.sprintlink.net (Paul Ferguson x2044) Date: Mon, 27 Sep 93 09:21:14 PDT Subject: Denning paper (Post it!) Message-ID: <9309271618.AA07561@fiber.sprintlink.net> On Mon, 27 Sep 1993 11:12:44 -0400, <ssteele at eff.org> Shari Steele writes - > Dorothy Denning sent me a rather lengthy article entitled, "Wiretap Laws > and Procedures: What Happens When the U.S. Government Taps a Line," which > she wrote with Don Delaney of the NYS Police, John Kay of the Monmouth > County (NJ) Prosecutor's office, and Alan McDonald of the FBI. I'm willing > to send a copy to this list, but I wanted to make sure that I'm not in > violation of list ettiquette to send a long (2 e-mail messages) post. > What's the proper course of conduct here? Post it! _____________________________________________________________________________ Paul Ferguson Mindbank Consulting Group fergp at sytex.com Fairfax, Virginia USA ferguson at icp.net From ssteele at eff.org Mon Sep 27 09:36:15 1993 From: ssteele at eff.org (Shari Steele) Date: Mon, 27 Sep 93 09:36:15 PDT Subject: Wiretap Article (1 of 2) Message-ID: <199309271634.AA01886@eff.org> Here it is. >Date: Fri, 24 Sep 1993 16:31:55 -0400 (EDT) >From: denning at cs.georgetown.edu (Dorothy Denning) >Subject: Wiretap Article >To: ssteele at eff.org >Cc: denning at guvax.acc.georgetown.edu >Errors-To: Postmaster at cs.georgetown.edu >Content-Transfer-Encoding: 7BIT > >Shari, > >The following article on wiretap laws and procedures was written in >response to the many questions and misunderstandings that have arisen >in the context of escrowed encryption as well as Digital Telephony. I >would appreciate it if you would send it out through the eff-news >mailing list and archive it in your database of papers. > >Thanks, >Dorothy >------- > > WIRETAP LAWS AND PROCEDURES > WHAT HAPPENS WHEN THE U.S. GOVERNMENT TAPS A LINE > > > Donald P. Delaney, Senior Investigator > New York State Police > > Dorothy E. Denning, Professor and Chair > Computer Science Department, Georgetown University > > John Kaye, County Prosecutor > Monmouth County, New Jersey > > Alan R. McDonald, Special Assistant to the Assistant Director > Technical Services Division, Federal Bureau of Investigation > > > September 23, 1993 > > > >1. Introduction > >Although wiretaps are generally illegal in the United States, the >federal government and the governments of thirty seven states have been >authorized through federal and state legislation to intercept wire and >electronic communications under certain stringent rules which include >obtaining a court order. These rules have been designed to ensure the >protection of individual privacy and Fourth Amendment rights, while >permitting the use of wiretaps for investigations of serious criminal >activity and for foreign intelligence. > >This article describes the legal requirements for government >interceptions of wire and electronic communications and some of the >additional procedures and practices followed by federal and state >agencies. The legal requirements are rooted in two pieces of federal >legislation: the Omnibus Crime Control and Safe Streets Act (Title III >of the Act (hereafter "Title III")), passed in 1968, and the Foreign >Intelligence Surveillance Act (FISA), passed in 1978. Title III >established the basic law for federal and state law enforcement >interceptions performed for the purpose of criminal investigations, >while FISA established the law for federal-level interceptions >performed for intelligence and counterintelligence operations. We will >first describe Title III interceptions and then describe FISA >interceptions. > > >2. Title III Interceptions > >Title III, as amended (particularly by the Electronic Communications >Privacy Act of 1986), is codified at Title 18 USC, Sections 2510-2521. >These statutes provide privacy protection for and govern the >interception of oral, wire, and electronic communications. Title III >covers all telephone communications regardless of the medium, except >that it does not cover the radio portion of a cordless telephone >communication that is transmitted between the handset and base unit. >The law authorizes the interception of oral, wire, and electronic >communications by investigative and law enforcement officers conducting >criminal investigations pertaining to serious criminal offenses, i.e., >felonies, following the issuance of a court order by a judge. The >Title III law authorizes the interception of particular criminal >communications related to particular criminal offenses. In short, it >authorizes the acquisition of evidence of crime. It does not authorize >noncriminal intelligence gathering, nor does it authorize interceptions >related to social or political views. > >Thirty seven states have statutes permitting interceptions by state and >local law enforcement officers for certain types of criminal >investigations. All of the state statutes are based upon Title III >from which they are derivative. These statutes must be at least as >restrictive as Title III, and in fact most are more restrictive in >their requirements. In describing the legal requirements, we will >focus on those of Title III since they define the baseline for all >wiretaps performed by federal, state, and local law enforcement >agencies. > >In recent years, state statutes have been modified to keep pace with >rapid technological advances in telecommunications. For example, New >Jersey amended its electronic surveillance statute in 1993 to include >cellular telephones, cordless telephones, digital display beepers, fax >transmissions, computer-to-computer communications, and traces obtained >through "caller-ID". > >Wiretaps are limited to the crimes specified in Title III and state >statutes. In New Jersey, the list includes murder, kidnapping, >gambling, robbery, bribery, aggravated assault, wrongful credit >practices, terrorist threats, arson, burglary, felony thefts, escape, >forgery, narcotics trafficking, firearms trafficking, racketeering, and >organized crime. > >Most wiretaps are large undertakings, requiring a substantial use of >resources. In 1992, the average cost of installing intercept devices >and monitoring communications was $46,492. Despite budget constraints >and personnel shortages, law enforcement conducts wiretaps as >necessary, but obviously, because of staffing and costs, judiciously. > >2.1 Application for a Court Order > >All government wiretaps require a court order based upon a detailed >showing of probable cause. To obtain a court order, a three-step >process is involved. First, the law enforcement officer responsible >for the investigation must draw up a detailed affidavit showing that >there is probable cause to believe that the target telephone is being >used to facilitate a specific, serious, indictable crime. > >Second, an attorney for the federal, state, or local government must >work with the law enforcement officer to prepare an application for a >court order, based upon the officer's affidavit. At the federal level, >the application must be approved by the Attorney General, Deputy >Attorney General, Associate Attorney General, any Assistant Attorney >General, any acting Assistant Attorney General, or any Deputy Assistant >Attorney General in the Criminal Division designated by the Attorney >General. At the state and local level, the application must be made >and approved by the principal prosecuting attorney of the state (State >Attorney General) or political subdivision thereof (District Attorney >or County Prosecutor). The attorney must be authorized by a statute of >that state to make such applications. > >Third, the attorney must present the approved application ex parte >(without an adversary hearing) to a federal or state judge who is >authorized to issue a court order for electronic surveillance. A state >or local police officer or federal law enforcement agent cannot make an >application for a court order directly to a judge. > >Typically, a court order is requested after a lengthy investigation and >the use of a "Dialed Number Recorder" (DNR). The DNR is used to track >the outgoing calls from the suspect's phone in order to demonstrate >that the suspect is communicating with known criminals. > >Title III requires that an application for a court order specify: > > (a) the investigative or law enforcement officer making the > application and the high-level government attorney authorizing > the application; > > (b) the facts and circumstances of the case justifying the > application, including details of the particular offense under > investigation, the identity of the person committing it, the > type of communications sought, and the nature and location of > the communication facilities; > > (c) whether or not other investigative procedures have been tried > and failed or why they would likely fail or be too dangerous; > > (d) the period of time for the interception (at most 30 days - > extensions may be permitted upon reapplication); > > (e) the facts concerning all previous applications involving any of > the same persons or facilities; > > (f) where the application is for the extension of an order, the > results thus far obtained from the interception. > >The process of making an application for a court order is further >restricted by internal procedures adopted by law enforcement agencies >to ensure that wiretaps conform to the laws and are used only when >justified. The following describes the process for the FBI and the New >York State Police. > >2.1.1 FBI Applications > >In order for an FBI agent to conduct an interception, the agent must >follow procedures that go well beyond the legal requirements imposed by >Title III and which involve extensive internal review. In preparing >the affidavit, the FBI agent in the field works with the field office >principal legal advisor and also with an attorney in the local U.S. >Attorney's Office, revising the documentation to take into account >their comments and suggestions. After the documents are approved by >field office management, they are submitted to the Department of >Justice's Office of Enforcement Operations (OEO) in the Criminal >Division and to the FBI Headquarters (HQ). At FBI HQ, the documents go >to the Legal Counsel Division (LCD) and the Criminal Investigative >Division (CID). Within the CID, they are sent to the program manager >of the criminal program unit relating to the type of violation under >investigation, e.g., organized crime. The program manager determines >whether the subjects of the proposed interception are worthy targets of >investigation and whether the interception is worth doing. Attorneys >in the FBI's LCD and the DOJ's OEO further refine the documents. > >After the documents are approved by the DOJ's OEO and by FBI HQ, they >are referred to the Deputy Assistant Attorney General (or above), who >reviews the documents and signs off on them. At this point, the DOJ >authorizes the local U.S. Attorney's Office to file the final version >of the documents (application, affidavit, court order, and service >provider order) in court. The U.S. Attorney's Office then submits the >documents and the DOJ authorization to a federal judge. The entire >process can take as long as a month. > >The following summarizes the people and organizations involved in the >preparation or approval of the application and the issuance of a court >order: > > 1. FBI agent > 2. FBI field office attorney (principal legal advisor) > 3. FBI field office management > 4. Attorney in local U.S. Attorney's office > 5. DOJ Office of Enforcement Operations (OEO) > 6. FBI HQ Legal Counsel Division (LCD) > 7. FBI HQ Criminal Investigative Division (CID) > 8. DOJ Deputy Assistant Attorney General (or higher) > 9. Federal District Court judge > > >2.1.2 New York State Police Applications > >Within the New York State Police, electronic surveillance is conducted >by Senior Investigators in the Bureau of Criminal Investigation (BCI). >In preparing an affidavit, the investigator works with the District >Attorney's Office (or, in the case of a federal investigation, the U.S. >Attorney's office) and with the BCI Captain of the investigator's >troop. (Wiretap applications can be made and approved by the State >Attorney General, but this is unusual.) The Captain assesses whether >review by Division Headquarters is necessary and confers with the >Assistant Deputy Superintendent (ADS) or Headquarters Captain for final >determination. If Headquarters review is deemed necessary, then all >documentation is sent to the ADS along with a memorandum, endorsed by >the Troop Unit Supervisor and the Troop or Detail Commander, requesting >approval. If Headquarters review is deemed unnecessary, then the memo >is sent without the documentation. Once the ADS and District Attorney >(DA) approve the application, the DA submits the application to a judge >who grants or denies the court order. > >2.2 Issuance of a Court Order > >Not all judges have the authority to grant court orders for wiretaps. >In New Jersey, for example, only eight judges are designated as >"wiretap judges" for the entire state. These judges are given special >training to be sensitive to personal rights of privacy and to recognize >the importance of telephone intercepts for law enforcement. > >Before a judge can approve an application for electronic surveillance >and issue a court order, the judge must determine that: > > (a) there is probable cause for belief that an individual is > committing, has committed, or is about to commit an offense > covered by the law; > > (b) there is probable cause for belief that particular > communications concerning that offense will be obtained through > such interception; > > (c) normal investigative procedures have been tried and have failed > or reasonably appear unlikely to succeed or to be too dangerous; > > (d) there is probable cause for belief that the facilities from > which, or the place where the communications are to be > intercepted are being used, or are about to be used, in > connection with the commission of such offense, or are leased > to, listed in the name of, or commonly used by such person. > >In addition to showing probable cause, one of the main criterion for >determining whether a court order should be issued is whether normal >investigative techniques have been or are likely to be unsuccessful >(criterion (c) above). Electronic surveillance is a tool of last >resort and cannot be used if other methods of investigation could >reasonably be used instead. Such normal investigative methods usually >include visual surveillance, interviewing subjects, the use of >informers, telephone record analysis, and DNRs. However, these >techniques often have limited impact on an investigation. Continuous >surveillance by police can create suspicion and therefore be hazardous; >further, it cannot disclose the contents of telephone conversations. >Questioning identified suspects or executing search warrants at their >residence can substantially jeopardize an investigation before the full >scope of the operation is revealed, and information can be lost through >interpretation. Informants are useful and sought out by police, but >the information they provide does not always reveal all of the players >or the extent of an operation, and great care must be taken to ensure >that the informants are protected. Moreover, because informants are >often criminals themselves, they may not be believed in court. >Telephone record analysis and DNRs are helpful, but do not reveal the >contents of conversations or the identities of parties. Other methods >of investigation that may be tried include undercover operations and >stings. But while effective in some cases, undercover operations are >difficult and dangerous, and stings do not always work. > >If the judge approves the application, then a court order is issued >specifying the relevant information given in the application, namely, >the identity of the person (if known) whose communications are to be >intercepted, the nature and location of the communication facilities, >the type of communication to be intercepted and the offense to which it >relates, the agency authorized to perform the interception and the >person authorizing the application, and the period of time during which >such interception is authorized. A court order may also require that >interim status reports be made to the issuing judge while the wiretap >is in progress. > >2.3 Emergencies > >In an emergency situation where there is immediate danger of death or >serious physical injury to any person, or conspiratorial activities >threatening national security or characteristic of organized crime, >Title III permits any investigative or law enforcement officer >specially designated by the Attorney General, the Deputy Attorney >General, or the Associate Attorney General, or by the principal >prosecuting attorney of any state or subdivision thereof, to intercept >communications provided an application for a court order is made within >48 hours. In the event a court order is not issued, the contents of >any intercepted communication is treated as having been obtained in >violation of Title III. > >In New York State, even an emergency situation requires a court order >from a judge. However, the judge may grant a temporary court order >based on an oral application from the District Attorney. The oral >communication must be recorded and transcribed, and must be followed by >a written application within 24 hours. The duration of a temporary >warrant cannot exceed 24 hours and cannot be renewed except through a >written application. > >2.4 Execution of a Court Order > >2.4.1 Installation of a Wiretap > >To execute a court order for a wiretap, the investigative or law >enforcement officer takes the court order or emergency provision to the >communications service provider. Normally, the service provider is the >local exchange carrier. When served with a court order, the service >provider (or landlord, custodian, or other person named) is mandated >under Title III to assist in the execution of the interception by >providing all necessary information, facilities, and technical >assistance. The service provider is compensated for reasonable >expenses incurred. In light of rapid technological developments >including cellular telephones and integrated computer networks, the New >Jersey statute also requires the service provider to give technical >assistance and equipment to fulfill the court order. This requirement >has not yet been tested in court. > >Normally, the government leases a line from the service provider and >the intercepted communications are transmitted to a remote government >monitoring facility over that line. In many cases, the bridging >connection is made within the service provider's central office >facility. Alternatively, a law enforcement agency may request the >service provider to give the "pairs and appearances" (a place to >connect to the suspect's line) in the "local loop" for the suspect's >phone. A law enforcement technician then makes the connection. > >When a suspect's telephone is subject to change (e.g., because the >person is attempting to evade or thwart interception), then a "roving" >wiretap, which suspends the specification of the telephone, may be >used. In this case, prior to intercepting communications, the officer >must use some other method of surveillance in order to determine the >exact location and/or telephone number of the facility being used. >Once determined, the location or telephone number is given to the >service provider for coordination and prompt assistance. The officer >may not intercept communications randomly in order to track a person >(random or mass surveillance is not permitted under any >circumstances). > >2.4.2 Minimization > >Once any electronic surveillance begins, the law enforcement officer >must "minimize" -- that is, attempt to limit the interception of >communications to the specified offenses in the court order. Prior to >the surveillance, a federal or state attorney holds a "minimization >meeting" with the investigators who will be participating in the case >to ensure that the rules are followed. > >Minimization is normally accomplished by turning off the intercept and >then performing a spot check every few minutes to determine if the >conversation has turned to the subject of the court order. This avoids >picking up family gossip. Special problems may arise where criminals >communicate in codes that are designed to conceal criminal activity in >what sounds like mundane household discussion. If an intercepted >communication is in a code or foreign language, and if someone is not >reasonably available to interpret the code or foreign language, then >the conversation can be recorded and minimization deferred until an >expert in that code or language is available to interpret the >communication. Should a wiretap fail to meet the minimization >parameters, all of the evidence obtained from the wiretap could be >inadmissible. > >2.4.3 Recording > >All intercepted communications are to be recorded when possible. As a >practical mater, law enforcement officers make working copies of the >original tapes. In many instances at the state and local level, the >originals are delivered to the prosecutor's office and maintained in >the prosecutor's custody. The copies are screened by the case officer >for pertinent conversations (e.g., "I'll deliver the dope at 8:00 >pm."). A compilation of the relevant conversations, together with the >corroboratory surveillances often provides the probable cause for >search warrants and/or arrest warrants. > >2.4.4 Termination of Electronic Surveillance > >Electronic surveillance must terminate upon attainment of the >objectives, or in any event within 30 days. To continue an interception >beyond 30 days, the officer, through a government attorney, must apply >for and be granted an extension based upon a new application and court >order. > >When the period of a court order, or extension thereof, expires, the >original tapes must be made available to the issuing judge and sealed >under court supervision. The tapes must be maintained in such fashion >for 10 years. > >2.5 Notification and Use of Intercepted Communications as Evidence > >Upon termination of an interception, the judge who issued the court >order must notify the persons named in the order that the interception >took place. Normally, this must be done within 90 days, but it may be >postponed upon showing of good cause. If the judge determines that it >would be in the interest of justice to make portions of the intercepted >communications available to the subjects, the judge may do so. > >The contents of the communications may not be used as evidence in any >trial or hearing unless each party has received a copy of the >application and court order at least 10 days in advance of the trial, >and has been given the opportunity to move to suppress the evidence. A >motion to suppress the evidence may be made on the grounds that it was >not obtained in complete conformance with the laws. > >2.6 Reports > >Within 30 days after the expiration or denial of a court order, Title >III requires that the judge provide information about the order to the >Administrative Office of the United States Courts (AO). Each year the >Attorney General (or a designated Assistant Attorney General) must >report, on behalf of the federal government, to the AO a summary of all >orders and interceptions for the year; reports for state and local >jurisdictions are made by the principal prosecuting attorney of the >jurisdiction. The AO then integrates these summaries into an annual >report: "Report on Applications for Orders Authorizing or Approving the >Interception of Wire, Oral, or Electronic Communications (Wiretap >Report)" covering all federal and state electronic surveillance, >including wiretaps. The 1992 report is about 200 pages and includes >information about each interception authorized in 1992, update >information for interceptions authorized in 1982-1991, and summary >statistics. The summary statistics include the following data (numbers >in parenthesis are the 1992 figures): > > (1) number of interceptions authorized (919), denied (0), and > installed (846) > > (2) average duration (in days) of original authorization (28) and > extensions (30) > > (3) the place/facility where authorized (303 single family dwelling, > 135 apartment, 3 multi-dwelling, 119 business, 4 roving, 66 > > From ssteele at eff.org Mon Sep 27 09:36:15 1993 From: ssteele at eff.org (Shari Steele) Date: Mon, 27 Sep 93 09:36:15 PDT Subject: Wiretap Article (2 of 2) Message-ID: <199309271635.AA01892@eff.org> >Date: Fri, 24 Sep 1993 16:31:55 -0400 (EDT) >From: denning at cs.georgetown.edu (Dorothy Denning) >Subject: Wiretap Article >To: ssteele at eff.org >Cc: denning at guvax.acc.georgetown.edu >Errors-To: Postmaster at cs.georgetown.edu >Content-Transfer-Encoding: 7BIT > > combination, 289 other) > > (4) major offenses involved (634 narcotics, 90 racketeering, 66 > gambling, 35 homicide/ assault, 16 larceny/theft, 9 kidnapping, > 8 bribery, 7 loansharking/usury/extortion, 54 other) > > (5) average number of (a) persons intercepted (117), (b) > interceptions (1,861), and (c) incriminating intercepts (347) > per order where interception devices were installed > > (6) average cost of interception ($46,492) > > (7) type of surveillance used for the 846 interceptions installed > (632 telephone, 38 microphone, 113 electronic, 63 combination) > > (8) number of persons arrested (2,685) and convicted (607) as the > result of 1992 intercepts > > (9) activity taking place during 1992 as the result of intercepts > terminated in years 1982-1991, including number of arrests > (1211), trials (280), motions to suppress that are granted (14), > denied (141), and pending (37), and convictions (1450) (there is > a lag between interceptions, arrests, and convictions, with many > arrests and most convictions associated with a wiretap that > terminated in one year taking place in subsequent years) > >Most of the above data is broken down by jurisdiction. Of the 919 >authorized intercepts, 340 (37%) were federal. New York State had 197, >New Jersey 111, Florida 80, and Pennsylvania 77. The remaining 114 >intercepts were divided among 18 states, none of which had more than 17 >intercepts. During the past decade, the average number of authorized >intercepts per year has been about 780. > >Individual law enforcement agencies also require internal reports. For >example, the New York Sate Police requires that each week, the Troop or >Detail Captain prepare a report summarizing the status of all >eavesdropping activity within the unit, including the productivity and >plans for each electronic surveillance installation and a brief >synopsis of pertinent activity. This is sent to the New York State >Police Division Headquarters Captain who prepares a report summarizing >the status of all eavesdropping installations. > >One of the reasons for the significant amount of post wiretap reporting >is to provide a substantial record for legislatures when considering >whether or not to reenact or modify wiretap statutes. > > >3. FISA Interceptions > >Title 50 USC, Sections 1801-1811, the Foreign Intelligence Surveillance >Act (FISA) of 1978, covers electronic surveillance for foreign >intelligence purposes (including counterintelligence and >counterterrorism). It governs wire and electronic communications sent >by or intended to be received by United States persons (citizens, >aliens lawfully admitted for permanent residence, corporations, and >associations of U.S. persons) who are in the U.S. when there is a >reasonable expectation of privacy and a warrant would be required for >law enforcement purposes; nonconsensual wire intercepts that are >implemented within the U.S.; and radio intercepts when the sender and >all receivers are in the U.S. and a warrant would be required for law >enforcement purposes. It does not cover intercepts of U.S. persons who >are overseas (unless the communications are with a U.S. person who is >inside the U.S.). Electronic surveillance conducted under FISA is >classified. > >FISA authorizes electronic surveillance of foreign powers and agents of >foreign powers for foreign intelligence purposes. Normally, a court >order is required to implement a wiretap under FISA. There are, >however, two exceptions. The first is when the communications are >exclusively between or among foreign powers or involve technical >intelligence other than spoken communications from a location under the >open and exclusive control of a foreign power; there is no substantial >risk that the surveillance will acquire the communications to or from a >U.S.person; and proposed minimization procedures meet the requirements >set forth by the law. Under those conditions, authorization can be >granted by the President through the Attorney General for a period up >to one year. The second is following a declaration of war by >Congress. Then the President, though the Attorney General, can >authorize electronic surveillance for foreign intelligence purposes >without a court order for up to 15 days. > >Orders for wiretaps are granted by a special court established by >FISA. The court consists of seven district court judges appointed by >the Chief Justice of the United States. Judges serve seven-year >terms. > >3.1 Application for a Court Order > >Applications for a court order are made by Federal officers and require >approval by the Attorney General. Each application must include: > > (1) the Federal officer making the application; > > (2) the Attorney General's approval; > > (3) the target of the electronic surveillance; > > (4) justification that the target is a foreign power or agent of a > foreign power (except no U.S person can be considered a foreign power > or agent thereof solely based on activities protected by the First > Amendment) and that the facilities or places where the surveillance > is be directed will be used by the same; > > (5) the proposed minimization procedures, which must meet certain > requirements to protect the privacy of U.S. persons; > > (6) the nature of the information sought and type of communications > subjected to surveillance; > > (7) certification(s) by the Assistant to the President for National > Security Affairs or other high-level official in the area of > national security or defense (Presidential appointee subject to > Senate confirmation) that the information sought is foreign > intelligence information and that such information cannot > reasonably be obtained by normal investigative methods; > > (8) the means by which the surveillance will be effected; > > (9) the facts concerning all previous applications involving the same > persons, facilities, or places; > > (10) the period of time for the interception (maximum 90 days or, > when the target is a foreign power, one year); > > (11) coverage of all surveillance devices to be employed and the > minimization procedures applying to each. > >Some of the above information can be omitted when the target is a >foreign power. > >Within the FBI, the process of applying for a court order under FISA is >as exacting and subject to review as under Title III. The main >differences are that under FISA, the FBI Intelligence Division is >involved rather than the Criminal Investigative Division, the DOJ >Office of Intelligence Policy and Review (OIPR) is involved rather than >either the U.S. Attorney's Office or the DOJ Criminal Division, and the >application is approved by the Attorney General (or Acting Attorney >General) rather than by a lower DOJ official. > >3.2 Issuance of a Court Order > >Before a judge can approve an application, the judge must determine >that the authorizations are valid; that there is probable cause to >believe that the target of the electronic surveillance is a foreign >power or agent of a foreign power and that the facilities or places >where the surveillance is be directed will be used by the same; and >that the proposed minimization procedures meet the requirements set >forth in the law. If the judge approves the application, an order is >issued specifying the relevant information from the application and >directing the communication carrier, landlord, custodian, or other >specified person to furnish all necessary information, facilities, and >technical assistance and to properly maintain under security procedures >any records relating to the surveillance. > >3.3 Emergencies > >In an emergency situation, the Attorney General or designee can >authorize the use of electronic surveillance provided the judge is >notified at the time and an application is made to the judge within 24 >hours. If such application is not obtained, then the judge notifies >any U.S. persons named in the application or subject to the >surveillance, though such notification can be postponed or forgone upon >showing of good cause. > >3.4 Use of Intercepted Communications as Evidence > >Like Title III, FISA places strict controls on what information can be >acquired through electronic surveillance and how such information can >be used. No information can be disclosed for law enforcement purposes >except with the proviso that it may only be used in a criminal >proceedings under advance authorization from the Attorney General. If >the government intends to use such information in court, then the >aggrieved person must be notified in advance. The person may move to >suppress the evidence. > >3.5 Reports > >Each year, the Attorney General must give the Administrative Office of >the United States Courts (AO) a report of the number of FISA >applications and the number of orders and extensions granted, modified, >or denied. In 1992, there were 484 orders. Since 1979, there has been >an average of a little over 500 FISA orders per year. > >Because intercepts conducted under FISA are classified, detailed >information analogous to that required under Title III is not reported >to the AO, nor made available to the public. However, records of >Attorney General certifications, applications, and orders granted must >be held for at least 10 years, and the Attorney General must inform two >Congressional oversight committees of all surveillance activity on a >semiannual basis. These committees are the House Permanent Select >Committee on Intelligence and the Senate Select Committee on >Intelligence. > > >Acknowledgements > >We are grateful to Geoffrey Greiveldinger for many helpful suggestions >on an earlier draft of this report. > > > From Derek_L_Davis at ccm.hf.intel.com Mon Sep 27 10:31:14 1993 From: Derek_L_Davis at ccm.hf.intel.com (Derek L Davis) Date: Mon, 27 Sep 93 10:31:14 PDT Subject: Wiretap Article by Dorothy Denning Message-ID: <930927103702_1@ccm.hf.intel.com> I'd like to see it too (the Denning Wiretap Article). Derek (the other other other Derek, apparently) From mpjohnso at nyx.cs.du.edu Mon Sep 27 10:41:14 1993 From: mpjohnso at nyx.cs.du.edu (Michael Johnson) Date: Mon, 27 Sep 93 10:41:14 PDT Subject: Challenge: break the MPJ Encryption Algorithm Message-ID: <Pine.3.05.9309271122.A29490-d100000@nyx> I would like as many of you as are interested to take a serious look at a private key block encryption algorithm that I invented and let me know if there is any weakness in it that you can discover. No, I will not insult you with a block of random data as a challenge text. I have published the full algorithm, including source code, in my Master's Thesis. It is available to callers in the USA only on my BBS at 303-938-9654 (local to the Denver/Boulder calling area) as CRYPTMPJ.ZIP and MPJ_PS.ZIP. CRYPTMPJ.ZIP contains a plain ASCII text version of my thesis, full Pascal source code, and an executable program CRYPTMPJ.EXE that was used to test it. MPJ_PS.ZIP contains a PostScript version of my Thesis so that you can print out the pictures and see the equations more normally. Other sources: CompuServe, IBMSYS forum, as CRYPTM.ZIP; anonymous ftp to soda.berkeley.edu; and on the disks bound in the back of the book "Network Security Secrets" by David Stang and Sylvia Moon (ISBN1-56884-021-7; published by IDG Books Worldwide, Inc.). Here is a short description of the algorithm: 1. Using a convoluted key expansion process, expand a 128 bit (16 byte) key into 160 different, reversible 256 byte substitution boxes. 2. Execute ten rounds of encryption, where each round consists of (1) alter each byte of the input by replacing it with the value obtained by using the input byte as an index into the corresponding substitution box, then (2) perform a fixed "wire crossing" bit selection such that each output byte is a function of one bit from each of 8 different input bytes. Each substitution box is used only once in encrypting a block. Block size is 16 bytes (128 bits). Attacks I have considered: 1. Brute force (both exhaustive key search and precomputation). Good luck. 2. Analytical solution for the contents of the substitition arrays with a chosen plain text attack. With 10 or more rounds, the complexity of the matrix of boolean equations required and the quantity of known or chosen plain text required seems to make this impractical, but I may be missing something. 3. Differential cryptanalysis. Since the structure of the cipher algorithm has no simpler subkeys than the arrays themselves, this can't be done in the same sense as Biham and Shamir have discussed for DES, IDEA, etc. There may be a related attack, but I haven't thought of one yet (hardly a proof of nonexistance!) 4. Attack of the key expansion algorithm to simplify an analytical attack of the contents of the substitution arrays. This seems to me to be worse than a frontal attack on the arrays, given the complexity of the key scheduling algorithm. Then again, I suffer inventor's blindness in this area. The only complaints anyone has made so far are not fatal, in my humble opinion: 1. The key is fixed length. OK, the key expansion could be done differently to make this variable, but 128 bits is enough to preclude exhaustive key search within the budgets of anyone I anticipate worrying about for the next 10 years, at least. That assumes growth in computing power of a few orders of magnitude, too. 2. It is a symetric key algorithm, not a public key algorithm. Guilty as charged. On the other hand, you don't have to pay royalties to PKP (or anyone, including me) to use the algorithm in your own code or hardware. 3. The user interface to CRYPTMPJ.EXE is confusing, archaic, and not as simple as it should be. True. I plan to fix this some day, but it is still not a problem with the algorithm. 4. The source code is in Pascal, not C. Easily fixed by porting. If anyone does this before I do, please send me a copy. I wish I had the resources to offer a cash reward, but I don't. On the other hand, If you break the MPJ encryption algorithm and post your solution, then you will have the satisfaction of having beaten me in an intellectual game. If no one succeeds in breaking the MPJ encryption algorithm after reasonable effort has been applied, then there will be a secure, royalty free, unpatented block cipher available for use in the USA. (Where else would math be patented?) -- Mike Johnson (mpj at csn.org) This message contains speech and writings protected by the First Amendment of the Constitution of the United States of America. From stig at netcom.com Mon Sep 27 11:11:19 1993 From: stig at netcom.com (Stig) Date: Mon, 27 Sep 93 11:11:19 PDT Subject: Wiretap Article (2 of 2) In-Reply-To: <199309271635.AA01892@eff.org> Message-ID: <9309271809.AA12276@netcom4.netcom.com> In <199309271635.AA01892 at eff.org>, Shari Steele wrote... > >Date: Fri, 24 Sep 1993 16:31:55 -0400 (EDT) > >From: denning at cs.georgetown.edu (Dorothy Denning) > >Subject: Wiretap Article > >To: ssteele at eff.org > >Cc: denning at guvax.acc.georgetown.edu > >Errors-To: Postmaster at cs.georgetown.edu > >Content-Transfer-Encoding: 7BIT > > > > combination, 289 other) > > > > (4) major offenses involved (634 narcotics, 90 racketeering, 66 > > gambling, 35 homicide/ assault, 16 larceny/theft, 9 kidnapping, > > 8 bribery, 7 loansharking/usury/extortion, 54 other) > > > > (5) average number of (a) persons intercepted (117), (b) > > interceptions (1,861), and (c) incriminating intercepts (347) > > per order where interception devices were installed > > > > (6) average cost of interception ($46,492) > > > > (7) type of surveillance used for the 846 interceptions installed > > (632 telephone, 38 microphone, 113 electronic, 63 combination) > > > > (8) number of persons arrested (2,685) and convicted (607) as the > > result of 1992 intercepts > > > > (9) activity taking place during 1992 as the result of intercepts > > terminated in years 1982-1991, including number of arrests > > (1211), trials (280), motions to suppress that are granted (14), > > denied (141), and pending (37), and convictions (1450) (there is > > a lag between interceptions, arrests, and convictions, with many > > arrests and most convictions associated with a wiretap that > > terminated in one year taking place in subsequent years) > > > >Most of the above data is broken down by jurisdiction. Of the 919 > >authorized intercepts, 340 (37%) were federal. New York State had 197, > >New Jersey 111, Florida 80, and Pennsylvania 77. The remaining 114 > >intercepts were divided among 18 states, none of which had more than 17 > >intercepts. During the past decade, the average number of authorized > >intercepts per year has been about 780. > > > >Individual law enforcement agencies also require internal reports. For > >example, the New York Sate Police requires that each week, the Troop or > >Detail Captain prepare a report summarizing the status of all > >eavesdropping activity within the unit, including the productivity and > >plans for each electronic surveillance installation and a brief > >synopsis of pertinent activity. This is sent to the New York State > >Police Division Headquarters Captain who prepares a report summarizing > >the status of all eavesdropping installations. > > > >One of the reasons for the significant amount of post wiretap reporting > >is to provide a substantial record for legislatures when considering > >whether or not to reenact or modify wiretap statutes. > > > > > >3. FISA Interceptions > > > >Title 50 USC, Sections 1801-1811, the Foreign Intelligence Surveillance > >Act (FISA) of 1978, covers electronic surveillance for foreign > >intelligence purposes (including counterintelligence and > >counterterrorism). It governs wire and electronic communications sent > >by or intended to be received by United States persons (citizens, > >aliens lawfully admitted for permanent residence, corporations, and > >associations of U.S. persons) who are in the U.S. when there is a > >reasonable expectation of privacy and a warrant would be required for > >law enforcement purposes; nonconsensual wire intercepts that are > >implemented within the U.S.; and radio intercepts when the sender and > >all receivers are in the U.S. and a warrant would be required for law > >enforcement purposes. It does not cover intercepts of U.S. persons who > >are overseas (unless the communications are with a U.S. person who is > >inside the U.S.). Electronic surveillance conducted under FISA is > >classified. > > > >FISA authorizes electronic surveillance of foreign powers and agents of > >foreign powers for foreign intelligence purposes. Normally, a court > >order is required to implement a wiretap under FISA. There are, > >however, two exceptions. The first is when the communications are > >exclusively between or among foreign powers or involve technical > >intelligence other than spoken communications from a location under the > >open and exclusive control of a foreign power; there is no substantial > >risk that the surveillance will acquire the communications to or from a > >U.S.person; and proposed minimization procedures meet the requirements > >set forth by the law. Under those conditions, authorization can be > >granted by the President through the Attorney General for a period up > >to one year. The second is following a declaration of war by > >Congress. Then the President, though the Attorney General, can > >authorize electronic surveillance for foreign intelligence purposes > >without a court order for up to 15 days. > > > >Orders for wiretaps are granted by a special court established by > >FISA. The court consists of seven district court judges appointed by > >the Chief Justice of the United States. Judges serve seven-year > >terms. > > > >3.1 Application for a Court Order > > > >Applications for a court order are made by Federal officers and require > >approval by the Attorney General. Each application must include: > > > > (1) the Federal officer making the application; > > > > (2) the Attorney General's approval; > > > > (3) the target of the electronic surveillance; > > > > (4) justification that the target is a foreign power or agent of a > > foreign power (except no U.S person can be considered a foreign power > > or agent thereof solely based on activities protected by the First > > Amendment) and that the facilities or places where the surveillance > > is be directed will be used by the same; > > > > (5) the proposed minimization procedures, which must meet certain > > requirements to protect the privacy of U.S. persons; > > > > (6) the nature of the information sought and type of communications > > subjected to surveillance; > > > > (7) certification(s) by the Assistant to the President for National > > Security Affairs or other high-level official in the area of > > national security or defense (Presidential appointee subject to > > Senate confirmation) that the information sought is foreign > > intelligence information and that such information cannot > > reasonably be obtained by normal investigative methods; > > > > (8) the means by which the surveillance will be effected; > > > > (9) the facts concerning all previous applications involving the same > > persons, facilities, or places; > > > > (10) the period of time for the interception (maximum 90 days or, > > when the target is a foreign power, one year); > > > > (11) coverage of all surveillance devices to be employed and the > > minimization procedures applying to each. > > > >Some of the above information can be omitted when the target is a > >foreign power. > > > >Within the FBI, the process of applying for a court order under FISA is > >as exacting and subject to review as under Title III. The main > >differences are that under FISA, the FBI Intelligence Division is > >involved rather than the Criminal Investigative Division, the DOJ > >Office of Intelligence Policy and Review (OIPR) is involved rather than > >either the U.S. Attorney's Office or the DOJ Criminal Division, and the > >application is approved by the Attorney General (or Acting Attorney > >General) rather than by a lower DOJ official. > > > >3.2 Issuance of a Court Order > > > >Before a judge can approve an application, the judge must determine > >that the authorizations are valid; that there is probable cause to > >believe that the target of the electronic surveillance is a foreign > >power or agent of a foreign power and that the facilities or places > >where the surveillance is be directed will be used by the same; and > >that the proposed minimization procedures meet the requirements set > >forth in the law. If the judge approves the application, an order is > >issued specifying the relevant information from the application and > >directing the communication carrier, landlord, custodian, or other > >specified person to furnish all necessary information, facilities, and > >technical assistance and to properly maintain under security procedures > >any records relating to the surveillance. > > > >3.3 Emergencies > > > >In an emergency situation, the Attorney General or designee can > >authorize the use of electronic surveillance provided the judge is > >notified at the time and an application is made to the judge within 24 > >hours. If such application is not obtained, then the judge notifies > >any U.S. persons named in the application or subject to the > >surveillance, though such notification can be postponed or forgone upon > >showing of good cause. > > > >3.4 Use of Intercepted Communications as Evidence > > > >Like Title III, FISA places strict controls on what information can be > >acquired through electronic surveillance and how such information can > >be used. No information can be disclosed for law enforcement purposes > >except with the proviso that it may only be used in a criminal > >proceedings under advance authorization from the Attorney General. If > >the government intends to use such information in court, then the > >aggrieved person must be notified in advance. The person may move to > >suppress the evidence. > > > >3.5 Reports > > > >Each year, the Attorney General must give the Administrative Office of > >the United States Courts (AO) a report of the number of FISA > >applications and the number of orders and extensions granted, modified, > >or denied. In 1992, there were 484 orders. Since 1979, there has been > >an average of a little over 500 FISA orders per year. > > > >Because intercepts conducted under FISA are classified, detailed > >information analogous to that required under Title III is not reported > >to the AO, nor made available to the public. However, records of > >Attorney General certifications, applications, and orders granted must > >be held for at least 10 years, and the Attorney General must inform two > >Congressional oversight committees of all surveillance activity on a > >semiannual basis. These committees are the House Permanent Select > >Committee on Intelligence and the Senate Select Committee on > >Intelligence. > > > > > >Acknowledgements > > > >We are grateful to Geoffrey Greiveldinger for many helpful suggestions > >on an earlier draft of this report. > > > > > > > THIS IS THE SORT OF NOISE THAT'S BETTER KEPT OFF THE LIST. Private messages should be sent via private email. stig ;; __________________________________________________________________________ ;; Stig at netcom.com netcom.com:/pub/stig/00-PGP-KEY ;; It's hard to be cutting-edge at your own pace... 32 DF B9 19 AE 28 D1 7A ;; Bullet-proof code cannot stand up to teflon bugs. A3 9D 0B 1A 33 13 4D 7F From pmetzger at lehman.com Mon Sep 27 11:46:14 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 27 Sep 93 11:46:14 PDT Subject: Wiretap Article (2 of 2) In-Reply-To: <9309271809.AA12276@netcom4.netcom.com> Message-ID: <9309271841.AA08215@snark.lehman.com> Stig says: > > > THIS IS THE SORT OF NOISE THAT'S BETTER KEPT OFF THE LIST. Private messages > should be sent via private email. > > stig What? This is the fist bit of substantive stuff on a list filled with noise for months. What do you think the list is for? To provide a place for conspiracy theorists to jerk each other off? Ms. Steele, it was perfectly appropriate. This is exactly the sort of thing the list is for. Perry From stig at netcom.com Mon Sep 27 12:06:14 1993 From: stig at netcom.com (Stig) Date: Mon, 27 Sep 93 12:06:14 PDT Subject: Wiretap Article (2 of 2) In-Reply-To: <pmetzger@lehman.com> Message-ID: <9309271904.AA21497@netcom4.netcom.com> In <9309271841.AA08215 at snark.lehman.com>, "Perry E. Metzger" wrote... > > Stig says: > > > > > > THIS IS THE SORT OF NOISE THAT'S BETTER KEPT OFF THE LIST. Private messages > > should be sent via private email. > > > > stig > > What? This is the fist bit of substantive stuff on a list filled with > noise for months. What do you think the list is for? To provide a > place for conspiracy theorists to jerk each other off? > > Ms. Steele, it was perfectly appropriate. This is exactly the sort of > thing the list is for. > > Perry Ms. Steele's forwarding of the Denning article was entirely appropriate. Two people publicly asking Ms. Steele to forward it when email would have sufficed was noise. I replied to Paul, not Shari, so I figured that a careful reader would be able to properly disambiguate my pronouns.... Oh well. Stig ;; __________________________________________________________________________ ;; Stig at netcom.com netcom.com:/pub/stig/00-PGP-KEY ;; It's hard to be cutting-edge at your own pace... 32 DF B9 19 AE 28 D1 7A ;; Bullet-proof code cannot stand up to teflon bugs. A3 9D 0B 1A 33 13 4D 7F From ssimpson at eff.org Mon Sep 27 12:51:16 1993 From: ssimpson at eff.org (Sarah L Simpson) Date: Mon, 27 Sep 93 12:51:16 PDT Subject: ACTIVIST ALERT -The Clock is Ticking! Message-ID: <199309271949.AA04775@eff.org> That's right - the clock is ticking. The deadline to get things to cryptnow at eff.org is 8:00pm EST. It is now just before 4pm - that's 4 short hours to go. Don't let this deadline pass! Please note - my previous message offered a sample letter directed to "Mr. Director". NIST's director is actually a woman, so please omit the "Mr.". ============================= And because time is so tight, EFF has set up an Internet address where you can send your electronic comments in lieu of mailing them through the U.S. Postal Service. Send your letters to: cryptnow at eff.org We will be printing out all letters and hand-delivering them before the deadline, so please make sure to send us any letter you want included no later than 8pm on Monday, September 27. If you would like additional background materials, you can browse the pub/EFF/crypto area of our anonymous ftp site (ftp.eff.org). The original solicitation of comments can be found there and is called NIST-escrow-proposal. DO NOT WAIT TO WRITE YOUR COMMENTS! TIME IS SHORT! ====================== <<your name>> <<your organization>> <<your street address>> <<your city, state, zip>> <<date>> National Institute for Standards and Technology (NIST) ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Mr. Director: I am writing to oppose the Proposed Federal Information Processing Standard (FIPS) for and Escrowed Encryption Standard, docket # 930659-3159. Encryption is vital for the protection of individual privacy in the Information Age. As more and more personal information flows around electronic networks, we all need strong encryption to safeguard information from unwanted intrusion NIST should not be moving forward with technical standards specification until critical policy decisions are made. These policy issues include: o Continued Legal Use of All Forms of Encryption: When the Clinton Administration announced the Clipper Chip, it assured the public that this would be a purely voluntary system. We must have legal guarantees that Clipper isn't the first step toward prohibition against un-escrowed encryption. o Legal Rights of Escrow Users: If people choose to deposit their keys with the government or any other escrow agent, they must have some legal recourse in the event that those keys are improperly released. The most recent draft of the escrow procedures specifically states, however: "These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired." Leaving users with no recourse will discourage use of the system and is a tacit acceptance of unscrupulous government behavior. o Open Standards: People won't use encryption unless they trust it. Secret standards such as Clipper cannot be evaluated by independent experts and do not deserve the public trust. In addition, the current proposed technical standard is incomplete. It should not be approved until futher comment on the complete proposal is possible o Operating Procedures Unclear: The full operating procedures for the escrow agents has yet to be issued. Public comment must be sought on the complete procedures, not just the outline presented in the draft FIPS. Even the government-selected algorithm review group has declared that it needs more information on the escrow process. o Identity of Escrow Agents: The identity of one or both of the escrow agents has not been firmly established. o Algorithm Classified: Asking for comments on an algorithm that is classified makes a mockery of citizen participation in government decision-making. NIST will be involved in making many critical decisions regarding the National Information Infrastructure. The next time NIST solicits public comments, it should be ready to accept reply by electronic mail in addition to paper-based media. Sincerely, <<name>> <<title>> ****************************** Sarah L. Simpson Membership Coordinator Electronic Frontier Foundation 1001 G Street, NW Suite 950 East Washington, DC 20001 202/347-5400 tel 202/393-5509 fax From wcs at anchor.ho.att.com Mon Sep 27 13:21:16 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Mon, 27 Sep 93 13:21:16 PDT Subject: Wiretap Article by Dorothy Denning Message-ID: <9309271653.AA29243@anchor.ho.att.com> It would probably be ok to send to the list, though I suspect most of us have ftp access (it's available on ftp.vortex.com in pub/privacy/wiretap.laws.Z) either directly by mail, and somebody will probably post it to Usenet soon. Kaye is my local prosecutor, and while he's not as rabidly corrupt about forfeiture as some of the nearby county prosecutors, he's been relatively energetic about using and supporting it and finding new things to forfeit property for. Bill Stewart From ezf at osf.org Mon Sep 27 17:21:21 1993 From: ezf at osf.org (Ed Frankenberry) Date: Mon, 27 Sep 93 17:21:21 PDT Subject: mailing list addition request In-Reply-To: <199309271949.AA04775@eff.org> Message-ID: <9309280020.AA27583@postman.osf.org> Please add "ezf at osf.org" to the "cypherpunks" e-mail list. Thank you, Ed From bkoball at well.sf.ca.us Mon Sep 27 17:41:21 1993 From: bkoball at well.sf.ca.us (Bruce R Koball) Date: Mon, 27 Sep 93 17:41:21 PDT Subject: Verilog encryption broken Message-ID: <93Sep27.173714pdt.14125-3@well.sf.ca.us> The following is an article that I posted in the EFF conf on the WELL. Though it's written for non-tech readers, I thought it might be of interest to the cypherpunks. -- Bruce -------- A recent anonymous posting in the comp.lang.verilog newsgroup on Usenet has generated a raging controversey and threatens to shake up the electronic design automation (EDA) community. The posting was a program that broke the encryption scheme used to protect the proprietary libraries that are part of Cadence Design Systems high-end IC design tool Verilog-XL. Verilog is a sophisticated CAD tool that allows engineers to design and simulate new chips before they are manufacturered. These libraries contain detailed descriptions of integrated circuit building blocks (called cells) and are usually supplied by different chip manufacturers in an encrypted format because their information could be used to reverse engineer the proprietary cells and the chips built with them. Cadence also uses the encryption to prevent these libraries from being used with lower-cost Verilog clones that are available. The anonymous poster claimed that he was doing this in protest of Cadence's pricing policies. The program was written in Perl, a Unix scripting language, and contained Verilog encryption tables. It exploited debugging features that were left in Verilog by Cadence programmers to break Verilog's rather simple encryption scheme. Cadence's response on the net was swift and strongly worded: > > Newsgroups: comp.lang.verilog > From: robert at cadence.com (Robert Donohue) > Subject: Cadence Official Position on Protected Code > Organization: Cadence Design Systems, Inc. > Date: Thu, 16 Sep 1993 00:11:36 GMT > > On September 14, 1993, someone posted on the 'Internet' a program > relating to Cadence Design Systems Verilog technology. This disclosure was > unauthorized by Cadence and is illegal. Any copying of the program or any > use of it would be unlawful, subjecting the infringer to substantial civil > and, potentially, criminal penalties. > > Cadence is investigating this unauthorized disclosure and copying, and > will take all available legal actions against the person who made the > disclosure when his or her identity is learned. Any person or entity using > such illegally posted code will also be the subject of the same legal > action. You should immediately destroy any copy you may have made of the > program. Anyone having information about the illegal posting should contact > Robert Donohue, Cadence's General Counsel, at 'robert at cadence.com' or > telephone (408) 944-7748 or fax at (408) 944-0215 in the United States. > As might be expected, much heat has been generated in subsequent net discussions. Several issues are at stake. There has been some discussion over the legality of the posting and potential subsequent use of the Perl script. Cadence has apparently received heat from its users for what some have perceived as its heavy-handed reaction. Some Verilog users have complained that hacking on the libraries is sometimes necessary because of the insufficient documentation of their contents. Perhaps the most serious implication for the EDA community is the apparent ease with which the protection of numerous ASIC vendor's intellectual property was broached. The data contained in these libraries are the "crown jewels" for these chip manufacturers and are typically protected by non-disclosure agreements between the manufacturers and their customers. There has been some mention of liability on Cadence's part for any unauthorized disclosure that may occur. Finally, this incident will undoubtedly provide more ammunition for those who have been criticising the growing phenomenon of anonymous remailing services on the net. -------- P.S. Does anyone on this list know if the offending post was made through an anonymous remailer? -brk From VACCINIA at UNCVX1.OIT.UNC.EDU Mon Sep 27 18:11:21 1993 From: VACCINIA at UNCVX1.OIT.UNC.EDU (VACCINIA at UNCVX1.OIT.UNC.EDU) Date: Mon, 27 Sep 93 18:11:21 PDT Subject: PGP Business Week article Message-ID: <01H3GGRLXRQQ006YNP@UNCVX1.OIT.UNC.EDU> In case anyone is interested, there is a very sympathetic article in the Oct. 4, 1993 "Business Week" magazine about PGP and encryptation in general. It's on page 43. I'll just hit the highlights, but check it out. >Oddly, the crackdown on software {re:PGP} comes just as the administration is >loosening export controls on computer hardware. But the schizophrenia may be >more apparent than real."I don't think they've got the export policy together >enough to be split", says a key congressional staffer..... "This is an area >that has essentially been turned over to the spooks". >Meanwhile, there is growing concern in congress about possible damage to >exports. Quality encryptation software, "is available from foreign >manufacturers... and is easily transmitted using only a long-distance >telephone line and a modem," complained Representative Sam Gejdenson >(D-Conn.) and a high-powered bipartisan group of collegues in a Sept. 20 >letter to the President. >Still, the NSA can't stave off the inevitable for long. Gejdenson hopes to >produce legislation by early next year to revamp government policy on high- >tech exports. The result will probably include looser restrictions on >encryptation software- and a victory for Phil Zimmermann in his battle to >keep snoops out of his cyberspace. Hee-Hee, write Rep. Gejdenson via compuserve or any other way and let him know you support him on this one. I think if we keep at it we win. Scott G. Morham ! The First, Vaccinia at uncvx1.oit.unc.edu ! Second ! and Third ! Levels of ! Information Storage and Retrieval ! DNA, ! Biological Neural Nets, ! Cyberspace From baumbach at atmel.com Mon Sep 27 18:21:21 1993 From: baumbach at atmel.com (Peter Baumbach) Date: Mon, 27 Sep 93 18:21:21 PDT Subject: the public key minefield Message-ID: <9309272035.AA25846@bass.chp.atmel.com> > You seem to have missed my earlier summary of how patents are structured. > A separate part of the patent from the claims describes how to build the > claimed device. The claims aren't supposed to. Do you agree or disagree that: 'the concept of "anti-gravity" device is not patentable. If I could duplicate the effect of your anti-gravity device without using any of the same novel mechanisms. My device would be separately patentable.' ? If you agree, then how can you patent "public key systems" as a concept? If you disagree, then we can leave it at that. Peter Baumbach baumbach at atmel.com From smb at research.att.com Mon Sep 27 18:41:21 1993 From: smb at research.att.com (smb at research.att.com) Date: Mon, 27 Sep 93 18:41:21 PDT Subject: the public key minefield Message-ID: <9309280140.AA22526@toad.com> > You seem to have missed my earlier summary of how patents are struct ured. > A separate part of the patent from the claims describes how to build the > claimed device. The claims aren't supposed to. Do you agree or disagree that: 'the concept of "anti-gravity" device is not patentable. If I could duplicate the effect of your anti-gravity device without using any of the same novel mechanisms. My device would be separately patentable.' ? If you agree, then how can you patent "public key systems" as a concept? If you disagree, then we can leave it at that. The question is phrased improperly. Apart from the fact that the concept (though not the reality) of anti-gravity is prior art, they didn't patent the concept of public-key cryptography. Rather, they patented a class of devices fitting a certain description, with one public key cryptosystem as an example and as a separate set of claims. To use your analogy, I could patent anti-gravity achieved by interposing a screen of some substance opaque to gravity, and patent Cavorite as an instance of that class. If you had another use for Cavorite, you'd be home free. Or if you found a way to neutralize gravity by beaming anti-gravitons downward, you'd probably be clear, too. But if you found another substance besides Cavorite that was opaque to gravity -- yes, that would be covered by my patent. (Fortunately, H.G. Wells didn't patent his literary device. But I can't think of another science fiction author who used that technique....) It's certainly possible that all possible cryptosystems that achieve the same effect would be covered by their description. That, of course, is the mark of a good patent attorney's work -- that he or she managed to fashion so broad a claim. But maybe you can find a better way to do what you really want to do, which is trade keys and authenticate messages. And if you do -- well, then, the patent system has succeeded in its goals, in that the monopoly assigned to someone else has stimulated you to find another way to do things, and thus furthered the useful arts and sciences. From doug at netcom.com Mon Sep 27 18:46:19 1993 From: doug at netcom.com (Doug Merritt) Date: Mon, 27 Sep 93 18:46:19 PDT Subject: Verilog encryption broken In-Reply-To: <bkoball@well.sf.ca.us> Message-ID: <9309280144.AA10672@netcom.netcom.com> Bruce R Koball <bkoball at well.sf.ca.us> said: >P.S. Does anyone on this list know if the offending post was made >through an anonymous remailer? -brk In looking at the newsgroup in question, it appears that someone cancelled the controversial article, but it is clear from responses that the poster was "an33929 at anon.penet.fi". Doug From MIKEINGLE at delphi.com Mon Sep 27 21:11:23 1993 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Mon, 27 Sep 93 21:11:23 PDT Subject: Clinton UN Speech / Msg to Prez/VP Message-ID: <01H3GN1EBEV690N1NN@delphi.com> In his UN speech this morning, Clinton talked about cracking down on nuke and missile proliferation, and he also mentioned eliminating cold-war-era restrictions which are harming American business. Let's put together a message to president at whitehouse.gov and vice-president at whitehouse.gov (since Gore is the info-highway guru) stating our position. Points we should make: (please modify and add to this list) * Crypto export restrictions are among the most obsolete and oppressive of these restrictions. * Americans can be jailed for exporting software which is widely used throughout the world (e.g. DES), and which in many cases was even developed outside the U.S. * These restrictions have already hurt American software companies. * They will prevent America from taking the lead in many crucial information technologies. * They will leave American companies vulnerable to industrial espionage. And our position on Clipper: * Clipper should not be established as a mandatory standard for the general public or for business. * Alternatives to Clipper should not be restricted. * Telecommunications companies should not be coerced into using Clipper. * Clipper chips should not have any special export status due to the fact that we keep the keys. This would put American makers of crypto hardware at a serious disadvantage in the world market. * Clipper should be reserved for its stated purpose - protection of non-classified information within the Federal government. * Use outside the government should be purely voluntary. * The whole concept of key escrow needs serious public examination. While the government may have the right, with a warrant, to knock down your door, key escrow is equivalent to requiring every citizen to give the police a copy of his or her key. This is a major departure from the status quo, not a continuation of it. --- MikeIngle at delphi.com P.S. It could be worse. Remember Clipper was a Bush administration plan. Bush was a former CIA head. He also had a dictatorial attitude and felt no need to justify his actions to anyone. Bush would probably have tried to ban crypto outright as soon as Clipper was ready. From markh at wimsey.bc.ca Mon Sep 27 21:31:23 1993 From: markh at wimsey.bc.ca (Mark C. Henderson) Date: Mon, 27 Sep 93 21:31:23 PDT Subject: Verilog encryption broken Message-ID: <m0ohWe6-0001EbC@vanbc.wimsey.com> > A recent anonymous posting in the comp.lang.verilog newsgroup on Usenet > has generated a raging controversey and threatens to shake up the > electronic design automation (EDA) community. The posting was a program > that broke the encryption scheme used to protect the proprietary > libraries that are part of Cadence Design Systems high-end IC design > tool Verilog-XL. Verilog is a sophisticated CAD tool that allows ... This does bring up an interesting ethical question. What should one do when one discovers that a vendor is marketing an encryption scheme for the protection or to limit the use of specific information, which is easy to break. Obviously, one is neither doing the vendor nor the customers of that vendor a favour by posting a detailed account of the weakness of the system. One the other hand, if one justs sits on the information, it is clear that other people will be able to deduce the weakness in the system and actually use it to steal information; and why not, I suppose anyone who puts trust in "smoke and mirrors security" probably deserves exactly what they get. The world abounds with weak encryption algorithms which are being used to protect information of consderable value. The case with Verilog, and their use of an easily "crackable" scheme is far from unique. Still I don't have an answer. Say one discovers that a vendor is protecting its customers' information using a simple "crackable" linear encryption function. Is that information something to reveal, something to keep secret or what? If one were to approach the vendor in question with that kind of information, I can imagine all sorts of legal entanglements that might arise. There are other instances which are similar. Information on the (in)security of various operating systems comes to mind. Comments? -- Mark Henderson markh at wimsey.bc.ca (personal account) RIPEM key available by key server/finger/E-mail MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433 From cvoid at netcom.com Mon Sep 27 22:06:18 1993 From: cvoid at netcom.com (Christian Void) Date: Mon, 27 Sep 93 22:06:18 PDT Subject: Phil Zimmerman on 'The Death of DES' Message-ID: <Pine.3.05.9309272220.A26747-b100000@netcom3> I found the following on Usenet, and was curious as to the validity of the statements made. If anyone has any other information regarding this, please post or mail it private. I don't know if any of it already floated through here, but thought you might be interested in it. --- Seen on the PRIVACY FORUM mailing list: ----------------------- Date: Wed, 8 Sep 93 13:13:12 -0400 From: "Alan (Gesture Man) Wexelblat" <wex at media.mit.edu> Subject: DES is a dead dog... From: Philip Zimmermann <prz at columbine.cgd.ucar.EDU> Subject: Re: DES Key Search Paper (fwd) Michael Weiner presented a paper at Crypto93 that describes a fast DES key search engine that uses a special inside-out DES chip that he designed. This chip takes a single plaintext/ciphertext pair and quickly tries DES keys until it finds one that produces the given ciphertext from the given plaintext. Weiner can get these chips made for $10.50 each in quantity, and can build a special machine with 57000 of these chips for $1 million. This machine can exhaust the DES key space in 7 hours, finding a key in 3.5 hours on the average. He works for Bell Northern Research in Ottawa, and says they have not actually built this machine, but he has the chip fully designed and ready for fabrication. This is a stunning breakthrough in the realization of practical DES cracking. BTW-- note that PEM uses straight 56-bit DES. --- Christian Void /T71 | "I don't like it, and I'm sorry I | VMResearch, Inc. cvoid at netcom.COM | ever had anything to do with it." | P.O. Box 170213 Tel. 1+415-807-5491 | -Erwin Schrodinger (1887-1961) | SF, CA 94117 * PGP v2.3a Public Key Available Via Finger * From tedwards at wam.umd.edu Mon Sep 27 22:21:24 1993 From: tedwards at wam.umd.edu (technopagan priest) Date: Mon, 27 Sep 93 22:21:24 PDT Subject: Easy cracking Message-ID: <199309280518.AA18205@rac5.wam.umd.edu> If you found out you could easily crack a commercial "protection" method, what do you do? First, you stay anonymous, because otherwise they will try to get you, no matter what your intentions are. I think it is best to send the information, anonymously, with a working example to the company. But chances are that they will sit on it due to fear of loosing market share or being sued by users. So the question is, is it more ethical to allow the userbase to have their information cracked by "bad guys," possibly without their knowledge, or publish the information so that the userbase is aware of the security breach, and can do something about it? It depends on the situation, of course. But no one will believe you if you say "I can crack xyz programs 'protected' data" without showing how it works. When it comes right down to it, individuals have to be responsible about the cryptosystems they use. And you are much better off knowing that your data is possibly crackable rather than not knowing it, and having hackers crack it without your knowledge. Hopefully this whole incident will get software companies thinking more seriously about using scholarly-tested secure cryptosystems. -Thomas From marc at MIT.EDU Mon Sep 27 22:46:19 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Mon, 27 Sep 93 22:46:19 PDT Subject: Easy cracking In-Reply-To: <199309280518.AA18205@rac5.wam.umd.edu> Message-ID: <9309280541.AA00928@steve-dallas.MIT.EDU> >> If you found out you could easily crack a commercial "protection" >> method, what do you do? I'd send it off to CERT anonymously. They have good relationships with vendors, who often put out patches CERT presents them with security-related problems. If I saw no response after 6-12 months (about a vendor release cycle), I might start being more public about it. This solution means that the problem has a reasonable chance of getting solved, without causing too much damage in the interim. If I had reason to believe that some security hole was being used heavily and maliciously by someone, I would explain this to CERT and wait a significantly smaller period of time, like a week or two, before going public. This would prevent people from being unknowingly hurt by a bug. It's important not to go too public too quickly, because people have a tendency to panic. When the 1988 Internet Worm was discovered, peoples' reaction was to pull the plug on the net. This was counterproductive, since it made it difficult to tell people how to protect themselves against the Worm. Parts of the MILNET remained disconnected for weeks. Marc From bill at twwells.com Tue Sep 28 00:11:24 1993 From: bill at twwells.com (T. William Wells) Date: Tue, 28 Sep 93 00:11:24 PDT Subject: Verilog encryption broken In-Reply-To: <m0ohWe6-0001EbC@vanbc.wimsey.com> Message-ID: <CE1xH2.1Dt@twwells.com> In article <m0ohWe6-0001EbC at vanbc.wimsey.com>, Mark C. Henderson <markh at wimsey.com> wrote: : What should one do when one discovers that a vendor is marketing : an encryption scheme for the protection or to limit the use of : specific information, which is easy to break. Whatever you want to do. Contrary to what I suppose is a popular opinion, this is not an ethical question *unless* you have some sort of contractual obligation that makes it so or unless your personal, *private* ethics says something on the subject. People who rely on trade secrets are making a bet. The bet is as follows: first, that all people who have access to the trade secret will respect the agreements, both by not disclosing their trade secret and by protecting it from disclosure; and, second, that if someone does violate one of those agreements, he has deep enough pockets that suing him will make up for the loss. When the trade secret is exposed, *it is gone*. *Forever*. That's the law. Those who once had a trade secret cannot legally demand of (uninvolved) others that they help them protect it. I would guess that it is *Verilog* whose ass is in the fire. If you or I were to use that script to extract information from their libraries, *unless* we had an agreement with Verilog not to, it would be perfectly legal to do so. And it would be perfectly legal to broadcast that information. However, Verilog, by not adequately protecting the information in the libraries, may well be liable for the disclosure. What it looks like from this distance is that Verilog is running scared, trying to frighten would be extractors into not spreading the information they would get so that the amount of damage Verilog will have to take will be limited. Verilog, their customers, and library providers, made a bet. They lost. No one (who is uninvolved) has *any* obligation to help them minimize the loss from losing their bet. I have no doubt that Verilog would like to have the discussion turn away from the simple business aspects toward a touchie-feelie mass-debation about ethics but to do so would simply be evading the real issues. From julf at penet.fi Tue Sep 28 00:41:24 1993 From: julf at penet.fi (Johan Helsingius) Date: Tue, 28 Sep 93 00:41:24 PDT Subject: Verilog encryption broken In-Reply-To: <93Sep27.173714pdt.14125-3@well.sf.ca.us> Message-ID: <199309280736.AA20648@mail.eunet.fi> > A recent anonymous posting in the comp.lang.verilog newsgroup on Usenet > has generated a raging controversey and threatens to shake up the > electronic design automation (EDA) community. > P.S. Does anyone on this list know if the offending post was made > through an anonymous remailer? -brk It was posted using anon.penet.fi. I have already been contacted by Verilog's legal representatives. Julf From ld231782 at longs.lance.colostate.edu Tue Sep 28 00:46:19 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 28 Sep 93 00:46:19 PDT Subject: Denning article - sites for retrieval Message-ID: <9309280745.AA20360@longs.lance.colostate.edu> The article has been placed in Privacy Forum archives: ===cut=here=== Date: Fri, 24 Sep 1993 16:49:45 -0400 (EDT) From: denning at cs.georgetown.edu (Dorothy Denning) Subject: Wiretap Article The following article on wiretap laws and procedures was written in response to the many questions and misunderstandings that have arisen about wiretaps in the context of escrowed encryption as well as Digital Telephony. This article may be distributed. Dorothy Denning denning at cs.georgetown.edu [ I have included the introductory portion of the paper below. The entire text (~33K bytes) has been placed into the PRIVACY Forum archives. To access: Via Anon FTP: From site "ftp.vortex.com": /privacy/wiretap.laws.Z or: /privacy/wiretap.laws Via e-mail: Send mail to "listserv at vortex.com" with the line: get privacy wiretap.laws as the first text in the BODY of your message. Via gopher: From the gopher server on site "gopher.vortex.com" in the "*** PRIVACY Forum ***" area under "wiretap.laws". -- MODERATOR ] From ld231782 at longs.lance.colostate.edu Tue Sep 28 00:51:25 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 28 Sep 93 00:51:25 PDT Subject: idiotic government regulations: DO SOMETHING! Message-ID: <9309280748.AA20432@longs.lance.colostate.edu> Here's everyone's chance to do something *constructive* about idiotic government regulations. Imagine this -- an email address to report them! ------- Forwarded Message Date: Sun, 26 Sep 93 23:14:39 EDT From: "Paul Jones" <pjones at sunsite.unc.edu> Subject: REGO needs your suggestions - soon The following announcement comes from the Office of the National Performance Review- they are looking for anecdotes regarding useless government regulations, and reccomendations for eliminating needless bureaucracy. This is the Net's chance to have a say in fixing what's wrong with the US government. - ------ Vice President Gore's task force on reinventing government (REGO) called for many changes in the federal government. Now that the report has been issued, we have shifted to implementation of those recommendations. Successful implementation of those changes will require the collective efforts of many people across government. To provide support and to help implement the recommendations, a "network of networks" is being established. The network, dubbed "NetResults" will link together government workers at the federal, state, and local levels, and will provide ways for people in the private and non-profit sectors to participate as well. This message is an initial effort by NetResults to get information and support for these recommendations. On September 11, 1993, President Clinton signed an executive order calling for the elimination of one-half of executive branch internal regulations within three years. We'd like your assistance in helping us find the best examples of obsolete, redundant, or dysfunctional federal regulations. This is your opportunity to let senior federal policy managers know about federal regulations or internal administration policies and procedures that prevent effective service to the taxpayer. We plan to forward this information to the Federal Quality Institute for its use in helping agencies eliminate or reduce regulations. Any replies should give a brief description of the regulation or internal administrative procedures and a specific citation where this regulation is found. Please send us this information either through electronic mail to: sillyreg at sunsite.unc.edu or fax it to REGO at: (202) 632-0390. For immediate impact, send your responses by electronic mail before September 28, 1993. If you are interested in more information on "NetResults", please send an electronic mail message to Steve Butterfield at steveb at sunsite.unc.edu, Dennis Egan at dennise at tmn.com, or Andy Campbell at andy at tmn.com. We appreciate your interest and will look forward to your replies. ------- End of Forwarded Message From gg at well.sf.ca.us Tue Sep 28 01:01:24 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 28 Sep 93 01:01:24 PDT Subject: saturation tactics? Message-ID: <93Sep28.005832pdt.14165-1@well.sf.ca.us> yeah, here's a cheaper version. Write to the arms excport license people and pester them with questions: I'm a BBS operator, what should I do?; I'm a businessperson travelling overseas and need my crypto to comm with the home office what should I do?; all this kind of thing. Swamp them with letters. Every person and every circumstance which even remotely fits. An alternative version which would require more guts and perhaps a serious conscientious decision about whether it's worth making this an act of civil disobedience, is to write to them and say, "I'm a BBS operator, not an arms merchant, and on the strength of my 1st-A rights I'm not going to censor my board or get a license..." or "I'm a businessperson who travels & takes my cryupto out of the country on my laptop to comm with the home office; I'm not an arms dealer either and I don't intend to get a license..." And again, there is strength in numbers here. And of course, a good steganographic program or two would be a very nice development indeed, Just In Case. -gg From ld231782 at longs.lance.colostate.edu Tue Sep 28 01:01:27 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 28 Sep 93 01:01:27 PDT Subject: Ringing Dingaling Rebuttal Message-ID: <9309280756.AA20517@longs.lance.colostate.edu> Here's a cypherpunkesque rebuttal of the recent article. ===cut=here=== Date: Mon, 27 Sep 93 08:39:11 -0400 From: shap at viper.cis.upenn.edu (Jonathan Shapiro) To: denning at cs.cosc.georgetown.edu Subject: Re: Wiretap Article Dorothy: Recently you sent out a piece of mail providing information on wiretap laws in connection with the Clipper chip. I wish to draw to your attention that the laws concerning wiretapping are largely irrelevant to the issue at hand, and why. Let us assume that the wiretap laws as they stand are sound (I do not believe this, but it doesn't matter). Let us ignore the fact that the new Attorney General was recently asked to sign a large pile of blank warrants in the interests of "National Security," and rightly went through the roof. Let us further imagine that the system is Good, and that the likes likes of McCarthy, J. Edgar Hoover, Richard M. Nixon, G. Gordon Liddy, and Ollie North are gone forever. In fact, let's go so far as to ignore that as the Federal Government grows and grows it is a _necessary_ consequence that we will encounter more such people. Let us ignore the abridgements of the First Amendment rights of encryption technologists during the '60s and '70s by the NSA, and discount their bleatings as the reactions of alarmists. Finally, let us imagine that the timing of the munitions investigation into Pretty Good Privacy is entirely accidental, and that this does not amount to an attempt to make the only viable alternative encryption technology illegal de facto. As a personal matter, I'm inclined to grant this point because the agencies involved are too disorganized to have successfully coordinated. Government is _not_ intrinsically evil. It _is_ intrinsically amoral. The propriety of a government is only as sound as its weakest member in a position of relevant power. We can sometimes catch the offenders and subject them to due process, but doing so does not compensate their victims for their abuses. To be sure, this term's politicos are swearing themselves stupid promising that other encryption technologies will not be outlawed. By them. Of course, the policies change from term to term, and the guarantees of this group of people are therefore irrelevant to the long term. The question, you see, is not _whether_ the Clipper technology will be abused, but _how_soon_. The lessons of history, Ms. Denning, are best not forgotten. Jonathan S. Shapiro Synergistic Computing Associates From ld231782 at longs.lance.colostate.edu Tue Sep 28 01:01:33 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 28 Sep 93 01:01:33 PDT Subject: Steve Jackson opposes Clipper FIPS Message-ID: <9309280800.AA20584@longs.lance.colostate.edu> ===cut=here=== Date: Sun, 26 Sep 93 21:15:13 GMT From: sj at indial1.io.com (Steve Jackson) Subject: Comments on Clipper/Skipjack proposal Steve Jackson, President Sept. 26, 1993 Steve Jackson Games / Illuminati Online PO Box 18957, Austin, TX 78760 512-447-7866 sj at io.com National Institute for Standards and Technology (NIST) ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Sirs: I am writing in opposition to the Proposed Federal Information Processing Standard (FIPS) for an Escrowed Encryption Standard, docket # 930659-3159. As a publisher of both printed and online materials, I am deeply concerned by the potential effect of the proposed standard, which appears to me to have been produced in haste and to be lacking many significant elements required for informed citizen comment. I am in strong agreement with the points raised by the EFF and CPSR in their comments opposing the proposed standard. Private access to strong encryption is simply vital to protect the privacy of individuals in today's online environment. Legitimate business requirements for confidentiality also mandate free access to good encryption technology. The manner in which this proposal has been put forward is improper and incomplete. An algorithm intended for private and commercial purposes should not be classified as a "national security matter." And it is wholly improper to ask for meaningful "citizen input" while the algo- rithm itself is secret, the identities of the escrow agents are not firmly established, complete operating procedures are not available, and no legal recourse is yet proposed for the improper release of keys. In particular, the proposal fails to define what "legal authorization," other than a court order, might be available to compel the escrow agents to release a key. This omission is unacceptable. If keys are to be released to any authority except a United States court, the details must be made public immediately. Finally, a strong guarantee is needed that the Clipper/Skipjack system will never become mandatory, and that other forms of encryption will remain freely and legally available to all Americans. The proposal should be withdrawn until all these issues can be addressed. Only then can a legitimate period of citizen comment begin. Respectfully submitted - Steve Jackson ------- End of Forwarded Message From khijol!erc Tue Sep 28 01:16:19 1993 From: khijol!erc (Ed Carp) Date: Tue, 28 Sep 93 01:16:19 PDT Subject: Verilog encryption broken In-Reply-To: <CE1xH2.1Dt@twwells.com> Message-ID: <m0oha7n-00022PC@khijol> Uh, anyone save that particular article? <grin> -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From gg at well.sf.ca.us Tue Sep 28 01:21:24 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 28 Sep 93 01:21:24 PDT Subject: PGP Business Week article Message-ID: <93Sep28.011745pdt.14161-2@well.sf.ca.us> Re. Representative Sam Gejdenson (pronounced as if spelled "gaydenson", accent on first syllable): I went to one of his campaign appearances when he first ran for office (this was Middletown Connecticut, 1980), and was very much impressed by his positions on various issues, and in particular, his background knowledge in a number of areas including engineering and policy areas related to the environment.... he is definitely someone who has a good ability to digest and utilise technical information in detail, and I'd say he could be a very very key person on our side of these issues. He definitely deserves 100% support and all the solid detailed information we can provide. -gg From gg at well.sf.ca.us Tue Sep 28 01:26:19 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 28 Sep 93 01:26:19 PDT Subject: Verilog encryption broken Message-ID: <93Sep28.012251pdt.14162-1@well.sf.ca.us> Re Mark's question about the ethics of revealing that a proprietary system is crackable: I believe there is every right and duty to make the vulnerability publicly known. However, this can be done without disclosing enough of the content of the badly-protected information as to come in for heat. For example, one might post little snippets of a source code file which by themselves aren't usable but which the original owners will instangly recognise. This would be akin to the "fair use" of quotations from literature and poetry in critical reviews. And I also believe it would stand up in court, because the material which was revealed in the quotations could not be used in and of itself to devalue the content of the original complete work. -gg From Lyle_Seaman at transarc.com Tue Sep 28 01:41:24 1993 From: Lyle_Seaman at transarc.com (Lyle_Seaman at transarc.com) Date: Tue, 28 Sep 93 01:41:24 PDT Subject: Contributions to Zimmermann--Where?? In-Reply-To: <9309250733.AA09491@netcom5.netcom.com> Message-ID: <YgdnqI=0Bwwb0vqa9o@transarc.com> tcmay at netcom.com (Timothy C. May) writes: > If Phil--who appears to be the main target, never > mind that the _document subpoena_ was not directed at him this time > around--is successfully indicted, sent to trial, etc., then this will > have a chilling effect on others. *Somebody* will be indicted. That's what Grand Juries do. Lyle Transarc 707 Grant Street 412 338 4474 The Gulf Tower Pittsburgh 15219 From karn at unix.ka9q.ampr.org Tue Sep 28 02:01:25 1993 From: karn at unix.ka9q.ampr.org (Phil Karn) Date: Tue, 28 Sep 93 02:01:25 PDT Subject: My comments to NIST Message-ID: <9309280902.AA09142@unix.ka9q.ampr.org> 7431 Teasdale Avenue San Diego, CA 92122 karn at unix.ka9q.ampr.org September 27, 1993 Director, Computer Systems Laboratory ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Re: A Proposed Federal Information Processing Standard for an Escrowed Encryption Standard (EES) Docket No 930659-3159 RIN 0693-AB19 Comments of Philip R. Karn, Jr Sirs: I am writing in response to your call for comments on the aforementioned matter that appeared in the Federal Register on July 30, 1993. I am writing as a concerned individual with BS and MS degrees in electrical and computer engineering and 15 years of professional experience in communications, computer networking and security at leading edge R&D organizations. I currently work in the digital cellular telephone industry, a ripe application for robust encryption if there ever was one. I feel that my experience in this field qualifies me to comment on the practicality of the proposed standard. First of all, I am totally opposed to the entire concept of key escrow. It is a dangerous, un-American and fatally flawed idea that should never have been proposed. In my opinion, everyone has the Constitutional right to use the encryption scheme of their choice, whether or not the government can break it. The impact of strong encryption on the enforcement of legitimate laws is and will remain minimal. Even unbreakable encryption is incapable of thwarting standard investigational techniques such as informants, testimony compelled through grants of immunity, "end point" surveillance (e.g., hidden microphones), the gathering of physical evidence of crimes and so forth. Strong un-escrowed encryption will, on the other hand, finally put an end to illegal, often politically motivated interceptions of private electronic communications without having to rely on anyone's goodwill, such as the still-unnamed "key escrow agencies". Precisely because eavesdropping has been so easy to do and so hard to detect, the government has repeatedly proven itself untrustworthy in this regard, as documented in great detail by the Watergate investigations and the Church Committee hearings of the 1970s. Why should we trust it now? Although the government currently claims that the EES will be a "voluntary" standard, many of its features make no sense whatsoever in this context. For example, why must the Skipjack algorithm be kept secret if individuals remain free to use other algorithms such as triple-key DES or IDEA that are quite probably even stronger? The government's claim is completely transparent, as one simply cannot escape the conclusion that the EES is a prelude to a ban on all other encryption schemes, or at least a ban on those the government can't crack. And this presents a profoundly disturbing threat to some very important Constitutional principles. Countless others have argued forcefully against the proposal on these and other grounds. For example, see the points made by the Computing Professionals for Social Responsibility (CPSR) in the attached Appendix. I fully agree with CPSR and feel that they alone should have been enough to stop the proposal long ago. However, the fact that the Escrowed Encryption Standard has advanced so quickly despite these serious problems reveals the totally one-sided nature of the decision process. Far from being an independent and impartial agency, NIST has proven itself to be merely a pawn for the National Security Agency, the Federal Bureau of Investigation and other powerful intelligence and law enforcement agencies. Despite (or perhaps because of) encryption's enormous potential to put real "teeth" into the Constitutional principles of privacy and freedom of speech and association, these agencies are notably unsympathetic to tFrom owner-cypherpunks Tue Sep 28 05:51:28 1993 Received: by toad.com id AA02707; Tue, 28 Sep 93 05:46:19 PDT Received: by toad.com id AA02651; Tue, 28 Sep 93 05:41:49 PDT Return-Path: <nowhere at bsu-cs.bsu.edu> Received: from bsu-cs.bsu.edu ([147.226.112.101]) by toad.com id AA02647; Tue, 28 Sep 93 05:41:46 PDT Received: by bsu-cs.bsu.edu (5.57/Ultrix3.0-C) id AA08271; Tue, 28 Sep 93 07:43:59 -0500 Date: Tue, 28 Sep 93 07:43:59 -0500 Message-Id: <9309281243.AA08271 at bsu-cs.bsu.edu> From: Anonymous <nowhere at bsu-cs.bsu.edu> To: cypherpunks at toad.com X-Remailed-By: Anonymous <nowhere at bsu-cs.bsu.edu> X-Ttl: 0 X-Notice: This message was forwarded by a software- automated anonymous remailing service. Subject: Disturbing statistics on wiretaps Organization: Coalition for Cryptographic Freedom In the paper written by Delaney, Denning and Kaye (Wiretap Laws and Procedures -- What Happens when the U.S. Government Taps a Line, September 23, 1993), a few numbers were presented from a 1992 report which reflect the wiretaps put into place during that year. Without further details concerning the specifics surrounding some of these numbers, it should certainly raise eyebrows on a couple of points: - All 919 "interceptions" were authorized. The numbers presented in this report indicate that none were denied. - Out of this number, 303 were in single family homes, 135 were in apartments and 289 were categorized as placed in "other" locations. - Out of 919, 634 were placed into service for interception of information involving narcotics. The closest contender in this area involved racketeering, in which 90 was the magic number. - The number of persons arrested was 2,685. Of that number, only 607 were convicted. These statistics alone should concern YOU. From pmetzger at lehman.com Tue Sep 28 05:56:19 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 28 Sep 93 05:56:19 PDT Subject: Clinton UN Speech / Msg to Prez/VP In-Reply-To: <01H3GN1EBEV690N1NN@delphi.com> Message-ID: <9309281255.AA14898@snark.lehman.com> Mike Ingle says: > In his UN speech this morning, Clinton talked about cracking down on nuke > and missile proliferation, and he also mentioned eliminating cold-war-era > restrictions which are harming American business. Let's put together a > message to president at whitehouse.gov and vice-president at whitehouse.gov > (since Gore is the info-highway guru) stating our position. Messages sent to president at whitehouse.gov are weighed, not read. I suspect this will have about as much effect on the president as a note written in a bottle and tossed into the ocean. However, on that basis, its perfectly harmless for you to send a letter saying anything whatsoever other than a threat on the president's life, so if you and others would like to spend time writing such a thing, you can feel free. Just remember that there is no cypherpunks organization, so you can't claim to represent us. Perry From ssteele at eff.org Tue Sep 28 06:16:19 1993 From: ssteele at eff.org (Shari Steele) Date: Tue, 28 Sep 93 06:16:19 PDT Subject: GIF experts Message-ID: <199309281314.AA13690@eff.org> Hi everyone. I know this is not the focus of the cypherpunks, but I was hoping one of you folks out there might be able to point me in the direction of a technoid who could testify about how easy it is to manipulate GIF images. Please respond by private message (ssteele at eff.org) so I don't cause any more noise on the list. Thanks. Shari From mab at crypto.com Tue Sep 28 06:21:28 1993 From: mab at crypto.com (Matt Blaze) Date: Tue, 28 Sep 93 06:21:28 PDT Subject: my clipper letter Message-ID: <9309281309.AA27963@crypto.com> Matthew Blaze 55 River Drive South Jersey City, NJ 07310 September 25, 1993 National Institute for Standards and Technology (NIST) ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Dear Director: I am writing to express my opposition to the Proposed Federal Information Processing Standard (FIPS) for an Escrowed Encryption Standard, docket #930659-3159. First, let me state my qualifications in this area. I hold a Ph.D. in computer science in the area of large-scale systems from Princeton University. I am presently employed as a Principal Investigator / Member of Technical Staff in the Computing Systems Research Laboratory of AT&T Bell Laboratories. My research focuses on the design of cryptographically secure networked computing and communications systems and I have published several research papers in this field. I must emphasize, however, that I am making these comments as a private citizen; nothing in this letter should be construed as representing the opinion or position of my employer or any other organization. I state my affiliation only for the purpose of identification. I believe that adoption of the proposed Escrowed Encryption Standard would be harmful to the national interest in at least two ways. First, it will harm us economically, putting our computing and communications technology at a significant disadvantage against foreign competition. Second, it will hinder, rather than promote, the increasingly vital efforts to improve the security of our information infrastructure. Several aspects of the proposed standard render the system inadequate for our competitive and information security needs. First, because the proposed system relies on the use of a special, tamper-resistant computer chip, it is impossible to manufacture equipment or design systems that have their cryptographic security functions based entirely in software. The implementation of cryptographic systems in software has only recently been made feasible by advances in computer speed and has significant advantages over hardware (chip)-based encryption. Software encryption can be included in digital voice and computer communications equipment, such as cellular telephones, at virtually no increase in marginal cost. Hardware-based encryption (based on technologies such as the proposed standard), on the other hand, can add over a hundred dollars to the end price of each unit. This could represent an increase of several times the original price for typical low-end consumer communications products. Clearly, devices that include the proposed standard will be at a significant disadvantage compared with equivalent products (possibly from foreign competitors) that employ software-based encrypFrom owner-cypherpunks Tue Sep 28 06:46:18 1993 Received: by toad.com id AA03637; Tue, 28 Sep 93 06:41:30 PDT Received: by toad.com id AA03607; Tue, 28 Sep 93 06:38:21 PDT Return-Path: <cme at ellisun.sw.stratus.com> Received: from transfer.stratus.com ([134.111.1.10]) by toad.com id AA03603; Tue, 28 Sep 93 06:38:18 PDT Received: from lectroid.sw.stratus.com by transfer.stratus.com (4.1/3.14-jjm) id AA14444; Tue, 28 Sep 93 09:38:16 EDT Received: from ellisun.sw.stratus.com by lectroid.sw.stratus.com (4.1/3.10-jjm) id AA29408; Tue, 28 Sep 93 09:38:15 EDT Received: by ellisun.sw.stratus.com (4.1/SMI-4.1) id AA25476; Tue, 28 Sep 93 09:38:15 EDT Date: Tue, 28 Sep 93 09:38:15 EDT From: cme at ellisun.sw.stratus.com (Carl Ellison) Message-Id: <9309281338.AA25476 at ellisun.sw.stratus.com> To: cypherpunks at toad.com Subject: Re: saturation tactics? >From: "George A. Gleason" <gg at well.sf.ca.us> >Subject: saturation tactics? >Message-Id: <93Sep26.015035pdt.14005-3 at well.sf.ca.us> >Date: Sun, 26 Sep 1993 01:50:31 -0700 >lots and lots of people & companies applying for those arms export licenses, >"saturation," which involves lots and lots of people scrupulously obeying an >unfair or controversial law to the point where it starts to swamp the >system. I'd much rather not do it. There won't be enough people out there to really swamp the system. Meanwhile, it lends credence to the stupid notion that S/W crypto is arms. I much prefer the statements in the READMEs at soda.berkeley.edu .... The official Stratus line on this issue, BTW, is that we don't want to deal in munitions. We have no intention of selling arms to anyone. We sell much of our product overseas and we sell only freely available crypto -- the stuff which is so widely documented and available that no terrorist or unfriendly government could possible not already have it. In particular, we sell software DES and a few simpler systems for our customers to use as they will. Of course, ye olde US Gov't still forces not to export this except to financial institutions (which is a reasonable fraction of our business) but there are other customers pissed at us because we obey the stupid US export laws. Needless to say, Stratus as a company wants to see the export laws changed. - Carl Disclaimer: I don't speak for Stratus. For the official company policy, see the company's letter to NIST re: Skipjack. [I certainly hope these will be available to the public.] From Lyle_Seaman at transarc.com Tue Sep 28 07:06:20 1993 From: Lyle_Seaman at transarc.com (Lyle_Seaman at transarc.com) Date: Tue, 28 Sep 93 07:06:20 PDT Subject: idiotic government regulations: DO SOMETHING! In-Reply-To: <9309280748.AA20432@longs.lance.colostate.edu> Message-ID: <wge3hVb0Bwwb4vqiZT@transarc.com> "L. Detweiler" <ld231782 at longs.lance.colostate.edu> writes: > Here's everyone's chance to do something *constructive* about idiotic > government regulations. Imagine this -- an email address to report them! Oh, beautiful. Just like the government: > ------- Forwarded Message > > Date: Sun, 26 Sep 93 23:14:39 EDT > From: "Paul Jones" <pjones at sunsite.unc.edu> > Subject: REGO needs your suggestions - soon ... > On September 11, 1993, President Clinton signed an executive order ... > For immediate impact, send your responses by electronic mail before > September 28, 1993. Yup, gives a lot of time for feedback. Lyle Transarc 707 Grant Street 412 338 4474 The Gulf Tower Pittsburgh 15219 From romana at apple.com Tue Sep 28 08:16:19 1993 From: romana at apple.com (Romana Machado) Date: Tue, 28 Sep 93 08:16:19 PDT Subject: GIF experts Message-ID: <9309281512.AA28646@apple.com> Hi Shari, I am not quite an expert on GIFs, but I know a thing or two about manipulating digital images to hide information - steganography, and I am writing a shareware tool for the MAC that can embed data undetectably within GIF images. The first release date is scheduled for October 15. I am also working on providing an IBM version of this about one month later. If this interests you, let me know. Cheers, Romana romana at apple.com From mab at crypto.com Tue Sep 28 09:46:19 1993 From: mab at crypto.com (Matt Blaze) Date: Tue, 28 Sep 93 09:46:19 PDT Subject: FAX # for Clipper Comments Message-ID: <9309281631.AA29750@crypto.com> I just checked with NIST; they are accepting FAX comments on the Escrowed Encryption Standard until close-of-business today. The number is 301-948-1784 -matt From stig at netcom.com Tue Sep 28 09:51:30 1993 From: stig at netcom.com (Stig) Date: Tue, 28 Sep 93 09:51:30 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <nowhere@bsu-cs.bsu.edu> Message-ID: <9309281647.AA25164@netcom4.netcom.com> It should be noted that although it is illegal for the cops/feds/spooks to tap phone lines without a warrant, only illegally-obtained voice communications are inadmissible in court. This means that fax and modem communications can be illegally intercepted and STILL used in court against you. Stig ;; __________________________________________________________________________ ;; Stig at netcom.com netcom.com:/pub/stig/00-PGP-KEY ;; It's hard to be cutting-edge at your own pace... 32 DF B9 19 AE 28 D1 7A ;; Bullet-proof code cannot stand up to teflon bugs. A3 9D 0B 1A 33 13 4D 7F From mnemonic at eff.org Tue Sep 28 12:21:32 1993 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 28 Sep 93 12:21:32 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <9309281647.AA25164@netcom4.netcom.com> Message-ID: <199309281919.AA17954@eff.org> Stig writes: > It should be noted that although it is illegal for the cops/feds/spooks to tap > phone lines without a warrant, only illegally-obtained voice communications > are inadmissible in court. This means that fax and modem communications can > be illegally intercepted and STILL used in court against you. The same is true of e-mail over the Internet--there is no statutory exclusionary rule that would prvent its admissibility in court. It is at least theoretically possible, however, to exclude illegally seized communications of these sorts using a "pure 4th Amendment" (nonstatutory) exclusionary rule. Don't hold your breath, though. --Mike From allan at elvis.tamu.edu Tue Sep 28 12:51:32 1993 From: allan at elvis.tamu.edu (Allan Bailey) Date: Tue, 28 Sep 93 12:51:32 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <199309281919.AA17954@eff.org> Message-ID: <9309281950.AA04308@elvis.tamu.edu> Mike Godwin writes: >Stig writes: >> are inadmissible in court. This means that fax and modem communications can >> be illegally intercepted and STILL used in court against you. > >The same is true of e-mail over the Internet--there is no statutory >exclusionary rule that would prvent its admissibility in court. It is at >least theoretically possible, however, to exclude illegally seized >communications of these sorts using a "pure 4th Amendment" (nonstatutory) >exclusionary rule. > >Don't hold your breath, though. I don't think e-mail over the Intenet will ever be used in court since anyone capable of reading the RFC would be able to forge email. So, anyone could claim that the email being used as evidence is a forgery _and_ be able to prove it by doing it or demonstrating it. At least, I think this would be a way to get it thrown out. :-) I'm not a lawyer, I don't even pretend to be one on MUD. Allan From ssimpson at eff.org Tue Sep 28 13:21:32 1993 From: ssimpson at eff.org (Sarah L Simpson) Date: Tue, 28 Sep 93 13:21:32 PDT Subject: No Subject Message-ID: <199309282015.AA18701@eff.org> I'm happy to say that there were 225 letters offering comments on the proposed key escrow system sent to the cryptnow at eff.org address. They were printed out and delivered today. Many thanks to all who responded to the call for action. I've gotten really positive responses to the post and our electronic mail mechanism. If you think that this sort of notice helped you to be informed and participate in policy, please drop me a note at ssimpson at eff.org. Let me know if you think that this is an important service that EFF can provide for the online community. Below is the text of the comments that EFF filed with NIST today. ================================ September 27, 1993 National Institute for Standards and Technology ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 Gaithersburg, MD 20899 To The Director: The Electronic Frontier Foundation (EFF) writes in strong opposition to the Proposed Federal Information Processing Standard (FIPS) for an Escrowed Encryption Standard, docket # 930659-3159. We believe that NIST's guidance in setting technical standards for security and privacy protection is a critical part of the growth of the National Information Infrastructure, but any action on the proposed escrow technical standards must await the resolution of several fundamental policy issues. Thus, at this time, we oppose the proposed FIPS in all of its parts. Well over 200 EFF members are also critical of the Proposed FIPS. We believe this demonstrates the depth of public concern about the implementation of key escrow systems. EFF is a nonprofit, public interest organization whose public policy mission is to ensure that the new electronic highways emerging from the convergence of telephone, cable, broadcast, and other communications technologies enhance free speech and privacy rights and are open and accessible to all segments of society. Introduction Widespread, affordable cryptography is vital for the protection of individual privacy in the Information Age. As more and more personal information flows around electronic networks, we all need strong encryption to safeguard information from unwanted intrusion. Personal information, such as health care records, private communications among friends and families, and personal financial transactions, will also travel over this information infrastructure. The business community can only make full use of the infrastructure if it is assured that the data it transmits is secure from unauthorized interception. In short, if communications in the new infrastructure are vulnerable, all of our lives and businesses would be subject to both damaging and costly privacy and security losses. Resolve Policy Issues and Objectives Before Promulgating Technical Standards EFF has been in ongoing dialogue with NIST, the White House, and Congress regarding the very complex public policy choices raised by cryptography policy. We are hopeful that this dialogue will result in a positive, comprehensive set of cryptography and privacy policies. But until these issues are resolved, we believe any approval of technical standards is premature. Among the public policy issues to be resolved are the following: 1. Guaranteed Continued Legal Use of All Forms of Encryption When the Clinton Administration announced the Clipper Chip, it assured the public that this would be a purely voluntary system. We must have legal guarantees that Clipper is not the first step toward prohibition against un-escrowed encryption. Yet the Administration has not offered any such guarantees, either in the form of proposed legislation or even agency rules. 2. Identity of Escrow Agents When Clipper was first proposed, some in the Administration suggested that one of the two escrow agents would be a government agency and the other a private, non-governmental organization. Now it appears that plans for a private escrow agent have been dropped in favor of NIST and the Department of Treasury, though there is still no final designation of agents. We are unable to comment on the security or reliability of escrow procedures proposed here when we do not know who will be administering the escrow databases. We also note that there is active consideration of having more than two escrow agents. This option should be explored from a policy perspective before a technical standard is adopted. 3. Legal Rights of Escrow Users If individuals do choose to deposit their keys with the government, or any other escrow agent, they must have some legal recourse in the event that those keys are improperly released. However, the most recent draft of escrow procedures specifically states: "These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired." Leaving users with no recourse will discourage use of the system and provides little disincentive against unscrupulous government behavior. In the Proposed FIPS, NIST also suggests an unusual and, we believe, incorrect notion of what an escrow agent is. The Proposed FIPS adopts the incomplete definition of an escrow system found in Webster's Dictionary. The Proposed FIPS states: To escrow something (e.g., a document, an encryption key) means that it is "delivered to a third person to be given to the grantee only upon the fulfillment of a condition." (Webster's Seventh New Collegiate Dictionary). This definition omits the very basic notion that an escrow agent has responsibilities to those who deposit things of value in the escrow account. Black's Law Dictionary, which we believe may be a more appropriate source of information about escrow relationships, states that an escrow contract is an: Agreement between buyer, seller, and escrow holder setting forth rights and responsibilities of each. It is the general legal rule that one who deposits value with an escrow agent is entitled to recover damages from the escrow agent in the event of a breach of the agent's duty of care: Depositor is entitled to recover damages sustained because of escrow agent's unwarranted act, and where grantee participates in wrongful delivery he also may be liable, but recovery is limited to damages actually attributable to wrongful delivery. Collier v Smith (Mo App) 308 SW2d 779. (See ANNOTATION: Who must bear loss resulting from defaults or peculations of escrow holder. 15 A.L.R.2d 870.) The notion of an escrow agent who is insulated from all liability to the depositor is wholly alien to American law and custom. The government may, of course, seek to establish escrow agents free of legal liability, but this is fundamentally a policy choice, not a matter of technical standards. Until there is some agreement on the real responsibilities of the escrow agents, NIST is not in a position to set technical and operating standards. 4. Open, Trusted Standards: A key goal of the Clipper Proposal is to promote widespread encryption in the marketplace. Yet people will not use encryption unless they trust it. Secret standards such as Clipper cannot be evaluated by independent experts and do not deserve the public trust. Other parties, including Whitfield Diffie of Sun Microsystems, have commented extensively on this issue. EFF fully subscribes to those remarks. Insufficient Technical and Operating Information Available for Comments Even aside from the major policy issues left unanswered, the Proposed FIPS itself lacks the detail necessary to allow full public comment. First, the full operating procedures for the escrow agents has yet to be issued. Public comment must be sought on the complete procedures, not just the outline presented in the draft FIPS. Even the government-selected algorithm review group has declared that it needs more information on the escrow process. Second, asking for comments on an algorithm that is classified makes a mockery of citizen participation in government decision-making. Action on the Proposed FIPS Must Be Delayed to Allow Completion of Public-Private Consultation Mandated by Presidential Decision Directive President Clinton's announcement of the Clipper initiative made very clear that there should be "early and frequent consultations with affected industries, the Congress and groups that advocate the privacy rights of individuals as policy options are developed" (April 16, 1993 Press Statement). EFF and other organizations have invested significant effort in dialogue and policy review with the Administration. We have made some progress, but many issues remain unresolved. EFF believes that for NIST to rush forward with a FIPS in advance of resolving the fundamental policy issues cited above would prematurely curtail the dialogue that the President ordered. Finally, NIST will be involved in making many critical decisions regarding the National Information Infrastructure. The next time NIST solicits public comments, it should be ready to accept reply by electronic mail in addition to paper-based media. Over 200 of EFF's members e-mailed comments to our offices, which we then printed and hand-delivered to NIST. We hope that in the near future, NIST and other federal agencies will be prepared to accept comments directly via the Internet. Respectfully Submitted, Jerry J. Berman Daniel J. Weitzner Executive Director Senior Staff Counsel ****************************** Sarah L. Simpson Membership Coordinator Electronic Frontier Foundation 1001 G Street, NW Suite 950 East Washington, DC 20001 202/347-5400 tel 202/393-5509 fax From mpjohnso at nyx.cs.du.edu Tue Sep 28 13:26:20 1993 From: mpjohnso at nyx.cs.du.edu (Michael Johnson) Date: Tue, 28 Sep 93 13:26:20 PDT Subject: MPJ Encryption Algorithm comments Message-ID: <Pine.3.05.9309281458.B7822-9100000@nyx> Due to an unfortunate circumstance beyond my control, all of my mail from this group for the last 30 hours got forwarded to /dev/null. If anyone had comments on the MPJ Encryption algorithm, please send them to me again at mpj at csn.org or mpjohnso at nyx.cs.du.edu. Mike From mnemonic at eff.org Tue Sep 28 13:31:33 1993 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 28 Sep 93 13:31:33 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <9309281950.AA04308@elvis.tamu.edu> Message-ID: <199309282026.AA18872@eff.org> Allan writes: > I don't think e-mail over the Intenet will ever be used in court > since anyone capable of reading the RFC would be able to forge email. > So, anyone could claim that the email being used as evidence is a > forgery _and_ be able to prove it by doing it or demonstrating it. This is not how evidence works. The fact that Internet mail can be forged may cast doubt on the authenticity of a message, but it wouldn't result in its inadmissibility. The jury can make its own decision about whether the mail is authentic, based on full information about the possibility of forgery. --Mike From cme at ellisun.sw.stratus.com Tue Sep 28 13:46:22 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Tue, 28 Sep 93 13:46:22 PDT Subject: Phil Zimmerman on 'The Death of DES' Message-ID: <9309282044.AA26047@ellisun.sw.stratus.com> Single DES is weak, for a known plaintext attack. I think we knew that. We didn't know how weak. We can extrapolate to an NSA machine with 1 second scan of all keys, perhaps. So -- 1. use triple DES 2. before using DES, XOR with a stream from a decent PRNG (destroying the known plaintext) 3. in between DES operations, mix bytes up as with tran (posted on sci.crypt occasionally, avbl from me by mail or on ripem.msu.edu) -- spreading bytes out within a huge block, further hiding any known text - Carl From mpjohnso at nyx.cs.du.edu Tue Sep 28 14:36:22 1993 From: mpjohnso at nyx.cs.du.edu (Michael Johnson) Date: Tue, 28 Sep 93 14:36:22 PDT Subject: Challenge: break the MPJ Encryption Algorithm In-Reply-To: <9309282029.AA26018@ellisun.sw.stratus.com> Message-ID: <Pine.3.05.9309281542.A16613-a100000@nyx> On Tue, 28 Sep 1993, Carl Ellison wrote: > Is each of your 160 permutation arrays a self-inverse or do you generate > different arrays for encryption and decryption? No, they are not self inverses. The inverses are computed from the forward arrays to decrypt in electronic codebook mode. Note that in some chaining modes, the reverse mode isn't even needed, and the arrays could literally be filled with random numbers. Mike Johnson Long live the U. S. Constitution! From VACCINIA at UNCVX1.OIT.UNC.EDU Tue Sep 28 15:11:35 1993 From: VACCINIA at UNCVX1.OIT.UNC.EDU (VACCINIA at UNCVX1.OIT.UNC.EDU) Date: Tue, 28 Sep 93 15:11:35 PDT Subject: Rep. Gejdenson's NET address Message-ID: <01H3HOLMKMOY006CDY@UNCVX1.OIT.UNC.EDU> >Still the NSA can't stave off the inevitable for long. Gejdenson hopes to >produce legislation by early next year to revamp government policy on high >tech exports. Rep. Gejdensons NET address is: bozrah at hr.house.gov for those of you who care to write him. This is a receive address only, he can't as of yet respond. Scott G. Morham ! The First, Vaccinia at uncvx1.oit.unc.edu ! Second ! and Third ! Levels of ! Information Storage and Retrieval ! DNA, ! Biological Neural Nets, ! Cyberspace From pmetzger at lehman.com Tue Sep 28 16:11:35 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 28 Sep 93 16:11:35 PDT Subject: Phil Zimmerman on 'The Death of DES' In-Reply-To: <9309282044.AA26047@ellisun.sw.stratus.com> Message-ID: <9309282309.AA15986@snark.lehman.com> I personally favor triple DES + IDEA. The notion is that if triple DES is weak maybe IDEA isn't, and vice versa -- you are no weaker than the strongest of the two systems. Perry Carl Ellison says: > Single DES is weak, for a known plaintext attack. I think we knew that. > We didn't know how weak. > > We can extrapolate to an NSA machine with 1 second scan of all keys, > perhaps. > > So -- > > 1. use triple DES > > 2. before using DES, XOR with a stream from a decent PRNG (destroying > the known plaintext) > > 3. in between DES operations, mix bytes up as with tran (posted on > sci.crypt occasionally, avbl from me by mail or on ripem.msu.edu) > -- spreading bytes out within a huge block, further hiding any > known text > > - Carl From nate at VIS.ColoState.EDU Tue Sep 28 16:46:34 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Tue, 28 Sep 93 16:46:34 PDT Subject: saturation tactics? In-Reply-To: <93Sep28.005832pdt.14165-1@well.sf.ca.us> Message-ID: <9309282346.AA20111@nagel.VIS.ColoState.EDU> George A. Gleason coersed the electrons into symbolizing: >yeah, here's a cheaper version. Write to the arms excport license people >and pester them with questions: I'm a BBS operator, what should I do?; I'm a >businessperson travelling overseas and need my crypto to comm with the home >office what should I do?; all this kind of thing. Swamp them with letters. >Every person and every circumstance which even remotely fits. > >An alternative version which would require more guts and perhaps a serious >conscientious decision about whether it's worth making this an act of civil >disobedience, is to write to them and say, "I'm a BBS operator, not an arms >merchant, and on the strength of my 1st-A rights I'm not going to censor my >board or get a license..." or "I'm a businessperson who travels & takes my >cryupto out of the country on my laptop to comm with the home office; I'm >not an arms dealer either and I don't intend to get a license..." And >again, there is strength in numbers here. > >And of course, a good steganographic program or two would be a very nice >development indeed, Just In Case. > >-gg > I would favor this oprion, since each person could write several letters, each addressing a separate topic/gripe/question. BTW, what is the snail-mail address to send these letters to? -nate -- +-------------------------------------------------------------------- | Nate Sammons email: nate at VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate at monet.VIS.ColoState.Edu for my PGP key | #include <std.disclaimer> | Always remember "Brazil" +----------------------+ From VACSC0D4 at VAX.CSUN.EDU Tue Sep 28 17:16:22 1993 From: VACSC0D4 at VAX.CSUN.EDU (VACSC0D4 at VAX.CSUN.EDU) Date: Tue, 28 Sep 93 17:16:22 PDT Subject: No Subject Message-ID: <930928171300.3286@VAX.CSUN.EDU> A little over a month ago, I called Mykotronx and asked for information about the Clipper chip. Their response was vague: we're working on some ap notes, but they're not ready yet. I called back today. The person who answered the phone put me on hold for a minute, then came back and told me she had spoken to the VP of engineering and that the ap notes would be ready in four weeks. It looks like Clipper has really been put into high gear. When they are ready, I'll try to get them and post the interesting stuff here. -- MikeIngle at delphi.com (using my student account; don't reply here - reply to Delphi) From smb at research.att.com Tue Sep 28 17:16:35 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 28 Sep 93 17:16:35 PDT Subject: Disturbing statistics on wiretaps Message-ID: <9309290015.AA12269@toad.com> The same is true of e-mail over the Internet--there is no statutory exclusionary rule that would prvent its admissibility in court. It is at least theoretically possible, however, to exclude illegally seized communications of these sorts using a "pure 4th Amendment" (nonstatutory) exclusionary rule. Don't hold your breath, though. Do you really think that? One could argue, fairly strongly, that the rules set forth in the ECPA have created an expectation of privacy, and that a violation of that expectation would be exactly the violation of the 4th Amendment that the Supreme Court addressed in the 1967 decision that led to the original wiretap provisions in the Omnibus Crime Control and Safe Streets Act. From baumbach at atmel.com Tue Sep 28 17:16:38 1993 From: baumbach at atmel.com (Peter Baumbach) Date: Tue, 28 Sep 93 17:16:38 PDT Subject: the public key minefield Message-ID: <9309282214.AA01006@bass.chp.atmel.com> > The question is phrased improperly. Apart from the fact that the > concept (though not the reality) of anti-gravity is prior art, they > didn't patent the concept of public-key cryptography. Rather, they > patented a class of devices fitting a certain description, with one > public key cryptosystem as an example and as a separate set of claims. > To use your analogy, I could patent anti-gravity achieved by interposing > a screen of some substance opaque to gravity, and patent Cavorite as > an instance of that class. If you had another use for Cavorite, you'd > be home free. Or if you found a way to neutralize gravity by beaming > anti-gravitons downward, you'd probably be clear, too. But if you > found another substance besides Cavorite that was opaque to gravity -- > yes, that would be covered by my patent. (Fortunately, H.G. Wells didn't > patent his literary device. But I can't think of another science > fiction author who used that technique....) > > It's certainly possible that all possible cryptosystems that achieve the > same effect would be covered by their description. That, of course, is > the mark of a good patent attorney's work -- that he or she managed to > fashion so broad a claim. But maybe you can find a better way to do what > you really want to do, which is trade keys and authenticate messages. I think you have convinced me. I don't want to be convinced, so maybe I will try again later, when I have learned more about it. ;-) This means to me, that you cannot patent a broad claim, until you have a narrow specific example of it. Anti-gravity had prior art, public key systems did not. If without inventing a public key system, someone had described the concept in general terms, then prior art would exist for this as well. The person who invented the wheel (or sled?) might have been able to have claims broad enough to cover hovercrafts. > And if you do -- well, then, the patent system has succeeded in its goals, > in that the monopoly assigned to someone else has stimulated you to find > another way to do things, and thus furthered the useful arts and sciences. At what expense? Will our government win some battles, it might otherwise lose to the cypherpunks? Would legal access to pgp, now, be a deciding factor to maintaining legal access to non-clipper encryption later? Peter Baumbach baumbach at atmel.com From svet at nrcbsa.bio.nrc.ca Tue Sep 28 17:51:35 1993 From: svet at nrcbsa.bio.nrc.ca (Svetlana Borisova) Date: Tue, 28 Sep 93 17:51:35 PDT Subject: the public key minefield (fwd) Message-ID: <9309290047.AA02306@ nrcbsa.bio.nrc.ca> svet wrote: From plaz at netcom.com Tue Sep 28 18:31:36 1993 From: plaz at netcom.com (Geoff Dale) Date: Tue, 28 Sep 93 18:31:36 PDT Subject: Clinton UN Speech / Msg to Prez/VP Message-ID: <9309290127.AA07856@netcom.netcom.com> Perry Metzger states (perhaps incorrectly): >Mike Ingle says: >> In his UN speech this morning, Clinton talked about cracking down on nuke >> and missile proliferation, and he also mentioned eliminating cold-war-era >> restrictions which are harming American business. Let's put together a >> message to president at whitehouse.gov and vice-president at whitehouse.gov >> (since Gore is the info-highway guru) stating our position. > >Messages sent to president at whitehouse.gov are weighed, not read. I >suspect this will have about as much effect on the president as a note >written in a bottle and tossed into the ocean. > >However, on that basis, its perfectly harmless for you to send a >letter saying anything whatsoever other than a threat on the >president's life, so if you and others would like to spend time >writing such a thing, you can feel free. Just remember that there is >no cypherpunks organization, so you can't claim to represent us. Depends how you define harmless. If I recall the original e-mail release correctly, they do archive all messages. No assurances are made that these messages will not be used against you (ie- might end up in some file on you; I doubt that it would be used in court). To reenforce Perry's point: Any threats against the Prez or his clan WILL get forwarded to the secret service, so DON'T pull that one. Death threats are useless (and most likely counter-productive) tactics anyway. But writing letters to that address are probably at least as effective as writing to him via US Snail. Keep the message focused on one idea (remember it will probably be tabulated as for or against an issue) and make sure that the message gets across clearly. Who knows, if a enough messages get through on a subject, Bill or Al might get a one line statement in one of there meetings saying that the online community is "up in arms" about skipjack or the pgp subpoenas. _______________________________________________________________________ Geoff Dale -- insert standard disclaimers here -- plaz at netcom.com "Communists! Those bug-brained motherfuckers are even worse than the schmucks who think they run things here." - Norman Spinrad, from his novel "Little Heroes" From charliemerritt at BIX.com Tue Sep 28 19:06:22 1993 From: charliemerritt at BIX.com (charliemerritt at BIX.com) Date: Tue, 28 Sep 93 19:06:22 PDT Subject: CLIPPER CHIP /NO! Message-ID: <9309282158.memo.25178@BIX.com> Dear Mr. Prisident: I do not like the "Big Brother Inside" Clipper chip. Wire Taps need to be hard to do. I know you and Al are nice guys, but Richard Nixon and his plumbers could come back! A crypto chip with a government trapdoor (key escrow) is an idea fit for a J. Edgar Hoover, not nice people. Please dont make a techno-fool of your administration. A Razorback Fan from Arkansas...Charlie Merritt [charliemerritt at bix.com] From mnemonic at eff.org Tue Sep 28 19:31:36 1993 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 28 Sep 93 19:31:36 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <199309290015.AA21015@eff.org> Message-ID: <199309290230.AA22137@eff.org> smb at research.att.com writes > The same is true of e-mail over the Internet--there is no > statutory exclusionary rule that would prvent its > admissibility in court. It is at least theoretically possible, > however, to exclude illegally seized communications of these > sorts using a "pure 4th Amendment" (nonstatutory) exclusionary > rule. > > Don't hold your breath, though. > > Do you really think that? One could argue, fairly strongly, that the > rules set forth in the ECPA have created an expectation of privacy, > and that a violation of that expectation would be exactly the violation > of the 4th Amendment that the Supreme Court addressed in the 1967 > decision that led to the original wiretap provisions in the Omnibus > Crime Control and Safe Streets Act. What's your point? One can argue all sorts of things. Are you saying you have reason to believe an argument of this sort is likely to be a winner? Me, I just work from what I know about 4th Amendment caselaw. --Mike From doug at netcom.com Tue Sep 28 19:31:38 1993 From: doug at netcom.com (Doug Merritt) Date: Tue, 28 Sep 93 19:31:38 PDT Subject: the public key minefield (fwd) In-Reply-To: <svet@nrcbsa.bio.nrc.ca> Message-ID: <9309290227.AA09947@netcom4.netcom.com> [ In the following 100 line post about the origin and philosophy of relevent law, I gradually lead in to privacy issues; I discuss U.S. laws regarding patents and privacy and such because I am largely unfamiliar with such laws in other countries; mea culpa. If you don't really care about legal issues, skip this. ] Svetlana Borisova <svet at nrcbsa.bio.nrc.ca> said: >smb at research.att.com wrote: > And if you do -- well, then, the patent system has succeeded in its goals, > in that the monopoly assigned to someone else has stimulated you to find > another way to do things, and thus furthered the useful arts and > sciences. > Of course, wonderful idea! Hey, let's patent all irrigating systems >so that people have to think of other ways to make plants grow. I agree that the patent system in the U.S. (and elsewhere, 'though I know much less about that) has severe faults in implementation. The entire area of software patents is being grossly mishandled, for instance. On the other hand, you seem to have a distaste for the entire *theory* behind it, and I must differ on that point. The legal philosophy of patents is to encourage invention that will be of value to society in general. It is *not* directly intended for the benefit of the person holding the patent, although it often seems to work out that way. "smb" is referring to that philosophy. The alternative to the general philosophy is to refuse to grant legal protection to invention. >The goal of patents is to give a researcher a reward for his invention; to >give him the opportunity to make money off it. This is incorrect; ask any patent attorney. In the U.S., anyway. Ask a Canadian patent attorney...but I'm 99.9% sure that Canada follows precisely the same legal philosophy. In the U.S., the legal philosophy is derived from the fundamental meta- philosophy of its law which evolved out of British common law dating back to at least the Magna Carta, which is that (loosely) the purpose of law is for the common good. Every year there are cases in the U.S. where judges make a "surprising" decision that overturns the apparent letter of the law in favor of an appeal to the common good of society. Case law is filled with such things. There is always a tradeoff against rights of the individual. But the Magna Carta itself was necessary in order to begin to establish some rights for individuals against that of society (as represented in that time by the sovereign). Similarly in the U.S., the Bill of Rights acts to establish those minimal rights. But whereever the Bill of Rights is not explicit, on average you can expect courts to rule in favor of the rights of society. (And sometimes even then...) There are some cases where this is easy to view as a bad thing, others where it seems clearly a bad thing. But there is nonetheless many centuries of tradition behind this approach. Patent law is merely one more example. As smb said, it offers a monopoly for an individual, which would usually be considered to be contrary to the good of society. But it does so in order to foster more invention, which is considered to be a good for society. It simply appeals to individual avarice for the sake of the common good, trading off the global long term good against the short term loss. In short, it has an unusual lack of short-sightedness to it...in *theory*. Patent law most certainly and unquestionably is *not* in existence for the benefit of the inventor, like it or not. If you are implying that you think that there should never be legal protection for intellectual property of any sort, as e.g. Stallman has told me he believes, then we'll just have to agree to disagree. Stallman believes that such a philosophy is in favor of individual rights, but historically that philosophy has resulted in a *loss* of individual rights. But then, Stallman isn't too hot on history of law... If on the other hand you merely mean that you disagree with the way that the patent system is working out in a lot of cases currently in the U.S., then you should be more careful to distinguish the legal theory from the legal implementation of the theory. It's very much like the U.S. Bill of Rights in theory versus practice; the two can be quite different. Cypherpunks is in large part about privacy. In Roe versus Wade, privacy was (rather amazingly) held to be an implication of the U.S. Constitution, and as a side effect abortion was judicially held to be legal. The right to privacy is not explicitly spelled out in the Constitution nor Bill of Rights, though, and so most courts, including the U.S. Supreme Court, have far more often held that there is no automatic right to privacy. That's why Roe vs. Wade was both amazing at the time, and has been in such jeopardy since. California is an interesting case, because its state constitution *does* guarantee a right to privacy, but that doesn't slow down the right to life protests, naturally, just as an aside. :-) Public key cryptography is a mechanism for privacy. There are vast complications because: 1) Privacy is not explicitly guaranteed by the U.S. Constitution. 2) Privacy is not generally guaranteed by case law, Roe vs. Wade aside. 3) The patent claims for public key cryptography are overly broad, demonstrating obvious incompetence on the part of the patent examiners involved, yet to correct this injustice would require a test case in which the plaintiff willingly exposed himself to the potential of large damages. 4) This effectively makes the only known methods for *technically* private long distance communication via any media impractical for *legal* reasons. 5) Even in California, the state constitution is of no help, because the applicable patent law and privacy case law are in the federal domain, not the state's -- at least by default. Again it would take an actual court decision to decide otherwise, which doesn't appear likely. The question is what to do given all of this. If one works within the system, the answer is to find someone with bucks for a defense and devise a test case...one intended to lose at every level until it reaches the Supreme Court, where it is then intended to win and thus establish ultimate precedent. Chancy proposition. The other in-system approach is to lobby and to educate. Also chancy. But worth doing. Doug P.S. I am not a lawyer, nor do I play one on t.v. From russell at eternity.demon.co.uk Tue Sep 28 20:21:37 1993 From: russell at eternity.demon.co.uk (Russell Earl Whitaker) Date: Tue, 28 Sep 93 20:21:37 PDT Subject: CONFERENCE: European Computers, Freedom & Privacy Message-ID: <16612@eternity.demon.co.uk> -----BEGIN PGP SIGNED MESSAGE----- ECFP '93: The First European Conference on Computers, Freedom and Privacy The New Cavendish Club London, England 20th November 1993 Organised by ECFP Ventures Limited Co-operating organisations : The Libertarian Alliance Privacy International, UK UK Cryptoprivacy Association SCOPE - ---------------------------------- The widespread use of computers and communication systems has brought considerable benefits to our business and personal lives and will continue to change and shape the way in which we live. However, with those benefits come unprecedented threats to our personal privacy and potential for abuse. A variety of different models for protection of individual privacy in the electronic age have been suggested, ranging from state regulation to individual action through the use of strong cryptography. However, these solutions bring with them their own class of problems, including excessive state involvement in private matters and the frustration of law enforcement and national security objectives. The First European Conference on Computers, Freedom and Privacy will both provide an introduction to these issues and the technological developments that drive them, and examine different ways in which individual rights can be guaranteed. These questions are central to the preservation of a free society in the Information Age. John M. Brimacombe Conference Chair KEYNOTE SPEAKER - ---------------------------------- John Gilmore Email: gnu at cygnus.com JOHN GILMORE is Chairman of the Board of Cygnus Support, who provide commercial support for free software. As founder and board member of the Electronic Frontier Foundation and the Cypherpunks, he has campaigned extensively for electronic privacy. John will speak on building a society in which personal privacy is guaranteed through the use of strong cryptography. OTHER SPEAKERS - ---------------------------------- John Brimacombe (Chairman) Email: john at mantis.co.uk JOHN BRIMACOMBE is the Managing Director of Jobstream Group plc, developers of business software. A graduate in both law and computer science, he was an advisor to CFP '93 in San Francisco. John will serve as conference moderator. Simon Davies Email: davies at privint.demon.co.uk SIMON DAVIES is Director General of Privacy International and a member of the School of Law at the University of New South Wales. He will be looking at new developments in surveillance and ways of combating them. Tom Burroughes Email: tom at reptile.demon.co.uk (after 10 October 1993) TOM BURROUGHES is Deputy Chief Reporter with the East Anglian Daily Times in Ipswich, England. He will be giving a journalist's point of view on privacy issues, including recent incidents involving eavesdropping on cellular telephones, and the roles of various corporate and government bodies in the recent adoption of cellphone signal encryption standards in the UK. David Chaum Email: chaum at digicash.nl DAVID CHAUM is head of the Cryptography Group at the Center for Mathematics and Computer Science (CWI) in Amsterdam, and founder of DigiCash, which develops electronic payments systems. Dr. Chaum received his Ph.D. in computer science from the University of California, Berkeley, in 1982, and joined CWI in 1984. He helped to found the International Association for Cryptologic Research and remains active on its board. David also consults internationally on cryptology. Duncan Frissell Email: frissell at panix.com DUNCAN FRISSELL is an attorney, technical author and consultant on matters of personal and financial privacy. Duncan will speak on "Traditional Privacy in the Electronic Age". Elaine Fletcher ELAINE FLETCHER is Assistant Solicitor for Eric James Howe, Data Protection Registrar (UK). Elaine will speak on issues arising from the Data Protection regime established under the 1984 Data Protection Act. Chris Tame CHRIS TAME is the Director of the Libertarian Alliance and Director of the smokers rights group FOREST, as well as UK representative of the Libertarian International. He has written extensively for such academic journals as /Science and Public Policy/, /Economic Affairs/, and /The Jewish Journal of Sociology/, and such books as *The Case For Private Enterprise* and *The Politics of Crime Control*. He appears regularly on radio and television in the UK. Chris will speak on the libertarian views of data protection and privacy. Russell Whitaker Email: whitaker at eternity.demon.co.uk RUSSELL WHITAKER, conference co-organiser, is a consultant on electronic communications, a director of ECFP Ventures Ltd and communications editor of Extropy magazine. Russell will speak on the composition of, and influences upon, the electronic community in Britain today, and how public policy affects those on computer bulletin boards and online services. PROGRAMME - --------------------------------- Registration 9.30 - 10.00 am First session 10.00 - 11.30 am BREAK 11.30 - 11.50 am Second session 11.50 am - 1.20 pm BREAK 1.20 - 2.20 pm Third session 2.20 - 3.50 pm BREAK 3.50 - 4.10 pm Fourth session 4.10 - 5.40 pm PANEL SESSION 5.40 - 6.20 pm Closing remarks 6.20 - 6.30 pm Lunchtime is the break after the second session, and lunch itself is not included in the price of the conference. There are pubs and restaurants in the immediate vicinity. Coffee, tea and biscuits will be on sale through the day, however. Registration form: - --------------------------------- NAME _____________________________________ JOB TITLE _____________________________________ ORGANISATION/AFFILIATION _________________________ ___________________________________________ MAILING ADDRESS _____________________________________ ____________________________________________________ ____________________________________________________ ____________________________________________________ TELEPHONE ___________________________________________ FAX ___________________________________________ E-MAIL ___________________________________________ IMPORTANT NOTE: only *fully* completed forms with full telephonic details will be accepted, to be used in the event of any emergency changes, such as change of venue. This is not optional. CLASS OF REGISTRATION : [Prices are Pounds Sterling] Student 10.00 ($16.00 U.S.) Normal 17.50 ($28.00 U.S.) Normal before 1 Nov 93: 15.00 ($24.00 U.S.) Press (Contact for arrangements) MEANS OF PAYMENT: - U.S. cheques/cash - U.K. cheques/cash - EuroCheques (tm) Unfortunately, due to bank conversion charges, we are unable to accept cheques drawn on other overseas accounts, for payment of this year's attendance fees. PROCEEDINGS AND AUDIO/VIDEOGRAPHY - ------------------------------------------- You may pre-order copies of transcripts of the proceedings, which will be shipped within 90 days after the conference: "Please send me ____ copies of the conference proceedings at 20 pounds each." Video and audio recordings will be made of the conference, in its entirety. No pre-sales will be made; tapes go on sale in December 93/January 94. Cheques, made payable to "ECFP Ventures Limited", should be sent with this form to : 16 Circus Road MM Box 8593 London NW8 6PG England Please direct any further enquiries to the above address, or: ecfp-1st at eternity.demon.co.uk (Email) +44 81-812-2661 (Manned message service; quick response) HOW TO FIND THE NEW CAVENDISH CLUB : - ---------------------------------------------- The New Cavendish Club is 2 minutes walk from Marble Arch Underground station. Immediately turn right as you exit from the station onto Oxford Street. Then take the first turning on the right, i.e. Great Cumberland Street. The New Cavendish Club is 3 blocks north on the northeast corner of the intersection of Great Cumberland Street with Upper Berkeley Street. Address: New Cavendish Club 44 Great Cumberland Place London W1H 8BS - ----- Text ends --------- -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLKjhjYTj7/vxxWtPAQGjQAP+NW1LOc806i0c3MmA2RiluzWmDKvFEPPm ibtU3tbqqF93fb0lqJ/z1q8DEtWeiG6LnLQ41IasIHDL6o7EmZEWXN6G17CDFLSk cQHCGaIpC9BkBI8VwnsPZIlItL5T+TkcOwLjdqp7x24tQ9uAm3BhpFLGMfLJAnwB xI/ZG0zMEIs= =QElR -----END PGP SIGNATURE----- Russell Earl Whitaker whitaker at eternity.demon.co.uk Communications Editor AMiX: RWhitaker EXTROPY: The Journal of Transhumanist Thought Board member, Extropy Institute (ExI) Co-organizer, 1st European Conference on Computers, Freedom and Privacy, London, 20 November 1993 From cdodhner at indirect.com Tue Sep 28 20:31:36 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Tue, 28 Sep 93 20:31:36 PDT Subject: Stickers Message-ID: <199309290329.AA27847@indirect.com> I recently received email from Whit Diffie regarding some concerns he had about the "Big Brother Inside(tm)" stickers. I asked for and received permission to repost the message to the group, however I seemed to have misplaced (ie, hit the wrong button) it, so I'll paraphrase. Firstly, he suggested that I wait before ordering/distributing the stickers because without clipper phones to put them on they may very well be stuck in random places, and that could reduce the impact of a good, focused, silmultanius distribution. Secondly, He asked that I try to add some more substantial information to the stickers, such as a short note that basicly says this phone is pre-tapped, use at your own risk. After some thought, I sent in the order anyway. My reasons for this action were that 1) Some people stated that they had already sent me money, and I wouldn't want to change the facts of the matter after the money was sent, and 2) Any more substantial information would increase the size of the sticker, which would make it more visible, harder to place, and would anger the owners of the property on which it was placed substantialy more. I think it is appropriate at this time to restate the reason that these stickers have been (are being) produced/distributed. Everyone on the list is familiar I'm sure with the clipper wiretap chip and the issues surrounding it. Everyone on the list I am equaly sure has seen at one time or another the "Intel Inside" stickers on Ibm and Dell and other computers, and in ads for those computer and ads paid for by intel itself. It is an image seen by a signifigant portion of the population each and every day. I was in a local computer store not too long ago when I heard a man ask a salesperson "Does this one have intel inside?" and I'm sure that he had not a clue in the world what that meant. Everyone on this list I'm fairly certain has either read George Orwell's famous book, _1984_, or has at least been exposed to it's influence of society through the introduction of such words and phrases as "Big Brother", "Thought Police", "Doublespeak", etc.. Horible images of goverment invasions of privacy, mass media mind control, and legalslation run amok come to mind quite easily... Our Big Brother Inside sticker has been designed to look as much like the intel logo as possible, without breaking any copyright laws or anything like that. But instead of conveying the message "This product contains parts built by a company you know and trust" our sticker seems to say, "This product is a tool built by the goverment to keep tabs on your personal life". It is intended to be descretely applied to telephones, faxes, modems, computers, and other devices containing the clipper or capstone chips or other key-escrowed technology. It is intended to be seen by those who would potentialy purchase such items, as an attempt to dissuade them from doing so. It is intended _NOT_ to be seen by the owners of establishments selling said items, as that would lead to thier removal at least; prosocution at most. I think another sticker, in brighter colors and containing informative text, could be usefull for applying to clipper phones etc that have already been deployed; a use at your own risk type thing. The time for that has not yet come. I hope I didn't leave anything out, Please use discretion regarding what messages get sent to the list and what can be handled through email. BTW; My total of sticker orders and contributions (not counting today) is: 6875 stickers sold $166 contributed I sent a check for $145 today, so everything past that is going to my cost to mail out the stickers to the people who ordered them. Any funds left over wil be used as a starting point for some cypherpunks tshirts, and proceeds from the shirts (if I ever do them) will go to the eff. Happy Hunting, -Chris ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner at indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" "If guns are outlawed, only the government will have guns." -E. Abbey My opinions are shareware. For a registered copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------ From Anonymous Tue Sep 28 17:44:00 1993 From: Anonymous (Anonymous) Date: Tue, 28 Sep 93 20:44:00 EDT Subject: the public key minefield In-Reply-To: <9309280140.AA22526@toad.com> Message-ID: <f838a5797815e73623d6e879cfcc848d@NO-ID-FOUND.mhonarc.org> smb at research.att.com wrote: > > Do you agree or disagree that: > > 'the concept of "anti-gravity" device is not patentable. > If I could duplicate the effect of your anti-gravity device without > using any of the same novel mechanisms. My device would be > separately patentable.' ? > > If you agree, then how can you patent "public key systems" as a > concept? > > If you disagree, then we can leave it at that. > > The question is phrased improperly. Apart from the fact that the > concept (though not the reality) of anti-gravity is prior art, they > didn't patent the concept of public-key cryptography. Rather, they > patented a class of devices fitting a certain description, with one > public key cryptosystem as an example and as a separate set of claims. > To use your analogy, I could patent anti-gravity achieved by interposing > a screen of some substance opaque to gravity, and patent Cavorite as > an instance of that class. If you had another use for Cavorite, you'd > be home free. Or if you found a way to neutralize gravity by beaming > anti-gravitons downward, you'd probably be clear, too. But if you > found another substance besides Cavorite that was opaque to gravity -- > yes, that would be covered by my patent. (Fortunately, H.G. Wells didn't > patent his literary device. But I can't think of another science > fiction author who used that technique....) Since the patent seems to cover all public key cryptography (or at least that's what PKP would like you to believe), the analogy would be more like patenting a 'device that erradicates effects of gravitational attraction in a localized area', ie. any anti-gravity device, when you actually developed only the Cavorite method. > It's certainly possible that all possible cryptosystems that achieve the > same effect would be covered by their description. That, of course, is > the mark of a good patent attorney's work -- that he or she managed to > fashion so broad a claim. But maybe you can find a better way to do what > you really want to do, which is trade keys and authenticate messages. > And if you do -- well, then, the patent system has succeeded in its goals, > in that the monopoly assigned to someone else has stimulated you to find > another way to do things, and thus furthered the useful arts and > sciences. Of course, wonderful idea! Hey, let's patent all irrigating systems so that people have to think of other ways to make plants grow. Let's patent the combustion engine so that people will think of other engine types. Let's patent hydro-electric dams to give more incentive to the controlled fusion researchers. While we're at it, let's patent electric devices altogether, so that people can think of other brilliant ways to make things work. While necessity is mother of invention, one must not forget which is more important: satisfying the necessity or making an invention. The goal of patents is to give a researcher a reward for his invention; to give him the opportunity to make money off it. -- =============================================================== Svetlana Borissova svet at nrcbsa.bio.nrc.ca National Research Council Canada Home: (613) 747-7820 Laboratory of Biological Sciences (M-54) Work: (613) 990-7381 Protein Crystallographer (613) 991-6981 =============================================================== -- =============================================================== Svetlana Borissova svet at nrcbsa.bio.nrc.ca National Research Council Canada Home: (613) 747-7820 Laboratory of Biological Sciences (M-54) Work: (613) 990-7381 Protein Crystallographer (613) 991-6981 =============================================================== From svet at nrcbsa.bio.nrc.ca Tue Sep 28 21:21:37 1993 From: svet at nrcbsa.bio.nrc.ca (Svetlana Borisova) Date: Tue, 28 Sep 93 21:21:37 PDT Subject: the public key minefield (fwd) In-Reply-To: <9309290227.AA09947@netcom4.netcom.com> Message-ID: <9309290419.AA02815@ nrcbsa.bio.nrc.ca> Doug Merritt wrote: > >The goal of patents is to give a researcher a reward for his invention; to > >give him the opportunity to make money off it. > > This is incorrect; ask any patent attorney. In the U.S., anyway. Ask > a Canadian patent attorney...but I'm 99.9% sure that Canada follows precisely > the same legal philosophy. > > In the U.S., the legal philosophy is derived from the fundamental meta- > philosophy of its law which evolved out of British common law dating back > to at least the Magna Carta, which is that (loosely) the purpose of law is > for the common good. Every year there are cases in the U.S. where judges make > a "surprising" decision that overturns the apparent letter of the law > in favor of an appeal to the common good of society. I am sorry for not making my point clear. What I was trying to say is that the goal of a patent is to give a researcher a reward for his invention *so that* there would be incentive for a researcher to do research, thereby promoting invention, which is for the common good of the society. I was not implying, as it might have seemed from my post, that the purpose of patents was that researchers could get rich at the expense of the rest of the society. I do not believe that patents are intrisically bad. True, the patent system has some flaws, but it *does* provide an incentive for research, and I don't argue for abolishment of patents since I can't think of a better system. My post's intention was to protest the statement that patents are issued so that people could find alternate ways to achieve the same purpose as the patented device does, which was my interpretation of what the following paragraph said: > >smb at research.att.com wrote: > > And if you do -- well, then, the patent system has succeeded in its goals, > > in that the monopoly assigned to someone else has stimulated you to find > > another way to do things, and thus furthered the useful arts and > > sciences. While patents are issued to provide incentive for research, it's not by creating necessity for invention, but by giving a reward for successful research. Sorry for not making it clear the first time. -- =============================================================== Svetlana Borissova svet at nrcbsa.bio.nrc.ca National Research Council Canada Home: (613) 747-7820 Laboratory of Biological Sciences (M-54) Work: (613) 990-7381 Protein Crystallographer (613) 991-6981 =============================================================== From ld231782 at longs.lance.colostate.edu Tue Sep 28 22:11:38 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 28 Sep 93 22:11:38 PDT Subject: Orange book, the NSA, and the NCSC In-Reply-To: <9309241531.AA13351@jazz.hal.com> Message-ID: <9309290510.AA26874@longs.lance.colostate.edu> Mr. Jason Zions <jazz at hal.com> posted a clarification on a misunderstanding that the Orange book has anything to do with cryptographic algorithms, pointing out that it deals only with higher level security issues. However, his strong claim that the NSA is not involved with these criteria whatsoever appears to be complete fantasy, as T. Newsham pointed out, also indicating that the NCSC (Nat'l Center for Security & Communications?) which ``came out with the original Trusted Criterion rainbow books including the orange book'' is apparently just another ugly NSA protrusion. In fact, I can remember people posting suggestions when I first joined the list (a seeming eternity ago) that the NCSC is *entirely* a front agency for the NSA, with no independent operation whatsoever--supposedly essentially nothing but a reception office and a secretary. I'm willing to accept that the Orange book doesn't specifically address cryptography, and I appreciate the clarifications on something that is one of the deepest, complex, and most obscure military handbooks, which frankly I take some pride and relief in having very little knowledge of, but I'm writing to correct another serious error in the original post: >NSA is uninterested in making systems secure; their job is to >break them anyway. This is simply entirely incorrect. A *very* major aspect of the NSA function, ever since its inception, involves the *creation* of secure cryptographic algorithms and equipment. Skipjack is simply the first `commercial' version ever introduced of a cryptographic algorithm. They have supported virtually all branches of the U.S. military in the code-making function. They are directly responsible for most encryption schemes and devices used in military radio communication (tanks, airplanes, ships, etc.). I understand the NSA even sells cryptographic equipment to some countries (U.S. allies) making sure it can be intercepted and decrypted -- this from claims of one of the `defectors' of the agency, I believe. Bamford describes it all in _Puzzle_Palace_. In fact, I've often stated the following position on the NSA, which highlights its past dual role and future legitimate one: Since ``the cold war is over'', if they are to exist at all, they should focus their energy on something *constructive* like algorithm development and not something *destructive* like its sinister vacuum-cleaner intelligence slurping. Increasingly, the world is making the choice for them. From jim at Tadpole.COM Tue Sep 28 22:41:38 1993 From: jim at Tadpole.COM (Jim Thompson) Date: Tue, 28 Sep 93 22:41:38 PDT Subject: Orange book, the NSA, and the NCSC Message-ID: <9309290539.AA11755@tadpole.Tadpole.COM> Keep yourself on the NSA watch list, send email to someone at docmaster.ncsc.mil every once in a while. :-) Jim From newsham at wiliki.eng.hawaii.edu Tue Sep 28 22:46:24 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Tue, 28 Sep 93 22:46:24 PDT Subject: My comments to NIST In-Reply-To: <9309280902.AA09142@unix.ka9q.ampr.org> Message-ID: <9309290543.AA17021@toad.com> > > Comments of Philip R. Karn, Jr great letter! I'm glad we have someone like you on our side. Keep up the good work. Tim N. From ld231782 at longs.lance.colostate.edu Tue Sep 28 22:51:38 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Tue, 28 Sep 93 22:51:38 PDT Subject: Clipper specifics In-Reply-To: <01H3CEGQ0YCI987NKX@delphi.com> Message-ID: <9309290546.AA27506@longs.lance.colostate.edu> Mike Ingle <MIKEINGLE at delphi.com> asked some penetrating questions about Clipper function, that deserve to be brought up again: >Technical question: from what I've read, Clipper is only a single- >key system, basically an 80-bit super-DES. So when you hit the >SECURE button on your AT&T ClipperPhone, how do the phones exchange >session keys? DH exchange or something similar? Is this implemented >in the Clipper chip itself, or in external hardware? The following is based on some very faintly remembered technical data once circulated by D. Denning. I'd be appreciative if anyone can point out where it is located or elaborate on my description below. The Clipper chip does *not* implement key exchange. It is essentially nothing but a low-level encryption device. I would like to see the specifications that are supposedly available or will be soon (I got the impression that E. Hughes got some kind of Clipper specifications at one point, a long time ago). However, as I understand it the chip sends out the law enforcement exploitation field (LEEF) (the beautifully apropos term `exploitation' has now been replaced with Access) along with the encrypted data to the chip pins. Now, two Clipper chips will *not* work in conjuction with each other unless each is fed a valid LEEF from the other. However, since the chip does not accomplish this function (the communication, that is; it does *create* the field), and it is handled outside the chip, there is no guarantee that the system designer does not, for example, encrypt the LEEF in the communications transit, thereby completely sabotaging the `exploitative' tappability of the chip. Hence there is a *very* real possibility that this scheme, or something similar, could be used to gain Skipjack-level encryption without any key escrow complications. I suspect the NSA is *extremely* worried about this. They probably require that the chip purchaser promise to use Clipper in a way that guarantees the LEEF is accessable (plaintext). They may even create a contractual obligation wherein the surrounding device (telephone or whatever) cannot be approved for sale until it passes an NSA endorsed tapping test. (what fun!) I consider this all very plausible and probable. (This would be a neat trick -- use the chip itself to encrypt LEEF fields -- hah! twist an insecure chip into a secure one, and spit in the face of the NSA!) The NSA probably would rather *not* come out with a Clipper type chip because of the above weakness. But this is the absolute lowest level chip they can get away with. There are many applications that would reject a more sophisticated chip -- Clipper is already expensive enough as it is. However, the Capstone chip *does* have key exchange functions built in -- it uses Diffie Hellman, apparently. And I consider it likely that the LEAF field transfer cannot be thwarted in the above way. This is a do-everything chip with exponentiation and the DSA algorithm built in. All these sweet-looking contortions to support `public debate' on the Clipper proposal are rather pathetic given that the Capstone has been in development for many years. Is there really any chance that its production would be derailed by some annoying public comments? I certainly hope so, but it's not a pretty picture. Note that early in the Clipper debate, D. Denning and others were vague on the Capstone and Clipper key exchange function. That's because Clipper didn't have it, and Capstone used Diffie Hellman. Now, as we are so familiar with, PKP holds a iron-fisted, vice-lock grip on *all* public key cryptography. The government is supposedly able to use the patented technology without prior arrangement (I believe this is a qualification of the NSF research grants that led to the patents?) but the chips would still not be able to be used in *commercial* arrangements (the whole point) without a PKP agreement. Hence, it was *absolutely critical* that the government get the *official endorsement* of PKP and a legal arrangement to allow the use of public key cryptography in the Capstone and Clipper arrangements. The wretched announcement was just a matter of time -- what was so surprising was that PKP also got awarded a new iron-fisted, vice-lock grip on the Digital Signature Standard. Apparently, the incredibly lucrative revenues from public key licensing on Clipper and Capstone alone just didn't cut it. Conspiracy theorists can easily believe that this outrageous, scheming arrangement was made *far prior* to its actual announcement (June? I forget), and there is a lot of circumstantial evidence to support this. The NSA's goal with Clipper and Capstone was *commercial* from the *very beginning* -- now *officially* confirmed as at least 3 years! -- and they would be first to make sure it wasn't thwarted by those pesky patents everyone else has to break their shins on. In fact, going just a bit further, there is a lot of circumstantial evidence that PKP is very closely allied with the NSA in various ways. How is it one company has gotten public key patents that were developed at two different universities (Stanford & MIT) and diverse researchers (Diffie, Hellman, Rivest, Shamir, Adleman)?! Why is the government so eager to grant them a critical *new* cryptgraphic algorithm stranglehold with DSA? [key exchange] >Is the format >standardized? If not, there will be plenty of interoperability >problems with the first generation of phones. For that matter, there >will probably be problems even if it is standardized. About the only company ready for Clipper chips is AT&T, and I think they are using Diffie Hellman key exchange currently with some proprietary algorithms (they have a license on Public Key directly from PKP already) in their secure phones. I suspect any companies that come out with new phone encryption equipment based on Clipper, if any are insane enough to exist, will try to be compatible with the AT&T `standard' (ug). As far as I know AT&T has not published their own key exchange standard used by the phones, however. That is, it is proprietary, and might even be protected by patents of their own! This is a rare occasion where incompatibility is something to beam about! From karn at unix.ka9q.ampr.org Tue Sep 28 22:56:23 1993 From: karn at unix.ka9q.ampr.org (Phil Karn) Date: Tue, 28 Sep 93 22:56:23 PDT Subject: My comments to NIST In-Reply-To: <9309290545.AA09638@unix.ka9q.ampr.org> Message-ID: <9309290556.AA09654@unix.ka9q.ampr.org> Thank you. Sternlight didn't like it, but what else is new? :-) Phil From karn at qualcomm.com Tue Sep 28 23:31:39 1993 From: karn at qualcomm.com (Phil Karn) Date: Tue, 28 Sep 93 23:31:39 PDT Subject: Clipper specifics In-Reply-To: <9309290546.AA27506@longs.lance.colostate.edu> Message-ID: <9309290628.AA16515@servo> As I recall from a note from Denning some months back, the bits of the LEEF (Law Enforcement Exploitation Field, its original and far more descriptive name) are spread out among the ciphertext in some unspecified way precisely to make it difficult or impossible to remove. Damn. Now I remember one of the points I meant to make in my NIST comments, but forgot: if the LEEF is added periodically to the ciphertext stream, that implies that the ciphertext data rate must be greater than the plaintext rate. And that precludes just dropping the Clipper chip into existing synchronous communication systems such as our CDMA digital cellular telephone system without *major* system redesign. Everything in our system is designed around four specific fixed frame "rates", specifically 16, 40, 80 or 171 bits every 20 ms: the vocoder, which generates these "frames", the CDMA modem, the Viterbi decoder, everything. Encryption that simply performs a 1-to-1 mapping between plaintext and ciphertext would be easy to add to this system. But an encryption chip that has to add something to each frame to encode an LEEF is useless to me. Anybody know if there is a "reply comments" cutoff date for the Clipper proposal? Under the rules that usually govern this sort of thing, if you can find someone else's comments on file that address the point you make, you can usually file "reply comments" that address this point beyond the original due date -- as long as it arrives by the "reply comments" date (usually a month or two later). Phil From karn at qualcomm.com Tue Sep 28 23:36:22 1993 From: karn at qualcomm.com (Phil Karn) Date: Tue, 28 Sep 93 23:36:22 PDT Subject: Orange book, the NSA, and the NCSC In-Reply-To: <9309290539.AA11755@tadpole.Tadpole.COM> Message-ID: <9309290635.AA16536@servo> Better yet, send them large PGP-encrypted messages using maximum-length public keys that are not registered with the key servers. That should keep their Crays busy for a while. :-) Phil From jkreznar at ininx.com Tue Sep 28 23:56:22 1993 From: jkreznar at ininx.com (John E. Kreznar) Date: Tue, 28 Sep 93 23:56:22 PDT Subject: Question EFF yielding of crypto authority to NIST In-Reply-To: <199309282015.AA18701@eff.org> Message-ID: <9309290653.AA28234@ininx> > Below is the text of the comments that EFF filed with NIST today. > ... > When the Clinton Administration announced the Clipper Chip, it > assured the public that this would be a purely voluntary system. We must > have legal guarantees that Clipper is not the first step toward prohibition > against un-escrowed encryption. Yet the Administration has not offered any > such guarantees, either in the form of proposed legislation or even agency > rules. > ... Actually, they have issued such legal guarantees. They're in the form of the administration's vow to uphold the US Constitution. That document's 9th and 10th amendments preclude US Government denial or disparagement of the people's right to use cryptography (and a whole lot of others). The fact that these legal guarantees are being ignored simply illustrates that their tyranny is unbridled. By engaging NIST on this subject, the EFF is implicitly yielding to them authority which is not theirs to begin with. John E. Kreznar | Relations among people to be by jkreznar at ininx.com | mutual consent, or not at all. From rjc at gnu.ai.mit.edu Wed Sep 29 00:31:38 1993 From: rjc at gnu.ai.mit.edu (Ray) Date: Wed, 29 Sep 93 00:31:38 PDT Subject: Hacking ClipperPhones Message-ID: <9309290726.AA18034@geech.gnu.ai.mit.edu> "Cypherpunks Hack Hardware" It seems logical that when the ClipperPhones come out, they will have some kind of vocoder chip in them. (I doubt the (co)decoding will be implemented on the Clipper chip itself) If so, cypherpunks can take advantage of this situation. By hacking up a daugherboard, the phone's vocoder/modem/sampler can be exploited and interfaced to a PC (possibility via something as simple as a null modem cable or centronics). After that, the software hackers can do their job. If the ClipperPhone becomes popular and the daughterboard is cheap to build ($25-50), it would serve as a massive hardware platform for cypherpunks phone software. The alternative is to produce our own vocoder/sampler boards, but I doubt we could approach the economy of scale that AT&T can, plus we get to ride on the back of their advertising/marketing by having them sell the basic hardware. (then we just release a hack for it) What do you think? -Ray -- Ray Cromwell | Engineering is the implementation of science; -- -- EE/Math Student | politics is the implementation of faith. -- -- rjc at gnu.ai.mit.edu | - Zetetic Commentaries -- From ebrandt at jarthur.Claremont.EDU Wed Sep 29 00:36:22 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Wed, 29 Sep 93 00:36:22 PDT Subject: Clipper specifics In-Reply-To: <9309290546.AA27506@longs.lance.colostate.edu> Message-ID: <9309290733.AA19505@toad.com> > From: "L. Detweiler" <ld231782 at longs.lance.colostate.edu> > *create* the field), and it is handled outside the chip, there is no > guarantee that the system designer does not, for example, encrypt the > LEEF in the communications transit, thereby completely sabotaging the > `exploitative' tappability of the chip. > > Hence there is a *very* real possibility that this scheme, or something > similar, could be used to gain Skipjack-level encryption without any > key escrow complications. I suspect the NSA is *extremely* worried > about this. Their spokesagency, NIST, has said that it will be illegal to encrypt on top of Skipjack or to mung the LEEF. Pre-encryption is not mentioned, AFAIK, and would be borderline impossible to detect anyway. As I see it, this is already a restriction on non-Skipjack encryption, issued in the same document that assured us that no such thing is being considered. It's a special case, to be sure, but it clearly asserts a government power to restrict the means and manner of private encryption performed entirely within the United States. This is a key issue, IMO. Eli ebrandt at jarthur.claremont.edu From smb at research.att.com Wed Sep 29 00:51:38 1993 From: smb at research.att.com (smb at research.att.com) Date: Wed, 29 Sep 93 00:51:38 PDT Subject: Disturbing statistics on wiretaps Message-ID: <9309290751.AA19846@toad.com> smb at research.att.com writes > The same is true of e-mail over the Internet--there is no > statutory exclusionary rule that would prvent its > admissibility in court. It is at least theoretically possible, > however, to exclude illegally seized communications of these > sorts using a "pure 4th Amendment" (nonstatutory) exclusionary > rule. > > Don't hold your breath, though. > > Do you really think that? One could argue, fairly strongly, that th e > rules set forth in the ECPA have created an expectation of privacy, > and that a violation of that expectation would be exactly the violat ion > of the 4th Amendment that the Supreme Court addressed in the 1967 > decision that led to the original wiretap provisions in the Omnibus > Crime Control and Safe Streets Act. What's your point? One can argue all sorts of things. Are you saying you have reason to believe an argument of this sort is likely to be a winner? Me, I just work from what I know about 4th Amendment caselaw. I realize that you know more about the relevant case law than I do. It would be pretty sad if you didn't. But I'm not completely ignorant of either this subject in particular, or constitutional law in gneral, and I like to learn more. I'm asking to be educated, and I don't like to rely on assertions by authority. I advanced what I thought was a fairly strong argument against your point. Further, the wording of the statute seems pretty clear to me. 18 USC 2515: Prohibition of use as evidence of intercepted wire, oral, or electronic communications Whenever any wire, oral, or electronic communications has been intercepted, no part of the contents of such communication and no evidence derived therefrom may be received in evidence in any trial, hearing, or other proceeding in or before any court, grand jury, department, officer, agency, regulatory body, legis- lative committee, or other authority of the United States, a State, or a political subdivision thereof if the disclosure of that information would be in violation of this chapter. As I read it, if the government doesn't follow the wiretap rules, the evidence thereby obtained can't be used. What have I missed? --Steve Bellovin From khijol!erc Wed Sep 29 02:11:39 1993 From: khijol!erc (Ed Carp) Date: Wed, 29 Sep 93 02:11:39 PDT Subject: Orange book, the NSA, and the NCSC In-Reply-To: <9309290635.AA16536@servo> Message-ID: <m0ohwxY-00022PC@khijol> > Better yet, send them large PGP-encrypted messages using maximum-length > public keys that are not registered with the key servers. That should > keep their Crays busy for a while. :-) Even if a Cray can crack a PGP-encrypted message in, say, an hour, flooding the system with messages would tend to obscure real traffic with obscure junk. Hey, I can encrypt /vmunix with a random key as fast as the next person. :) -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From wcs at anchor.ho.att.com Wed Sep 29 02:31:40 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Wed, 29 Sep 93 02:31:40 PDT Subject: Disturbing statistics on wiretaps Message-ID: <9309282139.AA18609@anchor.ho.att.com> In cypherpunks, allan at elvis.tamu.edu (Allan Bailey) writes: > I don't think e-mail over the Intenet will ever be used in court > since anyone capable of reading the RFC would be able to forge email. > So, anyone could claim that the email being used as evidence is a > forgery _and_ be able to prove it by doing it or demonstrating it. Different standards of proof apply to different kinds of court cases. Criminal cases need "proof beyond all reasonable doubt"; civil cases tend to need "preponderance of evidence". Forging email is similar to forging typed documents - sometimes cases will heavily use evidence like analysis of individual typewriter characteristics (which was more useful when people had real manual typewriters than with laserprinters), other cases won't examine those details unless one side or the other claims the document isn't theirs or is forged (and remember, this is typically subject to perjury if you're caught lying.) If you're being accused of a serious crime with severe penalties, like murder, an assertion that you didn't type/email something will be taken seriously, and probably lead to more analysis; if they can't *really* prove you sent it, that can be grounds for appeal. But if you're being accused in a civil lawsuit with only monetary damages, like libel/slander or whatever the legal form was in the case where somebody on a computer network disparaged a company's stock and the directors sued when stock value dropped, the assertion may be listened to, but even if there aren't enough log-files to strongly support the assertion that you didn't say it, the jury may decide there's enough evidence to find for the plaintiff, especially if you were a user of that computer network and didn't go net.screaming that you'd been impersonated. (On the other hand, after you lose the libel/slander/etc. suit, if the government decides to charge you with perjury for saying it wasn't your email, the log-files and lack of provability become much more relevant.) Of course, if you're accused of a minor offense with major penalties, e.g. political crimes like drug possession or trespasses like the E911 document copying, lack of proof will be treated as evidence that you know something about DRUGGZZZ or HACKING and are therefore EEEVILL and your penalties will be tripled :-( # Bill Stewart wcs at anchor.ho.att.com +1-908-949-0705 Fax-4876 # AT&T Bell Labs, Room 4M-312, Crawfords Corner Rd, Holmdel, NJ 07733-3030 # # goin' where the climate suits my clothes .... From gg at well.sf.ca.us Wed Sep 29 02:36:22 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 29 Sep 93 02:36:22 PDT Subject: Disturbing statistics on wiretaps Message-ID: <93Sep29.023420pdt.14278-2@well.sf.ca.us> And of course it should be remembered that there is still an old drug-war thing on the books which allows 72 hours' interception without a court order. Now depending on how that's interpreted, 72 hours are a lot of conversations. This stuff can be used for background intelligence and investigation where it never winds up in court but is used to get information to be used in other ways. "It's what they don't tell you..." -gg From gg at well.sf.ca.us Wed Sep 29 02:51:40 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 29 Sep 93 02:51:40 PDT Subject: Hacking ClipperPhones Message-ID: <93Sep29.024627pdt.14278-2@well.sf.ca.us> Re your suggestion of a cypherpunk daughterboard to substitute for Clipper in "secure" phones etc.: I have a sneaky suspicion that AT&T won't be quite so cooperative. They constantly do things in such a way as to make it darn hard to do anything with their products except exactly what they intended to do. It might be worth a try though... OTOH anything that creates more demand for AT&T phones is a not-good thing in my view... we need an entirely competing product, and preferably cheaper than an AT&T clipperphone + daughterboard, for obvious competitive reasons. There are plenty of telephone manufacturers in the world. Some are relatively small shops in Asia which make European knock-offs for the Asian operating companies. I know of another one in Portugal which at least ten years ago was favorable to doing mildly custom stuff. If nyone here is seriously interested in competing cryptophones, I'd be willing to find an appropriate telephone set manufacturer who makes quality phones and is willing to put in a daughterboard socket or other useful mods. -gg at well.sf.ca.us From mnemonic at eff.org Wed Sep 29 05:11:42 1993 From: mnemonic at eff.org (Mike Godwin) Date: Wed, 29 Sep 93 05:11:42 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <199309290751.AA24066@eff.org> Message-ID: <199309291205.AA25225@eff.org> Steve Bellovin writes: > I realize that you know more about the relevant case law than I do. It > would be pretty sad if you didn't. But I'm not completely ignorant of > either this subject in particular, or constitutional law in gneral, and > I like to learn more. I'm asking to be educated, and I don't like to > rely on assertions by authority. This is both a fair comment and a fair request. Sorry for being irritable yesterday. > I advanced what I thought was a > fairly strong argument against your point. Further, the wording of the > statute seems pretty clear to me. 18 USC 2515: > > Prohibition of use as evidence of intercepted wire, > oral, or electronic communications > > Whenever any wire, oral, or electronic communications has > been intercepted, no part of the contents of such communication > and no evidence derived therefrom may be received in evidence in > any trial, hearing, or other proceeding in or before any court, > grand jury, department, officer, agency, regulatory body, legis- > lative committee, or other authority of the United States, a > State, or a political subdivision thereof if the disclosure of > that information would be in violation of this chapter. This is not an accurate presentation of 2515, Steve. "Electronic communications" was not added to 18 USC 2515 by ECPA. The statutory exclusionary rule applies only to wire and oral communications. > As I read it, if the government doesn't follow the wiretap rules, > the evidence thereby obtained can't be used. What have I missed? You've missed the actual language of 18 USC 2515. I don't know where you got this one. --Mike From m5 at vail.tivoli.com Wed Sep 29 05:36:23 1993 From: m5 at vail.tivoli.com (Mike McNally) Date: Wed, 29 Sep 93 05:36:23 PDT Subject: Carl Ellison on 'The Death of DES' In-Reply-To: <9309282044.AA26047@ellisun.sw.stratus.com> Message-ID: <9309291229.AA11549@vail.tivoli.com> > Carl Ellison says: > > 3. in between DES operations, mix bytes up as with tran (posted on > > sci.crypt occasionally, avbl from me by mail or on ripem.msu.edu) > > -- spreading bytes out within a huge block, further hiding any > > known text Can someone comment on the efficacy of this technique when used in conjunction with encryption modes other than ECB, and/or with the simple XOR "pre-scramble" technique? I agree that it "couldn't hurt", security-wise, but of course it does introduce a (slight) processing overhead. If it introduces no real additional security, I don't see the point. (Enlighten me!) (This for some reason reminds me of the way little kids tie shoes; they sometimes make enormous knots which, ultimately, are weaker than a simple bow.) -- Mike McNally From nowhere at bsu-cs.bsu.edu Wed Sep 29 06:06:27 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Wed, 29 Sep 93 06:06:27 PDT Subject: Triple DES products hitting market Message-ID: <9309291308.AA19748@bsu-cs.bsu.edu> excerpted from: Communications Week No. 473, September 27, 1993 page 36 Cylink Triples Encryption by Sharon Fisher Sunnyvale, Calif. - Cylink Corp. has announced an encryption product that improves security by encrypting data three times using current standards. The Cylink product uses the Data Encryption Standard, which defines a 56-bit key for scrambling messages to prevent access by unauthorized users. DES was adopted in 1977 as the U.S. federal standard for data encryption. Skirting DES Limitations Some users have expressed concern, however, that DES' 56 bits cannot prevent a determined attacker from using more powerful hardware and software to crack the code. The Cylink product addresses the problem by using DES to encrypt the data more than once, according to company officials. Cylink's Cipher/Decipher-HSi offers triple-DES, which encrypts DES data three times, and gives the 56-bit key the effect of a 112-bit key, according to the company, based here. The triple-DES approach makes the Cylink product more secure than the government's proposed Clipper system, which uses an 80-bit key, the company said. Users could get the triple-DES effect by manually encrypting data three times, but the process would take three times as long as single DES encryption, Cylink noted. Cidec-HSi uses improved circuit technology that performs the three encryptions without taking that long, the company said. Cidec-HSi works at speeds of up to 2.048 million bits per second and is available with a wide variety of interfaces, Cylink said. It also includes a public key management system, which lets users exchange keys so that they can read each other's messages. The device also offers an optional embedded channel service unit, which can be connected directly to the public T1 carrier network, the company said. Cylink said it can retrofit current Cidec-HSi systems so they can benefit from the new triple-DES technology. AT&T Compatibitlity The company said that Cidec-HSi meets compatibility standards for use with AT&T's Accunet T1.5 and Extended Superframe Format services. Cylink can be reached at 735-5800. From ssteele at eff.org Wed Sep 29 07:41:47 1993 From: ssteele at eff.org (Shari Steele) Date: Wed, 29 Sep 93 07:41:47 PDT Subject: saturation tactics? Message-ID: <199309291438.AA26395@eff.org> Nate asks: >BTW, what is the snail-mail address to send these letters to? Willam B. Robinson United States Department of State Bureau of Politico-Military Affairs Office of Defense Trade Controls Washington, DC 20522-0602 George suggests: >yeah, here's a cheaper version. Write to the arms excport license people >and pester them with questions: I'm a BBS operator, what should I do?; I'm a >businessperson travelling overseas and need my crypto to comm with the home >office what should I do?; all this kind of thing. Swamp them with letters. >Every person and every circumstance which even remotely fits. > >An alternative version which would require more guts and perhaps a serious >conscientious decision about whether it's worth making this an act of civil >disobedience, is to write to them and say, "I'm a BBS operator, not an arms >merchant, and on the strength of my 1st-A rights I'm not going to censor my >board or get a license..." or "I'm a businessperson who travels & takes my >cryupto out of the country on my laptop to comm with the home office; I'm >not an arms dealer either and I don't intend to get a license..." And >again, there is strength in numbers here. I like the first idea. As an attorney (stop with the hissing out there!), I feel a need to remind you that these State Department guys are serious. They can really make your life miserable -- just ask Phil Z. I strongly suggest that you keep that in mind before openly suggesting that you intend to export encryption. I agree that the export laws stink. I'm hoping we can get the law nixed without anyone going to jail. Shari From mpj at csn.org Wed Sep 29 08:01:51 1993 From: mpj at csn.org (Michael Johnson) Date: Wed, 29 Sep 93 08:01:51 PDT Subject: Carl Ellison on 'The Death of DES' In-Reply-To: <9309291229.AA11549@vail.tivoli.com> Message-ID: <Pine.3.05.9309290818.A2965-b100000@teal.csn.org> On Wed, 29 Sep 1993, Mike McNally wrote: > > Carl Ellison says: > > > 3. in between DES operations, mix bytes up as with tran (posted on > > > sci.crypt occasionally, avbl from me by mail or on ripem.msu.edu) > > > -- spreading bytes out within a huge block, further hiding any > > > known text > Can someone comment on the efficacy of this technique when used in > conjunction with encryption modes other than ECB, and/or with the > simple XOR "pre-scramble" technique? I agree that it "couldn't hurt", > security-wise, but of course it does introduce a (slight) processing > overhead. If it introduces no real additional security, I don't see > the point. (Enlighten me!) > > (This for some reason reminds me of the way little kids tie shoes; > they sometimes make enormous knots which, ultimately, are weaker than > a simple bow.) One integrated large block cipher is much more secure than this kind of combination of ciphers, unless you repeat them in enough rounds to make a compound product cipher out of it. In other words, des | tran really isn't much stronger than des, but des|tran|des|tran|des|tran|des|tran... could be quite strong (not to mention slow). Mike Johnson Long live the U. S. Constitution! From jhall at lambda.msfc.nasa.gov Wed Sep 29 08:06:27 1993 From: jhall at lambda.msfc.nasa.gov (Joel Hall) Date: Wed, 29 Sep 93 08:06:27 PDT Subject: unsubscribe Message-ID: <9309291459.AA19130@lambda.msfc.nasa.gov> unsubscribe From thug at phantom.com Wed Sep 29 08:41:45 1993 From: thug at phantom.com (Murdering Thug) Date: Wed, 29 Sep 93 08:41:45 PDT Subject: Triple DES Wanted Message-ID: <m0oi3fO-0009GjC@mindvox.phantom.com> I'm looking for a Triple DES file encryption program that takes arguments in the same form as /bin/crypt or /usr/bin/des. Is there a /bin/3des out there somewhere? Has anyone come across 3des.c? And if so, can you point me in the direction where it may be found. Thanks.. If no such program exists, I think it would be very useful to the cypherpunks community if it were made available. I'd also like to see a similar stand-alone version of IDEA (/usr/bin/idea?), but since it is patented, that's probably not going to happen, which is why I'm looking for something like /bin/3des. l8r, thug From mab at crypto.com Wed Sep 29 09:06:27 1993 From: mab at crypto.com (Matt Blaze) Date: Wed, 29 Sep 93 09:06:27 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <199309291646.AA28909@eff.org> Message-ID: <9309291714.AA14997@crypto.com> Mike Goodwin writes: >Steve Bellovin writes: > > >Here's the actual language of 18 USC 2515 (note the omission of >"electronic communications"): > > >Sec. 2515. Prohibition of use as evidence of intercepted wire or oral >communications > >Whenever any wire or oral communication has been intercepted, no part of >the contents of such communication and no evidence derived therefrom may >be received in evidence in any trial, hearing, or other proceeding in or >before any court, grand jury, department, officer, agency, regulatory >body, legislative committee, or other authority of the United States, a >State, or a political subdivision thereof if the disclosure of that >information would be in violation of this chapter. >--Mike Out of curiousity, what's "wire communication" for the purpose of this statute? How does that differ from electronic communication (other than, perhaps, non-voice data traffic sent via cellular telephone)? Thanks -matt From mnemonic at eff.org Wed Sep 29 10:31:46 1993 From: mnemonic at eff.org (Mike Godwin) Date: Wed, 29 Sep 93 10:31:46 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <9309291714.AA14997@crypto.com> Message-ID: <199309291730.AA29712@eff.org> Matt Blaze writes: > Out of curiousity, what's "wire communication" for the purpose of this > statute? How does that differ from electronic communication (other than, > perhaps, non-voice data traffic sent via cellular telephone)? Rather than type in the lengthy definition sections, which refer to each other, let me just say that a "wire communication" includes an "aural transfer"--that is, a human voice. An "electronic communication" may use the phone lines, but the definition excludes anything that qualifies as a "wire or oral communication". See 18 USC 2510 (12)(B). The definition of "wire communication" is 18 USC 2510 (1). The definition of "electronic communication" is 18 USC 2510 (12). The definition of "aural transfer" is 18 USC 2510 (18). --Mike From pmetzger at shearson.com Wed Sep 29 10:36:30 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Wed, 29 Sep 93 10:36:30 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <199309291646.AA28909@eff.org> Message-ID: <9309291732.AA22615@snark.lehman.com> Mike Godwin says: > Sec. 2515. Prohibition of use as evidence of intercepted wire or oral > communications > > Whenever any wire or oral communication has been intercepted, no part of > the contents of such communication and no evidence derived therefrom may > be received in evidence in any trial, hearing, or other proceeding in or > before any court, grand jury, department, officer, agency, regulatory > body, legislative committee, or other authority of the United States, a > State, or a political subdivision thereof if the disclosure of that > information would be in violation of this chapter. How does the statute define "wire" communication? Perry From tcmay at netcom.com Wed Sep 29 10:36:46 1993 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 29 Sep 93 10:36:46 PDT Subject: Orange book, the NSA, and the NCSC In-Reply-To: <9309291641.AA27012@matt.ksu.ksu.edu> Message-ID: <9309291733.AA06497@netcom3.netcom.com> Dan Odom clarifies some information about NSA, NCSC, Orange Book series, etc.: > > I'm willing to accept that the Orange book doesn't specifically address > > cryptography, and I appreciate the clarifications on something that is > > one of the deepest, complex, and most obscure military handbooks, which > > Uh, any American citizen is entitled to one (1) free copy of the > Orange Book (and every other book in the Rainbow series); all you have > to do is ask. The address on the inside of my copy says: > > NCSC > 9800 Savage Road > Fort George G. Meade, MD 29755-6000 I got on this list of automatic books several years ago and now have about a dozen or more different publications, in different colors, from blue to green to the famous orange. All from the National Computer Security Center. Nothing juicy, and not much fun (for me) to read. Unix gurus trying to get better security classifications for their machines and systems have to read this stuff, though. > Since every NSA address I've ever seen is 9800 Savage Road, I assume > that it's some sort of secretarial thing. But if you ask them for a > copy of the Rainbow Series, they'll send it to you and also put you on > the list to receive updates. It is _not_ deep, complex, or obscure; Savage Road is the actual address of the Agency; Fort Meade per se is huge. NCSC as created in 1984 as part of NSDD-145 (National Security Decision Directive-145, a very important one). Prior to that date it had been called the DoD Computer Security Center, located smack dab in the center of SIGINT City. (I visited in May of 1991, strictly to satisfy my own curiousity. The closest I got was the front gate, with the newly installed "National Security Agency" signs. Signs said "Das Photographen ist Strictly Verboten," but I took a bunch anyway out my car window.) > And before anybody starts forming consipiracy theories, I am not > related to Lieutenant General William Odom; we just share a name :-). I'd long been meaning to ask Dan about this. General Odom once was introduced at a speech he was giving to Jim Bamford. Odom recoiled and said "Sir, I consider you to be an unindicted felon." -Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From marc at GZA.COM Wed Sep 29 10:46:31 1993 From: marc at GZA.COM (Marc Horowitz) Date: Wed, 29 Sep 93 10:46:31 PDT Subject: Easy cracking In-Reply-To: <9309291707.AA16624@tadpole.Tadpole.COM> Message-ID: <9309291744.AA01511@dun-dun-noodles.aktis.com> >> The same kind of thing happened at Sun, except with the >> secure rpc stuff. Had a guy send mail saying, "I know your >> two primes." Sun replied, "No way." (And lauged internally.) I'm not sure this is how it happened, but the person (maybe there's more than one?) who did this is a cypherpunk, who will identify himself if he wants. He also wrote a paper on this. The first version of the paper had the private key at the top of the first page, but it got removed because certain spooks got upset. Marc From mdiehl at triton.unm.edu Wed Sep 29 10:46:47 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 29 Sep 93 10:46:47 PDT Subject: Subterranean Clipper Chip Blues In-Reply-To: <9309291653.AA16344@tadpole.Tadpole.COM> Message-ID: <9309291744.AA17276@triton.unm.edu> According to Jim Thompson: > > Subject: Subterranean Clipper Chip Blues > > PC/Computing, October 1993 > Page 468 (opposite inside back cover). > Note: _abc_ indicates italics. > > Illustration: several computers with keyholes in the screens. > Clinton's smiling face rises from the White House, as a long > arm reaches out with a key... > Anyone out there with a color scanner??? PLEASE scan this puppy! Distributing .gif images represents the next generation of Electronic Propaganda! So, if anyone has a scanner, please scan this one and make if available to us. Thanx in advance. J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! <RL> Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. <Me> al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! <Me> Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From khijol!erc Wed Sep 29 11:11:46 1993 From: khijol!erc (Ed Carp) Date: Wed, 29 Sep 93 11:11:46 PDT Subject: Orange book, the NSA, and the NCSC In-Reply-To: <9309291733.AA06497@netcom3.netcom.com> Message-ID: <m0oi5rq-00022EC@khijol> > I got on this list of automatic books several years ago and now have > about a dozen or more different publications, in different colors, > from blue to green to the famous orange. All from the National > Computer Security Center. > > Nothing juicy, and not much fun (for me) to read. Unix gurus trying to > get better security classifications for their machines and systems > have to read this stuff, though. I had to wade through all that government stuff a while back. I've got the complete series, but haven't gotten any updates. :( It's all pretty dry and stuffy, but it did have some useful stuff, like the password guidelines and how they figure out which machines can be trusted and which can't. > Savage Road is the actual address of the Agency; Fort Meade per se is > huge. NCSC as created in 1984 as part of NSDD-145 (National Security > Decision Directive-145, a very important one). Prior to that date it > had been called the DoD Computer Security Center, located smack dab in > the center of SIGINT City. Why is Directive 145 important? <curious> > I'd long been meaning to ask Dan about this. General Odom once was > introduced at a speech he was giving to Jim Bamford. Odom recoiled and > said "Sir, I consider you to be an unindicted felon." <snicker> I got a good laugh out of that one!! :) :) -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From jim at Tadpole.COM Wed Sep 29 11:21:46 1993 From: jim at Tadpole.COM (Jim Thompson) Date: Wed, 29 Sep 93 11:21:46 PDT Subject: Orange book, the NSA, and the NCSC Message-ID: <9309291820.AA17528@tadpole.Tadpole.COM> Been to "the fort" twice, once on 'official business', once on a joyride around the 'campus'. :-) ("See them big sat dishes? Don't want to get too close to them, marines with guns up there.") The visitor's center has a small, but facinating museum of crypto stuff, everything from enigma-style machines to a device that does I-don't-remember-how-many-but-it-was-huge gigaflops on a hand-rolled chip made on site, to a device for intercepting (and decrypting) microwave transmissions. Not much satilite stuff. Pretty cool. The guards all wear big (loaded, I checked) guns. You're issued a little badge to carry around your neck. Get too far from your escort, or in a room without your escort, and they get really upset (from what I was told, I didn't try). Across the highway is a state camp for delinquent boys. Jim From mnemonic at eff.org Wed Sep 29 11:31:47 1993 From: mnemonic at eff.org (Mike Godwin) Date: Wed, 29 Sep 93 11:31:47 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <9309291732.AA22615@snark.lehman.com> Message-ID: <199309291829.AA00403@eff.org> Perry writes: > How does the statute define "wire" communication? Sigh. I hate typing stuff in, but I'll go ahead and type this one in. Sec. 2510. Definitions As used in this chapter-- (1) "wire communication" means any aural transfer made in whole or in part through the use of facilities for the transmission of communications by the aid of wire, cable, or other like connection between the point of origin and the point of reception (including the use of such connection in a switching station) furnished or operated by any person engaged in providing such facilities for the transmission of interstate or foreign communications or communications affecting interstate or foreign commerce and such term includes any electronic storage of such communication, but such term does not include the radio portion of a cordless telephone communication that is transmitted between the cordless telephone handset and the base unit;.... ----- --Mike From smb at research.att.com Wed Sep 29 11:36:30 1993 From: smb at research.att.com (smb at research.att.com) Date: Wed, 29 Sep 93 11:36:30 PDT Subject: Easy cracking Message-ID: <9309291833.AA29821@toad.com> >> The same kind of thing happened at Sun, except with the >> secure rpc stuff. Had a guy send mail saying, "I know your >> two primes." Sun replied, "No way." (And lauged internally.) I'm not sure this is how it happened, but the person (maybe there's more than one?) who did this is a cypherpunk, who will identify himself if he wants. He also wrote a paper on this. The first version of the paper had the private key at the top of the first page, but it got removed because certain spooks got upset. ?? As far as I know, Sun's secure RPC uses Diffie-Hellman with a 192-bit modulus. LaMacchia and Odlyzko solved the discrete log problem for that size, but there's no single private key to disclose. For those who are interested, the reference is @article{nfscrack, author = {Brian A. LaMacchia and Andrew M. Odlyzko}, journal = {Designs, Codes, and Cryptography}, pages = {46--62}, title = {Computation of Discrete Logarithms in Prime Fields}, volume = {1}, year = {1991}, xnote = "11211-900629-12TM" } From pmetzger at shearson.com Wed Sep 29 11:36:50 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Wed, 29 Sep 93 11:36:50 PDT Subject: soda.berkeley.edu Message-ID: <9309291836.AA13512@kublai.lehman.com> Hi folks. I just tried doing an anonymous ftp to soda.berkeley.edu and it failed. Has something happened? Perry From wcs at anchor.ho.att.com Wed Sep 29 11:56:30 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Wed, 29 Sep 93 11:56:30 PDT Subject: Clipper specifics Message-ID: <9309291709.AA01660@anchor.ho.att.com> > Their spokesagency, NIST, has said that it will be illegal to encrypt > on top of Skipjack or to mung the LEEF. Pre-encryption is not > mentioned, AFAIK, and would be borderline impossible to detect anyway. Actually, it won't be illegal, unless they get CONgress to pass some laws, but they may be able to do some contractual constraints on it as part of the process of getting your Skipjack products approved, either through the current process of export approval, or through the approval process described in the proposed FIPS (which basically says "Whatever NSA wants"); they could even place restrictions on selling Clipper chips to unapproved companies. It *will* violate the FIPS, if the FIPS gets approved, so you won't be able to sell SkipJack/LEAF products to the government unless they're capable of operating without post-encryption. That doesn't mean they won't buy dual-mode products that are switchable between secure and FIPS modes, though obviously the politics of the situation don't make that real likely :-) An interesting question is whether the export or manufacturing approval processes will ban the use of Clipper/etc. in programmable devices, either explicitly user-programmable ones, or devices in which the PROMs are easily replaced. It costs a little, but using flash-EPROM in a secure phone would make firmware upgrades easy, and that could include a LEAF-masking option. From tcmay at netcom.com Wed Sep 29 11:56:46 1993 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 29 Sep 93 11:56:46 PDT Subject: Orange book, the NSA, and the NCSC In-Reply-To: <m0oi5rq-00022EC@khijol> Message-ID: <9309291855.AA19302@netcom3.netcom.com> I mentioned NSDD-145 and Ed Carp asked for more information: > > Savage Road is the actual address of the Agency; Fort Meade per se is > > huge. NCSC as created in 1984 as part of NSDD-145 (National Security > > Decision Directive-145, a very important one). Prior to that date it > > had been called the DoD Computer Security Center, located smack dab in > > the center of SIGINT City. > > Why is Directive 145 important? <curious> National Security Decision Directive 145 (NSDD-145) was signed by Reagan in 1984 as the "National Policy on Telecommunications and Automated Information Security." It extended the charter of the NSA from just the protection of government information (I'm talking about the COMSEC part of NSA, of course) to commercial, non-gov't information as well. The "Commercial COMSEC Endorsement Program" (CCEP). (I believe COMSEC, Communications Security, has since been changed to INFOSEC. One thing the Agency does is to frequently change the names of groups, departments, functions. Security by bureaucracy I guess.) You may recall that the Feds said around this time that DES was basically dead, that the CCEP would result in a new line of crypto systems...several companies, including Cylink, Intel, etc., developed products for inclusion on the Evaluated Products List (EPL). NSDD-145 also created the NCSC, as noted earlier. As everyone knows, "DOCKMASTER" is a not-especially-secure machine used by NCSC-affiliated researchers and vendors to send mail, etc. The frequent comments about how the NSA/NCSC is "on the Net" are hardly revelatory. Many machines are on the Net, and you can surely bet that the important machines are not. (And of course various nets exist. Milnet (or MILNET, or whatever) is one, and various successors to the old AUTOVON and AUTODIN command and control nets.) The National Computer Security Act came later, circa 1987. I have a lot more stuff in my files, but this ought to satisfy the casually curious. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From bal at martigny.ai.mit.edu Wed Sep 29 12:41:47 1993 From: bal at martigny.ai.mit.edu (Brian A. LaMacchia) Date: Wed, 29 Sep 93 12:41:47 PDT Subject: Easy cracking Message-ID: <9309291937.AA01203@toad.com> Subject: Re: Easy cracking From: smb at research.att.com To: Marc Horowitz <marc at GZA.COM> Cc: jim at Tadpole.COM (Jim Thompson), cypherpunks at toad.com, honey at citi.umich.edu Date: Wed, 29 Sep 93 14:32:27 EDT >> The same kind of thing happened at Sun, except with the >> secure rpc stuff. Had a guy send mail saying, "I know your >> two primes." Sun replied, "No way." (And lauged internally.) I'm not sure this is how it happened, but the person (maybe there's more than one?) who did this is a cypherpunk, who will identify himself if he wants. He also wrote a paper on this. The first version of the paper had the private key at the top of the first page, but it got removed because certain spooks got upset. ?? As far as I know, Sun's secure RPC uses Diffie-Hellman with a 192-bit modulus. LaMacchia and Odlyzko solved the discrete log problem for that size, but there's no single private key to disclose. The discrete log problem is "brittle" -- you have to do a lot of precomputation work for any particular modulus, but once you've done that work finding individual discrete logs is easy. We had received a "challenge number" from someone at Sun (i.e. they gave us g^x mod p, and we had to find x). We included both numbers in our paper. Interestingly enough, although Sun used a 192-bit prime, the comments in the source code refer to p as a 128-bit prime. Also, g=3 for the Sun RPC system, and code comments refer to g as a primitive root modulo p. But 3 isn't a primitive root modulo this particular p. We suspected that someone at Sun decided 128 bits was too short, and increased the length of the modulus to 192 (still too short) without changing the comments and verifying the primitivity of g. --bal P.S. I've put a PostScript version of the paper up for anonymous FTP, if you're interested in the details. Get the file martigny.ai.mit.edu:/pub/bal/field.ps From ebrandt at jarthur.Claremont.EDU Wed Sep 29 13:11:47 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Wed, 29 Sep 93 13:11:47 PDT Subject: Clipper specifics In-Reply-To: <9309290733.AA19505@toad.com> Message-ID: <9309292009.AA01715@toad.com> I said: > Their spokesagency, NIST, has said that it will be illegal to encrypt > on top of Skipjack or to mung the LEEF. Checking the relevant document again, I think this is wrong: -------------------- Federal Information Processing Standards Publication XX 1993 XX Announcing the Escrowed Encryption Standard (EES) [blah blah] The security equipment shall ensure that the LEAF is transmitted in such a manner that the LEAF and ciphertext may be decrypted with legal authorization. No additional encryption or modification of the LEAF is permitted. [...] -------------------- I remembered this text out of context. Correctly interpreted, it looks like it's just a specification for devices implementing the (voluntary, natch) Escrowed Encryption Standard. Sorry about that. Eli ebrandt at jarthur.claremont.edu From peb at PROCASE.COM Wed Sep 29 14:01:48 1993 From: peb at PROCASE.COM (Paul Baclace) Date: Wed, 29 Sep 93 14:01:48 PDT Subject: soda.berkeley.edu Message-ID: <9309292057.AA00345@banff.procase.com> Name (soda.berkeley.edu:peb): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230-The disk drive which holds our anonymous FTP directory is dead; we are 230-unable to support anonymous FTP access until it is alive again. 230- 230 Guest login ok, access restrictions apply. ftp> dir 221- 221 Server shutting down. Goodbye. 421 Service not available, remote server has closed connection From pmetzger at shearson.com Wed Sep 29 14:01:52 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Wed, 29 Sep 93 14:01:52 PDT Subject: Sun Secure RPC Message-ID: <9309292058.AA16396@kublai.lehman.com> So if Sun Secure RPC has been cracked this wide open, why hasn't sun taken any action? Indeed, why hadn't I heard before? I would have expected this paper (which I am now reading) to have been disseminated far and wide... Perry From nate at rodin.VIS.ColoState.EDU Wed Sep 29 14:21:48 1993 From: nate at rodin.VIS.ColoState.EDU (nate at rodin.VIS.ColoState.EDU) Date: Wed, 29 Sep 93 14:21:48 PDT Subject: Address/phone number for Micotronics? Message-ID: <9309292120.AA20336@rodin.VIS.ColoState.EDU> Does anyone out there have the Address and phone number of Micotronics? -nate -- +-------------------------------------------------------------------- | Nate Sammons email: nate at VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate at monet.VIS.ColoState.Edu for my PGP key | #include <std.disclaimer> | Always remember "Brazil" +----------------------+ From koontzd at lrcs.loral.com Wed Sep 29 14:41:49 1993 From: koontzd at lrcs.loral.com (David Koontz ) Date: Wed, 29 Sep 93 14:41:49 PDT Subject: Clipper specifics Message-ID: <9309292138.AA04244@nebula.lrcs.loral.com> >From: "L. Detweiler" <ld231782 at longs.lance.colostate.edu> >Now, two Clipper chips will *not* work in conjuction with each other >unless each is fed a valid LEEF from the other. However, since the chip >does not accomplish this function (the communication, that is; it does >*create* the field), and it is handled outside the chip, there is no >guarantee that the system designer does not, for example, encrypt the >LEEF in the communications transit, thereby completely sabotaging the >`exploitative' tappability of the chip. >Hence there is a *very* real possibility that this scheme, or something >similar, could be used to gain Skipjack-level encryption without any >key escrow complications. I suspect the NSA is *extremely* worried >about this. They probably require that the chip purchaser promise to >use Clipper in a way that guarantees the LEEF is accessable >(plaintext). They may even create a contractual obligation wherein the >surrounding device (telephone or whatever) cannot be approved for sale >until it passes an NSA endorsed tapping test. (what fun!) I consider >this all very plausible and probable. (This would be a neat trick -- >use the chip itself to encrypt LEEF fields -- hah! twist an insecure >chip into a secure one, and spit in the face of the NSA!) Having read the chip spec for the MYK-78 carefully, being a chip/hardware weenie type, having military experience in cryptographic systems, and having exposure to Type I chips (which have a lot of similarity to clipper) there is a fundamental architecture feature of the MYK-78 that can be exploited. The MYK-78 allows multiple cryptographic contexts (encryption or decryption sessions) to be processed at the same time. This is intended to allow a chip with a single instantiation of the cryptographic algorithm to be used for full duplex communications. It requires all simultaneous encryption/decryption sessions to use the same session key although multiple cryptographic vectors (from different initial vectors) may be used. The MYK-78 is fast enough (bandwidth wise) to allow 20-30 duplex vocoder conversations, and could be used in a secure phone bridge using a single clipper chip. The undocumented or classified protocol requires that LEEFs be used for each session, extracted for transmission and input for reception. The chip requires that for every initial vector generated/requested that the included Law Enforcement Exploitation Field (LEEF or 'greened' LEAF) be subsequently input to enable decryption. The LEEF is output when the IV is read, the IV is part of the LEEF. (You can see that to use a single MYK-78 for multiple duplex conversations requires care in assuring that the distant end supplies its IV.) Cryptographic context for multiple sessions (send and receive sides for a single duplex path) is save through the use of save and restore context commands. To get around sending the LEEF we instead generate an IV, followed immediately by a save crypto context command (which produces the IV without the LEEF). The feed the IV (actually the LEEF to our own chip to enable decryption. We transmit the IV(sans LEEF) through separate protocol to the distant end. We receive the distant ends LEEFless IV and use it with the restore crypto context command to initialize the decryption session. This allows both ends to operate without actually transmitting a LEEF. Once decryption is enabled cryptographic resyncronization can be limited to exchange of LEEFless IVs. Securely exchanging IVs is not without difficulty. The clipper chip can't be used without establishing secure communications. Clipper chip modes can't be changed without requiring IV (and LEEF) introduction for other than ECB mode. One possibility is to use the chip in ECB mode with external XOR and feedback management to support a feedback mode. Likewise you could through the use of save/restore crypto context commands and by accepting the necessity for cryptographic restarts, switch the chip to ECB mode and encrypt the IV, say in a special key, for transmission to the distant end. A lot of dancing, but no one is allowed to cut in. -- >About the only company ready for Clipper chips is AT&T, and I think >they are using Diffie Hellman key exchange currently with some >proprietary algorithms (they have a license on Public Key directly from >PKP already) in their secure phones. I suspect any companies that come >out with new phone encryption equipment based on Clipper, if any are >insane enough to exist, will try to be compatible with the AT&T >`standard' (ug). As far as I know AT&T has not published their own key >exchange standard used by the phones, however. That is, it is >proprietary, and might even be protected by patents of their own! This >is a rare occasion where incompatibility is something to beam about! >From: rjc at gnu.ai.mit.edu (Ray) >"Cypherpunks Hack Hardware" > It seems logical that when the ClipperPhones come out, they will have >some kind of vocoder chip in them. (I doubt the (co)decoding will be >implemented on the Clipper chip itself) If so, cypherpunks can >take advantage of this situation. Not having seen a clipperphone (there are none currently available), one wonders if it is possible to play the above described trick with the clipper chip and implement your own communications protocol, capturing program control of whatever processor is used. This gives you skipjack security without big brother being inside. A mode switch could include compatiblility with the Escrowed Encryption Standard (EES). >From: "George A. Gleason" <gg at well.sf.ca.us> >Re your suggestion of a cypherpunk daughterboard to substitute for Clipper >in "secure" phones etc.: >I have a sneaky suspicion that AT&T won't be quite so cooperative. They >constantly do things in such a way as to make it darn hard to do anything >with their products except exactly what they intended to do. It might be >worth a try though... OTOH anything that creates more demand for AT&T phones >is a not-good thing in my view... we need an entirely competing product, and >preferably cheaper than an AT&T clipperphone + daughterboard, for obvious >competitive reasons. AT&T uses a proprietary vocoder known as ACELP, which will prevent knock off products without licensing. There are only a limited number of ways to prevent you from modifying their hardware. 1) Built In Test (BIT) features. The processor operating the phone could perform system level integrity checks and could refuse to work if the code space doesn't check out, say for valid memory contents being unmodified, or unused memory space not showing up blank. This could be defeated with access to instruction and data streams. 2) With a high enough level of integration no modification may be possible. (no visability or ability to modify instructions for operating the clipper chip) 3) Refuse to sell you the phones. Seems silly, but they already have rules on who they can sell to (U.S. citizens, corporations), under State Department rules. It seems probable they will do their own distributing and large customer could always be denied sales upon request of virtually any of the components of the U.S. government. 4) Tamperproof packaging of the phone (I don't think they'd get UL approval for self destruct devices), say erasing the vocoder algorithm. Sufficient numbers of false zeroizing should defeat this say, organizing a couple hundred customers to swamp the system. You would think a phone would be vulnerable to false zeroizing from throwing it in your briefcase. 5) Refuse to do maintenance and/or void the warranty. With a sufficient level of integration the phones become throw-aways upon failure. This doesn't affect organized crime. 6) legal barriers, largely ineffective (making it a federal crime to tamper with a clipperphone is a joke). Outlawing nonrecognizable encryption schemes (this could be spoofed, through the use of canned LEEFs with session keys you never intend to use, but allows some useful intelligence (the serial number) to leak. A single stolen and subsequently destroyed phone could supply the LEEF, but still serves as a red flag. The ability to not transmit the LEEF suggests the ability to recognize one. Intercepting and storing several thousand (over time) for use randomly as spoofed headers would hamper detection. This is all predicated on the assumption that at least NSA will test suspected crypto streams for clipper, and routinely do traffic analysis. You could imagine modifying the phone totally nondestructively, through the use of chip clips or whatever. -- >From: karn at qualcomm.com (Phil Karn) >Damn. Now I remember one of the points I meant to make in my NIST >comments, but forgot: if the LEEF is added periodically to the >ciphertext stream, that implies that the ciphertext data rate must be >greater than the plaintext rate. There is no evidence of anything at the chip level requiring periodic LEEF extraction. This would almost undoubtedly be handled at the communications protocol level. One would guess that the feds would be happy to have the LEEF occur every time you require crypto sync. Byte counts could be used to verify all this. --- All of this has to be apparent to at least the NSA, and I'm sure that no disreputable manufacturer will get to play with the clipper chips and build a product that doesn't adhere to EES. Having seen the certification process for implementations of Type I chips, product certification seems likely. Blackmarket demand can be generated from two sources: persons seeking more absolute privacy and criminals seeking secure communications. I am not at all bothered by the privacy aspect, but would be bothered by supplying or modifying phones for criminals, depending on the crime. It seems unlikely that there is any enforceable method to prevent modification of clipperphones, although discovery of a safe modification process could consume a large number of phones if countermeasures are included. All this is very sensistive to economy of scale. The more phone there are out there, the more blackmarket demand for modified phones and the easier it would be to avoid detection. The question is whether given the potential black market for modified clipperphones, whether skipjack is indeed secure against its creator. (sounds paranoid, I know) From kelly at netcom.com Wed Sep 29 14:46:48 1993 From: kelly at netcom.com (Kelly Goen) Date: Wed, 29 Sep 93 14:46:48 PDT Subject: (fwd) More on CIA's Internet Debut Message-ID: <9309292147.AA09267@netcom.netcom.com> Path: netcom.com!netcomsv!decwrl!spool.mu.edu!darwin.sura.net!udel!news!news.world.net!speedway.net!nyxfer!nyt From: nyt at blythe.org (NY Transfer News) Newsgroups: alt.conspiracy Subject: More on CIA's Internet Debut Keywords: pigs in the wire Message-ID: <XHFiac4w165w at blythe.org> Date: Sun, 26 Sep 93 20:35:32 EDT Reply-To: nyt at blythe.org (NY Transfer News) Distribution: world Organization: NY Transfer News Collective Lines: 93 /* Written 1:24 am Sep 27, 1993 by cwarren at peg.apc.org in igc:gen.bigbro */ /* ---------- "CIA, watching, watching, watching" ---------- */ Topic 189 CIA, INTERNET - TRUE! Response 2 of 3 agarton cafe.australia 9:00 am Sep 24, 1993 Internet From: <dlr at well.sf.ca.us> To: dlr at netcom.com Date: Wed, 22 Sep 1993 Found the following on the Well and thought it may be of interest. ***************************************************************** The following appears in the premier issue of "The Internet Letter." I'm not sure what exactly is meant in the third paragraph--it seems a bit garbled. Paul Wallner is actually the coordinator of the Intelligence Community's efforts on "open source" (unclassified information useful to intelligence analysts, etc.), and not just CIA's--technically he works for the Director of Central Intelligence in his role as IC coordinator. The Internet Letter is edited by Jayne Levin, and is apparently premiering at Inet'93. *************************************************************************** 004) CIA, U.S. GOVERNMENT INTELLIGENCE AGENCIES DEVELOP INTERNET LINK Fourteen U.S. government intelligence agencies, led by the Central Intelligence Agency, are developing plans that would allow them to share unclassified information via the Internet. "Everyone is using it [the Internet]," said Paul Wallner, CIA Intelligence Community Open Source coordinator, in an exclusive interview with The Internet Letter. "Why not take advantage of it ourselves and use it. "We're not looking at the Internet as a way to gather intelligence," Wallner said. "The Internet is not viewed as a source of information for us." The agencies that would use Internet to exchange "public" information are part of the National Foreign Intelligence program. They include the National Security Agency, CIA and the Defense Intelligence Agency. The intelligence community will use the Internet to share information and ideas among themselves and the academic community, Wallner said. For example, if the CIA were asked about the nuclear waste problem in Russia, "a good way" to find out would be to talk to the scientific community on the Internet, he said. The system in place now is inadequate. While each agency has its own internal electronic communications network, two intelligence analysts working at different agencies but on the same project cannot send E-mail to one another. There also are no electronic links between the intelligence and academic communities. Communication is carried out mostly by telephone. Because of security concerns, the internal community network will not be connected directly to the Internet, Wallner said. The CIA plans to address the issue of security by creating "air gaps" between classified and unclassified information. An air gap would create a physical space between an agency's internal network and an Internet link. "That allows us to have another check on hackers and potential viruses," Wallner said. He characterized the tone of the discussion over security as "technical." There are three phases to the project, and the first phase is expected to start next spring. It involves establishing nine prototype Internet "nodes" that will connect to an Internet backbone. The CIA plans to seek engineering support from private industry to help design the network's overall architecture. Unclassified materials produced by the Foreign Broadcast Information Service (FBIS) may be available for anonymous FTP (file transfer protocol). No decision has been made on whether a Gopher or WAIS (Wide Area Information Server) server will be used, Wallner said. The government is grappling with whether public distribution of FBIS publications via the Internet would violate copyright law. Selected FBIS publications now are available in print and microfiche to government agencies and universities. FBIS publishes eight daily reports, one for each geographic region of the world. The information is gleaned from news accounts, commentaries and government statements from foreign broadcasts, and it is translated into English from more than 80 languages. --------------------- Big brother is here and watching :) + Join Us! Support The NY Transfer News Collective + + We deliver uncensored information to your mailbox! + + Modem:718-448-2358 Fax:718-448-3423 E-mail: nyt at blythe.org + From fnerd at smds.com Wed Sep 29 16:46:33 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Wed, 29 Sep 93 16:46:33 PDT Subject: ATM info? Message-ID: <9309292339.AA10574@smds.com> Pardon the off-topic post, but I thought people here would know. Does anyone know of a good, technical but readable summary of ATM? (Asomething Transfer Mode) How are things addressed? How do you request a channel? What is the format of the headers? How do switches work? Etc. Thanks, -fnerd at smds.com From frc%bwnmr4 at harvard.harvard.edu Wed Sep 29 17:36:33 1993 From: frc%bwnmr4 at harvard.harvard.edu (Fred Cooper) Date: Wed, 29 Sep 93 17:36:33 PDT Subject: PGP Docs... Message-ID: <9309300034.AA01423@bwnmr4.harvard.edu> Hiya Folks, I'm gonna assume that no one has the PGP docs in postscript or rtf format because no one has responded to my post except a couple other ppl looking for the same thing. So... I have converted the ascii txt files to WfW2.0 docs. I'll be uploading (to my account) a uuencoded file of them for windows ppl, and I'll do my best have a couple portable formats as well. (RTF, and probably PS) To folks who asked for copies: Gimme a couple days and I'll mail them out to you. Later FRC From jet at netcom.com Wed Sep 29 17:46:33 1993 From: jet at netcom.com (J. Eric Townsend) Date: Wed, 29 Sep 93 17:46:33 PDT Subject: need the verilog decryptor script... Message-ID: <9309300042.AA07832@netcom6.netcom.com> I'll do something very nice for the person who sends me, either electronically or on paper, the verilog decryptor. I'm not going to use it to crack verilog code for gain. (I need it for a demonstration for some folks.) jet 4546 B10 El Camino Real #189 Los Altos, CA 94022 or if you want to encrypt: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQCNAiuStukAAAEEALzis/ofetFmRbpxV+33Bj1ptYdkPpgBelpU9mW51C0yJi3I 8jPmBlQ3AAbkqoFWiSCvsw9QkkszT5KMuHocGgMO6SAubH+eneBVoZaSZBEddVsT QZLsf2yKMMr6qDA0hkACeFeCmtM95KzeaePTCc/Hm91AxNcsduZT0W0+vi3bAAUR tCNKLiBFcmljIFRvd25zZW5kIDxqZXRAbmFzLm5hc2EuZ292Pg== =WFox -----END PGP PUBLIC KEY BLOCK----- From jet at netcom.com Wed Sep 29 18:06:32 1993 From: jet at netcom.com (J. Eric Townsend) Date: Wed, 29 Sep 93 18:06:32 PDT Subject: thx, anon person Message-ID: <9309300103.AA10021@netcom6.netcom.com> thanks to the anon person who sent me the crypto code. -eric, vainly attempting to improve security throughout the valley... From nowhere at bsu-cs.bsu.edu Wed Sep 29 19:41:50 1993 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Wed, 29 Sep 93 19:41:50 PDT Subject: Mykotoxin info (old repost) Message-ID: <9309300241.AA07485@bsu-cs.bsu.edu> This is for Nate et al. - >Date: Sat, 15 May 93 20:32:35 PDT Howdy. The following is a sampling of the information I was able to grab out of the dumpsers outside Mykotronx. I have much more than this, but I'm fucking tired of typing. I found a used Selectric typewriter ribbon from the Exec Secretary, and their entire general ledger. Will post more as I get the time. Do not disclose the origin of this document (me) but you can publish it if you like to show that the people the government wants us to trust to keep the Clipper design secret, don't know jack shit about security. Information: Mykotronx Inc. 357 Van Ness Way (1 blk so. of Del Amo) Suite 200 Torrance CA 90501 (310) 533-8100 fax (310) 533-0527 STU III (310) 533-0738 Founded 1979 Resale # SR-AB 12-711252 Dunn & Bradstreet # 00-611-5281 Banking: Shearson Lehman Brothers Attn: Steve Scerra Acct # 509 24261 12011 21250 Hawthorne Bl Torrance, CA 90509 (310) 540-9511 Employee Names: Bob Gottfried, CEO Leonard J. Baker, President Ralph O' Connell, aka "The Father of COMSEC", NSA Lobbyist Mike Furusawa, Space COMSEC Manager Patti Linahan, Executive Secretary Kikuo Ogawa, Buyer R. Todd, W. Greenfield, KG-44B (Outrunner) Project John C. Droge, Personnel Bob Todd, Manufacturing Manager Landy Riley, Engineering Federal Express Acct # 1122-7492-8 NSA Contact Home Address: Ralph O' Connell 1401 Woodbridge Road Baltimore, MD 21228 (301) 747-6276 Principle NSA Technical Contact: National Security Agency Maryland Procurement Office Attn: N244 (CEB) (MDA904-92-G-0354/J.O. 5001) 9800 Savage Road Fort George G. Meade, MD 20755-6000 (301) 688-8086 NSA Accounting Contact: National Security Agency Maryland Procurement Office Finance and Accounting Office 9800 Savage Road Fort George G. Meade, MD 20755-6000 (301) 859-6715 KG-46 Tactical Decryptor Unit and KG-48B Outrunner Provisioning Conference participants: Robert Todd, Mykotronx Bill Greenfield, Mykotronx G. Burgio, NSA J. Gochnour, NSA J. Wimpy, Air Force Computer Systems Command S. Solis, Air Force Computer Systems Command To Be Discussed at meeting May 18 & 19, 1993 Outrunner Project Milestone Payments: 1. Preliminary Studies $268,074 2/14/92 2. Place Subcontract w/ VLSI $47,917 2/22/92 3. Complete PDR KG-44B $61,431 4/13/92 4. Complete PDR VLSI $71,090 5/19/92 5. Complete SFA Review VLSI $78,470 7/12/92 6. Complete CDR VLSI $106,638 7/17/92 7. Complete first KG-44B $166,641 8/12/92 8. Complete CDR $132,454 6/18/92 9. Complete tests 1st KG-48B $151,957 12/16/92 10. Complete fab VLSI $203,941 11/17/92 11a.Deliver 2 KG-44B to NSA $81,080 9/8/92 11b.Deliver 2 KG-44B to NSA $81,081 10/7/92 12. Complete Cryto Verif VLSI $152,223 12/16/92 13. Deliver 4 KG-44B to NSA $171,571 3/2/93 14a.Deliver 2 KG-44B to NSA $30,432 3/30/93 14b.Deliver 2 KG-44B to NSA $30,432 4/20/93 15. Deliver 4 KG-44B to NSA $60,864 4/24/93 16a.Deliver 1 KG-44B to NSA $15,216 4/28/93 16b.Deliver 3 KG-44B to NSA $45,648 5/12/93 17. Deliver 4 KG-44B to NSA $42,840 5/13/93 Total: $2,000,000 KG-44 VLSI Procurement: United Technologies Microelectronics Center 1575 Garden of the Gods Road Colorodo Springs, CO 80907 (719) 594-8000 fax (719) 594-8032 PO#5703-44ACN1 Feb 19, 1992 Invoice Date Feb 5, 1993 "Customer to pick up parts. Secret item handling. Secret Design KG-44LSI. Mykotronx P/N M20/00301XXX" Government contract # MDA904-92-C-A027 Group C Testing: $4,400 5 Parts @ $675ea $3,375 Job #BE-7281 Group C Samples PIC Number: HP67AG84WTDLC "Note: Group B samples also included with this shipment (ref Packlist #10128" "The export of this product is controlled by the US Government. The export of this product or the disclosure of related technical data to foreign nationals without the appropriate export license is prohibited by law." Test Plan for MYK-80: Statement of Work for Exatron Inc. 5/13/93 Develop test interface board for MYK-80 (176 pin TQFP) and I.M.S. tester. Interface to utilize "particle interconnect" system. Data on MYK-80 I.O. and IMS tester to be supplied by Mykotronx. Interface board to be installed in a work station which utilizes Exatron "PET" handler, tooled for the MYK-80; a vacuum pick-up device (manual, pencil type); work surfaces for JEDEC tray storage and operator support. The IMS tester will mount directly under the "PET" handler. Two "PET" handlers are to be quoted with two sets of specific nesting tools for the MYK-80. Installation in place at Mykotronx and initial operator and maintenance training to be included. Design review of the interface board layout, prior to release of the board to fabrication is to be held at Mykotronx. Manuals and Training Manuals subcontracted to: ELITE Technical Corporation Warren A. Griswold, President 1903 B Marshallfield Lane Redondo Beach, CA 90278 (310) 372-5616 CAPSTONE Financial Commitments by Mykotronx Basic VII Cap VLSI 10 $212,000 Sun 1 Yr maint hw&sw $2,700 Compass $159,400 IKOS Systems & sw $57,500 ELITE Technical Corp $8,000 IMS/Sun $119,000 Versatec Plotter $36,500 SJ (1) $71,200 SJ (2) $76,200 Exatron Test System $78,000 ROM Cell $60,000 AT&T $100,000 Surf Mgt (real estate) $13,900 Universal Shielding (Tempest) $20,600 Plotter maint $5,000 Litronics $225,000 Spyrus (1) $45,600 Spyrus (2) $44,800 Compass (2) $110,000 VLSI Tech $30,000 VLSI Tech (2) $163,000 VLSI Tech CAPSTONE TQFP $10,000 New Media NRE Design $18,700 South Coast Designers $14,600 South Coast $6,000 VLSI Tech Exponeniator Tamper Sys $163,000 Conres logic analyzer $3,200 VLSI Myk-78 tester $33,800 Here are exerpts of the general ledger of Mykotronx, the Torrance Based Big-Brother outfit that is going to make the Clinton Clipper wiretap chip. Period: 01/01/93 to 04/30/93 (first 4 months of 1993) Acct Descr Beg Bal Debits Credits ==1000 series== Shearson Lehman 286,511 2,620,096 2,670,822 Paine Webber 95,602 868 0 Dean Whitter 55,391 484 0 Petty Cash 3,000 0 0 Union bank payroll act 13,408 900,000 816,443 Accts rcvbl -customer 1,185,829 1,981,356 2,562,064 Accts rcvbl - eployees 7,125 48,450 55,575 Franchise tx rcvbl 2,165 0 0 Unbilled costs&fees 567,792 533,347 0 Raw inventory 172,252 0 76,064 Prepaid taxes 1,116 0 0 Prepaid sales tax 688 0 688 Equp/mach/furn 383,038 20,695 0 Accum depreciation 234,425 0 23,000 Deposits 9,272 0 0 ==2000 series== Accts Payable 482,895CR 1,869,477 1,684,555 Sales tax payable 147CR 176 0 Sales tax paid 0 0 0 FIT withheld 0 10,854 135,741 FICA withheld 0 0 56,622 CA state IT withh 0 0 36,163 CA state disability 0 0 8,730 SUI pybl employer 0 0 5,788 FUTA payable 0 0 2,007 FICA employer 0 0 56,621 Pd Payroll txs withh 0 290,820 0 401K withheld 0 0 42,712 Accrued payroll 25,637CR 343,682 318,045 Dental withheld 0 0 674 Dental plan pd 0 674 0 Withh 401K pd 0 42,712 0 Accrued bonuses 214,040 341,240 127,200 (holy shit - I wish I worked for a place that paid bonuses like that!) Accrued Vacation 44,252 0 0 Excess billings 139,216 154,706 55,036 Gross payroll 0 751,859 0 Gross payroll distrd 0 2,552 754,412 Lease obligations 4,911CR 0 0 ==3000 series== Common Stock 169,320 0 61,435 Capital disbursement 916,675 222,230 0 Retd Earnings, begng 2,385,020CR 0 0 ==4000 series== Sales, returns&allowc 0 6,014 2,577,323 Interest income 0 0 1,353 Int income tax free 0 0 2,490 ==5000 series== Consultants 0 47,395 47,395 Subcontracts 0 932,210 110,419 Other direct costs 0 62,265 5,454 Printing/repro costs 0 542 0 Equipment rental/leasg 0 1,537 1,537 Maint, repairs 0 1,761 0 Delivery 0 3,217 0 Postage 0 960 0 Materials/parts 0 186,252 22,423 Telephone 0 93 0 Travel 0 10,437 0 Inv Cost of Mfg Prod 0 76,064 0 Direct labor-Engnrg 0 240,341 54,172 Direct labor-Technician 0 129,839 37,459 Direct labor-Adminst 0 47,542 10,081 ==6000 series== Indirect labor 0 60,319 0 Holidays 0 32,867 27,331 Sick leave 0 3,276 0 Vacation 0 38,096 25,976 Retroactive pay 0 4,400 0 Job advertisments 0 655 0 Grp Med Ins non sharhl 0 25,522 1,818 Mykotronx pd payrl txs 0 64,417 0 Workers comp 0 9,554 1,418 Interest pd 0 0 0 Consultants 0 2,013 0 ADP Acctg 0 1,493 0 Real World Acct Suppt 0 1,485 0 Bank charges 0 155 0 Blueprints/repro 0 390 0 Proposals 0 2,817 0 Copier expense 0 514 0 Depreciation - elec eq 0 23,000 0 Dues & memberships 0 749 0 Education & Training 0 2,850 0 Employee relations 0 4,531 0 Business expense 0 7,431 0 Equip rental/lsng 0 4,458 0 Computer software 0 2,114 0 Insurance 0 9,061 1,380 Janitorial 0 20 0 Licenses & Permits 0 175 0 Maint, repairs 0 2,096 0 Delivery 0 995 13 Postage 0 942 0 Amort organiz expense 0 0 0 Taxes - franchise 0 2,763 0 Real & Pers prop tax 0 0 0 Rent 0 54,080 0 Subscriptions/books 0 325 0 Office/lab supplies 0 14,183 446 Telephone 0 7,961 36 Travel 0 10,296 1,303 Utilities 0 5,833 0 LTD Ins, non sharehld 0 2,877 594 401K Mykotronx contrib 0 17,411 0 ==7000 series== Special Bonus 0 132,200 123,200 (Double holy shit!) G&A Labor 0 103,4520 0 Legal Services 0 5,895 0 Board of Dir Expnse 0 1,078 0 Financial Svc 0 7,505 0 Totals 0 12,555,101 12,555,101 Other little items: Locks at Mykotronx installed and maintained by Torrance Lock and Key, 2421 Torrance Bl. Torrance, CA 90501 (310) 320-8840 For some reason, Mykotronx is over 90 days late paying a lousy $50 invoice. Mykotronx has a Mossler safe. It cost $1,693 when they bought it 11/27/90. They have never changed the combination. Outstanding VLSI purchase orders: VLSI Tech (Capstone) $212,000 AT&T (Myk-78) $71,200 Motorola (Myk-77) $76,200 AT&T (Misc) $100,000 Compass (Software) $159,400 VLSI Tech (Myk-78) $66,200 Litronics (PCMCIA Crypto) $225,000 VLSI Tech (Expoteniator) $163,000 VLSI Tech (Capstone TFQP) $10,000 VLSI Tech (Myk-78 fix) $68,500 VLSI Tech (Myk-78A proto) $11,000 VLSI Tech (Myk-78A prod.) $220,000 VLSI Tech (Myk-80 #1) $48,000 VLSI Tech (Myk-80 #2) $33,750 VLSI Tech (Myk-82) $80,000 VLSI Tech (Myk-79) $79,500 Their LAN was installed by Strategies, Inc for about $14,000. From ld231782 at longs.lance.colostate.edu Wed Sep 29 19:56:33 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Wed, 29 Sep 93 19:56:33 PDT Subject: (1) a cypherpunk gold mine (2) RSA-PKP patent treatise (3) registration saturation (4) L.D. cypherpunk awards Message-ID: <9309300255.AA05515@longs.lance.colostate.edu> Cypherpunk Gold Mine --- Hello, Mark Riordan runs ripem.msu.edu and this has some *hot* files of interest to cypherpunks. He has a very complete DES library with many versions, BigNum packages, and a *lot* of collected files from the net on a wide variety of interesting topics. Many excellent and fascinating bibliographies too. Of particular current interest -- he also has the complete current ITAR online (as I noted earlier). I'm enclosing various file lists at the end of this document. RSA-PKP patent treatise --- Also, for everyone who has ever wondered about the RSA-PKP patent claims (and there's been a recent flurry on the list): An excellent and very authoritative posting on the subject was written by G. Irlam and posted to sci.crypt, etc. on May 20 1991. His email address in the file does not appear to work anymore, but this file is so well researched I am considering turning it into a FAQ on Usenet. pub/crypt/docs/public-key-partners-patents.txt Thanks to S. Bellovin for holding on to this, sending it to me in response to a query, and to M. Riordan for very quickly sticking it on the site after I uploaded it yesterday. Registration Saturation --- But I'm writing chiefly on the following subject. H. Finney, in his first brilliant post analyzing the ITAR relative to PGP distribution, noted that D. Bernstein posted an interesting note about his trials and tribulations in attempting to `export' a cryptographic algorithm SNUFFLE on sci.crypt. All he wanted to do was *post* to the newsgroup. He has a big batch of letters in a file he posted to sci.crypt that show the interesting relationships between the Commerce and the State Departments related to the `Arms registration' involved in legal cryptographic documentation distribution. This is an *extremely* important file for anyone that wants to see what the actual process of getting approval for cryptographic distribution entails, even for simply *publishing* simple algorithms. If anyone wants to `saturate the process' as has been discussed repeatedly on this list, this is a MUST READ. D. Bernstein went through this amazingly hilarious-at-times procedure as an academic exercise in showing the world how obtuse and bizarre the actual U.S. bureacratic structures are that regulate this stuff. Here's a guy that went through the whole surreal process just to POST to SCI.CRYPT. Its MIND BOGGLING. I've also uploaded the file to soda.berkeley.edu, but I don't know if E.H. will put it online (space is apparently very tight on soda). In the meantime, the file is ripem.msu.edu:/pub/crypt/docs/shuffle-export-hassles. for the hard-core cypherpunks who drool over code and algorithms, the code itself is in ripem.msu.edu:/pub/crypt/other/snuffle.zip Note: this and other files on the site (e.g. DES code) require that you submit an application attesting to U.S. citizenship and promising not to further distribute the code. (I don't know what has happened to D. Bernstein on the net. He used to be a great dogged flamer of people like Sternlight and Silverberg, but haven't seen him lately. I suspect he's working on a new important project and hasn't time for all the noise!) Cypherpunk Awards --- Finally, I should note that M. Riordan and D. Bernstein are sci.crypt FAQ editors, but other than that I don't know much about them except that they have both been instrumental in providing some *fabulous* public services over the internet, particularly to the cryptographic community. I vote them Cypherpunks of the Month (even though they're not on the list). D. Koontz gets my vote as Cypherpunk of the Week for the *sharp* analysis that twists Clipper into something useful -- sort of Security by Exploiting Exploitation. I sure hope Mycotronx isn't listening! We might find that LEEF/IV hole patched up in the next version! (nobody sneezed at the dumpster post, so I tend to think some of this stuff goes on in a vacuum.) I've asked him to put the Clipper specs he has pored over into a more public place (scanned for FTP site?) for other scheming cypherpunks to poke at. Ripem.msu.edu File Lists --- Here are some ripem.msu.edu indexes. Don't forget, you have to register to get some of these (particularly the code). Check out file /pub/crypt/GETTING_ACCESS. Flames for including this will be ignored. ===cut=here== FTP Directory /pub/crypt/docs Parent Directory luc-algorithm.txt dss-proposal.txt tmp nist-secure-hash.txt nsa-letter.txt merkle-khufu-khafre-snefru.txt crypt-bookstores.txt crypto-history-books.txt crypt-journals.txt secure-netnews.txt getting-nist-pubs.txt factoring-bibliography.txt polygonal-pubkey-algorithm.txt rsa-conf-93 ritter-cloak.txt sci.crypt-faq.txt crc-discussion.txt blair-crypt-lesson.tex.Z public-key-overview-by-nist.txt.Z scientific-american-pgp-letter.txt rabin-algorithm.txt des-break.ps.Z golding-weak-consistency-dissertation.ps.Z password-certification-authority.ps.Z fast-random-nums.txt enigma-wiring.txt shuffle-array.txt crypt-sites.txt md5-cryptanalysis.txt crypto.bib rsa-faq.ps.Z rsa-public-key-cryptography-standards secret-sharing.txt des-validation.txt arj-encryption.txt playfair-challenge.txt luc-public-key-paper.ps.Z zero-knowledge-proofs.txt goldbug-book-dedication.txt nonlinear-combiners.txt clipper-chip.txt dss-subliminal-channels.txt nist-capstone.txt nist-dss-clipper-testimony.txt dod-pmsp-messages.txt msdos6.0-compression-calls.txt software-cryptophones.txt letters-against-clipper.txt elgamal-using-dss.txt english-trigram-frequencies.txt privacy-anonymity-faq.txt three-cryptographers-problem.txt crypto-random-num.bib kryptoknight-authentications-and-distribution.tar.Z arms-controls-phone-number.txt feal-algorithm.txt warlock-matrix-pubkey-algorithm.txt s-box-exam-question.txt rsa-nist-dsa-agreement.txt des-chip-paper-src-090.ps.Z tis-pem-faq.txt des-break-errata.txt itar-export-bibliography.txt dept-of-commerce-crypto-docs.txt sbox-overview.txt cpsr-statement.txt letter-against-nist-dsa-giveaway.txt shuffle-export-hassles.txt sbox-bibliography.txt ky-28-military-voice-encryptor.txt itar-july-93.txt williams-crc-guide.txt british-intelligence-books.txt des-key-search.ps idea-eurocrypt90.ps english-dictionary-ftp-site.txt intelligence-bibliographies.txt intelligence-journals.txt public-key-partners-patents.txt file /pub/crypt/other/CRYPT-COLLECTION.TXT =Index of Cryptology Programs =Compiled by Mark Riordan mrr at scss3.cl.msu.edu =Last updated 9 October 1992 Note: I can't seem to keep this document up-to-date, especially for the "docs" subdirectory on ripem.msu.edu. So, I have tried to create new files in the "crypt" tree with long, descriptive filenames. To find the latest on ripem.msu.edu, be sure to do an FTP rather than relying on this document. /mrr 22 Feb 93 Warning: the .zip files here were created with zip 5.0, not with pkzip.exe, and cannot be extracted with pkunzip. Get unzip.exe (also available at this site). cbw.tar.Z Robert W. Baldwin baldwin at xx.lcs.mit.edu Crypt Breaker's Workbench, circa Oct 1986. Program to help you cryptanalyze messages enciphered with the simple, obsolete program crypt(1). Reportedly used to help decipher R. T. Morris's worm (after the fact) from source code found on backup tapes at Cornell. enigma-peake.c Philip Peake (philip at axis.uucp in Paris) C program inspired by the World War II Enigma cipher machine, but the algorithm is not completely identical. enigma_2.zip Devours, et al. MS-DOS .EXE of a BASIC program that emulates the real WWII Enigma cipher machine. Unfortunately, source is not included. hill.zip John Cowan <magpie.MASA.COM!cowan> C program to implement Lester Hill's encryption scheme involving matrix arithmetic. I believe the algorithm dates to the 1920's. This code is from comp.sources.unix, Volume 17 (Feb 1989). i-hat-correlation-analysis.zip Douglas A. Gwyn <Gwyn at BRL.MIL> (Theory by many others) C code for various cryptographically useful statistical analysis functions: Kullback's information measure for a 2-way contingency table, Gamma and related functions (Poisson, Chi-squared, etc.), Pearson's Chi-squareed, etc. jones-splay-compression.zip Jeffrey Chilton, Douglas W. Jones <jones at cs.uiowa.edu> Compression/encryption program based on splay trees. C functions. linear-rng.zip William S.England (Theory by Stephen K. Park and Keith W. Miller) High-quality linear congruential random number generator. I doubt it's truly of cryptographic quality, though. In C, with instructions for adding directly into Perl. lucifer-outerbridge.c Richard Outerbridge <71755.204 at CompuServe.COM> C implementation of IBM's Lucifer cipher, a predecessor of DES. Speed-optimized version of April 1984, but the algorithm is inherently slow. Includes program which implements CBC. lucifer-smith.c Jonathan M. Smith (original by Arthur Sorkin) C implementation of IBM's Lucifer cipher, a predecessor of DES. Version of March 1991. Includes main program. Pretty slow. md4dos.zip Jouko Holopainen <jhol at stekt.oulu.fi> (Theory by Ron Rivest) Fast DOS implementation of the MD4 message digest function. With DOS executable and C and 8086 assembly code. md5.zip Ronald L. Rivest, RSA Data Security rivest at theory.lcs.mit.edu Fast and popular one-way hash function in C taken from RFC 1321. Contains a test program. Version of April 1992. md5-karn.zip Phil Karn Very fast DOS 386 assembler implementation of Ron Rivest's MD5 hash function. Contains the Transform routine only (the time-consuming part). Uses Borland C. Version of February 1992. mrrcip.zip Mark Riordan <mrr at scss3.cl.msu.edu> Implementations of many classical cipher schemes (simple substitution, columnar transpostion, Playfair, "straddling checkerboard", Vigenere, and so on). Of historical interest only. Main programs all, most in C but some in FORTRAN (hey, I wrote 'em a long time ago). nsea.zip Peter C. Gutmann <pgut1 at cs.aukuni.ac.nz> "Nonpatented Simple Encryption Algorithm"--actually fairly complex block cipher similar to DES. C functions and main program, with optional 8086 assembler module. In-depth description of algorithm, invented by author. okeefe_encrypt.tar.Z R. A. O'Keefe, Edinburgh. C code for a fairly simple block transposition cipher based on linear congruential random number generators. rot13.c Unknown This is the well-known "Rot-13" cipher used to obscure offensive Usenet postings. Complete C program (very short). scott-newdes.zip Robert Scott, Mark Riordan (mrr at scss3.cl.msu.edu) C implementation of NEWDES, an unfortunately-named block cipher (doesn't have much to do with DES, but probably has similar security) designed by Robert Scott and described in a 1985 issue of Cryptologia. The algorithm is fast and doesn't take much code. C functions & driver program included. setzer-trans.zip William Setzer <setzer at math.ncsu.edu> "Quick hack" C program that does transposition of 8192-byte chunks of its input, based on a random number generator. snefru2.5a.tar.Z Ralph C. Merkle (merkle at xerox.com) One-way fast hash function in C by a well-known cryptologist. C functions and test main program. Most people seem to use MD5 instead. Version of November 1990. snuffle.zip Dan Bernstein <brnstnd at nyu.edu> Encryption program which turns a secure hash function into a very good cipher. Oriented towards the Snefru hash function, which is not included here. Simple (but profound) C code. May be an old version. wpcrack.tar.Z Ron Dippold <rdippold at qualcomm.com> Programs to crack the encryption on WordPerfect 5.1 encrypted files. Source code in Borland C. --- DES implementations --- barrett-des.zip David A. Barrett <barrett at asgard.cs.colorado.edu> Fast DES implementation, with main program that works in Cipher Feedback mode. Sometimes known as "fast-des". Vintage Feb 1991. cdes-bishop.zip Matt Bishop, NASA Ames <bishop at bear.dartmouth.edu> Nice C main program/front-end to DES to implement just about every known mode of DES: ECB, CBC, CFB, OFB. Does NOT include an actual DES implementation. Includes man page. chalmers-des-1.0.tar.Z Stig Ostholm ostholm at ce.chalmers.se DES implementation with several utility programs and many useful extra functions. Runs on a variety of Unix systems. Pretty good documentation. Vintage October 1990. crypt-bsd-4.3-reno.c University of California at Berkeley This is the "crypt" password hashing function from BSD Unix. It necessarily includes an implementation of DES. Code is marked as being from 1990. I haven't tested it, but I believe it is probably quite slow. Nevertheless, it's probably in wide use. csu10des.zip Phil Karn <karn at Qualcomm.COM> (original by James Gillogly) Famous public domain DES implementation by Phil Karn of KA9Q fame. Includes C functions & main programs. This is one of the first public domain DES implementations, and many minor variations of it are floating around. This one, last modified March 1987, was posted to comp.sys.unix, Volume 10. Karn's DES is not as fast as most of the more recent DES implementations but it's a "classic". d3des.zip Richard Outerbridge <71755.204 at CompuServe.COM> Fast, compact DES implementation from a longtime DES programmer. Includes optional double and triple DES encryption. C functions only; skimpy but adequate documentation. August 1992 version. desCore-2-How.tar.Z Dana How <how at isl.stanford.edu> Portable, very fast implementation of basic DES routines only. Supposedly the fastest C version around. Not so fast at key-setting (i.e., password hacking). This code was submitted to comp.sources.misc as Volume 29, Issue 80 and later updated in Volume 29, Issue 128. May 92 version. des-dist.tar.Z Antti Louko (alo at kampi.hut.fi) Fast DES implementation, with main program and C function library for arbitrary precision integer arithmetic. Also known as "alodes". Last modified September 1992, but most code seems to date from 1989. fdes5-baldwin.zip Robert W. Baldwin <BALDWIN at xx.lcs.mit.edu> Fast DES/crypt implementation in C (functions only) This seems to be 1989-vintage code. Evidently it was/is a favorite of password crackers. koontz-des.tar.Z David G. Koontz <2004ktz%ucsbuxa at hub.ucsb.edu> Fast but large DES C functions and main program. Dates to March 1991, at which time it was one of the fastest around. Good verification suite included. libdes-young-p2.tar.Z Eric Young (eay at psych.psy.uq.oz.au) This is one of the fastest DES implementations around. These C library routines are designed to replace the MIT Athena DES routines that MIT does not make available for export. Includes a main program and a test program. This is Patch level 2, from July 1992. I believe an earlier version was known as eBones. mitchell-des.zip D. P. Mitchell DES implementation in C, with minimal driver program. Version of June 1983. I don't know how fast this is. There's no documentation and the code is uncommented. pfdes.zip Stuart Levy, Minnesota Supercomputer Center Portable, fast DES implementation in C, from April 1988. Includes demo & benchmark programs. Warning: files need cleaning up (control-Z's and extra spaces in makefile). ufc-crypt-pl1.tar.Z Michael Glad, email: glad at daimi.aau.dk Ultra Fast Crypt, fast replacement for crypt(3), patchlevel 1. This comes from comp.sources.misc volume 28, issues 115-116, March 1992. allen-des486.zip Steve Allen, email: 73277.620 at compuserve.com DES source (Turbo C & Assembler) & executable for MS-DOS. Requires 486 due to use of BSWAP instruction. Runs at 108KB/sec on 486-33. Includes triple-DES. Main programs as well as functions provided. June 1993. From jdwilson at shell.portal.com Wed Sep 29 19:56:50 1993 From: jdwilson at shell.portal.com (James D Wilson) Date: Wed, 29 Sep 93 19:56:50 PDT Subject: Clinton UN Speech / Msg to Prez/VP In-Reply-To: <9309281255.AA14898@snark.lehman.com> Message-ID: <9309291743.AA00866@jobe.shell.portal.com.shell.portal.com> I agree that messages to president at whitehouse.gov, or to the whitehouse area on Compu$erve are not acknowledged. I have sent several to each as well as a letter direct to President Hillary, none of which were acknowledged. I wrote about a major money-waster in government medical care systems which could easily save the government in the three-digit millions. For what its worth, the boondoggle is this: When DOD decided to automate their medical facilities they put out an RFP. A company called SAIC was aware that the entire software system that VA uses to automate its 1000 bed hospitals is available for free under the FOIA. SAIC got a copy of all the VA software, and bid to DOD to take this VA software which the government already owns, and sell it back to DOD for giga-bucks. Now they (DOD) must negotiate with and pay for every change they want to that software. Meanwhile the VA programmers continue to improve the VA software (DHCP) as salaried government employees. In fact, now DOD is looking to pay SAIC to write interface routines to allow the DOD software (CHCS) to share info with the VA software (DHCP). You would think that this would get their attention, but no. Instead we continue to pay a private firm to sell us our own software. Hows this for medical care cost over-runs? -Kimo From mike at NetAcsys.com Wed Sep 29 20:16:33 1993 From: mike at NetAcsys.com (mycal (voices through your head @ 88.1MHz)) Date: Wed, 29 Sep 93 20:16:33 PDT Subject: misc crypto stuff Message-ID: <2caa2729.acsys@NetAcsys.com> Cypherdudes, First a prediction, soon the news media will pick up on a major story on somthing like child porn being transfered around using something like PGP. It will get blown out of preportion, and there will be a call to outlaw anything but government approved government decodeable encription. The news media will do one of there steller jobs on how bad this encyption problem is and how there needs to be somthing done about it (see there handling of gun related stuph). The cattle, I mean ppl of this country that still don't know the first thing about computers, and even lots of those who, do will support the idea that something needs to be done (to protect those poor children) and congress will pass a law, call it the "communication security act" (don't you just love the names they choose for these laws that do the opposite of what they are titled). And since there is no crypto lobby that weilds much power (unlike the gun lobby), it will get passed, despite the outcry on the net, overloaded government email boxes and editorials from computer rags. Second, ever wonder why they picked 80 bits for the key length for clipper? I think they used the same criterea that they used when they picked 56 bits for DES. I'm somewhat sure that clipper, like DES is a sound encription method, but I'm also somewhat sure that 80 bits is not out of the NSA's realm of attacking if it was neccary (like there not being able to use the giant back door called key escrow). They probibly calculated that 80 bits is strong enough to provide a good level of protection against most cracking attemts that could be mustered from other governments and orginizations, but not against theirselvs, at least scailed for the preposed release date. 3rdly and finally, if anyone is interested I can send them, for educational purposes only, the source code for Zipcrack. It hacks Zip V1.1 only, and does a brute force attack, but it is economical for <7 character passwords. It could be modified to do things like a dictionary search, but I lost intrest a couple years ago. Anyway it is in C and is quite short. mycal From MIKEINGLE at delphi.com Wed Sep 29 20:46:33 1993 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Wed, 29 Sep 93 20:46:33 PDT Subject: Active Eavesdropping of Clipper Phones Message-ID: <01H3JEQNSDGS90NQOF@delphi.com> >From what I've read, the basic Clipper chip provides no key management, and AT&T is going to use DH. If there is no key certification involved, wouldn't this be vulnerable to active eavesdropping? In other words, cut the victim's phone line somewhere between his house and the central office. Connect up your tap. It just passes voice through, but when he goes secure, it breaks in and hijacks the key exchange. Instead of the two phones exchanging keys with each other, both exchange keys with your tap. Now you have two keys. Load each into a Clipper chip. Send the received data to one chip to decrypt, then to the other to encrypt with the other key, and send it on its way. Neither party would know he's being had - it is much like feeding someone a phony PGP key. The tap could use stock Clipper chips, with no need to reverse engineer, since they will be used for their intended purpose - to communicate with another Clipper at the far end. You could probably reduce it to a notebook computer and the guts of two AT&T ClipperPhones. There must be something to prevent this - isn't there? --- MikeIngle at delphi.com "Hey hey, NSA, how many phones did you tap today?" From cvoid at netcom.com Wed Sep 29 20:51:50 1993 From: cvoid at netcom.com (Christian Void) Date: Wed, 29 Sep 93 20:51:50 PDT Subject: Mykotoxin info (old repost) In-Reply-To: <9309300241.AA07485@bsu-cs.bsu.edu> Message-ID: <Pine.3.05.9309292014.A21632-8100000@netcom3> > able to grab out of the dumpsers outside Mykotronx. I have Now that the whole world knows, you probably won't be able to do it again. :( From cme at ellisun.sw.stratus.com Wed Sep 29 20:51:57 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Wed, 29 Sep 93 20:51:57 PDT Subject: Clipper specifics Message-ID: <9309300351.AA28935@ellisun.sw.stratus.com> I'd be surprised if they allow you a month or two for more comments. My current fantasy about Clipper is that the NSA did a deal with AT&T, demanding removal of DES chips in favor of Skipjack, getting AT&T to buy into a limited delay in product introduction with the gov't promising to get the Skipjack standard in place by Summer so that the AT&T phones weren't held up too long. That's all out of my own head, but it hangs together. Does anyone know specifics about AT&T's prior plans? Was there a DES version? - Carl From MIKEINGLE at delphi.com Wed Sep 29 21:01:50 1993 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Wed, 29 Sep 93 21:01:50 PDT Subject: Digicash: good description Message-ID: <01H3JF7JM47M8WXVML@delphi.com> Does anyone know where I can get a good, lucid ASCII description of digicash systems? --- MikeIngle at delphi.com From rjc at gnu.ai.mit.edu Wed Sep 29 21:01:56 1993 From: rjc at gnu.ai.mit.edu (Ray) Date: Wed, 29 Sep 93 21:01:56 PDT Subject: Hacking ClipperPhones In-Reply-To: <01H3JEO8NAZM90NQOF@delphi.com> Message-ID: <9309300358.AA29944@geech.gnu.ai.mit.edu> Mike Ingle () writes: > > > What do you think? > > I think I definitely want to see Clipper Phones hacked and slashed out of > existence, but as long as hardware hacking is required, their availability > will be limited to a small group of people who know how to use a soldering > iron. Why not concentrate on using commercial hardware (fast modems, > soundblaster cards with DSP, voicemail cards with hardware compression, etc) > to make a plug-and-play cryptophone using 3DES or IDEA, and PGP keys? That > will appeal to a much larger audience. We should definitely learn all we can > about the Clipper system, however. In a way, I agree, but I am skeptical on the price point we will be able to achieve compared to just cannibalizing a ClipperPhone for spare parts. Ideally, the "cypherpunk phone" should consist of 1) cheap v.32 modem (<$200) 2) cheap 8bit sampler/audio card 3) CELP vocoder ardware, or cheap DSP with it implemented in software 4) a fast 486 (to do real time 3DES/IDEA @ CELP rates) Most people already have 1,4, they need 2,3 which will cost anywhere from $300-600 depending on what kind of DSP you get. This is too much money for such a standard to proliferate. If the ClipperPhones are cheaper, we could do better to buy those and cannibalize them for parts. (maybe we could convince ZyXeL to add an "auto-CELP-comp" mode like v.42 to their modems with built in CELP? ) -- Ray Cromwell | Engineering is the implementation of science; -- -- EE/Math Student | politics is the implementation of faith. -- -- rjc at gnu.ai.mit.edu | - Zetetic Commentaries -- From cme at ellisun.sw.stratus.com Wed Sep 29 21:26:33 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Wed, 29 Sep 93 21:26:33 PDT Subject: Carl Ellison on 'The Death of DES' Message-ID: <9309300422.AA29026@ellisun.sw.stratus.com> >Date: Wed, 29 Sep 1993 08:56:21 -0600 (MDT) >From: Michael Johnson <mpj at csn.org> >Subject: Re: Carl Ellison on 'The Death of DES' >To: Mike McNally <m5 at vail.tivoli.com> >In-Reply-To: <9309291229.AA11549 at vail.tivoli.com> >Message-Id: <Pine.3.05.9309290818.A2965-b100000 at teal.csn.org> > In other words, des | tran really >isn't much stronger than des des | tran is exactly as secure as des. A final tran adds nothing. It looks messed up to a human, but there's no cryptographic value added. tran is of value *only* between two strong ciphers and its only value is to increase the size of the block affected by the surrounding ciphers. > , but des|tran|des|tran|des|tran|des|tran... >could be quite strong (not to mention slow). Try the new tran. The one originally posted had a slow (LC) PRNG. The new one uses subtract-with-borrow and it's faster. Another consumer warning: the s-w-b PRNG has a huge period but that doesn't make it cryptographically secure. If anything, this is probably the easiest PRNG to break. - Carl From markh at wimsey.bc.ca Wed Sep 29 21:46:33 1993 From: markh at wimsey.bc.ca (Mark C. Henderson) Date: Wed, 29 Sep 93 21:46:33 PDT Subject: Triple DES Wanted Message-ID: <m0oiFr9-0001TXC@vanbc.wimsey.com> > > I'm looking for a Triple DES file encryption program that takes arguments > in the same form as /bin/crypt or /usr/bin/des. Is there a /bin/3des out > there somewhere? Has anyone come across 3des.c? And if so, can you > point me in the direction where it may be found. Thanks.. > > If no such program exists, I think it would be very useful to the > cypherpunks community if it were made available. I'd also like to see a You could write one based on Richard Outerbridge's d3des. The essential routines are provided in the package, all you'd need to provide is the wrapper. d3des is the basis of what is currently used in RIPEM 1.1 I also used it in munge, which is an experimental encryption program I distributed a while back which encrypts with either IDEA or triple DES or a composition of the two in CFB mode. munge has an interface much like that of Unix "compress" (munge, unmunge, mcat &c.) I'd do things somewhat differently if I were going to redo it, but you can have it if you want it. Just don't ask me to maintain it or port it to anything else, as I don't want to put any more effort into it. There is significant ugliness in the code due to the fact that I was always maintaining backwards compatibility with previous versions. (if you want either munge or d3des, you can get by ftp it from either wimsey.bc.ca or ripem.msu.edu. Please don't export munge or anything from wimsey.bc.ca outside of the U.S. and Canada). Mark -- Mark Henderson markh at wimsey.bc.ca (personal account) RIPEM key available by key server/finger/E-mail MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433 From nate at VIS.ColoState.EDU Wed Sep 29 22:21:50 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Wed, 29 Sep 93 22:21:50 PDT Subject: spookey PGP problem... HELP! Message-ID: <9309300518.AA04623@monet.VIS.ColoState.EDU> OK, I'm running PGP 2.3a on an SGI Indigo R4000 (not that the machine really matters, but it might help). My keys were generated with PGP 2.2 (on teh Mac), and I have since (obviously) upgraded to 2.3 then to 2.3a. I just recently started to encrypt a lot of things with my own public key, and also noticed that the files encrypted with my pubkey were not necessarily decypherable by my secret key. I replaced my keyrings from backups make a while ago (they're just missing most of my public keys), and still no luck. I get the following error: Pretty Good Privacy 2.3a - Public-key encryption for the masses. (c) 1990-1993 Philip Zimmermann, Phil's Pretty Good Software. 1 Jul 93 Date: 1993/09/30 05:14 GMT File is encrypted. Secret key is required to read it. Key for user ID: Nathaniel David Sammons <nate at VIS.ColoState.Edu> 1022-bit key, Key ID AE9C65, created 1993/05/24 You need a pass phrase to unlock your RSA secret key. Enter pass phrase: Pass phrase is good. Just a moment... Error: RSA-decrypted block is corrupted. This may be caused either by corrupted data or by using the wrong RSA key. For a usage summary, type: pgp -h For more detailed help, consult the PGP User's Guide. What the hell? Sometimes it will decrypt the file (and sometimes not). I am very reluctant to issue a key-revocation certificate, since I would like to avoid this as much as possible, but it's not looking good. This is really worrying me. The data I encrypted is not that important, but it's still a MAJOR problem I am having. thanks, -nate -- +-------------------------------------------------------------------- | Nate Sammons email: nate at VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate at monet.VIS.ColoState.Edu for my PGP key | #include <std.disclaimer> | Always remember "Brazil" +----------------------+ From nate at VIS.ColoState.EDU Wed Sep 29 22:31:50 1993 From: nate at VIS.ColoState.EDU (nate at VIS.ColoState.EDU) Date: Wed, 29 Sep 93 22:31:50 PDT Subject: spookey PGP problem... gets spookier... Message-ID: <9309300527.AA04638@monet.VIS.ColoState.EDU> I just compiled 2.3a on a sun 4/280 in my Lab, and I was able to decrypt the files fine. The Mac version (2.3a) was also able to decrypt the files just fine. Hmmmmm..... -nate -- +-------------------------------------------------------------------- | Nate Sammons email: nate at VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate at monet.VIS.ColoState.Edu for my PGP key | #include <std.disclaimer> | Always remember "Brazil" +----------------------+ From mbl at ml7694a.leonard.american.edu Wed Sep 29 22:31:58 1993 From: mbl at ml7694a.leonard.american.edu (Matthew B. Landry) Date: Wed, 29 Sep 93 22:31:58 PDT Subject: Triple DES Wanted Message-ID: <9309300526.AA09069@toad.com> >wimsey.bc.ca or ripem.msu.edu. Please don't export munge or anything >from wimsey.bc.ca outside of the U.S. and Canada). This admonition rings a bell in my mind. Most of the US export laws seem to be based on "export outside US or Canada". So I'm wondering, are the comparable Canadian laws as strict about export of crypto software? Specifically, if US authorities won't stop us from exporting to Canada (placing files on Canadian FTP sites), will Canadian authorities stop us from exporting to Europe, et al. (foreign users FTPing the files from the deposit site)? Yes, it's a longshot. No, I don't have all the facts. Yes, I will probably get enough "clueless newbie" flames to set my Ethernet card on fire. I know all of these things. Could someone please answer the question? -- Matthew B. Landry ml7694a at american.edu (Finally!) mbl at ml7694a.leonard.american.edu From mdiehl at triton.unm.edu Wed Sep 29 23:06:36 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 29 Sep 93 23:06:36 PDT Subject: key-server down? Message-ID: <9309300605.AA27084@triton.unm.edu> Hi guys. I've been using the pgp key server for some time now, but lately I've been having problems with it. I send it commands (last 30 for example) and never get a reply. I believe I'm using the one on toxicwaste, but can't be sure since I have an alias for it and I'm not at my email account at the moment. Is this site down or am I just impatient? Thanx in advance. Lagers, J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! <RL> Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. <Me> al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politicly Incorrect! <Me> Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From hfinney at shell.portal.com Wed Sep 29 23:21:50 1993 From: hfinney at shell.portal.com (hfinney at shell.portal.com) Date: Wed, 29 Sep 93 23:21:50 PDT Subject: REMAIL: Message expansion Message-ID: <9309300550.AA26673@jobe.shell.portal.com.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- One of the problems with chaining remailers as we do it now is that the message becomes quite a bit larger as you wrap encryption layers around it, one for each remailer in the chain. Currently, the remailers are all text-based, which requires that the message be re-ascii'd at each stage of the encryption nesting. But ascii'ing a binary file using PGP's method increases its size by 1/3. If this asciification could be avoided at each step, the message would still grow as we add the PGP header and the remailing instructions at each step, but this would be more moderate. The PGP header is about 170 bytes, and the remailing instructions should not be more than 70 or 80 bytes, bringing the total to something less than 250 bytes per step. I did some calculations. Suppose you wanted to start with a message of, say, 4000 bytes which you will send through ten remailers. First off, we get an advantage because PGP will compress the message before encrypting it the first time. Let's suppose it manages to compress it by a factor of two. This means that we have a 2000-byte binary message as our actual starting point. In one model, we assume that we add 250 bytes per step. This is what it would be if we did not have to do the ASCII'ing process at each nesting. In the other model, we assume that we add 170 bytes, multiply by 4/3, then add 65 bytes for the "-----BEGIN PGP MESSAGE-----" stuff, and then another 80 bytes for the remailing instruction. This is how most of the chaining software actually works now. Setting up for a ten step chain, the first method produces an output file of 4500 bytes, while the second produces a file of 54046 bytes. This is quite a difference. If we wanted to add three more steps because we feel paranoid, the first method increases to 5250 bytes, while the second balloons to over 120K bytes! As a more extreme example, if the initial message was 10K bytes as we have sometimes seen here, a ten-step chain would produce an output of 7500 bytes without expansion, and over 100K bytes with expansion. (The smaller-than-input size in the non-expansion case is due to the assumed 2-to-1 PGP compression of the original message.) I think we should consider enhancing the remailers so this asciifying step is not necessary. It could be done something like this. As each remailer receives the message, it must be in ASCII since that is the only thing that makes it across the mail connections. It decrypts and de-ascii's it by running it through PGP just like it does now. Suppose this produces something like the following: :: Request-Remailing-To: <next remailer in chain> <binary data> The first part is in ASCII and is terminated by two new-line characters in a row. The rest of the message can be easily determined to be binary; in fact, it is a binary PGP file, one readable for the NEXT remailer in the chain. This could be detected because PGP puts special bytes at the front of the file. All the remailer has to do specially is to asciify the binary portion of the message, add the "Encrypted: PGP" header if we still use that, and send it off as it normally would. The next remailer receives a proper ASCII PGP message which it can handle by the same rules. Making this enhancment to the remailers would reduce the problems of message bloat caused by the redundant asciifying of the message for each stage of the remailer chain. As we move towards remailers which do batching and which do message padding so that all outgoing messages are the same size, it will be more important to avoid this bloat since one big message will force all others in the batch to be padded to that size by the remailer. Hal Finney hfinney at shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLKpGOqgTA69YIUw3AQGLCQQAgGTXKgPOtgbqs3Dab/PZZNR1XPmLqJIH nuf5Znj3bpOGGPFGPG5pBfSBmDn3U5uEnG7lMwKovSpXI6zxLv3IEd93X6oGaL5L 5SlZtqzWNgGGXIIVCwNkaio/W5DCvwYq3ZXPtOTWgDH4ZtKOPaifEFF885qv/VCw heGzkqREjWM= =qwkV -----END PGP SIGNATURE----- From mdiehl at triton.unm.edu Wed Sep 29 23:36:36 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 29 Sep 93 23:36:36 PDT Subject: fido encryption. Message-ID: <9309300633.AA27652@triton.unm.edu> Hi all! I just conducted an experiment whose results indicate how far we (Cypherpunks) have to go in educating the American Public WRT encryption technology: I send an encrypted message via fidonet! (awk!) I had heard a rumor that fidonet forbade encrypted e-mail, but I had to find out for myself. Well, they do. Now I understand that these sysops are spending their own money and equipment to provide these services and have the right to regulate it in any way they see fit. That's not the point. The point(s) is/are: 1) They ACTIVELY enforce this policy. They don't simply say "no," they check (presumably) all of their user's email to enforce this policy. 2) They seem to be afraid to pass/store encrypted messages on their system. This indicates to me a lack of understanding of the concept of privacy. They seem to buy into the idea that "only BAD people encrypt email." We need to educate the electronic community before we can hope to educate the general public. The text of the messages follow with the names removed. BTW, the text of the plaintext message was "this is a test." Just thought you'd be interested. Comments? =========================================================================== BBS: The Tech Source Date: 09-16-93 (00:00) Number: 261 To: MIKE DIEHL Recvd: YES (PVT) Subj: Encrypted Mail Conf: (0) PrivateE-M --------------------------------------------------------------------------- This is a test. -----BEGIN PGP PUBLIC KEY BLOCK----- version: 2.2 mQCNAiu/jPkAAAEEAMGeUcJS+AfY32cDfy/v/UcA9JdqNOBOl/K37jFOBuCkXCSp lBa ---END PGP PUBLIC KEY BLOCK----- Mike, Please advise the sender of this message that I DO NOT allow encrypted mail to pass thru this system. I expect folks to abide by this rule voluntarily... I would hate to have to block all messages from this source becuase someone wishes to violate my policy :) BTW, the debate about "encrypted" mail with me is MOOT... I will not vary from my position... (just thought I'd let you know in case you wanted to try to convince me it is OK to allow encrypted mail...) please have the other person send encrypted mail directly to your machine... Thank you.. Sysop of Another BBS? From strick at versant.com Wed Sep 29 23:51:50 1993 From: strick at versant.com (strick -- henry strickland) Date: Wed, 29 Sep 93 23:51:50 PDT Subject: Files on DH, HM, RSA, & HP patents Message-ID: <9309300651.AA01982@versant.com> I've been spending the week in Washington DC, so I went by the Public Search Room of the U S Patent and Trademark office and requested the complete files on the four patents named in rfc1424 (see below). I have photocopies of nearly the complete folders, which include the initial proposed patent and all the written communication between the patent attorney and the patent examiner. (I think all four of these patents had all of their claims rejected on the first pass.) You see the patent examiner explain what is wrong, criticizing the patent, and the subsequent ammendments and more rejections until the patent is granted. (This is important information if one wishes to challenge a patent. You can see how various arguments were dealt with before and what likely responses from patent examiners are.) I'll bring all of this to the October Mountain View cypherpunks meeting, assuming it is Sat Oct 9. I'll also try and be ready to summarize the history of each patent. What are missing from my copies are mostly legal communications that had no techincal interest -- powers of attorney & calculations of fees. I also omitted most of the published articles that were referenced (several other patents and some scholarly papers) and some seemingly redundant diagrams. Of course, I also have copies of the final patents granted. The Search Room is an interesting place. I pulled several faux pas and got quite an education in patents and federal offices.... strick -------------- excerpt follows -------------- RFC 1424 Key Certification and Related Services February 1993 The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University have granted Public Key Partners (PKP) exclusive sub-licensing rights to the following patents issued in the United States, and all of their corresponding foreign patents: Cryptographic Apparatus and Method ("Diffie-Hellman")............................... No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle").................... No. 4,218,582 Cryptographic Communications System and Method ("RSA")................................... No. 4,405,829 Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig").................... No. 4,424,414 These patents are stated by PKP to cover all known methods of practicing the art of Public Key encryption, including the variations collectively known as El Gamal. From athomas at hydra.acs.uci.edu Wed Sep 29 23:56:36 1993 From: athomas at hydra.acs.uci.edu (Andrew Thomas) Date: Wed, 29 Sep 93 23:56:36 PDT Subject: Two basic questions... Message-ID: <199309300655.AA16855@hydra.acs.uci.edu> First: Is there an FTP site with the excellent cypherpunk article from Whole Earth Review online? If there isn't, would someone be willing to email me a copy? Second: I couldn't find a clear answer from the pgp docs, is there any reason to upgrade your public key with newer versions of pgp? I generated my keys with 2.2 and am now using 2.3a, does this matter at all? I'm sorry if these questions have been addressed recently, I'm a little out of touch (I've got 700+ unread cypherpunks messages in my folder 8( Thanks, Andrew Thomas <aethomas at uci.edu> Distributed Computing Support - Office of Academic Computing University of California, Irvine dcs at uci.edu (714)856-8383 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQBNAixX9koAAAECANP9I4cYQFIIspJ/GtCjgMh1F0mHSlNvdN+HoMy7mBN9xegI rxLEw1cKIK1pQNYhZBoI63kohSoqN5tYgDWU80kABRG0IEFuZHJldyBUaG9tYXMg PGFldGhvbWFzQHVjaS5lZHU+ =Pk2n -----END PGP PUBLIC KEY BLOCK----- From catalyst at netcom.com Thu Sep 30 00:26:36 1993 From: catalyst at netcom.com (Scott Collins) Date: Thu, 30 Sep 93 00:26:36 PDT Subject: Active Eavesdropping of Clipper Phones Message-ID: <9309300715.AA02851@newton.apple.com> What you are describing is the classic 'man-in-the-middle' attack. It is not avoidable short of out of band signalling i.e., you know some fact/secret about the person you really want to talk to (like their public key) that does not go through the man-in-the-middle (to possibly be replace), and can't be faked. Even with such knowledge, you still have to design your protocol with care. The essence of one protocol that is proof against this attack is this: Diffie-Hellman key exchange, during which the two parties seeking privacy also exchange challenge data which is returned after being concatenated with the other parties a^x, and signed with their private key. These are only the central parts. Additionally, certificates might be exchanged etc. But even slight changes to this would make it less secure: e.g. if each party only sent the cryptographically signed a^x, then an attacker willing to build the log table to (much later) derive x (this person could even be the intended recipient) could use saved portions of a real exchange to mount a 'replay' attack. Also, choosing a system wide 'a' and 'p' increase the incentive to build the tables, much better to let people put their personal choice for 'a' and 'p' in their signed & sealed key certificate. This protocol is described in detail in a paper (that is not in front of me right now, so I'm a little fuzzy) that was published in 'Designs, Codes and Cryptograpy', a periodical originating in the Netherlands. I believe the authors were Diffie and van Oorschot(?), but I'm just can't remember off the top of my head. If Whit Diffie is reading this message, then surely he will know, I think, even if he wasn't the author. Without 'out of band' signalling, the clipper chip would certainly be subject to this kind of attack. My understanding is that Skipjack is symmetric, so that's no help. We already noted that straight DH key exchange is vulnerable. The only remaining hope, then, is that your phone knows some serial number or such about the phone you _intend_ to be communicating with, and that this fact is an unavoidable part of the IV such that once you know who the message is supposed to be coming from, you couldn't decrypt it unless it really did, and no one else could fake it. This is possible, but obviously teetering on the brink of asymmetry, and therefore, I think, unlikely. The man-in-the-middle attack is so well known, however, that clipper must have _some_ provision for it, and I just haven't read the right paragraph yet. Hope this helps, Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2B Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From khijol!erc Thu Sep 30 00:36:58 1993 From: khijol!erc (Ed Carp) Date: Thu, 30 Sep 93 00:36:58 PDT Subject: fido encryption. In-Reply-To: <9309300633.AA27652@triton.unm.edu> Message-ID: <m0oiIHr-00022cC@khijol> > 2) They seem to be afraid to pass/store encrypted messages on their > system. This indicates to me a lack of understanding of the concept of > privacy. They seem to buy into the idea that "only BAD people encrypt > email." Most of them are scared to death over possible liability, like if someone is selling credit card numbers and using their BBS to forward the messages, they feel they could be legally liable. There have been too many instances of folks getting their computers confiscated over this sort of thing. Personally, I feel like it's all a scam, cooked up by those in the DA's office who are jealous because ours are bigger than theirs are. ;) A 486/50 with a couple of GB HD and a SVGA monitor and a couple of 1.4K modems is a pretty hard thing to pass up if you're short on computing power in the DA's office ... and short on $$$... :( -- Ed Carp, N7EKG erc at apple.com 510/659-9560 anon-0001 at khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever" From msattler at netcom.com Thu Sep 30 00:56:36 1993 From: msattler at netcom.com (Michael Sattler) Date: Thu, 30 Sep 93 00:56:36 PDT Subject: fido encryption. Message-ID: <9309300753.AA29492@netcom.netcom.com> At 00:33 9/30/93 -0600, J. Michael Diehl wrote: >We need to educate the electronic community before we can hope to >educate the general public. Damn straight. >BTW, the debate about "encrypted" mail with me is MOOT... I will not vary >from my position... (just thought I'd let you know in case you wanted to >try to convince me it is OK to allow encrypted mail...) please have the >other person send encrypted mail directly to your machine... Scary, isn't it? ----------------------------------------------------------------------------- Michael S. Sattler msattler at netcom.com +1 (415) 358-3058 Digital Jungle Software Encrypt now; ask me how. (finger for PGP key) "Don't Panic!" -- Douglas Adams "Don't Panic. Stay Cool." -- PRZ From jrk at sys.uea.ac.uk Thu Sep 30 01:56:35 1993 From: jrk at sys.uea.ac.uk (Richard Kennaway) Date: Thu, 30 Sep 93 01:56:35 PDT Subject: soda.berkeley.edu Message-ID: <8826.9309300858@s5.sys.uea.ac.uk> It seems to be ok now. ftp> open soda.berkeley.edu Connected to soda.berkeley.edu. 220 soda FTP server (Version wu-2.1c(17) Wed Sep 22 18:58:23 PDT 1993) ready. Name (soda.berkeley.edu:jrk): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230-Welcome to soda.berkeley.edu. We have recently upgraded our ftpd to 230-version 2.1c; it may still have some problems. 230-Mail bug reports to root at soda.berkeley.edu. 230- 230-Please read the file README 230- it was last modified on Wed Jun 2 17:02:13 1993 - 120 days ago 230 Guest login ok, access restrictions apply. ftp> The cypherpunks directory is still there too. BTW, when anon ftp servers ask you to give your email address as a password, how many of you do? -- ____ Richard Kennaway __\_ / School of Information Systems Internet: jrk at sys.uea.ac.uk \ X/ University of East Anglia uucp: ...mcsun!ukc!uea-sys!jrk \/ Norwich NR4 7TJ, U.K. From mdiehl at triton.unm.edu Thu Sep 30 02:11:52 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Thu, 30 Sep 93 02:11:52 PDT Subject: soda.berkeley.edu In-Reply-To: <8826.9309300858@s5.sys.uea.ac.uk> Message-ID: <9309300907.AA03671@triton.unm.edu> According to Richard Kennaway: > > BTW, when anon ftp servers ask you to give your email address as a > password, how many of you do? PFfffft! On which planet? ;^) Mike. From an12070 at anon.penet.fi Thu Sep 30 03:46:37 1993 From: an12070 at anon.penet.fi (S. Boxx) Date: Thu, 30 Sep 93 03:46:37 PDT Subject: Business Week on PGP subpoenas Message-ID: <9309301044.AA16225@anon.penet.fi> BusinessWeek, October 4, 1993 p. 43, Washington Outlook SPY VS. COMPUTER NERD: THE FIGHT OVER DATA SECURITY Philip Zimmermann wanted to strike a blow for freedom. To help computer users keep data safe from snoopers, the Boulder (Colo.) software consultant and self-described "privacy activist" wrote a program making it easy to encode messages with an all-but-unbreakable cipher. And he offered it free through the network known as the Internet. Now, Zimmermann's gift to cyberspace has exposed an enormous gap in the Administration's vision of a high-tech future. The White House is promoting a data superhighway as a key to a competitive future. But the National Security Agency is trying to restrict the use of high-quality encryption, which experts believe business will need to take full advantage of the "information infrastructure." The focus of the fight is a program Zimmermann calls "pretty good privacy" (PGP). On Sept. 9, two software companies in Texas and Arizona that have been involved in publishing PGP received federal grand-jury subpoenas requesting documents and information about the program. CRACKDOWN. Although the government won't discuss the investigation, the computer world has a pretty good idea what's going on. Because sophisticated encryption allows friends and foes alike to protect communications, the software is subject to the same export controls as munitions. But PGP has popped up all over the world. The probe, says Zimmermann's lawyer, Philip Dubois, is aimed at "finding out how it occurred and whether an offence was committed." Oddly, the crackdown on software comes just as the Administration is loosening export controls on computer hardware. But the schizophrenia may be more apparent than real. "I don't think they've got the export policy together enough to be split," says a key congressional staffer. The underlying problem, explains Paul Freedenberg, a Washington attorney and export-controls specialist, is that "Clinton is very cautious about dabbling in national security. This is an area that has essentially been turned over to the spooks." Meanwhile, there is growing concern in Congress about possible damange to exports. Quality encryption software "is available from foreign manufacturers...and is easily transmitted using only a long-distance telephone line and a modem," complained Representative Sam Gejdenson (D-Conn.) and a high-powered bipartisan group of colleagues in a Sept. 20 letter to the President. "Yet the U.S. continues to control this computer software as a Munitions List item." Says Douglas Miller of the Software Publishers Assn.: "The U.S. government is succeeding only in crippling an American industry's exporting ability." While the goal of the NSA and other security agencies - keeping U.S. messages secure while allowing Uncle Sam to read those of both domestic and foreign bad guys - is laudable, technology may be rendering it impossible. "Law enforcers no longer have the inside track," says Eben Moglen of Columbia University law school. Experts agree that NSA officials are smart enough to see the writing on the wall, encrypted or not. But, says James Bitzos [sic], president of RSA Data Security Inc. in Redwood City, Calif., the agency wants to maintain as much control as possible for as long as possible. Today, intelligence agencies still have a shot at finding "needles in the haystack," he says. "If they lift export controls, they might as well go home." Still, the NSA can't stave off the inevitable for long. Gejdenson hopes to produce legislation by early next year to revamp government policy on high-tech exports. The result will probably include looser restrictions on encryption software - and a victory for Phil Zimmermann in his battle to keep snoops out of his cyberspace. By John Carey ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin at anon.penet.fi. From catalyst at netcom.com Thu Sep 30 04:16:37 1993 From: catalyst at netcom.com (Scott Collins) Date: Thu, 30 Sep 93 04:16:37 PDT Subject: Active Eavesdropping of Clipper Message-ID: <9309301111.AA04034@newton.apple.com> Mike Ingle quotes Matt Blaze (and I paraphrase): >[...] so the procedure for placing a secure call is to recognize >each other's voice in the clear mode, go secure, and read the hash >value to each other [...] you have to rely on prior knowledge of each >other's voice. [...] This is out of band WRT the encryption engine. Note that it can be used exactly like an asymmetric encryption key for authentication. You know the other persons signature/voice in advance and it is hard for an attacker to reproduce it. >[an attacker could] trick you into saying some numbers, digitally record >them, and then rearrange them and play them back. The 'replay' attack. Of course you always make the other person say the hash _and_ some (never reused?) data in a lump (re: my earlier post -- concatenate your challenge data with their a^x before signing) for instance: "Bob, please sing me the hash to the tune of 'Raindrops Keep Fallin' on My Head'" (Security can be fun). >Or introduce enough line noise so the person couldn't recognize your >voice, and read the fake key Signature not valid. Sorry Bob, I'll have to call you back. That is, _if_ it's really you. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins at newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2B Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst at netcom.com From jrk at sys.uea.ac.uk Thu Sep 30 05:01:54 1993 From: jrk at sys.uea.ac.uk (Richard Kennaway) Date: Thu, 30 Sep 93 05:01:54 PDT Subject: Source for MacPGP 2.3 Message-ID: <18775.9309301202@s5.sys.uea.ac.uk> I wrote: >I have MacPGP 2.3 (the Macintosh application). From what ftp site can I >obtain the source? soda only has Mac source for 2.2. In fact, I've found that I do have the source for MacPGP 2.3 (although someone told me the source wasn't released yet). I can't remember where I got it though. I won't undertake to email it to anyone, nor to place it on anonftp indefinitely, as the only anonftp area I have is on my desktop machine. However, I'm not going to be around for about a week, so I'm willing to make it available during that time. Any last-minute demands for me not to do this for some reason? Tough, I'm about to leave, after which it's out of my hands. One-time offer, valid for one week only!! ========================================= MacPGP2.3 application, documentation, and source (for Symantec (Think) C 5.0.4), will be available by anon ftp on jrk.sys.uea.ac.uk, from Thurs 30 Sep (today) 14:00 GMT until Fri 8 October 08:00 GMT. Note that this machine is in the UK. It is the responsibility of those accessing it to satisfy themselves of the legality of their actions. These files are available strictly on an "as-is" basis, with no warranty, express or implied, concerning their contents. Instructions: ftp to jrk.sys.uea.ac.uk and give the following commands. user anonymous (Give your email name as password...or not. All transfers will be logged.) cd "RK's Public Folder" (Yes, there are spaces in the name of the directory. This is a Macintosh.) ascii get macpgp2.3src.sea.hqx.pgp (NB. If you are ftp-ing from anything but another Mac, the above file must be transferred in ASCII mode.) binary get macpgp2.3.sit Once you have these files, you need to do the following steps: 0. Put both files on a Mac, if they aren't there already. 1. Use Stuffit 1.5.1 or any decoder (such as DownLine) which understands that format to decode macpgp2.3.sit. This will give several files, one of which is the MacPGP 2.3 application. 2. Use the application to verify the signature on macpgp2.3src.sea.hqx.pgp and to strip the ascii armoring from it, creating a file macpgp2.3src.sea.hqx. (If you already have PGP on a unix machine, you can do this there and then transfer the .hqx file to the Mac.) 3. Use a BinHex decoder to decode macpgp2.3src.sea.hqx. This yields an application macpgp2.3src.sea. 4. Run that application, and it will decode itself into the source for MacPGP2.3. Paranoids should note that macpgp2.3.sit is not PGP-signed, and you only have my word that it does what I say it does. macpgp2.3src.sea.hqx.pgp is signed, but not by me, and I am not in a position to certify its signature. I use MPW C, so I haven't even compiled the source myself. I am *not* able to answer any questions about MacPGP itself, nor will I or anyone else be available during the coming week to sort out any ftp problems. I will probably be out of reach of email during that time as well. -- ____ Richard Kennaway __\_ / School of Information Systems Internet: jrk at sys.uea.ac.uk \ X/ University of East Anglia uucp: ...mcsun!ukc!uea-sys!jrk \/ Norwich NR4 7TJ, U.K. From yerazunis at aidev.enet.dec.com Thu Sep 30 07:11:54 1993 From: yerazunis at aidev.enet.dec.com (Just-in-time terraforming 30-Sep-1993 1008) Date: Thu, 30 Sep 93 07:11:54 PDT Subject: FIDOnet encryption (or lack thereof) Message-ID: <9309301408.AA18400@enet-gw.pa.dec.com> >Mike, Please advise the sender of this message that I DO NOT allow >encrypted mail to pass thru this system. I expect folks to abide by this >rule voluntarily... > >I would hate to have to block all messages from this source becuase >someone wishes to violate my policy :) > >BTW, the debate about "encrypted" mail with me is MOOT... I will not vary >from my position... (just thought I'd let you know in case you wanted to >try to convince me it is OK to allow encrypted mail...) please have the >other person send encrypted mail directly to your machine... Heh. OK. Well, if one behaves "ethically", then I guess *that* closes the issue. It's his machine and he gets to make the rules. (this is my personally-adhered-to point of view) On the other hand, he doesn't seem to have protected himself against steganographic users (though the low bandwidth of steganography compared to obvious encryption may make the steg channel less useful). Others may choose to take this point of view- but it's your karma. -Bill From frissell at panix.com Thu Sep 30 07:51:53 1993 From: frissell at panix.com (Duncan Frissell) Date: Thu, 30 Sep 93 07:51:53 PDT Subject: A Word From Bill Message-ID: <199309301447.AA04744@panix.com> Since president at whitehouse.gov is not yet a full duplex operation, I wanted to take this opportunity to speak personally to all you cypherpunkian-Americans (and the odd foreigner) out there. I feel your pain. I understand your concerns. Your concerns are my concerns. As I said on September 14th: I want to say to my fellow Americans, when you live in a time of change, the only way to recover your security and broaden your horizons is to adapt to the change, to embrace it, to move forward. Nothing we do, nothing we do in this great capital can change the fact that factories or information can flash across the world, that people can move money around in the blink of an eye. Nothing can change the fact that technology can be adopted, once created, by people all across the world and then rapidly adapted in new and different ways by people who have a little different take on the way that technology works... ...I tell you my fellow Americans, that if we learn anything from the collapse of the Berlin Wall and the fall of the governments of Eastern Europe, even a totally controlled society cannot resist the winds of change that economics, and technology, and information flow have imposed on this world of ours. That is not an option. Our only realistic option is to embrace these changes... William Jefferson Blythe Clinton --- WinQwk 2.0b#0 From trestrab at GVSU.EDU Thu Sep 30 08:11:53 1993 From: trestrab at GVSU.EDU (BETH TRESTRAIL) Date: Thu, 30 Sep 93 08:11:53 PDT Subject: Availability of ACM papers on Net ? Message-ID: <9308307494.AA749412627@GVSU.EDU> Are any of Chaum's papers on untraceable mail and digital cash available on the Net? Advise and thanks. Jeff From mnemonic at eff.org Thu Sep 30 08:12:00 1993 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 30 Sep 93 08:12:00 PDT Subject: FIDOnet encryption (or lack thereof) In-Reply-To: <9309301408.AA18400@enet-gw.pa.dec.com> Message-ID: <199309301507.AA09112@eff.org> Bill writes: > Heh. OK. Well, if one behaves "ethically", then I guess *that* closes > the issue. It's his machine and he gets to make the rules. (this is > my personally-adhered-to point of view) My question is this: how does he know that the mail is encrypted if he's not examining the mail that passes through his system? If he *is* examining the mail that passes through his system, it seems likely that he is violating the Electronic Communications Privacy Act. --Mike From mdiehl at triton.unm.edu Thu Sep 30 08:36:38 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Thu, 30 Sep 93 08:36:38 PDT Subject: FIDOnet encryption (or lack thereof) In-Reply-To: <199309301507.AA09112@eff.org> Message-ID: <9309301533.AA11734@triton.unm.edu> According to Mike Godwin: > Bill writes: > > Heh. OK. Well, if one behaves "ethically", then I guess *that* closes > > the issue. It's his machine and he gets to make the rules. (this is > > my personally-adhered-to point of view) > > My question is this: how does he know that the mail is encrypted if he's > not examining the mail that passes through his system? If he *is* > examining the mail that passes through his system, it seems likely that he > is violating the Electronic Communications Privacy Act. That was my first question. Then it occured to me that I have seen bbs's which have disclaimers wrt email privacy. That is the loophole he is exploiting. J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! <RL> Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. <Me> al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! <Me> Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From mnemonic at eff.org Thu Sep 30 08:46:54 1993 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 30 Sep 93 08:46:54 PDT Subject: FIDOnet encryption (or lack thereof) In-Reply-To: <9309301533.AA11734@triton.unm.edu> Message-ID: <199309301545.AA09637@eff.org> J. Michael Diehl writes: > That was my first question. Then it occured to me that I have seen bbs's which > have disclaimers wrt email privacy. That is the loophole he is exploiting. Well, there's no doubt that users of his system can agree to allow the sysop to read their mail. But what about people whose mail passes *through* his system on the way to somewhere else? He has no agreement with them. --Mike From lowton at typhon.dra.hmg.gb Thu Sep 30 08:51:54 1993 From: lowton at typhon.dra.hmg.gb (Andy Lowton) Date: Thu, 30 Sep 93 08:51:54 PDT Subject: reading mail In-Reply-To: <9309301525.AA17869@jobe.shell.portal.com.shell.portal.com> Message-ID: <9309301653.AA28776@typhon.dra.hmg.gb> > My question is this: how does he know that the mail is encrypted if he's > not examining the mail that passes through his system? If he *is* > examining the mail that passes through his system, it seems likely that he > is violating the Electronic Communications Privacy Act. > > > --Mike He could be using an automatic search for the string at the beginning of pgp encrypted messages. Maybe someone on his system could check this out by removing the strings and seeing if he notices it then. Not that I'm encouraging anyone to break the rules of the system you understand :) mr lotion From doug at netcom.com Thu Sep 30 09:01:54 1993 From: doug at netcom.com (Doug Merritt) Date: Thu, 30 Sep 93 09:01:54 PDT Subject: FIDOnet encryption (or lack thereof) In-Reply-To: <mdiehl@triton.unm.edu> Message-ID: <9309301559.AA23757@netcom4.netcom.com> J. Michael Diehl <mdiehl at triton.unm.edu> said: According to Mike Godwin: >> examining the mail that passes through his system, it seems likely that he >> is violating the Electronic Communications Privacy Act. > >That was my first question. Then it occured to me that I have seen bbs's which >have disclaimers wrt email privacy. That is the loophole he is exploiting. I haven't kept up on this, so correct me if I'm wrong, but I thought that BBS's had a choice as to whether to operate as Common Carriers or not, as long as they were strictly consistent. If they want to be categorized as Common Carriers then they have to have strict policies of hands-off privacy, are not liable for the content of messages on their board, and the ECPA applies. But if they do not guarantee privacy, do not perform any kind of censorship or other control of message contents, then they are not Common Carriers and the ECPA does not apply. Prodigy would be an example of the former, Internet email & news would be an example of the latter. Yes? No? Is this stale, ancient, and incorrect info? Or if the concept is correct, is the problem that they are merely forwarding email from systems that *are* CC's, and so the ECPA applies to that particular service, whether or not it applies to the rest of what they do? Doug From nobody at shell.portal.com Thu Sep 30 09:16:54 1993 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Thu, 30 Sep 93 09:16:54 PDT Subject: Communications Week Article Message-ID: <9309301527.AA17927@jobe.shell.portal.com.shell.portal.com> In the Sept 28 issue of Communication Week, Pg 35-36. _Who will hold the Clipper Keys?_ *Last Paragraph* The administration will choose the escrow agents based on experience in handling sensitive information, according to the EFF report. It will avoid choosing low enforcement agencies to avoid conflicts of interest and it will not choose private companies because of concerns about the companies' longevity, the report said. Well hmm... what about the longevity of governmental agencies, or even the government itself? From wcs at anchor.ho.att.com Thu Sep 30 09:21:54 1993 From: wcs at anchor.ho.att.com (Bill_Stewart_HOY002_1305) Date: Thu, 30 Sep 93 09:21:54 PDT Subject: Active Eavesdropping of Clipper Phones Message-ID: <9309301536.AA21844@anchor.ho.att.com> There are a variety of ways around Diffie-Hellman spoofing. The current STU-III phones from AT&T, Motorola, etc., use several approaches - there's the Crypto Igniter Key dongles that you need to authorize your phone, which provides one form of out-of-band authentication (partly authentication of the DH keys, but more important is authentication that the person at the other end is probably cleared for the level of classification you're running the call at); there's also an LCD display on the phone that shows the other person's DH half-key, so you can do voice verification if you want. They may do other stuff as well. Scott Collins mentioned the "digital signature on RSA keys", which the Capstone phones probably do even though Clipperphones probably won't. There are also tricks about sending half the key at a time, though they're apparently still hackable. Bill From koontzd at lrcs.loral.com Thu Sep 30 09:36:54 1993 From: koontzd at lrcs.loral.com (David Koontz ) Date: Thu, 30 Sep 93 09:36:54 PDT Subject: DES Implementations Message-ID: <9309301635.AA04850@nebula.lrcs.loral.com> >koontz-des.tar.Z >David G. Koontz <2004ktz%ucsbuxa at hub.ucsb.edu> >Fast but large DES C functions and main program. >Dates to March 1991, at which time it was one of the fastest around. >Good verification suite included. I have three or four faster versions, when I think about it I try and produce smaller code (Cache size limits, don't you know) From huntting at glarp.com Thu Sep 30 10:17:02 1993 From: huntting at glarp.com (Brad Huntting) Date: Thu, 30 Sep 93 10:17:02 PDT Subject: How about a pgp RFC... Message-ID: <199309301716.AA17376@misc.glarp.com> If you've followed the PEM working group in recent years, you may have come to the conclusion as I have that it is not going anywhere, and probably never will. In an effort to make e-mail crypto more wide spread, I suggest we draw up an internet-draft on the PGP message format, and the algorithms used to send and receive messages. At the moment I can think of nothing PEM can do that PGP cant. Granted there are problems scaling the web-of-trust model, but PGP is also capable of using a top down model (really just a subset of the web model). One thing such a draft is sure to do is send a clear signal to the PEM group that they must either start swimming or sink. brad From pmetzger at lehman.com Thu Sep 30 10:46:37 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Thu, 30 Sep 93 10:46:37 PDT Subject: How about a pgp RFC... In-Reply-To: <199309301716.AA17376@misc.glarp.com> Message-ID: <9309301743.AA01457@snark.lehman.com> Actually, an application type for MIME would seem to be more than sufficient... Perry Brad Huntting says: > > If you've followed the PEM working group in recent years, you may > have come to the conclusion as I have that it is not going anywhere, > and probably never will. > > In an effort to make e-mail crypto more wide spread, I suggest we > draw up an internet-draft on the PGP message format, and the > algorithms used to send and receive messages. > > At the moment I can think of nothing PEM can do that PGP cant. > Granted there are problems scaling the web-of-trust model, but PGP > is also capable of using a top down model (really just a subset of > the web model). > > One thing such a draft is sure to do is send a clear signal to the > PEM group that they must either start swimming or sink. > > > brad From 72114.1712 at CompuServe.COM Thu Sep 30 10:56:37 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Thu, 30 Sep 93 10:56:37 PDT Subject: POISON PILL Message-ID: <930930175113_72114.1712_FHF68-1@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Punksters, Here is probably one of those dumb questions we non-technical types ask from time to time on this list. Please indulge me though, in case there is something to it. In today's America, we live under the constant threat of police seizure of our computer equipment and other assets. Of course, we can encrypt the information our files, but this is, at best, a passive solution. Are there any positive actions we can take? POISON PILL--What, if anything, can be done to booby-trap a computer? Once the cops have a machine, one would expect that they will paw through everything in it. In addition, they will probably use the stolen computer for their own data processing needs. What could be done have the computer screw up the cop's data days, weeks or months after the seizure? Of course, I would never do such a thing myself, nor would I advise anyone else to do so. I do, however, have a passing academic interest in the subject. Same for you folks too, right? S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From tcmay at netcom.com Thu Sep 30 11:06:36 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 30 Sep 93 11:06:36 PDT Subject: FIDONet Censorship? Message-ID: <9309301806.AA27173@netcom5.netcom.com> FIDONet operators are sometimes blocking encrypted messages. So what else is new? Their machines, their rules. Strictly speaking, this is not censorship. However, we can try to get them to change their rules. Better, route around such machines. John Gilmore has one of the best lines I've seen on this, quoted in the new book by Howard Rheingold (something about "Living on the Virtual Frontier," just out in the stores). John says something along these lines: "The Net tends to view censorship as damage and routes around it." -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From mnemonic at eff.org Thu Sep 30 11:11:55 1993 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 30 Sep 93 11:11:55 PDT Subject: FIDOnet encryption (or lack thereof) In-Reply-To: <9309301559.AA23757@netcom4.netcom.com> Message-ID: <199309301808.AA10882@eff.org> Doug Merritt writes: > I haven't kept up on this, so correct me if I'm wrong, but I thought that > BBS's had a choice as to whether to operate as Common Carriers or not, > as long as they were strictly consistent. If they want to be categorized > as Common Carriers then they have to have strict policies of hands-off > privacy, are not liable for the content of messages on their board, > and the ECPA applies. But if they do not guarantee privacy, do not perform > any kind of censorship or other control of message contents, then they > are not Common Carriers and the ECPA does not apply. ECPA is not limited to common carriers. > Prodigy would be an example of the former, Internet email & news would > be an example of the latter. ECPA applies both to Prodigy and to Internet message traffic. --Mike From mnemonic at eff.org Thu Sep 30 11:16:38 1993 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 30 Sep 93 11:16:38 PDT Subject: EFF RESPONDS IN PGP CASE Message-ID: <199309301812.AA10948@eff.org> Forwarded message: From pmetzger at lehman.com Thu Sep 30 11:21:55 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Thu, 30 Sep 93 11:21:55 PDT Subject: POISON PILL In-Reply-To: <930930175113_72114.1712_FHF68-1@CompuServe.COM> Message-ID: <9309301812.AA01574@snark.lehman.com> Sandy says: > POISON PILL--What, if anything, can be done to booby-trap a > computer? Once the cops have a machine, one would expect that > they will paw through everything in it. In addition, they will > probably use the stolen computer for their own data processing > needs. What could be done have the computer screw up the cop's > data days, weeks or months after the seizure? Of course, I would > never do such a thing myself, nor would I advise anyone else to > do so. Why wouldn't you? Its your machine, so what you do to it is perfectly legal. You are under no obligation to make your equipment suitable for people who wish to steal it. Nothing you can do in software will actually work, because people can always boot off a fresh disk and start from scratch. I suggest that the best way, which is not easy, is to alter the roms on the disk controllers so they will only work properly with a special version of the operating system. Then, run the special version of the operating system, which should require that you do something periodically or it will self destruct. Even if they reformat the disk, they still won't have the proper information to feed the controller so that it doesn't do unfortunate things. Perry From koontzd at lrcs.loral.com Thu Sep 30 11:22:03 1993 From: koontzd at lrcs.loral.com (David Koontz ) Date: Thu, 30 Sep 93 11:22:03 PDT Subject: Clipper specifics (more) Message-ID: <9309301819.AA04996@nebula.lrcs.loral.com> >From MIKEINGLE at delphi.com Wed Sep 29 20:44:02 1993 >Where do you get the MYK spec? From: Mykotronx, Inc. 357 Van Ness Way, Suite 200 Torrance, CA 90501 (310) 533-8100 FAX (310) 533-0527 The cover title is "VLSI Encryption/Decryption Device Data" The title block on the first page is "MYK-78 Encryption/Decryption Device" There is no copyright notice, I'm a bit vague on whether such notice is required at present. Each page bears the trademark of Mykotronx. >Do Type 1 chips use 80-bit keys like Clipper? One of the characteristics of data sheets for type I chips incommon with the MYK-78, is that no where are byte counts mentioned. The specs instead refer to reading or writing requisite bytes to satisfy testable flags. Even examining key storage device specs (Crypto Ignition Key, etc.) no byte counts are mentioned, rather a count value is specified in the header structure. One could assume that the key size of a type I device is classified. Some with exposure to Type I implementations believe that independent round keys are loaded, requiring a lot more storage. Having seen references to the cryptographic check word in Type I specs, I don't. Type I chip Cryptographic Algorithms (CA) are not specified in theire unclassified spec sheets and are presumeably classified. It is my personal belief that the cryptographic algorithm (SKIPJACK) may be the same as used in Type I devices. Major differences other than ambiguity with respect to the cryptographic algorithm, between Clipper and Type I devices includes: 1) No Red/Black Separation the MYK-78 has a single data port 2) The MYK-78 allows you to "fish" for the Cryptographic Check Word (CCW), a value used to verify the key has been loaded correctly. Type I devices require the CCW be correct, otherwise requiring passing through reset. This implies a central key management authority. 3) Strict certification requirements for Type I implementations, similar to that done for devices/firmware/software used for controling and releasing nuclear weapons. One presumes the level of testing for Escrow Encryption Standard compliant devices will be done to the black box level if conducted by NIST. 4) Some Type I chips include two sets of Cryptographic Algorithm hardware for FULL DUPLEX operatiion in a communications environment. There are otherwise higher levels of integration as well. 5) Type I chips generally contain provision for remote rekeying and remote zeroizing. Presumeably these same facilities are instead dedicated to the Law Enforcement Exploitation Field in the MYK-78. 6) At least one Type I chip is a hybrid, also cotaining an Intel 8051 type microprocessor. It is possible that the same silicon is used for clipper and Type I devices, were two different I/O pads (red and black ports) located adjacent but interleaved, with the same package pin bonded to both pads. Enabling CCW fishing could be a bonding option. While one could argue that red/black area partitioning might be employed on the silicon it is worth remembering that during encryption, only the final product is black, and for decryption the final product is red. The flexibility in control programming mentioned for the MYK-78 could reflect the requisite ability to control red and black ports as well as using remote rekeying/remote zeroizing facilities for LEEF. >How far ahead of such cyphers as IDEA and 3DES are the Type 1 cyphers? >Much more secure, or are we pretty close to *them*? Judging from the clipper chip, not much. The number of clocks for executing the CA in a Type I chip is the same as the clipper chip (64 clocks). The MYK-78 has been publicly stated to perform 32 rounds (one could image 64 rounds in 64 clocks). #From: wcs at anchor.ho.att.com (Bill Stewart +1-908-949-0705) ... #There's a little more information than that, though not much. #The Mykotronix blurb says that the algorithm uses S-boxes, and takes #64 clocks to do the encryption; I think someone said it's 32 rounds of >S-boxes, which would correspond well with this. ... #My personal speculation is that it's probably about 24-key-bits #stronger than DES, but I don't have a good guess on the weak keys issue. In Dorthy Dennings preliminary report on Skipjack there were several points of interest brought up in the overview on the cryptographic algorithm: 1) Differential Cryptanalysis ...We concluded it was not + possible to perform an attack based on differential cryptanalysis in + less time than with exhaustive search. -- Increasing the number of rounds descreases the S/N ratio. Changing The XOR for mixing key and data iin the cryptographic function f(R,K) to an adder would likewise make exhaustive search faster than differential cryptanalysis for DES (Chapter 4 of E. Biham and A. Shamir "Differential Cryptanalysis of the DES Encryption Algorithm", 1993 Springer-Verlag.) 2) Weak Keys + ... We saw no pattern of symmetry in the + SKIPJACK algorithm which could lead to weak keys. -- A key is weak when the encryption function and decryption function are identical (the same key works for either) 3) Symmetry Under Complementation + ...We tested SKIPJACK for this property and found + that it did not hold. -- In DES K XOR E(R) == !K XOR E(!R). All three of these can be defeated by exchanging the XOR between key and data in f(R,K) with adders. The carry is a good place to introduce more key bits per round (8 bits when modulo 64). Subtraction is used for decryption and addition for encryption (or vice versa). The key schedule is relatively easy to extend to 80 bits from 56. It might not be this easy, but then again it could. DES also has a property of the S boxes that collectively map a 32 bit input value (R) to a 32 bit output value (SboxP) according to a 48 bit subkey (Kn) that for a large portion of the keys, there are not 2^32 distinct output values. Where the holes occur in the output domain are dependent on the key, and key and not key have the same holes. Exploring this property has led investigators to discover differential cryptanalysis and linear cryptanalysis. If it were possible to "see" the output of the P permutation directly you could discover the round key (Kn) over a large amount of chiphertext by simply checking for 32 bit symbols that don't show up. Correlating missing symbols to keys is a momentous task, potentially requiring years. It is possible that a 4th category of cryptanalysis attack (Brute force is the other method) is predicated on this property (D.W. Davies cryptically :) mentions a method of discovering 16 key bits in his book published in the U.S. in 1983, I believe). Skipjack may have provision for defeating this hypothetical attack. From tcmay at netcom.com Thu Sep 30 11:26:37 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 30 Sep 93 11:26:37 PDT Subject: Availability of ACM papers on Net ? In-Reply-To: <9308307494.AA749412627@GVSU.EDU> Message-ID: <9309301823.AA29101@netcom5.netcom.com> > > Are any of Chaum's papers on untraceable mail and digital cash > available on the Net? Advise and thanks. > > Jeff Chaum's paper on the "Dining Cryptographers Problem," which appeared in Vol. 1, No. 1 of the "Journal of Cryptology," was posted to the list by the ILF (Information Liberation Front). It has appeared a couple of times, so check the Cypherpunks archives. The earlier CACM (the 1981 paper on "mixes," the seminal 1985 paper on untraceable cash) papers are not likely to appear, I would guess. First, these journals are widely available. Chaum's article in "Scientific American" last summer is easy to find. Second, the many diagrams and equations make ASCII presentation problematic. (Chaum's DC-Net paper was mostly text, with no diagrams, so ASCII versions were faithful.) Third, it takes a lot fo work ot scan and OCR a paper, even one without equations and diagrams, and the payback just isn't there. I will repeat here what I have said before: Anyone serious about this stuff should take the few hours it will take to find a decent-sized library and make copies of these and other important papers. ASCII versions are not adequate. The "crypto" section of libraries also will expose the visitor to the whole universe of crypto--the journals, the Proceedings, the various books. And Xeroxes of specific papers are cheap--a lot cheaper than having someone spend several hours scanning and OCRing a paper, correcting the many flaws, figuring out an ASCII representation of equations and diagrams, etc. (Non-OCRed images are of course prohibitively large, and I doubt my friends in the ILF are interested in this avenue.) This is not a flame directed at Jeff, just a call for people to do things the old-fashioned way, namely, to read the sources. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From jet at netcom.com Thu Sep 30 11:36:38 1993 From: jet at netcom.com (J. Eric Townsend) Date: Thu, 30 Sep 93 11:36:38 PDT Subject: fido encryption. In-Reply-To: <9309300633.AA27652@triton.unm.edu> Message-ID: <9309301835.AA13352@netcom6.netcom.com> J. Michael Diehl writes: > 2) They seem to be afraid to pass/store encrypted messages on their > system. This indicates to me a lack of understanding of the concept of > privacy. They seem to buy into the idea that "only BAD people encrypt > email." However, they do understand the US Gov's policy of 'we found it on your system, we're taking everything, it doesn't matter if you knew it was there or not'. From jet at netcom.com Thu Sep 30 11:36:55 1993 From: jet at netcom.com (J. Eric Townsend) Date: Thu, 30 Sep 93 11:36:55 PDT Subject: misc crypto stuff In-Reply-To: <2caa2729.acsys@NetAcsys.com> Message-ID: <9309301833.AA13178@netcom6.netcom.com> "mycal (voices through your head @ 88.1MHz)" writes: > First a prediction, soon the news media will pick up on a major story on > somthing like child porn being transfered around using something like > PGP. It will get blown out of preportion, and there will be a call to > outlaw anything but government approved government decodeable encription. Already happened. The fellow used something like PGP, if not PGP, to encrypt stuff to disk. If I remember correctly (Mike G., help me out here) he was asked to cough up the passwords in court as part of the legal proceedings. (I remember this only because of the following discussion of 'can a court make me give out my passwords?) No call for banning of encryption by The Media(tm). From jet at netcom.com Thu Sep 30 11:41:55 1993 From: jet at netcom.com (J. Eric Townsend) Date: Thu, 30 Sep 93 11:41:55 PDT Subject: FIDOnet encryption (or lack thereof) In-Reply-To: <199309301507.AA09112@eff.org> Message-ID: <9309301840.AA13551@netcom6.netcom.com> Mike Godwin writes: > My question is this: how does he know that the mail is encrypted if he's > not examining the mail that passes through his system? If he *is* > examining the mail that passes through his system, it seems likely that he > is violating the Electronic Communications Privacy Act. With UNIX it's quite simple to grep for "-----BEGIN PGP MESSAGE-----"... and ditch messages that match. I guess one could also run the incoming mail through a spell-checker and reject messages with greater than %99 failure rate. Neither of these require actual examination of the message by a human, neither reveal content of a message to a human. From warlord at MIT.EDU Thu Sep 30 11:51:55 1993 From: warlord at MIT.EDU (Derek Atkins) Date: Thu, 30 Sep 93 11:51:55 PDT Subject: key-server down? In-Reply-To: <9309300605.AA27084@triton.unm.edu> Message-ID: <9309301826.AA05639@toxicwaste.MEDIA.MIT.EDU> Hi. I Know that the toxicwaste (pgp.mit.edu) keyserver is working. It had some problems when I installed a new mail-handler script, but that has since been fixed. The Last command should work fine (I used it a few days ago). Hope this helps. -derek From mnemonic at eff.org Thu Sep 30 12:01:55 1993 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 30 Sep 93 12:01:55 PDT Subject: misc crypto stuff In-Reply-To: <9309301833.AA13178@netcom6.netcom.com> Message-ID: <199309301856.AA11463@eff.org> J. Eric writes: > Already happened. The fellow used something like PGP, if not PGP, to > encrypt stuff to disk. If I remember correctly (Mike G., help me out > here) he was asked to cough up the passwords in court as part of the > legal proceedings. (I remember this only because of the following > discussion of 'can a court make me give out my passwords?) No call > for banning of encryption by The Media(tm). I'm not sure which case you're thinking of, Eric. I know of no case in which the defendant was forced to disclose his keys. --Mike From koontzd at lrcs.loral.com Thu Sep 30 12:06:55 1993 From: koontzd at lrcs.loral.com (David Koontz ) Date: Thu, 30 Sep 93 12:06:55 PDT Subject: Clipper specifics (more) Message-ID: <9309301906.AA18597@monolith.lrcs.loral.com> >From MIKEINGLE at delphi.com Wed Sep 29 20:44:02 1993 >Where do you get the MYK spec? From: Mykotronx, Inc. 357 Van Ness Way, Suite 200 Torrance, CA 90501 (310) 533-8100 FAX (310) 533-0527 The cover title is "VLSI Encryption/Decryption Device Data" The title block on the first page is "MYK-78 Encryption/Decryption Device" There is no copyright notice, I'm a bit vague on whether such notice is required at present. Each page bears the trademark of Mykotronx. >Do Type 1 chips use 80-bit keys like Clipper? One of the characteristics of data sheets for type I chips incommon with the MYK-78, is that no where are byte counts mentioned. The specs instead refer to reading or writing requisite bytes to satisfy testable flags. Even examining key storage device specs (Crypto Ignition Key, etc.) no byte counts are mentioned, rather a count value is specified in the header structure. One could assume that the key size of a type I device is classified. Some with exposure to Type I implementations believe that independent round keys are loaded, requiring a lot more storage. Having seen references to the cryptographic check word in Type I specs, I don't. Type I chip Cryptographic Algorithms (CA) are not specified in theire unclassified spec sheets and are presumeably classified. It is my personal belief that the cryptographic algorithm (SKIPJACK) may be the same as used in Type I devices. Major differences other than ambiguity with respect to the cryptographic algorithm, between Clipper and Type I devices includes: 1) No Red/Black Separation the MYK-78 has a single data port 2) The MYK-78 allows you to "fish" for the Cryptographic Check Word (CCW), a value used to verify the key has been loaded correctly. Type I devices require the CCW be correct, otherwise requiring passing through reset. This implies a central key management authority. 3) Strict certification requirements for Type I implementations, similar to that done for devices/firmware/software used for controling and releasing nuclear weapons. One presumes the level of testing for Escrow Encryption Standard compliant devices will be done to the black box level if conducted by NIST. 4) Some Type I chips include two sets of Cryptographic Algorithm hardware for FULL DUPLEX operatiion in a communications environment. There are otherwise higher levels of integration as well. 5) Type I chips generally contain provision for remote rekeying and remote zeroizing. Presumeably these same facilities are instead dedicated to the Law Enforcement Exploitation Field in the MYK-78. 6) At least one Type I chip is a hybrid, also cotaining an Intel 8051 type microprocessor. It is possible that the same silicon is used for clipper and Type I devices, were two different I/O pads (red and black ports) located adjacent but interleaved, with the same package pin bonded to both pads. Enabling CCW fishing could be a bonding option. While one could argue that red/black area partitioning might be employed on the silicon it is worth remembering that during encryption, only the final product is black, and for decryption the final product is red. The flexibility in control programming mentioned for the MYK-78 could reflect the requisite ability to control red and black ports as well as using remote rekeying/remote zeroizing facilities for LEEF. >How far ahead of such cyphers as IDEA and 3DES are the Type 1 cyphers? >Much more secure, or are we pretty close to *them*? Judging from the clipper chip, not much. The number of clocks for executing the CA in a Type I chip is the same as the clipper chip (64 clocks). The MYK-78 has been publicly stated to perform 32 rounds (one could image 64 rounds in 64 clocks). #From: wcs at anchor.ho.att.com (Bill Stewart +1-908-949-0705) ... #There's a little more information than that, though not much. #The Mykotronix blurb says that the algorithm uses S-boxes, and takes #64 clocks to do the encryption; I think someone said it's 32 rounds of >S-boxes, which would correspond well with this. ... #My personal speculation is that it's probably about 24-key-bits #stronger than DES, but I don't have a good guess on the weak keys issue. In Dorthy Dennings preliminary report on Skipjack there were several points of interest brought up in the overview on the cryptographic algorithm: 1) Differential Cryptanalysis ...We concluded it was not + possible to perform an attack based on differential cryptanalysis in + less time than with exhaustive search. -- Increasing the number of rounds descreases the S/N ratio. Changing The XOR for mixing key and data iin the cryptographic function f(R,K) to an adder would likewise make exhaustive search faster than differential cryptanalysis for DES (Chapter 4 of E. Biham and A. Shamir "Differential Cryptanalysis of the DES Encryption Algorithm", 1993 Springer-Verlag.) 2) Weak Keys + ... We saw no pattern of symmetry in the + SKIPJACK algorithm which could lead to weak keys. -- A key is weak when the encryption function and decryption function are identical (the same key works for either) 3) Symmetry Under Complementation + ...We tested SKIPJACK for this property and found + that it did not hold. -- In DES K XOR E(R) == !K XOR E(!R). All three of these can be defeated by exchanging the XOR between key and data in f(R,K) with adders. The carry is a good place to introduce more key bits per round (8 bits when modulo 64). Subtraction is used for decryption and addition for encryption (or vice versa). The key schedule is relatively easy to extend to 80 bits from 56. It might not be this easy, but then again it could. DES also has a property of the S boxes that collectively map a 32 bit input value (R) to a 32 bit output value (SboxP) according to a 48 bit subkey (Kn) that for a large portion of the keys, there are not 2^32 distinct output values. Where the holes occur in the output domain are dependent on the key, and key and not key have the same holes. Exploring this property has led investigators to discover differential cryptanalysis and linear cryptanalysis. If it were possible to "see" the output of the P permutation directly you could discover the round key (Kn) over a large amount of chiphertext by simply checking for 32 bit symbols that don't show up. Correlating missing symbols to keys is a momentous task, potentially requiring years. It is possible that a 4th category of cryptanalysis attack (Brute force is the other method) is predicated on this property (D.W. Davies cryptically :) mentions a method of discovering 16 key bits in his book published in the U.S. in 1983, I believe). Skipjack may have provision for defeating this hypothetical attack. From derek at cs.wisc.edu Thu Sep 30 12:11:55 1993 From: derek at cs.wisc.edu (Derek Zahn) Date: Thu, 30 Sep 93 12:11:55 PDT Subject: How about a pgp RFC... In-Reply-To: <9309301743.AA01457@snark.lehman.com> Message-ID: <9309301909.AA11406@balder.cs.wisc.edu> Perry Metzger: > Actually, an application type for MIME would seem to be more than > sufficient... That's perfect! type: application subtype: pgp The registration procedure is pretty simple. I'd be happy to help work out a specification. If anybody tackles this, with or without help, please let me (or us) know. derek From MJMISKI at macc.wisc.edu Thu Sep 30 12:21:55 1993 From: MJMISKI at macc.wisc.edu (Matthew J Miszewski) Date: Thu, 30 Sep 93 12:21:55 PDT Subject: POISON PILL Message-ID: <23093014195422@vms2.macc.wisc.edu> Sandy, There are a number of ways in which you can set up *your* machine to self-destruct. The best way to accomplish this is through Perry's suggestion of a regular security check to which you must reply or the PILL is activated. If all you are concerned about is private mail or the like, a simple batch wipe file would work (hide the wipe program). Putting any prompt at boot and turning off obvious ways of defeating *your* security will help. Not to start everyone flaming, but there is nothing wrong with destroying your own computer thru infamous combinations of interrupt hooks and the like (was that cryptic enough to avoid a virii flame?) --Matt ______________________________________________________________________________ "This new technology (the printing press) threatened the Crown, which shuddered at the thought of widespread dissemination of works advocating religious heresy and political upheaval. The Crown's solution to the problem was a system of regulation designed to control this "dangerous" art." -From my Copyright Law Text (refrencing the Statute of Anne - the first Copyright Statute) (c)1993 ______________________/___________________________________mjmiski at macc.wisc.edu From m5 at vail.tivoli.com Thu Sep 30 12:26:38 1993 From: m5 at vail.tivoli.com (Mike McNally) Date: Thu, 30 Sep 93 12:26:38 PDT Subject: misc crypto stuff In-Reply-To: <2caa2729.acsys@NetAcsys.com> Message-ID: <9309301919.AA17782@vail.tivoli.com> J. Eric Townsend writes: > "mycal (voices through your head @ 88.1MHz)" writes: > > First a prediction, soon the news media will pick up on a major story on > > somthing like child porn being transfered ... > > Already happened. The fellow used something like PGP... > No call for banning of encryption by The Media(tm). Ahh, but recall how The Media operates. There will come a case involving encrypted data that for some reason can be made spectacular by the law enforcement agency involved. The agency will ensure that The Media paints as threatening a picture of "the encryption crisis" as desired. Even better would be the reaction to encryption involved in some Threat to National Security. In a situation anything like the Gulf War, any ominous words in a Pentagon press briefing will be siezed upon hungrily by The Media. All it'll take is one memorable incident. Even if mountains of evidence turn up later to show that the case was bogus, it won't matter. A suitable majority of the public will only remember the original terror, the few soundbytes about national security/drug dealers/cocaine cartels/child snuff films/Islamic extremists, and there'll be no stopping the Government from enacting whatever laws it pleases. -- Mike McNally From nobody at rosebud.ee.uh.edu Thu Sep 30 12:31:56 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Thu, 30 Sep 93 12:31:56 PDT Subject: REMAIL: digicash Message-ID: <9309301926.AA20380@toad.com> -----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, I've been experimenting with a primitive digital cash system for remailers. Originally I had hoped to combine the remailing and banking functions of the elee7h5 at rosebud remailer, but for now I have an even more primitive cash system implemented at elee6ue at rosebud. It seems to be performing as expected. A digital cash accepting remailer, along with a good positive reputation system, is the "crypto-anarchist" answer to labeling anonymous mail with subjects and/or usernames. (Of course, a subject that enables anonymous mail to blend in is great - such as "Re: your mail"). (Incidentally, since running pgp to get the signature from a pgp-signed message is expensive, I patched the script I use for positive reputation to give the option of checking signatures or not, if anybody is interested.) Currently, the only objection I've heard to anonymous mail is "somebody can abuse it"; future remailers will require payments, helping to address this concern. Basically, the remailer recognizes a Digicash pasting token, and for now the cash is a string of letters and numbers. Before remailing, the digicash is extracted and looked up in a cash list (which I create). If the cash is in the list, it is assumed to be valid, and the list is rewritten minus the cash string just used. If the cash isn't present, it is assumed to be invalid, and an insufficient funds message is remailed instead. The remailer does not keep a list of "spent" cash strings, so there is the possibility of duplication (once in every 36^60 times). As far as correlating the cash used to individual and a message, I can only assure you I could care less about the required bookkeeping. The pasting token looks like the others, and you use it in a similar way - - ----------8< cut here >8---------- :: Digicash: <here is the string> - ----------8< cut here >8---------- For example, I "paid" for the remailing of this message with - ----------8< cut here >8---------- :: Digicash: BcKjSoUEQaTam9xPs0oso2j0UVVb1M6OyxTn8QSX0rdT3eUIH4Vq1rXEpYH1D - ----------8< cut here >8---------- (Now, the above cash string should be invalid! :-) The way I'm distributing valid cash for the remailer is by email - mail me and I'll send you some valid cash strings. No charge :-) Karl L. Barrus <klbarrus at owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLKsyGYOA7OpLWtYzAQG/QAQAwNbDbKOdnWJ4g/tt8+0AdtR+5TzETfaU DaodN1LDs7+w46/KlyIoI/B9+C710U1f46dnd81MxMm6eTGcbwnkrTBhz7QlO7NH 1joVaoe8TVljk2RZnCYmpYbzXjuogZcAuuZKVWY3ES2iElKZLr24oCZbHWljPV4o griHzfbmHYI= =54L7 -----END PGP SIGNATURE----- From stig at netcom.com Thu Sep 30 13:21:55 1993 From: stig at netcom.com (Stig) Date: Thu, 30 Sep 93 13:21:55 PDT Subject: Digicash: good description In-Reply-To: <MIKEINGLE@delphi.com> Message-ID: <9309302016.AA13280@netcom3.netcom.com> In <01H3JF7JM47M8WXVML at delphi.com>, Mike Ingle wrote... > Does anyone know where I can get a good, lucid ASCII description > of digicash systems? > > --- MikeIngle at delphi.com > I haven't tested it, but I pulled a postscript to ascii converter off the net recently (alt.hackers I think)... I'll make it available as netcom.com:/pub/stig/src/gsascii.shar.gz Stig ;; __________________________________________________________________________ ;; Stig at netcom.com netcom.com:/pub/stig/00-PGP-KEY ;; It's hard to be cutting-edge at your own pace... 32 DF B9 19 AE 28 D1 7A ;; Bullet-proof code cannot stand up to teflon bugs. A3 9D 0B 1A 33 13 4D 7F From mccoy at ccwf.cc.utexas.edu Thu Sep 30 13:22:04 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Thu, 30 Sep 93 13:22:04 PDT Subject: POISON PILL In-Reply-To: <9309301812.AA01574@snark.lehman.com> Message-ID: <199309302019.AA01877@flubber.cc.utexas.edu> > From: "Perry E. Metzger" <pmetzger at lehman.com> > > Sandy says: > > POISON PILL--What, if anything, can be done to booby-trap a > > computer? Once the cops have a machine, one would expect that > > they will paw through everything in it. [...] > > Why wouldn't you? Its your machine, so what you do to it is perfectly > legal. You are under no obligation to make your equipment suitable for > people who wish to steal it. Well, you can do this, but you are taking your liberty into your own hands by doing so. Once your computer is siezed as part of a valid search warrant it is no longer "your computer" but is evidence in an ongoing investigation. If you were to booby trap your system so that there was actual descruction of components or data you would do two things: -1 Really, really piss off those investigating you. Nothing like giving people who can make your life a living hell a reason to want to make your life hell... -2 Opening yourself up for destruction of evidence and obstruction of justice charges in addition to whatever else they may have had on you. If you want to protect your data is such situations you need to set up your system so that even if they have the data it does them nothing (e.g. encryptiong), not so that it will destroy the data. jim From greg at ideath.goldenbear.com Thu Sep 30 13:51:56 1993 From: greg at ideath.goldenbear.com (Greg Broiles) Date: Thu, 30 Sep 93 13:51:56 PDT Subject: Fidonet, policies, privacy, and power. Message-ID: <VuJPac1w164w@ideath.goldenbear.com> The following is from Fidonet Policy Documet 4.06, dated May 5 1989. It's marked as not being in force yet, as it's awaiting ratification; dunno if it ever was or not. ---------- 2.1.3 Responsible for All Traffic Entering FidoNet Via the Node The sysop listed in the nodelist entry is responsible for all traffic entering FidoNet via that system. This includes (but is not limited to) traffic entered by users, points, and any other networks for which the system might act as a gateway. If a sysop allows "outside" messages to enter FidoNet via the system, the gateway system must be clearly identified by FidoNet node number as the point of origin of that message, and it must act as a gateway in the reverse direction. Should such traffic result in a violation of Policy, the sysop must rectify the situation. 2.1.4 Encryption and Review of Mail FidoNet is an amateur system. Our technology is such that the privacy of messages cannot be guaranteed. As a sysop, you have the right to review traffic flowing through your system, if for no other reason than to ensure that the system is not being used for illegal or commercial purposes. Encryption obviously makes this review impossible. Therefore, encrypted and/or commercial traffic that is routed without the express permission of all the links in the delivery system constitutes annoying behavior. See section 1.3.6 for a definition of commercial traffic. [...] 2.1.6 Private Netmail The word "private" should be used with great care, especially with users of a BBS. Some countries have laws which deal with "private mail", and it should be made clear that the word "private" does not imply that no person other than the recipient can read messages. Sysops who cannot provide this distinction should consider not offering users the option of "private mail". If a user sends a "private message", the user has no control over the number of intermediate systems through which that message is routed. A sysop who sends a message to another sysop can control this aspect by sending the message direct to the recipient's system, thus guaranteeing that only the recipient or another individual to whom that sysop has given authorization can read the message. Thus, a sysop may have different expectations than a casual user. 2.1.6.1 No Disclosure of in-transit mail Disclosing or in any way using information contained in private netmail traffic not addressed to you or written by you is considered annoying behavior, unless the traffic has been released by the author or the recipient as a part of a formal policy complaint. This does not apply to echomail which is by definition a broadcast medium, and where private mail is often used to keep a sysop-only area restricted. 2.1.6.2 Private mail addressed to you The issue of private mail which is addressed to you is more difficult than the in-transit question treated in the previous section. A common legal opinion holds that when you receive a message it becomes your property and you have a legal right to do with it what you wish. Your legal right does not excuse you from annoying others. In general, sensitive material should not be sent using FidoNet. This ideal is often compromised, as FidoNet is our primary mode of communication. In general, if the sender of a message specifically requests in the text of the message that the contents be kept confidential, release of the message into a public forum may be considered annoying. There are exceptions. If someone is saying one thing in public and saying the opposite in private mail, the recipient of the private mail should not be subjected to harassment simply because the sender requests that the message not be released. Judgement and common sense should be used in this area as in all other aspects of FidoNet behavior. 2.1.7 Not Routing Mail You are not required to route traffic if you have not agreed to do so. You are not obligated to route traffic for all if you route it for any, unless you hold a Network Coordinator or Hub Coordinator position. Routing traffic through a node not obligated to perform routing without the permission of that node may be annoying behavior. This includes unsolicited echomail. If you do not forward a message when you previously agreed to perform such routing, the message must be returned to the sysop of the node at which it entered FidoNet with an explanation of why it was not forwarded. (It is not necessary to return messages which are addressed to a node which is not in the current nodelist.) Intentionally stopping an in-transit message without following this procedure constitutes annoying behavior. In the case of a failure to forward traffic due to a technical problem, it does not become annoying unless it persists after being pointed out to the sysop. [...] 4.2 Routing Inbound Mail (Net Coordinator Responsibilities) It is your responsibility as Network Coordinator to coordinate the receipt and forwarding of host-routed inbound netmail for nodes in your network. The best way to accomplish this is left to your discretion. [...] You are not required to forward encrypted, commercial, or illegal mail. However, you must follow the procedures described in section 2.1.7 if you do not forward the mail. ---------- (end of Fidonet policy quote) The gist of Section 9 of the policy document, together with the Appendix of Fidonet "case histories" seems to be that the various Fidonet Czars can kick you out of the net if they consider you "excessively annoying". As far as I can tell, the ability (perhaps the right) to fuss around in other folks' business and other folks' mail is one of the factors (along with the ability to create and enforce any number of rules and regulations) which makes people think it's fun to run a BBS. The opportunity to exercise power seems to be a powerful motivator, whether it's on the net, on a BBS, or otherwise. Suggesting that we need to address that tendency in the "online" community before we address it in the general populace seems misguided to me. -- Greg Broiles greg at goldenbear.com Baked, not fried. From mnemonic Thu Sep 30 10:54:45 1993 From: mnemonic (Mike Godwin) Date: Thu, 30 Sep 1993 13:54:45 -0400 Subject: PGP/Constitutional Defense, Take IV (fwd) Message-ID: <199309301754.AA10784@eff.org> EFF TO DEFEND CRYPTO RIGHTS LEGALLY Washington, D.C. -- The Electronic Frontier Foundation has committed itself this week to legal defense efforts in response to what is apparently a U.S. government campaign against the use and export of cryptographic technology. EFF's response to the anti-cryptography campaign, which has been directed initially against the "Pretty Good Privacy" (PGP) encryption program written by Phil Zimmermann, is three-fold: o EFF and EFF board members will immediately contribute funds to Phil Zimmermann's current legal expenses as they relate to constitutional issues, and will encourage others to make donations for this legal effort. o EFF will continue to vigorously investigate the facts of the PGP case and other cryptography-related cases that may arise, in order to spotlight the constitutional issues raised by such cases. o EFF is now planning to launch in the near future a First Amendment campaign aimed both at raising funds to support legal work on the Constitutional issues raised by these cases, and at educating policymakers and the general public about need to reform our outmoded export control laws . The basic facts of the PGP case(s) are as follows: The Customs Bureau has interviewed Phil Zimmermann and others involved in PGP. A San Jose grand jury, convened by Assistant US Attorney William Keane, subpoenaed documents relating to PGP from Zimmermann, as well as ViaCrypt and Austin Code Works, two companies who intend to offer commercial products related to PGP. Finally, the State Department has sent a letter to the Austin Code Works requiring them to register as an arms dealer, even if they don't plan to export cryptography. In light of these developments, the Electronic Frontier Foundation Board of Directors met in Austin on Sept 22-23 to plan EFF's response. EFF's Board of Directors believes that this case may involve fundamental issues in the application of the U.S. Constitution to digital media. At stake is the right of privacy, public access to secure cryptography, the right to publish digital writings, and the right of equal protection under the law. We are resolved to take this matter very seriously. For this reason, EFF will undertake a vigorous investigation of the facts in this and any other PGP related cases which might arise. If the Grand Jury issues indictments that would, in the view of EFF, threaten the future of digital liberty, we are prepared to assist in the case and any others which might have similar adverse effects. We are also prepared to seek to amend the export laws to protect constitutional speech and the right to disseminate and use encryption to protect the citizens' right to privacy and to the security of their communications. In the short run, EFF will assist Phil and others involved with PGP to find criminal defense attorneys, explore ways to get any cases handled pro bono publico, or for expenses only, and contribute funds to Phil and other possible defendants for preindictment constitutional research, and we encourage others to do the same. As of this announcement, several thousand dollars have been pledged by EFF and EFF board members including John Gilmore, Mitchell Kapor, John Perry Barlow. In the near future, EFF will launch a national campaign designed to provide legal and financial support for cases or legislative efforts that would promote the Constitutionally guaranteed rights to develop, discuss, and use cryptographic technology. We urge you to help Phil Zimmermann in preparing his constitutional defense by contacting Phil's lawyer, Philip Dubois (dubois at csn.org, +1 303 444 3885, or 2305 Broadway, Boulder, CO 80304, USA). He is accepting legal defense contributions relating directly to Phil's defense as an individual. Board of Directors Electronic Frontier Foundation From stig at netcom.com Thu Sep 30 13:56:38 1993 From: stig at netcom.com (Stig) Date: Thu, 30 Sep 93 13:56:38 PDT Subject: fido encryption. In-Reply-To: <9309300753.AA29492@netcom.netcom.com> Message-ID: <9309302054.AA15926@netcom3.netcom.com> At CFP (or maybe it was an event at Modern Times in SF just before CFP...) I remember some people talking about this fidonet pickiness. There is also a large number of fido sites that DO pass encrypted traffic. They have their own "backbone" for encrypted traffic, too. I think that Tom Jennings was one of the people who was talking about this...which makes perfect sense, since I think he started fidonet... Stig ;; __________________________________________________________________________ ;; Stig at netcom.com netcom.com:/pub/stig/00-PGP-KEY ;; It's hard to be cutting-edge at your own pace... 32 DF B9 19 AE 28 D1 7A ;; Bullet-proof code cannot stand up to teflon bugs. A3 9D 0B 1A 33 13 4D 7F From 72114.1712 at CompuServe.COM Thu Sep 30 13:56:56 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Thu, 30 Sep 93 13:56:56 PDT Subject: POISON PILL :-) Message-ID: <930930204341_72114.1712_FHF65-1@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I wrote: . . . What could be done have the computer screw up the cop's data days, weeks or months after the seizure? Of course, I would never do such a thing myself, nor would I advise anyone else to do so. I do, however, have a passing academic interest in the subject. Same for you folks too, right? Perry responded: Why wouldn't you? Its your machine, so what you do to it is perfectly legal. You are under no obligation to make your equipment suitable for people who wish to steal it. Well duh, Perry. Let me rephrase that: . . . nor would I advise anyone else to do so. I do, however, have a passing academic interest in the subject. Same for you folks too, right? * * >>> please note! >>>> | <<<< please note! <<< \___/ (smiley face for the humor impaired) But all seriousness aside, Perry also offers a suggestion about altering the ROMs on the disk controllers and then using a special operating system. Sounds like a terrific idea. Just how hard is this to do? How about somebody writing a how-to manual for this? Or maybe all we need is a sticker that says: !!WARNING!! This Machine is Booby-Trapped Use at Your Own Risk S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From jet at netcom.com Thu Sep 30 14:01:56 1993 From: jet at netcom.com (J. Eric Townsend) Date: Thu, 30 Sep 93 14:01:56 PDT Subject: misc crypto stuff In-Reply-To: <199309301856.AA11463@eff.org> Message-ID: <9309302102.AA24247@netcom6.netcom.com> Mike Godwin writes: > I'm not sure which case you're thinking of, Eric. I know of no case in > which the defendant was forced to disclose his keys. I don't think I dreamed this, but... I remember hearing that one of the people hit by the bamse sting had encrypted a bunch of stuff on their system. I also remember some discussion of whether or not the person in question could be ordered to reveal their keys. (Maybe I *inferred* that the person had been ordered to reveal their keys since there was a discussion of whether or not it was legal.) -eric From cme at ellisun.sw.stratus.com Thu Sep 30 14:06:39 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Thu, 30 Sep 93 14:06:39 PDT Subject: Orange book, the NSA, and the NCSC Message-ID: <9309302103.AA05016@ellisun.sw.stratus.com> >Message-Id: <m0ohwxY-00022PC at khijol> >From: khijol!erc at uunet.UU.NET (Ed Carp) >Subject: Re: Orange book, the NSA, and the NCSC >Date: Wed, 29 Sep 1993 01:32:27 -0800 (PDT) >Even if a Cray can crack a PGP-encrypted message in, say, an hour, flooding >the system with messages would tend to obscure real traffic with obscure >junk. Hey, I can encrypt /vmunix with a random key as fast as the next >person. :) I still have my copy of (what I call) pgp-ran. I forgot what it was called when it was posted and I can't find the sources now. It puts rannos in PGP format. Does a copy of the sources exist on one of the servers? It's too fast to be doing any encryption but it would be good to have one which produces messages PGP recognizes as real, only for a public key which isn't on file. If PGP rejects a message, it wouldn't take up any Cray cracking time. - Carl Sample: -----BEGIN PGP MESSAGE----- Version: 2.1 tJaHof1c+6P+Llz8D7E4Nt7sETVMtqqazEhcjX4hRIgdtTZwPeocLjIP3dbkIF+7 JfXt2QOIYulFC+1RcdtoA233TTbbYZXi5uPv+d3WMcbObQf3tMfuCXlWqBxCaIkT 3zD1R6MdXnry4KplWJTZg5vK6gMUpxogkrV1lhS8J9uBHYmeh63BzmLtGXBvIpPt Uli6G12PylQ693YexPfk1qR7BSrK863QfZKmOB1BmG7j9TBuigSXKjSL19Vx4MCX mM90Nz1z5wW2DXkl328BZPNOMiAEvCcVOZJcM/PFvm7z9fY1VV2ukD9wm91V/RqN ZNm1/glIyDLCSgq3VqnQfzpzeqrWTCksQLhPrGYdJjgcDKTY07oTuRHM7yjO0H7E ScU9jsbsP7ISFcr6XTNFlUSgG1v78q/PGTMp/nWOieho6MiRfvXEEplKeUFa+FpE Y2uYdEmAiHodTKuz5F39ucIMwNnuSQzrGhDklpkHxMkEWT3PYvNHLVT8i6q1LdgR +j1jMZr9lPC7i5L7oYC0tVwPQaEb4ks2HiaU7FRhUTc3Nny1/0psJZ8Z0A0slhis D8A+BSfWl8Nyj/ojzRP8rLWfMKLxrtduqetrwMBVIOIsNwPABe9sqTL2dWnJEE3u kZSxbo5pwl3g03hT0O9HZzlwau0eliBK7T =7W70 -----END PGP MESSAGE----- From cme at ellisun.sw.stratus.com Thu Sep 30 14:16:58 1993 From: cme at ellisun.sw.stratus.com (Carl Ellison) Date: Thu, 30 Sep 93 14:16:58 PDT Subject: Disturbing statistics on wiretaps Message-ID: <9309302116.AA05298@ellisun.sw.stratus.com> >From: "George A. Gleason" <gg at well.sf.ca.us> >Subject: Re: Disturbing statistics on wiretaps >Message-Id: <93Sep29.023420pdt.14278-2 at well.sf.ca.us> >Date: Wed, 29 Sep 1993 02:34:18 -0700 >And of course it should be remembered that there is still an old drug-war >thing on the books which allows 72 hours' interception without a court >order. Now depending on how that's interpreted, 72 hours are a lot of >conversations. This stuff can be used for background intelligence and >investigation where it never winds up in court but is used to get >information to be used in other ways. "It's what they don't tell you..." This can't be true. I read DERD's paper on wiretap law and she certainly didn't mention anything like this. You must be making it up. :-) ? No, :-( - Carl From jet at netcom.com Thu Sep 30 14:21:57 1993 From: jet at netcom.com (J. Eric Townsend) Date: Thu, 30 Sep 93 14:21:57 PDT Subject: Fidonet, policies, privacy, and power. In-Reply-To: <VuJPac1w164w@ideath.goldenbear.com> Message-ID: <9309302120.AA26088@netcom6.netcom.com> Greg Broiles writes: > of Fidonet "case histories" seems to be that the various Fidonet Czars > can kick you out of the net if they consider you "excessively annoying". s/Fidonet/USENET/ From mdiehl at triton.unm.edu Thu Sep 30 14:41:57 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Thu, 30 Sep 93 14:41:57 PDT Subject: How about a pgp RFC... In-Reply-To: <199309301716.AA17376@misc.glarp.com> Message-ID: <9309302137.AA06516@triton.unm.edu> According to Brad Huntting: > > At the moment I can think of nothing PEM can do that PGP cant. > Granted there are problems scaling the web-of-trust model, but PGP > is also capable of using a top down model (really just a subset of > the web model). So where do I get PEM? I have pgp and ripem. Thanx in advance. J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! <RL> Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. <Me> al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! <Me> Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From mdiehl at triton.unm.edu Thu Sep 30 14:42:05 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Thu, 30 Sep 93 14:42:05 PDT Subject: FIDONet Censorship? In-Reply-To: <9309301806.AA27173@netcom5.netcom.com> Message-ID: <9309302141.AA06835@triton.unm.edu> According to Timothy C. May: > > FIDONet operators are sometimes blocking encrypted messages. So what > else is new? > Their machines, their rules. Strictly speaking, this is not > censorship. I believe I stated this in my original post. I have no problems with their right to do this. I simply wanted to make the point that we need to educate these people. > However, we can try to get them to change their rules. Better, route > around such machines. > > "The Net tends to view censorship as damage and routes around it." I like it! J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! <RL> Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. <Me> al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! <Me> Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From marc at GZA.COM Thu Sep 30 15:27:29 1993 From: marc at GZA.COM (Marc Horowitz) Date: Thu, 30 Sep 93 15:27:29 PDT Subject: FIDOnet encryption (or lack thereof) In-Reply-To: <199309301808.AA10882@eff.org> Message-ID: <9309302227.AA02421@dun-dun-noodles.aktis.com> >> ECPA applies both to Prodigy and to Internet message traffic. Could you define "Internet message traffic"? The ECPA says: "(3)(a) Except as provided in paragraph (b) of this subsection, a person or entity providing an electronic communication service to the public shall not intentionally divulge the contents of any communication (other than one to such person or entity, or an agent thereof) while in transmission on that service to any person or entity other than an addressee or intended recipient of such communication or an agent of such addressee or intended recipient. Does this apply to anyone who provides a service to the public? Is it legal for me to say "I'm gonna provide private email, but I reserve the right to read it" in the service contract? How is "public" defined here? Non-lawyers want to know :-) Marc From mike at NetAcsys.com Thu Sep 30 16:02:27 1993 From: mike at NetAcsys.com (mycal (voices through your head @ 88.1MHz)) Date: Thu, 30 Sep 93 16:02:27 PDT Subject: misc crypto stuff Message-ID: <2cab57ba.acsys@NetAcsys.com> On Thu, 30 Sep 93 18:33:08 GMT, "J. Eric Townsend" <jet at netcom.com> wrote: > "mycal (voices through your head @ 88.1MHz)" writes: >> [my prediction deleted] > > Already happened. The fellow used something like PGP, if not PGP, to > encrypt stuff to disk. If I remember correctly (Mike G., help me out > here) he was asked to cough up the passwords in court as part of the > legal proceedings. (I remember this only because of the following > discussion of 'can a court make me give out my passwords?) No call > for banning of encryption by The Media(tm). > Yes but if this is true it still was an isolated case, was they guy sending stuff to other ppl encrypted? Was he receiveing porn from over seas? Or was he just protecting his personal notes? The Media and the sheep, i mean ppl, wouldn't be moved to take a hard position if it is just one guy protecting his diary, even if it contained lots of evidance. But give them a network of child porno guys, and a well done under cover operation that gives just enough information that uncrackable crypto was used and that the police were lucky in catching these guys with inside info and that there are many encrypted messages flowing in and out, and throughout the US that could be pornographers just like these guys, or worse, and the police are powerless to do anything, even if they suspect wrong doing. Just watch the Media jump all over this one. mycal From mbl at ml7694a.leonard.american.edu Thu Sep 30 16:22:28 1993 From: mbl at ml7694a.leonard.american.edu (Matthew B. Landry) Date: Thu, 30 Sep 93 16:22:28 PDT Subject: Disturbing statistics on wiretaps Message-ID: <9309302319.AA24431@toad.com> >>And of course it should be remembered that there is still an old drug-war >>thing on the books which allows 72 hours' interception without a court >>order. Now depending on how that's interpreted, 72 hours are a lot of >>conversations. This stuff can be used for background intelligence and >>investigation where it never winds up in court but is used to get >>information to be used in other ways. "It's what they don't tell you..." > >This can't be true. > I don't know if this specific law is true or not, but a lot of those drug war laws are the type of thing that would make a sane person say "This can't be true". Only it is. For example, say that I mow lawns for spare cash as a teenager. When I go off to college here at AU, I pay some of my tuition with money from my lawn savings. AU takes some of my tuition and pays Mariott for providing meal plan service. Mariott pays its staff's wages with the money from AU. The staff pays their rent out of their wages. Perfectly natural chain of events, and it happens all the time. Now we introduce a new factor. One of my lawn customers, without my knowledge (because it was none of my business) sold drugs. He put some of the proceeds from the drug sale into my pocket when he paid me for services rendered. _All_ of the assets of _every single person and organization I mentioned above_ are now considered tainted with drug money, and are legally government property. The Mariott corporation would suddenly belong to the DEA. So would everything else. Every single piece of property involved could be auctioned off to the highest bidder, and the government would keep it all. Fortunately for AU and Mariott, I never mowed lawns in High School. Thus, I couldn't possibly have drug dealers for customers. This is the kind of hysteria-backed power that Joe McCarthy most likely dreamed about. This is the kind of power that Hitler had. This, incidentally, is very much like what Castro did in Cuba that made him so unpopular here in the US. So think before you say "that couldn't be true", because it probably is. -- Matthew B. Landry ml7694a at american.edu (Finally!) mbl at ml7694a.leonard.american.edu From tcmay at netcom.com Thu Sep 30 16:47:27 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 30 Sep 93 16:47:27 PDT Subject: Disturbing statistics on wiretaps In-Reply-To: <9309302319.AA24431@toad.com> Message-ID: <9309302347.AA09695@netcom5.netcom.com> Matthew Landry has written a nice piece on the craziness of the current system. "Political" stuff like this is nice to see, even though he's preaching to the choir here. .... > This is the kind of hysteria-backed power that Joe McCarthy most likely > dreamed about. This is the kind of power that Hitler had. This, incidentally, > is very much like what Castro did in Cuba that made him so unpopular here in > the US. > > So think before you say "that couldn't be true", because it probably > is. Well done! P.S. Your line length is too long. Try trimming it to 72-76 characters, to make quoting less problematic. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it. From mgream at acacia.itd.uts.edu.au Thu Sep 30 17:27:08 1993 From: mgream at acacia.itd.uts.edu.au (Matthew Gream) Date: Thu, 30 Sep 93 17:27:08 PDT Subject: POISON PILL In-Reply-To: <930930175113_72114.1712_FHF68-1@CompuServe.COM> Message-ID: <9310010028.AA19383@acacia.itd.uts.EDU.AU> In reply to (Sandy): | POISON PILL--What, if anything, can be done to booby-trap a | computer? Once the cops have a machine, one would expect that | they will paw through everything in it. In addition, they will | probably use the stolen computer for their own data processing | needs. What could be done have the computer screw up the cop's | data days, weeks or months after the seizure? Of course, I would | never do such a thing myself, nor would I advise anyone else to | do so. I do, however, have a passing academic interest in the | subject. Same for you folks too, right? How about this: Encrypted disk controller that uses 3DES (at a minimum) where the keys are modified by a low power localised RF transmission. Quite simply one could use a DDS receiver which looks at any one of X locations for a signal strength above some threshold (ie, say 2^16 frequency slots and only 3 * 56 of these are transmitting), this provides the XOR for the DES key. In fact, one could almost patch this into an existing DES controller given some assumptions about the onboard logic. Your transmitter should be like somewhere else in your flat, preferably hidden. Of course, once the feds get your computer and it doesn't work, they will ask you why, and you need some way here to keep them off. Actually, another idea, how about if the DES key(s) for your controller are hardwired onto it, an RF detector monitors a carrier on some specific frequency, if the carrier is not present at bootup, you could leak a high voltage into the 'key holder' and blow all the connected links. Once this is gone, there is no way to get back the data, and the feds can't force you, because 1) you can show how the key was random in the first place 2) you can show how the device blew it all (and that there was no return), and your justification can be for 'data security' reasons (ie, if theives get your system, they couldn't have extracted anything). They could probably example the chip substrate itself and see what was blown recently, so this needs work I guess. Another problem is that the above assumes they don't examine the disk, realise it is encrypted, realise the controller is custom, and then work back to figure out what is going on, and then question you before they do anything. Disclaimer: the above represents unsubstantiated theorising. Matthew. ps; when the feds take your computer (at least here in Australia) they take lots of nice pictures of it and take all the cables and stuff. Of course, half of them don't know the fucking difference between msdos and unix. -- Matthew Gream, M.Gream at uts.edu.au. "... encryption is the ultimate means of Consent Technologies, 02-821-2043. protection against an Orwellian state." From 72114.1712 at CompuServe.COM Thu Sep 30 17:32:28 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Thu, 30 Sep 93 17:32:28 PDT Subject: POISON PILL Message-ID: <931001002401_72114.1712_FHF27-1@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jim says I shouldn't booby-trap my computer because: -1 Really, really piss off those investigating you. Nothing like giving people who can make your life a living hell a reason to want to make your life hell... Too late, Jim, if the situations has gotten as far as warrants and seizures, they are already making my life a living hell. Investigation my ass; this is war! He further states: -2 Opening yourself up for destruction of evidence and obstruction of justice charges in addition to whatever else they may have had on you. Well, I haven't done the relevant legal research lately, but that's not the way I remember things. Plus please remember the subject of this note--POISON PILL. I not only want my *data* unavailable to the bastards, I want my *computer* unavailable to them, too. And if possible, I would love to have it fuck up *their data* as well. Eh...theoretically speaking, of course. S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From mgream at acacia.itd.uts.edu.au Thu Sep 30 17:37:08 1993 From: mgream at acacia.itd.uts.edu.au (Matthew Gream) Date: Thu, 30 Sep 93 17:37:08 PDT Subject: POISON PILL :-) In-Reply-To: <930930204341_72114.1712_FHF65-1@CompuServe.COM> Message-ID: <9310010035.AA19779@acacia.itd.uts.EDU.AU> In reply to (Sandy): | Or maybe all we need is a sticker that says: | | !!WARNING!! | This Machine is Booby-Trapped | Use at Your Own Risk I have Australian Defence Security Clearance stickers on my computer, they are so cool, these little yellow and red stickers that authorise the computer for secure use (and something else I can't remember). Of course, the Feds found these stickers funny. Matthew. -- Matthew Gream, M.Gream at uts.edu.au. "... encryption is the ultimate means of Consent Technologies, 02-821-2043. protection against an Orwellian state." From thug at phantom.com Thu Sep 30 18:02:28 1993 From: thug at phantom.com (Murdering Thug) Date: Thu, 30 Sep 93 18:02:28 PDT Subject: POISON PILL In-Reply-To: <931001002401_72114.1712_FHF27-1@CompuServe.COM> Message-ID: <m0oiYre-0009FJC@mindvox.phantom.com> Sandy Sandfort writes: > Well, I haven't done the relevant legal research lately, but > that's not the way I remember things. Plus please remember the > subject of this note--POISON PILL. I not only want my *data* > unavailable to the bastards, I want my *computer* unavailable to > them, too. And if possible, I would love to have it fuck up > *their data* as well. Eh...theoretically speaking, of course. Simple. Wire yourself up a peripheral bus card (ISA for PCs or NuBus for Macs) that contains a software/interrupt triggered relay. That relay is wired to a stick of dynamite, an electric match (available in hobby rocketry stores), and a 9v battery all glued to the peripheral bus card. If a stick of dynamite is not available, you may use a pipe bomb filled with flash powder from emptied m-80's. Then write yourself a boot-up password program that will trigger the bomb if the wrong password is entered. A 10" pipe bomb should make any PC or Mac quite useless in a matter of microseconds. For added effect, the pipe bomb may be strapped to the underside of the hard disk in your computer to make sure that data recovery is out of the question. Thug From koontzd at lrcs.loral.com Thu Sep 30 18:07:08 1993 From: koontzd at lrcs.loral.com (David Koontz ) Date: Thu, 30 Sep 93 18:07:08 PDT Subject: Who is clipper spying on? Message-ID: <9310010105.AA06462@nebula.lrcs.loral.com> >From: Bill Stewart ... >Subject: Comments on Proposed FIPS for Escrowed Encryption Standard ... >USAGE AND RISK ANALYSIS ... >While some proprietary protocols are weak, the strengths of DES and >variants such as Triple-DES are relatively well-known, >and DES implementations can be performed in software at substantially >lower cost than the customized hardware required for compliance with >this proposed FIPS - because the FIPS specifies that it is only >applicable to low-speed data, e.g. less than ISDN's 64000 bits/second, >software implementation requires minimal computational effort, >even for Triple-DES. >From the Federal Register: This proposed standard adopts encryption technology developed by the Federal government to provide strong protection for unclassified information and to enable the keys used in the encryption and decryption processes to be escrowed. This latter feature will assist law enforcement and other government agencies, under the proper legal authority, in the collection and decryption of electronically transmitted information. ... >From the proposed FIPS Escrow Encryption Standard: Data, for purposes of this standard, includes voice, facsimile and computer information communicated in a telephone system. Telephone system, for purposes of this standard, is limited to systems circuit-switched up to no more than 14.4 kbs or which use basic-rate ISDN, or to a similar grade wireless service. ------- I would be willing to believe the baud rate limit is entirely artificial and predicated on the equipment the NSA is providing for LE use. Then again it is pointed directly at telecommunications (voice, data), and appears to discourage the use of link encryption, perhaps for traffic flow analysis reasons. It would appear that someone is very interested in who uses cryptography and who they talk to with it. I wonder what Capstone will bring. ------- >From the proposed FIPS Escrow Encryption Standard: The encryption/decryption algorithm has been approved for government applications requiring encryption of sensitive unclassified telecommunications of data as defined herein. --- You don't suppose all this is to simply allow one part of the government to spy on another, do you? Is this really some disguised power play? I mean really, less than a 1000 authorized wiretaps in 1992? Someone is spending some big bucks here. From mdiehl at triton.unm.edu Thu Sep 30 18:32:28 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Thu, 30 Sep 93 18:32:28 PDT Subject: POISON PILL In-Reply-To: <931001002401_72114.1712_FHF27-1@CompuServe.COM> Message-ID: <9310010129.AA19728@triton.unm.edu> Well, I have to say that I love this idea! I have a few suggestions, tho. How about we take a copy of the public domain bios source, or disassemble one ourselves. We hack the code a bit... Then we burn a new prom to install into our machines. AND WE EPOXY THE MOTHER TO THE DAMNED BOARD! We build a card to stick in our machine which receives a radio signal which contains a decription key to be supplied to the bios hacks mentioned above. So we use a protable radio transmitter to send the password to our machine. Our bios waits for this password for use in decripting the filesystem. If the bios doesn't get this password, it trashes the cmos and does whatever other mean things it wants to. Perhapse part of the card could have login in it which would short the power- supply to the memory bus... shit! Hypothetically, we have two passwords for our system, one for the Feds, and one for Honest people. When the bios receives the Fed-password, it acts normally, (for a time?) except it also unleashes a *nasty* virus from within it's own rom! This would take "care" of the Fed's data in adition to screwing up the machine. Just my two cents.... J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! <RL> Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. <Me> al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! <Me> Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From andy at autodesk.com Thu Sep 30 18:42:28 1993 From: andy at autodesk.com (Andrew Purshottam) Date: Thu, 30 Sep 93 18:42:28 PDT Subject: fido encryption. In-Reply-To: <9309300633.AA27652@triton.unm.edu> Message-ID: <9309302131.AA03025@meefun.autodesk.com> Doesn't Fidonet have a long tradition of feuding and splitting into "subnets", which is facilitated by the way they maintain their nodelist files? An excited Fido'er expalined it to me one night at usenix several years ago, but I had little interest in pc networking then. Perhaps a encryption ok subset of fidonet could form? Anyone who knows more about this care to comment? Andy From doug at netcom.com Thu Sep 30 18:52:29 1993 From: doug at netcom.com (Doug Merritt) Date: Thu, 30 Sep 93 18:52:29 PDT Subject: Ultimate privacy/security Message-ID: <9310010151.AA25664@netcom5.netcom.com> The following starts out in a very philosophical way, but that's only to explain the thinking behind an algorithm I've been developing. The algorithm is nonetheless extremely unorthodox, so if you've no taste for that sort of thing, skip this. On the other hand, the following long term thinking is what lead me to join cypherpunks, so it's not just a passing fancy. * 1. Pitfalls of every previous scheme: It would be nice to find ultimate measures of security and privacy, but there always seems to be a hole somewhere. The point of passwords and encryption keys is to verify identity, but of course they can be stolen/intercepted/etc. If you have a highly secure 10K bit password, preferably generated by an analog hardware random number generator, you'll have to store it somewhere, e.g. in your wristwatch, and *that* could be stolen or taken by search warrant. Similar comments apply to favorite science fictional devices that are now becoming possible or even commercially available, such as retinal pattern checkers and prompted voice signatures...e.g. it's quite possible to record someone's voice print (a staple of movies by now), or in principle even synthesize their voice uttering a brand new sentence in response to a challenge. DNA authentication is *almost* possible in real time (give it a few years), but pretty much the same problem there: someone could easily steal a few of your skin cells. So is there any ultimate method of identity authentication? I thought of one, but it is philosophically unsettling, not to mention problematic in implementation. * 2. Getting to the roots of the issue: Why do we care about authenticating identity? It comes down to a matter of trust. Different people have different goals. We can't trust everyone else to share our goals; they may be malevolent from our point of view. We trust ourselves, in the sense of security issues, but to be on the safe side, we trust no one else. Therefore our identity is the issue. The problem is that passwords, voice prints, retinal prints, handwriting signatures, DNA signatures...none of these things actually guarantee identity. All of those can potentially be usurped by those who do not share our personal goals. And that points to a solution: * 3. Goals as the definition of identity: If we had a method of authentication that assured that the person in question shared our personal goals, then we would have the ultimate security/privacy scheme. If we cloned our mental selves, then that second occurrence of our own minds would be as trustworthy to us as *we* are to ourselves. So a hypothetical authentication scheme that managed to somehow authenticate the (relevant) goals of the person being tested as being identical to our own would assure us that the person may or may not be us, but is nonetheless trustworthy. In fact, such a scheme would have the unusual safety factor that it would protect against we ourselves having a change of heart and "going over to the enemy." Sounds good. Also sounds impossible. Maybe. However, I do have an algorithm in mind that *partially* satisfies the above criteria. In its current form, it is susceptible to forgery...what's to prevent bad guys from pretending to philosophies and goals that they don't truly believe in? This is essentially the same weakness as all previous schemes, so there would be no advancement in that sense (without some further strengthening of the scheme, if possible). But at least now we're operating on the absolute fundamentally direct level, where other schemes are indirect. Is this a strength or a weakness? (And what if the forgery-hole were plugged somehow?) I don't have an answer for that yet. I'm working on it, but it may be an insoluble problem...or maybe not, we shall see. Meanwhile, aside from the details of the algorithm, I'm interested in hearing people's thoughts about the strengths and weaknesses of this general approach as opposed to other authentication philosophies. Getting feedback about this is why I joined this list, but I've been a bit shy about bringing up such an unorthodox approach...not to mention learning what people here are like, and learning from the example of Tim, who consistently teaches me by being simultaneously insightful and supportive of people here. That is an approach that I long to emulate... thank you for the example. Doug P.S. Some of you high powered people out there will shoot the above full of holes, which is fine, that is helpful in itself; others *might* find some material to use in their professional research. Also fine, if that happens, but please mention my name if it leads to anything. I rarely manage to take things to the point of publication, so an acknowledgement here and there is gratifying. Thanks. :-) From doug at netcom.com Thu Sep 30 18:57:08 1993 From: doug at netcom.com (Doug Merritt) Date: Thu, 30 Sep 93 18:57:08 PDT Subject: POISON PILL Message-ID: <9310010154.AA25936@netcom5.netcom.com> Actually, you'd be surprised what is recoverable in the aftermath of an explosion. Bombs truly are no guarantee of unrecoverability of data, at least not simple things like dynamite and pipe bombs. Furthermore, pipe bombs throw shrapnel, and as such are anti-personnel devices. The goal was to destroy data, not FBI agents. Booby traps that take lives are considered in court as 1st degree murder. There are more elegant approaches. Doug From doug at netcom.com Thu Sep 30 19:07:07 1993 From: doug at netcom.com (Doug Merritt) Date: Thu, 30 Sep 93 19:07:07 PDT Subject: steganography & fidonet Message-ID: <9310010206.AA27468@netcom5.netcom.com> In regard to things like Fidonet sysops noting forbidden encryption pasing through their systems: Encrypted messages could be encoded in a final pass as English sentences. A 2000 line C program with a 200,000 word dictionary could encode and decode sentences that were roughly grammatical, even if they sounded really weird on average. Although I've never heard of this being done, it's pretty obvious in one sense, so I'm sure it's no surprise to the spooks. It surely wouldn't be obvious to snoopy Fidonet sysops, though, so it may have its uses. BTW a more complex program + dictionary could confine the encoded utterances to topical words and therefore sound even less weird. With enough sophistication, such an encoding could generally pass muster as "confusing and poorly worded jargon" to anyone but the most devoted analyst. I've got enough (or almost enough) sw & dictionaries & word clusters on hand to implement such a thing, but I've personally no purpose to use it for. Doug From baumbach at atmel.com Thu Sep 30 19:52:28 1993 From: baumbach at atmel.com (Peter Baumbach) Date: Thu, 30 Sep 93 19:52:28 PDT Subject: POISON PILL Message-ID: <9310010221.AA11014@bass.chp.atmel.com> What you need to do, is take advantage of the paranoia of the policemen. -Have fake bombs all over your computer. Police tend to blow up fake bombs just in case they are real. :-) -You need to add the signature of a virus to all your encrypted files. file.pgp is infected with Stoned type virus. Delete [y]: Peter Baumbach baumbach at atmel.com Now that I've thought of it, that bomb idea has many more applications! Let the police blow up the evidence. From klbarrus at owlnet.rice.edu Thu Sep 30 19:52:37 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Thu, 30 Sep 93 19:52:37 PDT Subject: REMAIL: digicash II Message-ID: <9310010251.AA18893@flammulated.owlnet.rice.edu> Heh, my math is slightly off: the chances of a duplication are actually 1/(62^60) since valid characters are [a-zA-Z0-9], and each cash string is of length 61, 60 characters taken randomly from the set of valid characters, and an initial 'B' (since all the cash issued from elee7h5 at rosebud starts with an 'A'). On the other hand, I'm not using a cryptographically strong random number generator (I'm waiting for the soon to be released PGP library :-) Remailing seems to a bit slower, probably because the perl hacks I added slurp the entire file of valid strings, check payment, and rewrite the file, minus valid payment. Also, the more enterprising and devious among you :-) will soon note that the remailer elee6ue at rosebud passes along the subject line even when payment fails. Thus, if you collapse your entire message into the subject, you can still get a message through. I will fix this problem soon! -- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From ld231782 at longs.lance.colostate.edu Thu Sep 30 20:12:28 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 30 Sep 93 20:12:28 PDT Subject: HELP! I lost a message Message-ID: <9310010308.AA15153@longs.lance.colostate.edu> I have been *drowning* in email lately, and I think I accidentally deleted a message that appeared on the list. It had the following text. Could anyone send me the original message ASAP? this is a matter of critical importance. Also, could the original author contact me if possible? I thought I sent you email but I can't find that either. Yes, I've got a bad case of cyberspatial insanity. tx. ===cut=here=== Date: Wed, 29 Sep 1993 10:43:47 -0700 (PDT) I agree that messages to president at whitehouse.gov, or to the whitehouse area on Compu$erve are not acknowledged. I have sent several to each as well as a letter direct to President Hillary, none of which were acknowledged. I wrote about a major money-waster in government medical care systems which could easily save the government in the three-digit millions. For what its worth, the boondoggle is this: When DOD decided to automate their medical facilities they put out an RFP. A company called SAIC was aware that the entire software system that VA uses to automate its 1000 bed hospitals is available for free under the FOIA. SAIC got a copy of all the VA software, and bid to DOD to take this VA software which the government already owns, and sell it back to DOD for giga-bucks. Now they (DOD) must negotiate with and pay for every change they want to that software. Meanwhile the VA programmers continue to improve the VA software (DHCP) as salaried government employees. In fact, now DOD is looking to pay SAIC to write interface routines to allow the DOD software (CHCS) to share info with the VA software (DHCP). You would think that this would get their attention, but no. Instead we continue to pay a private firm to sell us our own software. Hows this for medical care cost over-runs? From mike at NetAcsys.com Thu Sep 30 20:17:09 1993 From: mike at NetAcsys.com (mycal (voices through your head @ 88.1MHz)) Date: Thu, 30 Sep 93 20:17:09 PDT Subject: POISON PILL Message-ID: <2cab89d1.acsys@NetAcsys.com> On Thu, 30 Sep 1993 15:19:44 -0500 (CDT), "Jim McCoy" <mccoy at ccwf.cc.utexas.edu> wrote: > > If you want to protect your data is such situations you need to set up your > system so that even if they have the data it does them nothing (e.g. > encryptiong), not so that it will destroy the data. > OK, here is the twist that should work . If the computer falls into the wrong hands the computer could just lock down all the data on the hard disk, encripting it. None of the data would be lost, just encripted. You'd need the recovery program boot disk and the password/phrase to unlock the hard disk. This program could be hidden in a modified copy of the operating system, you could also add the modified prom code so the computer wouldn't work without the modified operating system. So they would have a useless computer, but the data wouldn't be recoverable and if they reformatted the HD, they still couldn't use it. I don't think they would be smart enough to know that the prom had been replaced. Then again, there are probibly already programs out there that encript the HD already. mycal From ld231782 at longs.lance.colostate.edu Thu Sep 30 20:42:28 1993 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Thu, 30 Sep 93 20:42:28 PDT Subject: FIDONet Mail filtering - a course of action Message-ID: <9310010341.AA15892@longs.lance.colostate.edu> FIDONet mail filtering came up many months ago. It is indeed an atrocious policy. Are these people in the same cyberspace we are? This is like hearing neanderthals inhabit many houses in the neighborhood. As for what *we* can do, well, if premier cyberspatial laywer Mike Godwin considers himself a hardcore cypherpunk, I'd expect that a letter on EFF stationary would have a pretty significant effect. It wouldn't have to be hostile or intimidating, just something along the tone of `please join the cyberspatial community and your concerned peers.' It could mention the strict legal significance of the ECPA -- that a strong case can be made that *any* filtering is in violation of it, and that one cannot screen encrypted mail without breaking it. In fact, ideally the letter would be general enough to give to anyone who is engaged in unwholesome activities along the same lines. If this is all too much work, I think just quoting his cypherpunk-list letters that suggest the ECPA does not exactly condone their behavior might have an effect too... Hee, hee, though I'd say the actual letter would be worth a coveted L.D. Cypherpunk of the Week award <g> I'm just waiting for an excuse to give M.G. one. I don't think everyone realizes how lucky we are to have him and Gilmore in the same room with us! From mdiehl at triton.unm.edu Thu Sep 30 21:32:38 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Thu, 30 Sep 93 21:32:38 PDT Subject: FIDONet Mail filtering - a course of action In-Reply-To: <9310010341.AA15892@longs.lance.colostate.edu> Message-ID: <9310010429.AA27615@triton.unm.edu> According to L. Detweiler: > > As for what *we* can do, well, if premier cyberspatial laywer Mike > Godwin considers himself a hardcore cypherpunk, I'd expect that a > letter on EFF stationary would have a pretty significant effect. It > wouldn't have to be hostile or intimidating, just something along the > tone of `please join the cyberspatial community and your concerned > peers.' It could mention the strict legal significance of the ECPA -- > that a strong case can be made that *any* filtering is in violation of > it, and that one cannot screen encrypted mail without breaking it. In > fact, ideally the letter would be general enough to give to anyone who > is engaged in unwholesome activities along the same lines. Well, I have no ethical problems with giving out the guy's name... > Hee, hee, though I'd say the actual letter would be worth a coveted > L.D. Cypherpunk of the Week award <g> I'm just waiting for an excuse > to give M.G. one. I don't think everyone realizes how lucky we are to > have him and Gilmore in the same room with us! We are indeed lucky people. There are a lot of "quality people" on this list. I am very gratefull to all of you. J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl at triton.unm.edu | Government forgets about the 1st! <RL> Mike.Diehl at f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. <Me> al945 at cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politically Incorrect! <Me> Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D From mnemonic at eff.org Thu Sep 30 21:37:09 1993 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 30 Sep 93 21:37:09 PDT Subject: FIDONet Mail filtering - a course of action In-Reply-To: <9310010341.AA15892@longs.lance.colostate.edu> Message-ID: <199310010434.AA16852@eff.org> Lance writes: > As for what *we* can do, well, if premier cyberspatial laywer Mike > Godwin considers himself a hardcore cypherpunk, I'd expect that a > letter on EFF stationary would have a pretty significant effect. This is a possibility, but perhaps we could do something subtler. I suggest that someone forward my cypherpunk-list letters to this sysop along with my phone number (202-347-5400) and let the guy know that he can call me to discuss the possible legal liability he is creating for himself. Outside of the issue of passing encrypted information, it seems common among Fido sysops to screen for other kinds of content. That can be way uncool, legally. --Mike From nobody at Menudo.UH.EDU Thu Sep 30 22:02:33 1993 From: nobody at Menudo.UH.EDU (nobody at Menudo.UH.EDU) Date: Thu, 30 Sep 93 22:02:33 PDT Subject: Anonymous Forwarding Software Available Message-ID: <199310010500.AA05647@Menudo.UH.EDU> At 9:26 PM 9/20/93 +0000, Ray wrote: >put a copy of my anonymous >forwarding software in soda.berkeley.edu:pub/cypherpunks/incoming/aforward.shar Can't find it. Was I too slow? From nobody at Menudo.UH.EDU Thu Sep 30 22:02:38 1993 From: nobody at Menudo.UH.EDU (nobody at Menudo.UH.EDU) Date: Thu, 30 Sep 93 22:02:38 PDT Subject: PERL: creating pgp look-alike messages Message-ID: <199310010500.AA05658@Menudo.UH.EDU> -----BEGIN PGP SIGNED MESSAGE----- In case you lost your random PGP look-alike message generator :-), here is one in PERL. Run it with an argument (number of lines of "encrypted" text to produce). Such a message won't pass pgp itself, since magic bytes and checksums aren't there. - ----------8< cut here >8---------- #!/usr/local/bin/perl #creates random messages that look like PGP messages @pgpchars = (a .. z, A .. Z, '+', '=', '/'); $lenpgpchars = @pgpchars; $pgplinelength = 64; $numlines = shift @ARGV; print "-----BEGIN PGP MESSAGE-----\n"; print "Version 2.3a\n\n"; foreach $i (0 .. $numlines) { foreach $j (0 .. $pgplinelength) { $char = $pgpchars[rand $lenpgpchars]; print $char; } print "\n"; } print "-----END PGP MESSAGE-----\n"; - ----------8< cut here >8---------- Karl L. Barrus <klbarrus at owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLKuzBIOA7OpLWtYzAQHJZgP+PE0kcLVyHr2Ml/D0QEYJqVh58x8h0UGD U8aShHVcryrKk7Uj2xXNtC8OAH1ltoi98jiEuJvqi3rcLaj8lui+gTSe96vpoWRP iQSMuQUn0NNMOP3BooeCoeV2KY7Kd4511Km8yOtzJflwPrk2AyeI8Bra4tpuVxnH 6eErL3MBUzU= =Xcys -----END PGP SIGNATURE----- From panzer at drown.slip.andrew.cmu.edu Thu Sep 30 22:27:11 1993 From: panzer at drown.slip.andrew.cmu.edu (Panzer Boy) Date: Thu, 30 Sep 93 22:27:11 PDT Subject: POISON PILL In-Reply-To: <931001002401_72114.1712_FHF27-1@CompuServe.COM> Message-ID: <Pine.3.05.1.9310010138.B6471-b100000@drown.slip.andrew.cmu.edu> Bombs. Electro-Magnectic Pulse would be good. But the only way I know how to generate one of these is via a nuke... Probably a little over kill. Blowing things up is nice and all but also lacks style (unless you nuke). Basically a permently encrypted harddrive would be fine. Every boot up you need to enter a password. If the screen saver kicks in, you have to enter a password, or it reboots. Stuff like this. If you want to, enter the wrong password and it still boots up. But when it does, there is a virus running or something else. Basically, if you are arrested for stuff, and they confiscate your equipment, they already are pretty sure of your guilt, if you are guilty or not. Pissing them off and destroying things makes you seem more guilty. Encryption is still viewed as something you do if you have something to hide. Why encrypt, unless you are guilty? Now that I think about it. When the wrong password is entered, the computer should still boot. But all the files that are encrypted are deleted from the directories. And they appear as bad blocks, or something else. I'm sure people could go on, and on with this stuff. Whatever happened to the Crypto-Stacker stuff? -Matt (panzer at drown.slip.andrew.cmu.edu) Do you use IRC? Try connecting to drown.slip.andrew.cmu.edu 6667 with a standard IRC client. From klbarrus at owlnet.rice.edu Thu Sep 30 22:37:30 1993 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Thu, 30 Sep 93 22:37:30 PDT Subject: FIDO, steganography, PGP Message-ID: <9310010537.AA05696@flammulated.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- I've had fun writing this! This is a PERL script that takes as input a PGP encrypted, ascii output file. It skips the headers and stuff, and converts every character in the body into a geographic name. I don't think I'll have a chance to write the reverse script tonight, but it will coming along soon. So maybe this can be used to mail other people lists of geographic names rather than encrypted messages since I've heard some networks frown upon encrypted mail :-) Generate your PGP file, and invoke the script like this: pgpsteg < encrypted_file_ascii_output > steg.out and steg.out will contain a list of places derived from your input file. - ----------8< cut here >8---------- #!/usr/local/bin/perl #simple minded steganography for pgp encrypted messages #Karl L. Barrus <klbarrus at owlnet.rice.edu> %conversion = ( '0', 'canada', '1', 'united states', '2', 'mexico', '3', 'pacific ocean', '4', 'atlantic ocean', '5', 'arctic ocean', '6', 'gulf of mexico', '7', 'north america', '8', 'allegheny mountains', '9', 'rocky mountains', 'a', 'alabama', 'b', 'alaska', 'c', 'arizona', 'd', 'new mexico', 'e', 'arkansas', 'f', 'california', 'g', 'colorado', 'h', 'connecticut', 'i', 'rhode island', 'j', 'delaware', 'k', 'maryland', 'l', 'florida', 'm', 'georgia', 'n', 'hawaii', 'o', 'idaho', 'p', 'illinois', 'q', 'indiana', 'r', 'iowa', 's', 'kansas', 't', 'kentucky', 'u', 'louisiana', 'v', 'maine', 'w', 'massachusetts', 'x', 'michigan', 'y', 'minnesota', 'z', 'mississippi', 'A', 'missouri', 'B', 'montana', 'C', 'nebraska', 'D', 'nevada', 'E', 'utah', 'F', 'new hampshire', 'G', 'vermont', 'H', 'new jersey', 'I', 'new york', 'J', 'north carolina', 'K', 'north dakota', 'L', 'south dakota', 'M', 'ohio', 'N', 'oklahoma', 'O', 'oregon', 'P', 'pennsylvania', 'Q', 'south carolina', 'R', 'tennessee', 'S', 'texas', 'T', 'virginia', 'U', 'washington', 'V', 'west virginia', 'W', 'wisconsin', 'X', 'wyoming', 'Y', 'washington d.c.', 'Z', 'bermuda', '+', 'guam', '/', 'puerto rico', '=', 'virgin islands', ); while (<>) { last if /^-----BEGIN PGP/; } while (<>) { last if /^$/; } while (<>) { last if /^-----END PGP/; $line = $_; chop $line; @pgpchars = split(//,$line); while (@pgpchars) { $convert = shift @pgpchars; print $conversion{$convert}, "\n"; } print "\n"; } - ----------8< cut here >8---------- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLKvBOYOA7OpLWtYzAQGsAwP/Y5xZx5nZdKYM785zQSmPAU60UqqqU7X+ bAZ6+6f0foC2bo7AfClSTcAcCmZkCyPAL10toB6Qs0Qzkoe6eZKSlRVJgy9WzDdB oZhJV/jlvYxxlgpBJXz95sJ7ADxmtIBw6jIbfRYPjX1zva7GenTeBzXcMTabJUZJ SPG853ZqWeA= =0MEu -----END PGP SIGNATURE----- From rjc at gnu.ai.mit.edu Thu Sep 30 23:02:31 1993 From: rjc at gnu.ai.mit.edu (Ray) Date: Thu, 30 Sep 93 23:02:31 PDT Subject: Anonymous Forwarding Software Available In-Reply-To: <199310010500.AA05647@Menudo.UH.EDU> Message-ID: <9310010557.AA13033@geech.gnu.ai.mit.edu> nobody at menudo.uh.edu () writes: > > At 9:26 PM 9/20/93 +0000, Ray wrote: > >put a copy of my anonymous > >forwarding software in soda.berkeley.edu:pub/cypherpunks/incoming/aforward.shar > > Can't find it. Was I too slow? No, it's there. Just ftp to soda and do "cd pub/cypherpunks/incoming" then "get aforward.shar" It's an invisible file. Eric hasn't moved it into another (more visible) directory yet. -- Ray Cromwell | Engineering is the implementation of science; -- -- EE/Math Student | politics is the implementation of faith. -- -- rjc at gnu.ai.mit.edu | - Zetetic Commentaries --