From smb at research.att.com Tue Jun 1 00:41:32 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 1 Jun 93 00:41:32 PDT Subject: Electronic Contracts Message-ID: <9306010741.AA20187@toad.com> Digital signatures on contracts are probably legal. I did some checking on the subject a while back; someone forwarded me the following official opinion from the U.S. Controller General. The specific reasoning applies only to the U.S. government, but most of the principles generalize. I'll add one note of my own -- from what I've read lately of the Federal rules of evidence, printouts of data recorded on disk, tape, etc., are considered to be equally original, as it were. A reference I haven't checked is Benjamin Wright, ``The Law of Electronic Commerce- EDI, Fax, and Email: Technology, Proof, and Liability''. It is a 1991 book published by Little Brown and Co., 1991. --Steve Bellovin United States General Accounting Office [Comptroller General] MEMORANDUM DATE: June 19, 1991 TO: Assistant Director, AFMD/ASA - John C. Martin FROM: Assistant General Counsel, OCG/AFMD - Thomas H. Armstrong Subject: Electronic Contracting (B-238449) This responds to your request for our opinion regarding whether agencies can use Electronic Data Interchange (EDI) technologies to create valid contractual obligations that can be recorded consistent with 31 U.S.C. (s) 1501 (section 1501). For the reasons stated below, we conclude that they can. BACKGROUND EDI is the electronic exchange of business information between parties, usually via a computer, using an agreed upon format. EDI is being used to transmit shipping notices, invoices, bid requests, bid quotes and other messages. Electronic contracting is the use of EDI technologies to create contractual obligations. EDI allows the parties to examine the contract, usually on video monitors, but sometimes on paper facsimiles, store it electronically (for example on magnetic tapes, on discs or in special memory chips), and recall it from storage to review it on video monitors, reproduce it on paper or even mail it via electronic means. Using EDI technologies, it is possible for an agency to contract in a fraction of the time that it now takes. The "paperless" nature of the technology, however, has raised the question of whether electronic contracts constitute obligations which may be recorded against the government. DISCUSSION Section 1501 establishes the criteria for recording obligations against the government. The statute provides, in pertinent part, as follows: "(a) An amount shall be recorded as an obligation of the United States Government only when supported by documentary evidence of-- (1) a binding agreement between an agency and another person (including an agency) that is-- (A) in writing, in a way and form, and for a purpose authorized by law. . . ." 31 U.S.C. (s) 1501(a)(1)(A). Under this provision, two requirements must be satisfied: first, the agreement must bind both the agency and the party with whom the agency contracts; second, the agreement must be in writing. Binding Agreement The primary purpose of section 1501(a)(1) is "to require that there be an _offer_ and an _acceptance_ imposing liability on both parties." 39 Comp. Gen. 829,831 (1960) (emphasis in original). Hence the government may record an obligation under section 1501 only upon evidence that both parties to the contract willfully express the intent to be bound. A signature traditionally has provided such evidence. _See_ _generally_ 65 Comp. Gen. 806, 810 (1986). Because of its uniqueness, the handwritten signature is probably the most universally accepted evidence of an agreement to be bound by the terms of a contract. _See_ 65 Comp. Gen. at 810. Courts, however, have demonstrated a willingness to accept other notations, not necessarily written by hand. _See_, _e.g._, _Ohl_&_Co._v._Smith_Iron_Works_, 288 U.S. 170, 176 (1932) (initials); _Zacharie_v._Franklin_, 37 U.S. (12 Pet.) 151, 161-62 (1838) (a mark); _Benedict_v._Lebowitz_, 346 F.2d 120 (2nd Cir. 1965) (typed name); _Tabas_v._Emergency_Fleet_ _Corporation_, 9 F.2d 648, 649 (E.D. Penn. 1926) (typed, printed or stamped signatures); _Berryman_v._Childs_, 98 Neb. 450, 153 N.W. 486, 488 (1915) (a real estate brokerage used personalized listing contracts which had the names of its brokers printed on the bottom of the contract in the space where a handwritten signature usually appears). As early as 1951, we recognized that a signature does not have to be handwritten and that "any symbol adopted as one's signature when affixed with his knowledge and consent is a binding and legal signature." B-104590, Sept. 12, 1951. Under this theory, we approved the use of various signature machines ranging from rubber stamps to electronics encryption 2 B-238449 devices. _See_ 33 Comp. Gen. 297 (1954); B-216035, Sept. 20, 1984. For example, we held that a certifying officer may adopt and use an electronic symbol generated by an electronic encryption device to sign vouchers certifying payments. B-216035, _supra_. The electronic symbol proposed for use by certifying officers, we concluded, embodied all of the attributes of a valid, acceptable signature: it was unique to the certifying official, capable of verification, and under his sole control such that one might presume from its use that the certifying officer, just as if had written his name in his own hand, intended to be bound. EDI technology offers other evidence of intent to be bound with the same attributes as a signature--for example, a "message authentication code," like that required by the National Institute of Standards and Technology (NIST) for the electronic transmission of data._1_/ In our opinion, this form of evidence is acceptable under section 1501. A message authentication code is a method designed to ensure the authenticity of the data transmitted; it is a series of characters that identifies the particular message being transmitted and accompanies no other message. As envisioned by NIST's Federal Information Processing Standard (FIPS) 113,_2_/ a message authentication code could be generated when the sender inserts something known as a "smart card"_3_/ into a system and inputs the data he wants to transmit. Encoded on a circuit chip located on the smart card is the sender's key. ____________________ _1_/ The Congress has mandated that NIST (formerly the National Bureau of Standards) establish minimum acceptable practices for the security and privacy of sensitive information in federal computer systems. Computer Security Act of 1987, Pub. L. No. 100-235, (s) 2, 101 Stat. 1724 (1988). _2_/ FIPS 113 adopts American National Standards Institute (ANSI) standard X9.9 for message authentication. It outlines the criteria for the cryptographic authentication of electronically transmitted data and for the detection of inadvertent and/or intentional modifications of the data. By adopting the ANSI standard, FIPS 113 encourages private sector applications of cryptographic authentication; the same standard is being adopted by many financial institutions for authenticating financial transactions. _3_/ A smart card is the size of a credit card. It contains one or more integrated circuit chips which function as a computer. 3 B-238449 The key is a secret sequence of numbers or characters which identifies the sender, and is constant regardless of the transmission. The message authentication code is a function of the sender's key and the data just loaded into the system. After loading his data into the system, the sender notifies the system that he wants to "sign" his transmission. The system sends the data first to the chip on the smart card; the chip then generates the message authentication code by applying a mathematical procedure known as a cryptographic algorithm. The card returns the data along with the just- generated message authentication code to the system, which will transmit the data and code to the recipient. When a contracting officer notifies the system that he wants to sign a contract being transmitted to a contractor, he is initiating the procedure for generating a message authentication code with the intention of binding his agency to the terms of the contract. The message authentication code evidences that intention, as would a handwritten or other form of signature. The code, incorporating the sender's key, is unique to the sender; and, the sender controls access to and use of his "smart card," where his key is stored. It is also verifiable. When the recipient receives the contract, either a notation identifying the message authentication code and the sender, usually by name. The recipient can verify its authenticity by putting the data that he just received into his system and asking his system to generate a message authentication code. That code should match the one annotating the message received._4_/ Writing To constitute a valid obligation under section 1501(a)(1)(A), a contract must be supported by documentary evidence "in writing." Some have questioned whether EDI, because of the paperless nature of the technology, fulfills this requirement. We conclude that it does. Prior to the enactment of section 1501, in the Supplemental Appropriations Act of 1955,_5_/ the was no "clean cut definition of obligations." H.R. Rep. No. 2266, 83rd Cong., 2d Sess. 50 (1954). Some agencies had recorded questionable obligations, including obligations based on oral contracts, in ____________________ _4_/ For the sake of simplicity, this example does not describe the complicated system of controls used to ensure that no human knows the keys that are used to generate message authentication codes. _5_/ Pub. L. No. 663, 68 Stat. 800, 830 (1954) 4 B-238449 order to avoid withdrawal and reversion of appropriate funds. _See_ 51 Comp. Gen. 631, 633 (1972). Section 1501 was enacted not to restrict agencies to paper and ink in the formation of contracts, but because, as one court noted, "Congress was by asserting oral contracts." _United_States_v._American_ _Renaissance_Lines_, 494 F.2d 1059, 1062 (D.C. Cir.), _cert_. _denied_, 419 U.S. 1020 (1974). The purpose of section 1501 was to require that agencies submit evidence that affords a high degree of certainty and lessens the possibility of abuse. _See_ H.R. Rep. No. 2266 at 50. While "paper and ink" offers a substantial degree of integrity, it is not the only such evidence. Some courts, applying commercial law (and the Uniform Commercial Code in particular), have recognized audio tape recordings, for example, as sufficient to create contracts. _See_, _e.g._, _Ellis_Canning_Company_v._Bernstein_, 348 F. Supp. 1212 (D. Colo. 1972). The court, citing a Colorado statute, stated that the tape recording of the terms of a contract is acceptable because it is a "reduc[tion] to tangible form."_6_/ _Id_. at 1228. In a subsequent case, the United States Court of Appeals held that an audio tape recording of an agreement between the Gainesville City Commission and a real estate developer was sufficient to bind the Commission. _Londono_v._City_of_Gainesville_, 768 F.2d 1223 (11th Cir. 1985). The court held that the tape recording constituted a "signed writing." _Id_. at 1228. In our opinion, EDI technology, which allows the contract terms to be examined in human readable form, as on a monitor, stored on electronic media, recalled from storage and reviewed in human readable form, has an integrity that is greater than an audio tape recording and equal to that of a paper and ink contract. Just as with paper and ink, EDI technology provides a recitation of the precise terms of the contract and avoids the risk of error inherent in oral testimony which is based on ____________________ _6_/ Some courts, interpreting the laws of other states, have held that a tape recording is not acceptable. _See_Roos_v._ _Aloi_, 487 N.Y.S. 2d 637 (N.Y. Sup. Ct. 1985), _aff'd_, 489 N.Y.S. 2d 551 (N.Y. App. Div.); _Sonders_v._Roosevelt_, 476 N.Y.S. 2d 331 (N.Y. App. Div. 1984). 5 B-238449 human memory._7_/ Indeed, courts, under an implied-in-fact contract theory, have enforced contracts on far less documentation than would be available for electronic contracts. _See_ _Clark_v._United_States_, 95 U.S. 539 (1877). _See_ _also_ _Narva_Harris_Construction_Corp._v._United_States_, For the purpose of interpreting federal statutes, "writing" is defined to include "printing and typewriting and _reproductions_ _of_visual_symbols_ by photographing, multigraphing, mimeographing, manifolding, or _otherwise_." 1 U.S.C. (s) 1 (emphasis added). Although the terms of contracts formed using EDI are stored in a different manner than those of paper and ink contracts, they ultimately take the form of visual symbols. We believe that it is sensible to interpret federal law in a manner to accommodate technological advancements unless the law by its own terms expressly precludes such an interpretation, or sound policy reasons exist to do otherwise. It is evident that EDI technology had not been conceived nor, probably, was even anticipated at the times section 1501 and the statutory definition of "writing" were enacted. Nevertheless, we believe that, given the legislative history of section 1501 and the expansive definition of writing, section 1501 and 1 U.S.C. (s) 1 encompass EDI technology. cc: Mr. F. Jackson ____________________ _7_/ Of course, just as with any contact or other official document, an agency must take appropriate steps to ensure the security of the document, for example, to prevent fraudulent modification of the terms. Agencies should refer to NIST standards in this regard. _See_, _e.g._, FIPS 113 _supra_ (regarding message authentication codes). In addition, agencies should refer to the GSA regulations regarding the maintenance of electronic records. _See_ 41 C.F.R. (s) 201-45.2. 6 B-238449 From nobody at cicada.berkeley.edu Tue Jun 1 05:47:56 1993 From: nobody at cicada.berkeley.edu (nobody at cicada.berkeley.edu) Date: Tue, 1 Jun 93 05:47:56 PDT Subject: National Security Telecommunications 5.27.93 Message-ID: <9306011324.AA17033@cicada.berkeley.edu> Some names we should all note... ============================================================================ E X E C U T I V E O F F I C E O F T H E P R E S I D E N T 27-May-1993 07:03pm TO: Jeffrey L. Eller TO: Jonathan P. Gill FROM: David Seldin Office of the Press Secretary SUBJECT: NATIONAL SECURITY TELECOMMUNICATIONS ADVISORY COMMISSION THE WHITE HOUSE Office of the Press Secretary For Immediate Release May 26, 1993 PRESIDENT APPOINTS AUGUSTINE TO CHAIR ADVISORY PANEL (Washington, DC) The President announced today that he has appointed Norman R. Augustine as Chair and William T. Esrey as Vice Chair of the President's National Security Telecommunications Advisory Committee (NSTAC). Augustine is Chairman and Chief Executive Officer of Martin Marietta Corporation and has previously served as Vice Chair of NSTAC. Esry is Chairman and Chief Executive Officer of Sprint Corporation. Also named to the NSTAC today were Joseph T. Gorman, the Chairman and CEO of TRW Inc., and Albert F. Zettlemoyer, the President of Paramax Systems Corporation and a Senior Vice President of Unisys Corporation. The President's National Security Telecommunications Advisory Committee is a Federal Advisory Committee designed to provide information and advice to the President regarding telecommunications planning. It is composed of up to 30 telecommunications industry executives. # # # From jordan at imsi.com Tue Jun 1 06:06:36 1993 From: jordan at imsi.com (Jordan Hayes) Date: Tue, 1 Jun 93 06:06:36 PDT Subject: Electronic Contracts Message-ID: <9306011235.AA08210@IMSI.COM> I believe if you really want it to hold up, you should use the Bellcore document signing service. Has anyone heard of a company that would provide this on a non-research basis? /jordan From ian at bvsd.Co.EDU Tue Jun 1 07:09:44 1993 From: ian at bvsd.Co.EDU (Ian S. Nelson) Date: Tue, 1 Jun 93 07:09:44 PDT Subject: How do I unsubscribe? Message-ID: <199306011447.AA14254@bvsd.Co.EDU> I'm taking off for summer, so how do I unsubscribe from the list? Also, whoever sends me info on that, please send me a message that will tell me how to get back on when I come back. thanks, -- Ian S. Nelson I speak for only myself. Finger for my PGP key. If you are a beautiful woman, it is mandatory that you reply to this message. From nobody at cicada.berkeley.edu Tue Jun 1 07:56:33 1993 From: nobody at cicada.berkeley.edu (nobody at cicada.berkeley.edu) Date: Tue, 1 Jun 93 07:56:33 PDT Subject: National Security Telecommunications 5.27.93 Message-ID: <9306011532.AA19547@cicada.berkeley.edu> -----BEGIN PGP SIGNED MESSAGE----- It is at best ironic to see the Chairman and CEO of TRW appointed to the President's National Security Telecommunications Advisory Committee, given the sieve-like nature of TRW's data collection. DEADBEAT -----BEGIN PGP SIGNATURE----- Version: 2.2 iQBFAgUBLAt1nfFZTpBW/B35AQE6kwF/S54u0IVgGwA0wj1FSFlfmhYsX6cdjwYM N68FWvVtdEanPm6tri84ziNkWvjEGtr4 =S7j2 -----END PGP SIGNATURE----- From hughes at soda.berkeley.edu Tue Jun 1 08:19:29 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 08:19:29 PDT Subject: Software infrastructure In-Reply-To: <9305311919.AA06505@toad.com> Message-ID: <9306011553.AA16160@soda.berkeley.edu> >I think what is really needed is >some way of dealing with people who read mail on their PC while using >some kind of terminal program or similar package to connect to a BBS, >commercial service, or Unix box. I think Hal is largely accurate here. Certainly the "DOS box as terminal" problem needs to be solved. With the advent of 386BSD, however, home Unix is going to be increasingly common. As an aside, I want to harp again on what I call the software infrastructure problem. If email and telecomm systems were well structured, instead of exhibiting so much history in themselves, most encryption freatures would be extremely easy to implement--just grab the right hook. Unfortunately this is not the situation. Hence my conclusion: The most important software development for wide scale deployment of cryptography has nothing _per se_ to do with cryptography. Let's go back to the DOS-as-terminal issue. The politics and economics of DOS shareware is such that source code is almost never made available. Gnu public license software is rare in the DOS world. I propose that interested cypherpunks write a DOS terminal program which _is_ free software. In order to overcome the inertia which Hal properly observes is endemic to any software change, I submit that to have source code available to fix or add features deemed desirable will be a key factor in acceptance of this software. I have my own ideas about multiplexing the channel to support background POP and file transfer, but I'll leave that for later. Such software, of course, would be properly layered to be able to add encryption at the key junctures. It would be entirely appropriate to discuss such architecture here on the cypherpunks list. When the developers's effort starts, I promise to find a way for them to have their own mailing list. Eric From hughes at soda.berkeley.edu Tue Jun 1 08:30:06 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 08:30:06 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: <9305312244.AA20903@malibu.sfu.ca> Message-ID: <9306011604.AA16401@soda.berkeley.edu> >this >stirred up an old idea I had about server anonimity, that is that the >actual physical location of a server would be very difficult to pin >down... This presumes a model where the logical server is a single machine. That doesn't have to be the case. By using a secret sharing protocol (M out of N reconstruction), one can multiply site any database, with sites anywhere in the world. A database then is in actuality not in any single place. >the only way to do this with any real degree of security >would be to bounce signals off a satellite but this would be rather >costly... Cryptography is all economics. If you are doing something where the location of a machine must not be revealed, then you've got the money to pay for a satellite link. High security means high expense, and there is no way around that. Eric From hughes at soda.berkeley.edu Tue Jun 1 08:41:02 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 08:41:02 PDT Subject: No Subject In-Reply-To: <199306010527.AA00963@xtropia> Message-ID: <9306011614.AA16663@soda.berkeley.edu> >This means that the pass phrase [for the remailer secret key] has to >exist, in the clear, in the scripts which implement the remailer. Currently that is the easiest way, to be sure. Another way would be to store the passphrase encrypted in a file so that at least it's not findable with strings(1). Here a quick hack for someone who's looking for a project: a passphrase storage process which accepts requests from a slightly modified PGP. Hal's basic point, however is not mitigated. Nothing is secure from a clever root. >Perhaps Karl could add a notation in his >remailer lists about which machines are public and which are private. An excellent suggestion. Eric From hughes at soda.berkeley.edu Tue Jun 1 08:54:26 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 08:54:26 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: Message-ID: <9306011628.AA17049@soda.berkeley.edu> >I think that building privacy into the architecture would be inherently >dangerous, however, it is a perfect way for the people building the system >to oppress the users, all the while convincing them that the system is >secure. We build the privacy into the system, not the government. The question is _who decides_? If we decide by creating, then more privacy will exist by fiat. >The only way to ensure your privacy is to seize it yourself. Absolutely. This does not contradict our activity of building the privacy into the system. Any privacy system you can build on top of an insecure network such as the internet can also be built on top of a privacy-friendly network. >There are a lot of ways to get a signal around the world without using a >satellite, ask any amateur radio enthusiast. One of the really great techniques I've hear about recently is a data channel that runs at 90% T1 speed over the ~900 MHz spread spectrum band. The legal limit is 1W transmitter power and 4W antenna gain (transmitted energy focusing). From what I hear, though, the antenna gain requirements are being ignored by lots of folks. What this means in practice is that you can set up a directional antenna and easily get a twenty mile hop on one of these units. >Why is there not more work being done on encrypting all internode traffic >streams? It doesn't seem too hard. Cylink has had a T1 link encrypter out for years. It uses D-H for key exchange. It's also costs (not-known-to-be-accurate) about 10K$ per end. Eric From hughes at soda.berkeley.edu Tue Jun 1 08:59:13 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 08:59:13 PDT Subject: Electronic Contracts In-Reply-To: <9306011235.AA08210@IMSI.COM> Message-ID: <9306011633.AA17111@soda.berkeley.edu> >I believe if you really want it to hold up, you should use the >Bellcore document signing service. Has anyone heard of a company >that would provide this on a non-research basis? The Bellcore service is properly a timestamping service and not a signature service. Their timestamp is constructed out of hash functions, not digital signatures. The algorithm is patented. Contact Bellcore for licensing. I'm not sure they are going to license; they may decide that they want all the timestamping revenue themselves. Eric From hughes at soda.berkeley.edu Tue Jun 1 09:22:44 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 09:22:44 PDT Subject: Clipperpunks Write Code? In-Reply-To: <9305312100.AA22836@netcom3.netcom.com> Message-ID: <9306011656.AA17722@soda.berkeley.edu> >The anti-Clipper work is related, but >probably isn't the core...fortunately, I doubt there's any conflict, as >people will work on what interests them, so the Clipper stuff probably >isn't affecting work on other core issues. We are trying to build a sandbox, and the government is trying to restrict the use of sand. My apologies to non-US readers for the diatribe on US politics. Unfortunately, if the US restricts cryptography, others are likely to follow, either by coercion or by example. I had dinner last night with, among others, John Gilmore and John Barlow, who have just been to DC with the rest of the EFF Board to talk to politicos. Without being too specific (I leave it to those who were there to decide the propriety of the details), but several things became clear. 1. Clinton has signed onto Clipper full-bore 100%. Bush started it, but Clinton, the ever-moderate, has told the eavesdropping community that he can take their side on some issues. 2. They're going to deploy Clipper without regard to public sentiment. That means that to be influenced by public sentiment, it is going to have to be huge. Educational efforts are going to have to be large. 3. Our government is looking at the "example of other governments" to justify that restrictions on cryptography are not beyond the pale. This is serious, make no mistake. If, as in the White House statement as reprinted in the Post, the government does restrict everything to be Clipper, all anonymity and pseudonymity efforts are worthless. That said, I also urge those who are writing code to continue. To those of you not writing code, however, I say start talking to your friends and neighbors and communities and newspapers. Now. Eric From hughes at soda.berkeley.edu Tue Jun 1 09:27:23 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 09:27:23 PDT Subject: No Subject In-Reply-To: <9305311901.AA28793@relay2.UU.NET> Message-ID: <9306011701.AA17888@soda.berkeley.edu> >I'm analyzing a piece of encryption shareware advertised on >comp.archives.msdos.announce. Could you post a more complete pointer to this? >PARTICULAR TOOLS I'D USEFUL... >- A binary file editor/composer with hex and ascii displays >- A tool for generating and viewing letter frequencies, digram/ >trigram frequencies Since you are going to be writing some of these, presumably, I take it you'll be sharing your code with us. Yes? >I looked on soda in pub/cypherpunks/cryptanalysis and found >nothing useful. The directory is there as much to inspire the writing of such software as it is to distribute it. Eric From mccoy at ccwf.cc.utexas.edu Tue Jun 1 09:35:14 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Tue, 1 Jun 93 09:35:14 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: Message-ID: <199306011712.AA08151@ccwf.cc.utexas.edu> Ryan Alan Porter writes: [...] > An aside: has anyone dealt with the concept of on-the-fly encryption for > mass storage, kind of like the way the PCs can be 'stacked' or 'doubled' > or whatever with on-the-fly compression? I was thinking about trying to > write some drivers for this for a 486 but I have never tried to write a > device driver before and was wondering if anyone might have any suggestions. Sort of. I am still trying to work out a few design problems on a system such as this for unix hosts. At the moment it looks like I will be doing this in linux but I still have a few issues to hammer out before I start coding. > 1) these public key algorithms that we are working on are slow as > balls, any idea if this would be feasable, given how PC users like to > equate hard drive speed with penis size? The PKE stuff would only need to handle the key management, so this could conceivably be done in software. The actual file encryption/decryption must be done in hardware if you want to have any sort of speed at all. This is actually the part I am still trying to figure out. A research lab in Switzerland designed a chip to do IDEA rather quickly, but I have still not been able to get any information on how/when this might be marketed or available outside the research lab (although I might be able to get one for research purposes...) Lacking an available IDEA chip I will have to use DES (multi-pass or some other variant to get around the limits on DES keyspace) in order to get the necessary throughput on the disk. > 2) it seems that having your private key hanging around somewhere in > memory the whole session would be horribly insecure, [...] This I why I am hoping to use linux. For those who don't know what linux is, it is a fairly popular free unix for 386/486 intel machines. With linux I can start by burying the private key in the kernel during runtime to give it some protection against snooping and hope to add a few kernel hacks to make it a little more secure against examination. Linux provides a dos emulator for those who need PC programs and unix/x11/whatever for the rest of us... Such a system would not be completely secure but would provide some protection for files, which is more than they get now... jim From mmidboe at cs.uah.edu Tue Jun 1 09:51:52 1993 From: mmidboe at cs.uah.edu (digital saint Computer Science Dept., Univ. of Alabama-Huntsville) Date: Tue, 1 Jun 93 09:51:52 PDT Subject: Remailers on networks like Fido or WWIV Message-ID: <9306011729.AA17003@uahcs2.cs.uah.edu> I've seen a lot about remailers on Internet but has anyone done any work with remailers on Fidonet, or WWIVNet style networks? I've been thinking about a WWIVNet anonymous remailer and can easily implement one for email, but the public postings would be much harder although I do have some ideas on that. If anyone else out there has any ideas, or has started on this already I'd really like to hear about it. d. saint From hughes at soda.berkeley.edu Tue Jun 1 10:16:40 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 10:16:40 PDT Subject: crypto '93: deadline for stipend Message-ID: <9306011750.AA19860@soda.berkeley.edu> For those of you who want to go to CRYPTO 93 and get paid to do so, the deadline is this Friday. The conference is Aug 22 et seq. in Santa Barbara. Details from the announcement are below. Eric ----------------------------------------------------------------------------- A very limited number of stipends are available to those unable to obtain funding. Applications for stipends should be sent to the General Chair before June 4, 1993. ---------------------- For other information, contact the General Chair: Paul C. Van Oorschot, Crypto '93 Bell-Northern Research (MAIL STOP 000) 3500 Carling Ave. Nepean, Ontario K2H 8E9 Canada Telephone: (613)-763-4199 Fax: (613)-763-2626 Internet: crypto93 at bnr.ca From jthomas at kolanut.mitre.org Tue Jun 1 10:39:17 1993 From: jthomas at kolanut.mitre.org (Joe Thomas) Date: Tue, 1 Jun 93 10:39:17 PDT Subject: Software infrastructure Message-ID: <9306011816.AA10998@kolanut> Eric Hughes writes: > I propose that interested cypherpunks write a DOS terminal program > which _is_ free software. In order to overcome the inertia which Hal > properly observes is endemic to any software change, I submit that to > have source code available to fix or add features deemed desirable > will be a key factor in acceptance of this software. I have my own > ideas about multiplexing the channel to support background POP and > file transfer, but I'll leave that for later. Such software, of > course, would be properly layered to be able to add encryption at the > key junctures. I may be able to help out in a DOS project (though I seem to be migrating quickly to Linux as it stabilizes...) Perhaps the GPL'ed program term would be useful in serial multiplexing applications. It's quite nice for Unix boxes, letting all kinds of streams coexist (even redirecting TCP/IP ports over serial without the overhead of SLIP/PPP). I believe I've heard someone on comp.os.linux or gnu.misc.discuss talk about hacking DES into term, so it sounds doable. I'm not sure how much the code assumes Unix serial device handing, but I'll have a look at the code. Joe From hughes at soda.berkeley.edu Tue Jun 1 10:46:28 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 10:46:28 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: <199306011712.AA08151@ccwf.cc.utexas.edu> Message-ID: <9306011820.AA21028@soda.berkeley.edu> > The actual file encryption/decryption >must be done in hardware if you want to have any sort of speed at all. Please, everyone who is working on this, remember. You can't do hard disk encryption in software on the host CPU. Thanks to Jim for reminding me to stress this. >Lacking an available IDEA chip I will have to use >DES (multi-pass or some other variant to get around the limits on DES >keyspace) in order to get the necessary throughput on the disk. DES hardware is already available and tested. Use it. Use a triple-keyed EDE version of DES. Is someone selling a raw DES chip on an ISA card? If so, use that so that others don't have to hack together their own hardware. >Such a system would not be completely secure but would provide some >protection for files, which is more than they get now... The keying material for the disk should not be one key for the whole disk. The keying material could easily be one key per track without the keys growing too large. Ideally this keying material would be held on a removable PCMCIA card and would talk directly to the device encryptor hardware with a protected channel. That will have to wait. Eric From elee9sf at Menudo.UH.EDU Tue Jun 1 10:48:49 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Tue, 1 Jun 93 10:48:49 PDT Subject: Remailers 06/01/93 Message-ID: <199306011826.AA09799@Menudo.UH.EDU> -----BEGIN PGP SIGNED MESSAGE----- Q1: What cypherpunk remailers exist? A1: 1: hh at pmantis.berkeley.edu 2: hh at cicada.berkeley.edu 3: hh at soda.berkeley.edu 4: nowhere at bsu-cs.bsu.edu 5: remail at tamsun.tamu.edu 6: remail at tamaix.tamu.edu 7: ebrandt at jarthur.claremont.edu 8: hal at alumni.caltech.edu 9: remailer at rebma.mn.org 10: elee7h5 at rosebud.ee.uh.edu 11: phantom at mead.u.washington.edu 12: hfinney at shell.portal.com 13: remailer at utter.dis.org 14: 00x at uclink.berkeley.edu 15: remail at extropia.wimsey.com NOTES: #1-#6 remail only, no encryption of headers #7-#12 support encrypted headers #15 special - header and message must be encrypted together #9,#13,#15 introduce larger than average delay (not direct connect) #14 public key not yet released ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks directory at soda.berkeley.edu (128.32.149.19). Instructions on how to use the remailers are in the remailer directory, along with some unix scripts and dos batch files. Mail to me (elee9sf at menudo.uh.edu) for further help and/or questions. ====================================================================== -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAufF4OA7OpLWtYzAQGsEwQAkAcRFuEUBlNVdObcvTMZL3RFsK0MPZXw EyjAKEIkJgScdkeIN8uiN4Glz14+BkiLYWwu9fGRJAhV0ytKx1F/RYNcseXG0Em6 en69SAKrf6rgWMuA3im/k0uWe3FPoCVWyXYU7g9gDxvyQcgBkF1o+Fj4Sr3PtUCR LcIEvwSM+pM= =jIRN -----END PGP SIGNATURE----- From elee9sf at Menudo.UH.EDU Tue Jun 1 11:15:59 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Tue, 1 Jun 93 11:15:59 PDT Subject: ANON/REMAIL: Remailers June 1, 1993 Message-ID: <199306011853.AA12217@Menudo.UH.EDU> ...teach me to not read my mail first... :-) -----BEGIN PGP SIGNED MESSAGE----- Q1: What cypherpunk remailers exist? A1: 1: hh at pmantis.berkeley.edu 2: hh at cicada.berkeley.edu 3: hh at soda.berkeley.edu 4: nowhere at bsu-cs.bsu.edu 5: remail at tamsun.tamu.edu 6: remail at tamaix.tamu.edu 7: ebrandt at jarthur.claremont.edu 8: hal at alumni.caltech.edu 9: remailer at rebma.mn.org 10: elee7h5 at rosebud.ee.uh.edu 11: phantom at mead.u.washington.edu 12: hfinney at shell.portal.com 13: remailer at utter.dis.org 14: 00x at uclink.berkeley.edu 15: remail at extropia.wimsey.com NOTES: #1-#6 remail only, no encryption of headers #7-#12 support encrypted headers #15 special - header and message must be encrypted together #9,#13,#15 introduce larger than average delay (not direct connect) #14 public key not yet released #9,#13,#15 running on privately owned machines ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks directory at soda.berkeley.edu (128.32.149.19). Instructions on how to use the remailers are in the remailer directory, along with some unix scripts and dos batch files. Mail to me (elee9sf at menudo.uh.edu) for further help and/or questions. ====================================================================== -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAulOYOA7OpLWtYzAQHLfQP/XDSipOUPctZnqjjTq7+665MWgysE1ex9 lh3Umzk2Q647KyqhoCo8f7nVrieAZxK0HjRFrRQnQCwjTSQrve2eAQ1A5PmJjyiI Y55E3YIXYmKrQekIHUKaMyATfnhNc6+2MT8mwaWz2kiOTRkun/SlNI3Cv3Qt8Emy Y6Zv0kk/7rs= =simY -----END PGP SIGNATURE----- From nobody at eli-remailer Tue Jun 1 11:55:12 1993 From: nobody at eli-remailer (nobody at eli-remailer) Date: Tue, 1 Jun 93 11:55:12 PDT Subject: No Subject Message-ID: <9306011855.AA08017@toad.com> -----BEGIN PGP SIGNED MESSAGE----- I don't think the idea of a "virtual server" for anonymity will really accomplish much. Even if you somehow manage to spread the software over several machines, you still need to publicize the entry and exit points for remailing requests. If the net police determine to shut down the server, they can go after those machines which are publically known to be the places where the anonymous messages come from and shut them down. Sure, if you have a network of machines you might be able to bring another one online pretty quickly to replace this one which has been shut down. But then the net police can go after that one. And so on. You'd get the same effect just by having a bunch of conventional remailing servers, only announcing one of them publically, and then having each one come online only after the one before it got shut down. The hard part in either of these scenarios is collecting more people who will run anonymity servers. I don't see that doing tricky stuff with virtualizing the calculations helps you much. Similarly, trying to put a machine at an unknown site, or perhaps in a friendly country, won't necessarily help. If the machine itself is inaccessible, the net police will go after its feeds, the points at which it connects into the network. Look at what happened to Julf. His machine was safe, sitting in a back room of his house. They went after his net feeds instead. The real answer is to publically defend remailers. I argue for remailing servers on the basis of preventing traffic analysis. Most people accept that the use of encryption is justified for email in order to protect individual privacy. I claim that remailing servers extend this protection to include not only the content of a message, but its destination as well. The net does little today to keep the facts private about whom you communicate with. Remailers provide that confidentiality. If we had enough remailers that we could confidentally run a virtualized system, knowing that we could keep brining them online faster than they could be shut down, I'd argue that a better use of those resources would be to publically identify all of the remailers and let them all operate on their own. This would provide a united front to oppose the anti-privacy forces, giving political strength to our goals. Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAtoGqgTA69YIUw3AQGFeQQAsnAHwZpe+BRzhp9umLJzWJDFgcHYYYwu Bp5GJI2LmhQWB1pNluLxupW/ZZZqlO78HApOcU9jL/eFEhZakoAd4RJPVBjXpadm w1vkfSDQ6qXKnPyj28FM1sm3eSyfRu3evAd8+MfGNFOlCeyrYNfya6G3OBOcwpf1 bJFe7upKVVQ= =8apG -----END PGP SIGNATURE----- From mccoy at ccwf.cc.utexas.edu Tue Jun 1 12:18:22 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Tue, 1 Jun 93 12:18:22 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: <9306011820.AA21028@soda.berkeley.edu> Message-ID: <199306011955.AA29541@flubber.cc.utexas.edu> Eric Hughes writes: [...] > > >Such a system would not be completely secure but would provide some > >protection for files, which is more than they get now... > > The keying material for the disk should not be one key for the whole > disk. The keying material could easily be one key per track without > the keys growing too large. Actually I was sort of thinking of the keying being done on a per-user basis. The user would supply a key (with the pub key kept online and the private part stored in kernel memory during the user session) that would be used for thier files and the system key would only be used to provide a secure channel between the user and the system (user encrypts thier key pair with the system key and transmits it). I have several ideas on how to close up some of the holes on the OS side, but at the moment I am trying to concentrate on finishing up the details of just the filesystem side so I can get coding. Right now I am working on making the system provide security such that the only way to get at a file is to either have the legitimate user's private key or to have the system private key and run the system as a sort of trojan horse collecting keys as users login. Having the system private key will not give you any sort of "replay" data (you will not be able to use the system key to get any past user keys or much of anything else...) and having the physical hardware without the system private key will give you nothing at all. jim From ryan at rtfm.mlb.fl.us Tue Jun 1 12:33:23 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Tue, 1 Jun 93 12:33:23 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: <9306011820.AA21028@soda.berkeley.edu> Message-ID: On Tue, 1 Jun 1993, Eric Hughes wrote: > > The actual file encryption/decryption > >must be done in hardware if you want to have any sort of speed at all. > > Please, everyone who is working on this, remember. You can't do hard > disk encryption in software on the host CPU. Thanks to Jim for > reminding me to stress this. Well thanks for the advice, but you fergot to mention why... > >Lacking an available IDEA chip I will have to use > >DES (multi-pass or some other variant to get around the limits on DES > >keyspace) in order to get the necessary throughput on the disk. > > DES hardware is already available and tested. Use it. Use a > triple-keyed EDE version of DES. > > Is someone selling a raw DES chip on an ISA card? If so, use that so > that others don't have to hack together their own hardware. I would be very interested in a card like this, if anyone can find one. > >Such a system would not be completely secure but would provide some > >protection for files, which is more than they get now... > > The keying material for the disk should not be one key for the whole > disk. The keying material could easily be one key per track without > the keys growing too large. > > Ideally this keying material would be held on a removable PCMCIA card > and would talk directly to the device encryptor hardware with a > protected channel. That will have to wait. Another possibility until then, and one that would be fun for people who like to play with EPROMS, is a card that had a cable leading to an external EPROM socket that you could lay on your desk or on top of the case or wherever. You burn your keys for the HD into a chip and use it as a key, physically inserting the chip in the socket each time. There are lots on new ways to make chips easy to plug in and out, I'm sure it wouldn't be too hard. I still don't see why all of the actual encryption couldn't be done in software though... > Eric -Ryan the Bit Wallah From fnerd at smds.com Tue Jun 1 12:38:04 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Tue, 1 Jun 93 12:38:04 PDT Subject: Verifying Privacy as an Upload/AI? Message-ID: <9306011936.AA19298@smds.com> (Posted to both extropians and cypherpunks.) Is there any way for a process running in a computer to verify that it has privacy? How could an AI, for instance, ever know that it had privacy? How could a person preparing to be uploaded provide for their continuing privacy? Assume these things, for the sake of argument: Strong public key crypto. Truly tamper-proof computers. Capability-based operating systems with proven protection between processes. We might ask Norm Hardy for a rundown on some of the wonderful things that are possible in these types of systems. You might even assume that... Humans can memorize things, and these things can't be decoded from their uploads' memory dumps. (See note on torture below). The process/person seeking assurance of privacy is capable of being downloaded into a humanoid robot with enough compute power. Can you prevent the bad guys from copying you and torturing information out of the copy? Can you be secure even if they can do that? Even with the best assumptions, I find this question tough. But then I'm dense sometimes. -fnerd From hughes at soda.berkeley.edu Tue Jun 1 13:06:15 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 13:06:15 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: <199306011955.AA29541@flubber.cc.utexas.edu> Message-ID: <9306012040.AA27161@soda.berkeley.edu> I argue that encrypted hard disks should be encrypted at the transfer level. >Actually I was sort of thinking of the keying being done on a per-user >basis. Never fear. Layered encryption is the way of the future. One layer of encryption for the disk as a whole, another for the users. When the stuff gets cheap enough, it will be everywhere. The question is "Who is your opponent?" If you are concerned with the users against each other, then use user level encryption. If you are concerned with the outside world against the machine, then encrypt at the disk controller or device driver level. If you are concerned about both, then do both. Eric From hughes at soda.berkeley.edu Tue Jun 1 13:09:11 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 13:09:11 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: Message-ID: <9306012042.AA27310@soda.berkeley.edu> >> You can't do hard >> disk encryption in software on the host CPU. >Well thanks for the advice, but you fergot to mention why... Performance. Look at how long it take to do encryption via software and how long by hardware. Consider that a Unix box can do other processor tasks while the disk is stepping. Re: EPROM as key A fragile device makes privacy for hackers only. General privacy will require something significantly more physically robust. Eric From hughes at soda.berkeley.edu Tue Jun 1 13:31:05 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 13:31:05 PDT Subject: No Subject In-Reply-To: <9306011855.AA08017@toad.com> Message-ID: <9306012105.AA28350@soda.berkeley.edu> >I don't think the idea of a "virtual server" for anonymity will really >accomplish much. For just plain old reliability in the face of expected hardware and connectivity failure, it is reason enough. When one examines intended such failures, the analysis must be more subtle. >... you still need to publicize the entry and exit points Yes. On any system at all, the portals that guard privacy are public. For whatever architecture you chose, you still need an actual email address that resolves down to some physical internet machine to gain access to that service. >If the net police determine to shut down the server Shutting down service is all economics. It you must simultaneously shut down even two machines, that is a larger cost that shutting down one, since there must be coordination. >one online pretty quickly to replace this one which has been shut down. >But then the net police can go after that one. And so on. Cost, cost, cost. What is possible and what is fiscally available are two different things. Two machines might be in the realm of possibility, but where is the cutoff exactly? >You'd get the same effect just by having a bunch of conventional remailing >servers, only announcing one of them publically, and then having each >one come online only after the one before it got shut down. No, there is a single and incredibly salient difference--communicating the change of address to all those who use the service. Right now, this changed information must either end up in people's head, or in their alias files, or in their scripts. Wherever it is, it would have to change. This effectively puts a fairly small upper bound on the user base for such a service, given the characterstic time it takes to communicate such changes. Plus, if you want pseudonymous return paths, then you have to make sure that data is transferred to a new system. >The hard part in either of these scenarios is collecting more people who >will run anonymity servers. The scenario I envision for virtualized databases is a business running such a network themselves or in partnership with other companies. Doing this all on netcom shell accounts just won't happen. The hard part here is trying to get someone to pay for the secure service. >If the machine itself is inaccessible, the net police will go after >its feeds, the points at which it connects into the network. If there is a single point of failure, that's a problem. This is a design criterion, not an overwhelming roadblock. >Look at what happened to Julf. His machine >was safe, sitting in a back room of his house. They went after his net >feeds instead. One-point failure! The politics of the connecting network are crucial in the long run. I have a separate message about that. >The real answer is to publically defend remailers. I see no reason why these two approaches are exclusive. Eric From stig at netcom.com Tue Jun 1 13:52:09 1993 From: stig at netcom.com (Stig) Date: Tue, 1 Jun 93 13:52:09 PDT Subject: Software infrastructure In-Reply-To: <9306011553.AA16160@soda.berkeley.edu> Message-ID: <9306012130.AA17995@netcom.netcom.com> To quote: Eric Hughes > > Let's go back to the DOS-as-terminal issue. The politics and > economics of DOS shareware is such that source code is almost never > made available. Gnu public license software is rare in the DOS world. > > I propose that interested cypherpunks write a DOS terminal program > which _is_ free software. In order to overcome the inertia which Hal > Let's generalize a bit: Since PC based unix is more available, this package should run on either PC or UNIX platforms. Tip doesn't cut it as a terminal program for UNIX and I don't know of another... SLIP has it's disadvantages. So, what I'm proposing is that the OS interface stuff be crammed into an interface layer. One intriguing application: Write an interface layer that uses SOCKETS for connectivity. We want to avoid the kitchen sink mentality, BUT if we're going to spend lots of time on this package, then why have it all go to waste when time comes to port the sucker? Stig /* Jonathan Stigelman, Stig at netcom.com, PGP public key by finger */ /* fingerprint = 32 DF B9 19 AE 28 D1 7A A3 9D 0B 1A 33 13 4D 7F */ From m5 at vail.tivoli.com Tue Jun 1 14:26:07 1993 From: m5 at vail.tivoli.com (Mike McNally) Date: Tue, 1 Jun 93 14:26:07 PDT Subject: Software infrastructure In-Reply-To: <9306012130.AA17995@netcom.netcom.com> Message-ID: <9306012202.AA14863@vail.tivoli.com> > Let's generalize a bit: Since PC based unix is more available, this > package should run on either PC or UNIX platforms. Tip doesn't cut it > as a terminal program for UNIX No kidding. > and I don't know of another... Kermit? > SLIP has it's disadvantages. Like, try making it work reasonably on a DOS platform. > We want to avoid the kitchen sink mentality, BUT if we're going to > spend lots of time on this package, then why have it all go to waste > when time comes to port the sucker? Why not just distribute a package of patches for the Kermit sources? Mike McNally From newsham at wiliki.eng.hawaii.edu Tue Jun 1 14:32:10 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Tue, 1 Jun 93 14:32:10 PDT Subject: Software infrastructure In-Reply-To: <9306011816.AA10998@kolanut> Message-ID: <9306012132.AA11983@toad.com> > I may be able to help out in a DOS project (though I seem to be migrating > quickly to Linux as it stabilizes...) Perhaps the GPL'ed program term > would be useful in serial multiplexing applications. It's quite nice for > Unix boxes, letting all kinds of streams coexist (even redirecting TCP/IP > ports over serial without the overhead of SLIP/PPP). I believe I've on a similar note the DNET protocol for amiga is quite nice. It comes with a nice socket like library. Works quite efficiently but contains no information about addressing (it is strictly point to point so it doesnt use any addressing). From peb at PROCASE.COM Tue Jun 1 14:32:55 1993 From: peb at PROCASE.COM (peb at PROCASE.COM) Date: Tue, 1 Jun 93 14:32:55 PDT Subject: Verifying Privacy as an Upload/AI? Message-ID: <9306012209.AA17679@banff.procase.com> I think you are headed in the right direction wrt a capability system, however, they are predicated on tamper proof hardware. Since you stipulate human being copying and torturing (sounds like tampering to me), I think this is not ultimate privacy. Hmm, perhaps you should set up a key escrow system (!) so that you need to call your most trusted friends to assemble your session key. The session key works only once, assuming a tamper proof, capability system. When you call them, they can quiz you on your mental and physical health to determine whether they should give you the keys...thus limiting the ability of a torturer. Paul E. Baclace peb at procase.com From MCMAHON at Eisner.DECUS.Org Tue Jun 1 14:48:54 1993 From: MCMAHON at Eisner.DECUS.Org (John (FuzzFace/Fast-Eddie) McMahon) Date: Tue, 1 Jun 93 14:48:54 PDT Subject: crypto '93 Message-ID: <01GYVGNSU5IM000DDC@Eisner.DECUS.Org> *Sigh* Crypto '93 conflicts with Interop San Francisco (apparently). From fnerd at smds.com Tue Jun 1 15:05:54 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Tue, 1 Jun 93 15:05:54 PDT Subject: Verifying Privacy as an Upload/AI? Message-ID: <9306012223.AA21470@smds.com> Just want to reinforce that my question is not how can an AI or upload BE secure, but how can they KNOW that they are secure. That is, given that you SEEM to be inside a secure system, how can you know that you are not inside a simulation that actually has a trap door? -fnerd From marc at GZA.COM Tue Jun 1 15:06:14 1993 From: marc at GZA.COM (Marc Horowitz) Date: Tue, 1 Jun 93 15:06:14 PDT Subject: Verifying Privacy as an Upload/AI? In-Reply-To: <9306012209.AA17679@banff.procase.com> Message-ID: <9306012243.AA11249@dun-dun-noodles.aktis.com> >> Since you stipulate human being copying and torturing (sounds like >> tampering to me), I think this is not ultimate privacy. >> When you call them, they can quiz you on your mental and physical health >> to determine whether they should give you the keys...thus limiting the >> ability of a torturer. Oh, sure. "Hi, Paul? This is Marc. I need your piece of my private key. How am I? Just fine. But if you don't give me the password, the guy holding the phone has some very unpleasant looking surgical equipment and there isn't an anaesthesiologist in sight, so I won't be fine for long. Just read it out loud, someone will key it in." Need I say more? Marc From clark at metal.psu.edu Tue Jun 1 15:47:44 1993 From: clark at metal.psu.edu (Clark Reynard) Date: Tue, 1 Jun 93 15:47:44 PDT Subject: Clipperpunks Write Code? Message-ID: <9306020003.AA02785@metal.psu.edu> Actually, I think that writing letters is somewhat useful; especially those of us who aren't very good at writing real code. I plug cypherpunks a bit in a Phrack article I just finished concerning my bust by the police a few years back; maybe you'd like to check it out, since it may be YOU if this damn Clipper thing goes through. This makes me glad I voted Marrou/Lord, and that I resisted the temptation to be suckered by that sellout bastard Clinton. I was worried that he would turn out to be a Jimmy Carter, but it's far worse than that. Carter, at least, had some human decency. Clinton has turned into the nightmare resurrection of Lyndon B. Johnson, and is probably stupid enough to get us into a war. Damn all politicians. If any of you read the Phrack article (I will not forward my article to the cypherpunks list, as it is well over 100K; those who wish to check it out can see it when and if it comes out; in all likelihood, Phrack 43, which is due to be out in a week or so), and believe that there is another publication which might be interested in it (I am willing to re-write for lay-persons); send me the info. Anyone who just absolutely can't WAIT to read it can request a copy from me, and I'll send it in three parts. While my article touches only tangentially on the issue of encryption (and my experience with weak encryption and with NOT having encryption), it may be of interest. Simply for your interest in cryptography, it is apparent that we are about to face a McCarthyesque witch-hunt. The government has already defined the terms of this conflict, and has declared war on basic human liberty. We must act accordingly. I advocate that the Clipper algorithm be discovered, if at all possible, by the comparison of the unlimited plaintext/ciphertext pairs which will be available to anyone with a Clipper phone and a computer, and the skills for differential cryptanalysis and/or IC Reverse Engineering. If the algorithm is made public, anonymously, within a year, and in so many copies that it is impossible to stop its distribution in electronic or samizdat form, Clipper is doomed. And it must be doomed. It's them or us. ---- Robert W. Clark Just Say No! to the rclark at nyx.cs.du.edu Big Brother Chip From bakunin at gnu.ai.mit.edu Tue Jun 1 16:13:41 1993 From: bakunin at gnu.ai.mit.edu (bakunin at gnu.ai.mit.edu) Date: Tue, 1 Jun 93 16:13:41 PDT Subject: things Message-ID: <9306012350.AA02271@spiff.gnu.ai.mit.edu> In re: tested telexes for those who don't know, telexes have been made 'secure' by use of a simple testing system for, say, banks to 'wire' money with. This extant paradigm gives me hope that electronic contracts are coming. In re: Wilde, ptui Pascal, SCHMASCAL. "Schlup.. schlup schlup." -WSB In re: govmnt nastiness Well, gee, I thought Carter was a pig, too. Lookit East Timor. But as Slick Willie goes, I dunno. I believe propagation of technology may outflank any intentions he may have. Maybe. be cool, michael From markh at wimsey.bc.ca Tue Jun 1 16:18:27 1993 From: markh at wimsey.bc.ca (Mark C. Henderson) Date: Tue, 1 Jun 93 16:18:27 PDT Subject: wimsey.bc.ca archive is back on line Message-ID: Due to a disk failure the anonymous ftp cryptography archive at wimsey.bc.ca (/pub/crypto) was off line for a couple of months. Well, it is back. (If you haven't used it before, we're on the other end of a slip link, so be please be patient, downloads take a while). As usual I'm asking that this archive not be used to illegally export cryptographic products from Canada and the U.S. -- Mark Henderson markh at wimsey.bc.ca (personal account) RIPEM key available by key server/finger/E-mail MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433 From peb at PROCASE.COM Tue Jun 1 16:42:52 1993 From: peb at PROCASE.COM (peb at PROCASE.COM) Date: Tue, 1 Jun 93 16:42:52 PDT Subject: Verifying Privacy as an Upload/AI? Message-ID: <9306020020.AA17715@banff.procase.com> >From marc at GZA.COM Tue Jun 1 15:44:15 1993 >But if you don't give me the password, the guy >holding the phone has some very unpleasant looking surgical equipment Alarm systems use duress codes for this that trigger a silent alarm when the password is entered. I'm not sure the proposed system here (a capability system) could have an extra channel that the bad guys don't know about. Using a hierarchy of escrow agents would be interesting--then by calling me up for part of the key would require me to get back to you after I called up the person at the next level. (Note that a hierarchy is a special case of a general graph, so the webs of trust idea is important here (could provide some redundancy).) Now, back to Steve's actual question, >From: fnerd at smds.com (FutureNerd Steve Witham) >given that you SEEM to be inside a secure system, how can you know >that you are not inside a simulation Ultimately, there is no proof you are not currently a simulation on a big computer. Why is time travel is not possible? It's too expensive on the current platform. (E.g, if SimEarth inhabitants could time travel, you would have a hard time keeping track of what they did and your machine would slow down considerably). On an upload, how many people can be in the same room? Can you make arbitrary video phone calls? Anything that stretches the compute resources could potentially make the bad guys impatient and blow their trojan horse universe. Paul E. Baclace peb at procase.com From gnu at cygnus.com Tue Jun 1 16:48:55 1993 From: gnu at cygnus.com (gnu at cygnus.com) Date: Tue, 1 Jun 93 16:48:55 PDT Subject: The new PEM release supports non-authoritarian certificates Message-ID: <9306020026.AA02946@cygnus.com> You can generate your own certificates using the new PEM code from TIS. This, in some ways, models the PGP "web of trust" model. At least it's a lot closer than the original PEM "you trust us, we don't trust you" model. They have also done something with the email address space, but I'm not sure what. Previously PEM required that you abandon your Internet email address and use an X.400 based address in certificates and such. More details will be available when the PEM release is out for FTP (within days, I think). John From ld231782 at longs.lance.colostate.edu Tue Jun 1 16:49:22 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Tue, 1 Jun 93 16:49:22 PDT Subject: Newsweek Clipper Coverage Message-ID: <9306020026.AA27360@longs.lance.colostate.edu> Under `Society -- Technology' in Newsweek of June 7 1993 p.70 appears the headline `The Code of the Future' subhead `Uncle Sam wants you to use ciphers it can crack'. This 1 page article is pretty ambitious for what it tries to cover. The figure shows a flowchart for encryption over a phone using a key. (Not particularly illuminating. In particular the role & point of the key is ambiguous.) At the bottom 1/4 page we have a sidebar ``Great Moments in Cryptography' with 1st known encryption (Egyptian), the Zimmerman Telegram role in WWI, the Japanese Purple breakthrough prior to Pearl Harbor (the picture is apparently Friedman holding the machine), and finally Nov 4 1952 (a day that will live in infamy), Truman creates the NSA, `master of math based codes'. The article notes in the lead-in a cute & useful `hook' for the public & popular role of cryptography I have been drawing for a long time for nontechnical friends, saying that with it Queen Elizabeth could have been spared the spectacle of the steamy Prince Charles phone revelations and eavesdroppers would have heard nothing but a hiss, and `no signal analyzer, no supercomputer, no wiretap could have decoded the white noise.' Fortunately, they attribute this `reputation saving magic' not to Clipper but a DES chip. ``That's what America's supersecret spymasters, the NSA, intended when they designed the cryptographic system in the 70s with IBM.'' (glaring errata; their involvement has always been officially claimed as *secondary* and *subsidiary* to IBM's, if even at all. But, it is an error in our favor.) Article doesn't mention Clipper by name, but says it was essentially a response to the unbreakable aspects of DES using key system. Eric Hughes, `computer security expert [at] Berkeley': ``The government is saying, `If you want to lock something up, you have to [give us] the key'.'' Next, the motivation. Our networks are insecure, Internet ``broken into 90 percent more times than 1991'' (where'd that little statistic come from? Gene Spafford?). Security of medical records, credit-card purchases, video rentals, cellular phones at stake. NSA chip used by AT&T would take a supercomputer over a billlion years to solve, says R. Kammer of NIST. Problems: NSA hasn't revealed the algorithm so nobody knows if its `hackproof'; agencies holding keys are vulnerable to `recreational hackers, foreign spooks, and industrial spies.' Here comes the gut-wrencher. ``For now now one is forced to use the NSA chip. But manufacturers who put a rival chip into, say, their modems would likely be denied government contracts, as well as export licenses for the NSA-proof products. Even that may not appease the spymasters. ***No one rules out a mandatory encryption standard,'' says NIST spokesman Mat Heyman.***'' Is that quote from the point of view `our concerns on this have not been allayed' or in the vein `all the NSA henchmen I know are chomping at the bit to legislate a monopoly or outlaw non-Clipper chips'? Overall, I'd say a favorable article that covers the basics, and rather excellent editing given the severe space limitation (less than many newspaper articles). Written by Sharon Begley with Melinda Liu in Washington and Joshua Cooper Ramo. * * * Cypherpunks, I'm extremely concerned about these little quotes popping up in the media. Just a few days ago we hear in the Washington Post: > Administration sources said that if the current plan doesn't >enable the NSA and FBI to keep on top of the technology, then Clinton >is prepared to introduce legislation to require use of its encryption >technology, which is crackable by the NSA, and to ban use of the >uncrackable gear. > "It's an option on the table," said a White House official. I sure hope that `official' has absolutely nothing to do with Clipper, but that's unlikely. It seems to me these are the sounds of a slow, sinister rumbling underway. Sometimes quotes like these are `floated trial balloons' but other times they are grotesque flickers of real internal machinations. The more I hear them the more I think they are in the latter category. So far, the administration and media just don't `get it' that a firestorm is in the making over any hair-thin deviation from the standard of `no domestic regulation of encryption'. If NSA & the administration thinks that the Clipper brouhaha was containable, just wait until they go a nanometer past it in the wrong direction. Actually, a Supreme Court case on cryptography issues seems in some ways to be inevitable. Wow, I'd say there'd probably be enough artillery to seriously damage NSA in that confrontation. Cypherpunks, I'd like to compile a list of all quotations on the `regulation of domestic cryptography' topic. That way we'll have a propaganda poster all ready if any idiot bureacrat thinks they can thumb their nose any further. I have the original announcement text and the Washington Post text above. It seems to me that an NIST representative claimed there were `no plans' to outlaw other cryptography. Where was that? Can everyone send me whatever they have on this topic? P.S. Many tx. to E.H. for the thorough and excellent collection in soda.berkeley.edu:/pub/cypherpunks/clipper. - - - For reference, here are the original Orwellian weasel words form the April 16 announcement: Q: If the Administration were unable to find a technological solution like the one proposed, would the Administration be willing to use legal remedies to restrict access to more powerful encryption devices? A: This is a fundamental policy question which will be considered during the broad policy review. The key escrow mechanism will provide Americans with an encryption product that is more secure, more convenient, and less expensive than others readily available today, but it is just one piece of what must be the comprehensive approach to encryption technology, which the Administration is developing. The Administration is not saying, "since encryption threatens the public safety and effective law enforcement, we will prohibit it outright" (as some countries have effectively done); nor is the U.S. saying that "every American, as a matter of right, is entitled to an unbreakable commercial encryption product." There is a false "tension" created in the assessment that this issue is an "either-or" proposition. Rather, both concerns can be, and in fact are, harmoniously balanced through a reasoned, balanced approach such as is proposed with the "Clipper Chip" and similar encryption techniques. From anton at hydra.unm.edu Tue Jun 1 17:18:13 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Tue, 1 Jun 93 17:18:13 PDT Subject: Electronic Contracts In-Reply-To: <9306010433.AA27082@anchor.ho.att.com> Message-ID: <9306020055.AA13186@hydra.unm.edu> Regarding "test cases" for digital signatures, not sure if this is 100% relevant but what the hell... In this area at least, when the UPS folk bring you a package that you must sign for, you no longer sign on paper, but on this funky electronic tablet. Now granted this thing is recording your "real" signature, and thus differs greatly, but still there may be something to this. Not sure where one would look for material having to do with such devices, and their relevance to a court case, but then again no one pays me legal consulting fees either. >:) -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From pleiku!kelly at netcom.com Tue Jun 1 17:31:39 1993 From: pleiku!kelly at netcom.com (Stop the Big Brother CHip) Date: Tue, 1 Jun 93 17:31:39 PDT Subject: No Subject In-Reply-To: <9306011855.AA08017@toad.com> Message-ID: <9306020109.AA01465@netcomsv.netcom.com> The actual server entry point could be through a cypherpunks encrypted anonymous remailer block. that could totally conceal the entry oiint given the proper type of remailer... as to the service posting machine... one could maintain a net of open nntp servers by ones confederates, one could then "forge" the posting and give an anonymous remailer block corresponding to the anon id... concealment and high security? given message encryption remailers and a public key for the forging NNTP posting mechanism I dont see many issues coming from that what do the rest of you thinK ... course this scheme depends on a common set of features on anon remailers... i.e. message encryption... cheers kelly -- Parts of this .sig borrowed with permission from T.C.May. Perhaps it will indeed get me busted also. .......................................................................... Kelly Goen | Crypto Anarchy: encryption, digital money, kelly at netcom.com | anonymous networks, digital pseudonyms, zero Intelligence Systems | knowledge, reputations, information markets, Specialists Inc. | black markets, face banks, data havens, dark | tech, covert channels, shared secrets, | alt.whistleblowers, collapse of governments. Technical Monkeywrench | Public Key: PGP 2.2. | .......................................................................... PGP 2.2 Key available from PGP Keyservers on the Internet. pub 1024/1BA573 1992/09/09 kelly Key fingerprint = EF 7A 38 99 22 84 E3 3B 90 2A DB 80 DC 65 DA 31 STOP THE WIRETAP CHIP(Clipper Chip)!! From marc at Athena.MIT.EDU Tue Jun 1 17:35:31 1993 From: marc at Athena.MIT.EDU (marc at Athena.MIT.EDU) Date: Tue, 1 Jun 93 17:35:31 PDT Subject: [daemon@ATHENA.MIT.EDU : FYI: White House EMail] Message-ID: <9306020112.AA09458@bill-the-cat.MIT.EDU> ------- Forwarded transaction [5834] daemon at ATHENA.MIT.EDU (Dave Farber) Commercialization & Privatization of the Internet 06/01/93 20:26 (90 lines) Subject: FYI: White House EMail Date: Tue, 1 Jun 1993 20:25:47 -0500 From: Dave Farber To: com-priv at psi.com THE WHITE HOUSE Office of Presidential Correspondence ______________________________________________________________ For Immediate Release June 1, 1993 LETTER FROM THE PRESIDENT AND VICE PRESIDENT IN ANNOUNCEMENT OF WHITE HOUSE ELECTRONIC MAIL ACCESS Dear Friends: Part of our commitment to change is to keep the White House in step with today's changing technology. As we move ahead into the twenty-first century, we must have a government that can show the way and lead by example. Today, we are pleased to announce that for the first time in history, the White House will be connected to you via electronic mail. Electronic mail will bring the Presidency and this Administration closer and make it more accessible to the people. The White House will be connected to the Internet as well as several on-line commercial vendors, thus making us more accessible and more in touch with people across this country. We will not be alone in this venture. Congress is also getting involved, and an exciting announcement regarding electronic mail is expected to come from the House of Representatives tomorrow. Various government agencies also will be taking part in the near future. Americans Communicating Electronically is a project developed by several government agencies to coordinate and improve access to the nation's educational and information assets and resources. This will be done through interactive communications such as electronic mail, and brought to people who do not have ready access to a computer. However, we must be realistic about the limitations and expectations of the White House electronic mail system. This experiment is the first-ever e-mail project done on such a large scale. As we work to reinvent government and streamline our processes, the e-mail project can help to put us on the leading edge of progress. Initially, your e-mail message will be read and receipt immediately acknowledged. A careful count will be taken on the number received as well as the subject of each message. However, the White House is not yet capable of sending back a tailored response via electronic mail. We are hoping this will happen by the end of the year. A number of response-based programs which allow technology to help us read your message more effectively, and, eventually respond to you electronically in a timely fashion will be tried out as well. These programs will change periodically as we experiment with the best way to handle electronic mail from the public. Since this has never been tried before, it is important to allow for some flexibility in the system in these first stages. We welcome your suggestions. This is an historic moment in the White House and we look forward to your participation and enthusiasm for this milestone event. We eagerly anticipate the day when electronic mail from the public is an integral and normal part of the White House communications system. President Clinton Vice President Gore PRESIDENT at WHITEHOUSE.GOV VICE.PRESIDENT at WHITEHOUSE.GOV ### ------- End of Forwarded Message ------ End of Forwarded Message --[5834]-- ------- End forwarded transaction From fergp at sytex.com Tue Jun 1 18:14:34 1993 From: fergp at sytex.com (Paul Ferguson) Date: Tue, 1 Jun 93 18:14:34 PDT Subject: Cypherpunks do what? Message-ID: <7NTH5B1w165w@sytex.com> -----BEGIN PGP SIGNED MESSAGE----- I'm all for cypherpunk code-writing; I'm all for crypto for the masses. In fact, I'm working it on a real-time basis, boys and girls. Somehow, I feel a bit slighted, and it goes a little beyond myself, if it need be known. I'm really not stupid enough to squeak without provocation. :-) I'd like to, additionally, see a sub-paragraph in the FAQ concerning non-code-writing exploits, such as the tedious task of accosting politicos. Is this not a desired activity? I shudder to think that cypherpunks would corner themselves in a manner which would exclude political maneuvers. IMHO, any cypherpunk who would close themselves off from political fire is either brilliant or idiotic, dependent upon method or mentality. Me -- I'll take the questionable route; I would rather get the answers I seek, sow the seeds of incongruity and ask questions of pertinent people. I'm asking that Eric Raymond add to "What do Cypherpunks do?" lineage, "Cypherpunks also do a lot of monkey-wrench work." We also run political gauntlets. We also draw attention, while other projects are accomplished. We also encourage other politico brethren of internationalities to join us in our struggle for electronic and cryptographic independence. We also interface with those turkeys on capitol hill (non-caps). Cypherpunks do more than write simple code -- we set precedence, we deliver technology. Cheers. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAwBGpRLcZSdHMBNAQHGIQP/YxBKfkjehoJawjExagITkr7emoEp3eMq wnj2Vp54dh8C8wfNdf+ovbT8siOfIT135ucLZQLDifLqp/iUgpnwk80Ur0427WSP Leb/UmLDm8HNO3gLyjDZ4YeLH++/qBiFb3Ej2+6ACyMc4wIUCXwKLnp1Ov3+E9vY 3Tjb25WVtXQ= =pLmj -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From tcmay at netcom.com Tue Jun 1 18:18:27 1993 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 1 Jun 93 18:18:27 PDT Subject: "Newsweek" Article on Clipper and Encryption Message-ID: <9306020156.AA27555@netcom.netcom.com> The following appeared in this week's "Newsweek," June 7, 1993, p. 70. Our own Eric Hughes is briefly quoted. Any mistakes are the fault of either me or my OCR program. The Code of the Future Uncle Sam wants you to use ciphers it can crack Forget the castle. If only Queen Elizabeth had given Chuck and Di a thumbnail-size computer chip for their wedding, she would have been spared reading in the London tabs how her son" wanted to live in [his lover's] trousers," among other excerpts from taped phone conversations. Instead, the chip would have converted their words into "hsssssss." No signal analyzer, no supercomputer, no wiretap could have decoded the white noise. The device that works this reputation-saving magic is called a Data Encryption Standard (DES) chip, and there's no practical way to crack it. That's what America's supersecret spymasters, the National Security Agency, intended when they designed the cryptographic system in the 1970s with IBM. While that delights industry and privacy advocates, it's come back to haunt the government: wiretaps are useless against any suspect using a DES-encrypted phone. So in April the Clinton administration announced it was backing the NSA in its push to impose a universal encryption standard to which the Feds alone would hold the keys. The agency argues that's the only way to ensure it will always be able to decode foreign communications. Civil libertarians and corporations don't see it that way. Says computer-security expert Eric Hughes of Berkeley," The government is saying, 'If you want to lock something up, you have to [give us] the key'." No one doubts that the nation's voice, data, electronic mail and other communications need locks, and fast. Industrial spies grab fax, e-mail and other computer and microwave transmissions out of the air. Hackers broke into Internet, a world-wide computer network, 773 times last year, 90 percent more than in 1991. Hackers also peek into computers that hold medical records, credit-card purchases, even video rentals. Cellular phones offer as much privacy as going on "Oprah." The FBI can't keep up with all the cybercrime. Secret codes can, and since World War, II codes have been based on algorithms--formulas that transform one set of numbers into another. NSA's new chip, to be used in a secure phone sold by AT&T, encrypts computer transmissions and phone conversations with an algorithm so complex "it would take a CRAY YMP [supercomputer] over a billion years to solve," says Raymond Kammer of the National Institute of Standards and Technology (NIST), which worked with NSA on the algorithm. Yet the principle is simple. A sending phone and a receiving phone electronically choose one algorithm, out of millions, for their conversation (diagram). The only way to unscramble the resulting 10001100101s is to obtain the "keys," which will be held by two agencies chosen by the attorney general. The agencies-this is the part NSA likes-would give them to officials who have the requisite wiretap warrant. But industry has a couple of problems with this. First, NSA has yet to explain how the chip works, so outside verification that it's hackproof will have to wait. Worse, with millions of NSA chips in use, the agencies holding the keys would have to store them on computers, which are vulnerable to recreational hackers, foreign spooks and industrial spies. For now, no one is forced to use the NSA chip. But manufacturers who put a rival chip into, say, their modems would likely be denied government contracts, as well asexport licenses for the NSA-proof products. Even that may not appease the spymasters. "No one rules out a mandatory encryption standard," says NIST spokesman Mat Heyman. That's industry's greatest fear, which NIST will attempt to allay in meetings this week. And next week Rep. Edward Markey holds hearings on whether NSA can keep the keys to its codes safe from hackers. Or even Fleet Street. SHARON BEGLEY with MELINDA LIU in Washington and JOSHUA COOPER RAMO From smb at research.att.com Tue Jun 1 18:32:28 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 1 Jun 93 18:32:28 PDT Subject: [daemon@ATHENA.MIT.EDU : FYI: White House EMail] Message-ID: <9306020132.AA18372@toad.com> Glad to hear the White House in on the net, but where's the PEM certificate for those addressses? From nobody at eli-remailer Tue Jun 1 18:55:59 1993 From: nobody at eli-remailer (nobody at eli-remailer) Date: Tue, 1 Jun 93 18:55:59 PDT Subject: request for cryptanalysis tools Message-ID: <9306020155.AA19081@toad.com> Eric Hughes asked about the piece of software I'm cryptanalyzing... > Could you post a more complete pointer to this? The program is "ncrypt". Available on garbo.uwasa.fi, /pc/crypt/ncrypt31.zip About pub/cypherpunks/cryptanalysis... I'll post anything useful that I write... > The directory is there as much to inspire the writing of such software > as it is to distribute it. Point taken! -cire From fergp at sytex.com Tue Jun 1 19:10:34 1993 From: fergp at sytex.com (Paul Ferguson) Date: Tue, 1 Jun 93 19:10:34 PDT Subject: Work the work! Message-ID: <64VH5B1w165w@sytex.com> -----BEGIN PGP SIGNED MESSAGE----- On Tue, 1 Jun 93 09:56:45 -0700, Eric Hughes wrote - > We are trying to build a sandbox, and the government is trying to > restrict the use of sand. We are indeed doing just this. Although the small minority of us compu-professionals are writing code, flailing congressmen, etc., it takes more than what is currently being acknowledged to get things changed. I will not, however, discontinue my diatribe with my elected representatives on the topic of our electronic rights to privacy under the first and fourth amendments. (I'm having too much fun doing something that I seriously, and perhaps foolishly, believe in.) Is there something going on with the EFF that we should know about? > That said, I also urge those who are writing code to continue. To > those of you not writing code, however, I say start talking to your > friends and neighbors and communities and newspapers. > Now. We are working on it. A vote of confidence towards crypto-freedom. Are we east-coast-niks welcome in this process? Is policy being drawn by a few EFF persona without consultation of the masses? Eric, before you say "Now,", you'd best detail us. I know what you mean, however, many of the crypto-warriors which may follow do not. It may be a good idea to _now_ place a broad policy statement. Cheers. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAwNs5RLcZSdHMBNAQFlRAP7BSpktDz4URB0rhWQ5mxb2UcJqEZHdp+2 It+Whxh1MzYTLFi0SfvZRQYjPEZO1wN2ac8bQyl2zOpi7viAg8X+AfEZACWooqUQ y8Dyddup15MNj/p53fJQhzKYaX4K4xD2h6WTWO1X8Q2SPHo0WV48Hu+uO8nyeoqD PJj0d/IHvg4= =6GvE -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From mdiehl at triton.unm.edu Tue Jun 1 19:33:40 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 1 Jun 93 19:33:40 PDT Subject: What do cypherpunks use? Message-ID: <9306020311.AA19986@triton.unm.edu> Since Cypherpunks write code, I thought it might be interesting to find out what kinds of systems cypherpunks USE. If you would be so kind as to fill out the included questionaire, I'll summerize. Thanx in advance. What kind of system do you use? What OS do you use? What mail reader do you use? Which online services do you use? Do you use pgp? Which version? If you use a personal computer, what communications program do you use? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Tue Jun 1 19:35:53 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 1 Jun 93 19:35:53 PDT Subject: WH email petition. Message-ID: <9306020313.AA20120@triton.unm.edu> In light of the White House getting on the net, how effective do you all think an electronic petition, about the BigBrotherChip, would be? Do you think that they would listen? Do you think that, perhapse, we would simply be put on a list of "trouble makers?" I was thinking of writting a petition and distributing it in every way I can think of, and encouraging people to send it to the White House. Any comments? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From karn at unix.ka9q.ampr.org Tue Jun 1 19:55:14 1993 From: karn at unix.ka9q.ampr.org (Phil Karn) Date: Tue, 1 Jun 93 19:55:14 PDT Subject: eavesdropping druggies Message-ID: <9306020332.AA16441@unix.ka9q.ampr.org> Today's San Diego Union Tribune has a locally-written article on the investigation into the murder of the Mexican cardinal by drug gangs. The title is "Drug gangs eavesdrop on rivals", and begins as follows:L "TIJUANA - The two rival drug gangs whose attempts to kill each other's leadership have left a Mexican cardinal and six others dead apparently have been using sophisticated electronic gear to monitor each other's movements, Mexican authorities reported yesterday. "In addition to the assault rifles, grenades and police and army uniforms being discovered in a series of safe houses, Mexican federal police are reporting finding devices designed to trace and monitor calls made from cellular telephones. "They also are finding sophisticated communications-monitoring equipment, walkie-talkies, tape recorders and pages upon pages of documents." The article continues with other developments in the investigation unrelated to electronic eavesdropping. A few (semi-serious) thoughts come to mind: 1. Perhaps the government doesn't want secure telephones in the hands of the drug lords not so much because it will thwart wiretapping by law enforcement, but because it will protect the gangs from each other -- and they aren't inhibited by Constitutional requirements. 2. Gee. I thought the cellular eavesdropping problem was completely solved by the recent ban on cellular-capable scanners. 3. I can't wait for the Federales to discover computers with PGP in one of these safehouses. And when it does, expect all hell to break loose in the crypto propaganda war. Phil From hughes at soda.berkeley.edu Tue Jun 1 20:34:59 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 20:34:59 PDT Subject: WH email petition. In-Reply-To: <9306020313.AA20120@triton.unm.edu> Message-ID: <9306020408.AA19558@soda.berkeley.edu> >In light of the White House getting on the net, how effective do you all think >an electronic petition, about the BigBrotherChip, would be? It appears that they are going to count responses and make totals pro and con any particular issue that people write about. Thus while the particulars of the petition don't really matter, the basic statements against restrictions on encryption technology do. I also heard no mention that they were going to do any kind of sorting by person or email address. Thus it appears that you get to vote early and often in this public opinion poll. Heh, heh, heh. Eric From hughes at soda.berkeley.edu Tue Jun 1 20:58:31 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 20:58:31 PDT Subject: Work the work! In-Reply-To: <64VH5B1w165w@sytex.com> Message-ID: <9306020432.AA20624@soda.berkeley.edu> Paul, you of all people don't need to feel slighted when I urge people to do something, anything, about the wiretap chips. Therefore, let me rephrase my exhortation to the list at large. If you are doing something, continue. If you are not, start. The particulars of what one does are not so nearly important to me as that one does something. Anyone who understands at least one tenth of this list understands more than your average reporter. While I would like all the details to be perfectly accurate everywhere, this is not going to happen. Even if you don't feel like you are an expert, you are more expert than most. With the aid of the documents in the ftp site, and a few hours time, you can become even more expert. > Is there something going on with the EFF that we should know about? The EFF is going to be involved with the cryptography issue. More than that and I defer to John Gilmore, who is on the EFF board and this list and who can speak more authoritatively than I. >I know what you >mean, however, many of the crypto-warriors which may follow do not. It >may be a good idea to _now_ place a broad policy statement. Here is my own very short version of my policy toward the wiretap chips: "The government has no right to restrict my use of cryptography in any way. They may not forbid me to use whatever ciphers I may like, nor may they require me to use any that I do not like." The hypothetical backdoor in clipper is a charlatan's issue by comparison, as is discussion of how to make a key escrow system 'work.' Do not be suckered into talking about an issue that is not important. If someone want to talk about potential back doors, refuse to speculate. The existence of a front door (key escrow) make back door issues pale in comparison. If someone wants to talk about how key escrow works, refuse to elaborate. Saying that this particular key escrow system is bad has a large measure of complicity in saying that escrow systems in general are OK. Always argue that this particular key escrow system is bad because it is a key escrow system, not because it has procedural flaws. This right issue is that the government has no right to my private communications. Every other issue is the wrong issue and detracts from this central one. If we defeat one particular system without defeating all other possible such systems at the same time, we have not won at all; we have delayed the time of reckoning. Trenchantly yours, Eric From ryan at rtfm.mlb.fl.us Tue Jun 1 21:34:12 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Tue, 1 Jun 93 21:34:12 PDT Subject: CryptoStacker Message-ID: Thanks for all of the responses on my questions concerning the CryptoStacker idea. I am kind of sick of talking about it though, and so I went out today and did some research on drivers and such. I am planning to create a software implementation of a PGP driver starting maybe tomorrow (I am being payed real dollars to write other code at the moment) for on-the-fly HD encryption. I haven't quite figured out how to create a commercially distrubutable system yet, but there really is no point sitting around arguing about this and that detail until somebody actually goes out and tries it... I have a feeling that this version will be slow as balls without hardware support, but that's not really the problem, is it? The main focus that I have right now is making the thing work. There have been lots of neat suggestions about multiple layers and suchlike tooalso, which are all fine and dandy, but they kind of missed the point: mainly what I am interested in is preventing access to the data on my HD by anyone but ME, screw LANs and multi-user problems and all of that, I just want to create a system whereby if the Secret Service busts down my door tomorrow while I am not here to throw the drive across the room, they will never be able to fetch out any incriminating evidence by picking apart my system in some lab somewhere. I can also see the advantage of a business worrying about spying, or even government agencies (wouldn't that be ironic) worrying about security and considering networks insecure. Anyway, we can add bells and whistles like network support and multiple layers and suchlike after we figure out how to get the basic engine to work, right? I have also seen everyone suggesting DES instead of PGP. I suppose that would really be a great idea for speed and suchlike, for some reason I was kind of attached to the whole public key idea, but I suppose that would be kind of close-to-worthless in this context, wouldn't it? I suppose we are to the point where I can use some actual technical advice, no need to reinvent the wheel, right? If anyone has any information of the overall architecture of projects like Stacker or DoubleStor, I would appreciate the input. I have used both in the past and I am kind of leaning toward a system like DoubleStor (which maintains directory structures and such, but compresses each file in place) for simplicity, but I am kind of hesitant to leave even a hint of the overall structure of the disk laying around for prying eyes. Trouble is, I don't have much experience screwing around with the FAT and such so I wouldn't want to do anything so bold as munching the entire disk into a single file and suchlike. Any ideas? -Ryan the Bit Wallah From ryan at rtfm.mlb.fl.us Tue Jun 1 21:34:13 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Tue, 1 Jun 93 21:34:13 PDT Subject: Clipper Message-ID: Just out of curiosity, does anyone on the cypherpunks list posess the technical skills that would be necessary to begin a project of hacking out a pin compatible version of the Clipper that didn't have the backdoors once the chip is out, a la AMD and CYRIX? If not, it would seem that we need to get some hardware geeks involved, as well as all of these software people around here, since crypto issues are moving more and more into the hardware, VLSI playing field. ("Cypherpunks write code.... and microcode"??) It would seem that one of the most direct ways to attack Clipper would be to pull another PGP, just create a chip that acts just like one, but a chip that we understand and we designed. There would be totally different problems involved, the Feds could much more easily seize chip production facilities, design would be more difficult, free distribution would be more difficult... I think that it would be quite possible, however. I mean, if an attack is truly to be made on the Clipper, writing letters to feds certainly won't help, the only thing that will help is making their proposal ineffective and uneconomical. Think about it, if a truly secure chip existed, it's sale would be almost certain; all of the 'criminals' that the feds are so afraid of would be sure to find us and buy one, not to mention every self respecting cypherpunk and cyberpunk in the universe, law enforcement agencies might even get into buying black market chips to protect themselves from escrow leaks... Also, if all of these shady types that the feds are using for their tactical arguments have truly secure chips anyway, all of the aformentioned arguments are rendered moot. So I guess the really important question is: does anybody know how to reverse engineer a chip and build a duplicate, pin-compatible device from the ground up while hiding from the feds the whole time and still managing to make a living? I guess that's a pretty rough question, but hey, this is war, right? -Ryan the Bit Wallah From hughes at soda.berkeley.edu Tue Jun 1 21:35:07 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 1 Jun 93 21:35:07 PDT Subject: "Newsweek" Article on Clipper and Encryption In-Reply-To: <9306020156.AA27555@netcom.netcom.com> Message-ID: <9306020508.AA23195@soda.berkeley.edu> I got a call one week ago today (Tuesday May 25th) from Josh Ramo at the science desk at Newsweek. I spoke to him for about an hour on the technicalities and politics of encryption. He was to my pleasant surprise quite able to follow a telephone description of how Diffie-Hellman key exchange works (!) and was quite conducive to my explanation of some of the less public aspects of the clipper project. I think we got extremely good coverage in this article. Here are some of the aspects involved. -- Josh mentioned that he had Dorothy Denning on his list of people to call. She did not get quoted; I did. There's significance to that. -- The pro-crypto quote came first. Kammer's quote, on technical matters, not political ones, came in the middle. The scary ominous 'mandatory standard' quote, from NIST, came last. -- They did not replay the White House line that skipjack is so much harder to crack than DES. I convinced Josh that by iterating DES, the pracatical security of the underlying ciphers was the same, i.e. impenetrable. Thus, no propagation of half-truths. -- The sub-headline is against false cryptography. -- The phrase "civil libertarians and corporations" was used, implying a united front across liberal/conservative lines against this proposal. This phrase was extremely clever on their behalf to avoid specifically mentioning partisan politics. -- The NSA is protrayed as demanding and coercive. First they'll deny government contracts and export licenses, and if that doesn't work, they'll outlaw it. -- Cellular phone are touted as insecure, implying that something ought to be done about that. -- The sidebar has an example of cryptography four millenia old; that's respectable. -- The article does not play up the escrow aspects of the wiretap chip. Their simplification, that the government has your key, attains the root issue without confusion. -- They mention that the keys wil have to be stored on computers, and are thus vulnerable. This a point I made specifically to Josh, and they took my example of foreign intelligence and *expanded* on it. --They mention that NIST worked on the algorithm with the NSA. All in all, I don't think we could have hoped for better. There's just about nothing flattering said about the wiretap chip, and plenty of things against it. The article is about as anti-Clipper as you might expect given that Newsweek does not want to appear too partisan one way or another. Eric From greg at ideath.goldenbear.com Tue Jun 1 22:14:46 1993 From: greg at ideath.goldenbear.com (Greg Broiles) Date: Tue, 1 Jun 93 22:14:46 PDT Subject: Term software development/design Message-ID: <5y6H5B1w164w@ideath.goldenbear.com> -----BEGIN PGP SIGNED MESSAGE----- Re development of crypto term software for PC and/or Unix platform(s): It seems like there are three general ways to approach this problem: 1. Offline reader style - ala QuickMail and its cronies - popular with DOS BBS's. 2. Waffle/UUPC style. 3. As an actual term program, but with an intelligent scrollback buffer/ASCII send module added. I have, several times, wished for a "guerilla offline reader" - a reader to collect all of the messages in all of the newsgroups (from my .newsrc file) that I read on some arbitrary Unix box, collect them into a file, compress it, and send them to my PC with Zmodem, so that I can browse at my leisure. Waffle/UUPC and a newsfeed is a better solution, but requires the cooperation of one's local sysadmin, who isn't necessarily interested in feeding someone news at 2400 bps. The ironic thing is that they don't care if you spend 4 hrs/day using that modem to read news - they just don't want you to tie it up for 45 mins with a small newsfeed. (Yes, there is the spool directory problem - and no, I don't think a flamewar about admins is useful here.) If we/I did something like this - it ought to be possible to do it in a shell script, or shell script + awk - and incorporated the means to receive/unpack a reply packet - I think it might be a good thing. The basic idea is to expand the access one's got via a networked Unix box to one's home machine, without necessarily requiring the permission or knowledge of local sysadmins. (No, I am not unfamiliar with the plight or circumstances of an arbitrary Unix sysadmin. I administrate a small system now, have been in charge of larger ones in the past, and have some experience with users doing peculiar and squirrely stuff with one's machine. :) I also don't think that what I'm proposing breaks either the letter or the intent of a reasonable security policy - but it is the sort of thing to make a control freak sysadmin go nuts.) Seems like the best way to implement the term program would be to add some intelligence to the "scrollback" (a buffer that holds the last 'n' lines of text appearing on the screen) which would allow it to find, extract, and process the --- BEGIN PGP SIGNATURE --- bits. The other side of this would be a process which would, given the name of a file on disk (or an editor buffer) locally, process it (sign,encrypt,whatever) and upload the results. This would be interesting, but I dunno if we'd be able to write something nice enough to become as widespread as Telix, Procomm, or whatever. (I also wonder if it's possible to add hooks to Telix/Procomm to do similar stuff.) For what it's worth, I have experience in C, and have fooled around with little assembly programs to read/write the PC's serial port on an interrupt-driven basis. (The use of a FOSSIL driver seems intelligent here, though.) I have written a PGP keyserver to run as an attachment to a DOS Waffle system, and intend to expand and improve that if I can get some free time. I'm interested in working on this stuff but am less interested in re-inventing any wheels. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAw+f33YhjZY3fMNAQHdTAQAr9sk4WdPxC/Bz8i5tEZ/ammwaUt6rEtL 13wMPT+L9JXGrgMNoey6EGjmrHXH9C0DweXGhPYIzq9U8EW9xmsacwEPets+sVJv T90gM/+aeQkixgRb93FIqIpCnRVzF9lQcin0v4e69s6mMk0y6WTQMEJkDXbKvKTM lCK6WBakWws= =QCej -----END PGP SIGNATURE----- -- Greg Broiles greg at goldenbear.com Golden Bear Computer Consulting +1 503 465 0325 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764 From julf at penet.FI Tue Jun 1 22:16:24 1993 From: julf at penet.FI (Johan Helsingius) Date: Tue, 1 Jun 93 22:16:24 PDT Subject: In-Reply-To: <9306011855.AA08017@toad.com> Message-ID: <9306020831.aa08455@penet.penet.FI> > Look at what happened to Julf. His machine > was safe, sitting in a back room of his house. They went after his net > feeds instead. A quick update: Telecom Finland finally delivered. My uncontrolled, no-AUP IP connection via EUnet (Copenhagen-Amsterdam-Alternet) went operational yesterday. The new 486 box also arrived. Expected to go into 100% service this weekend! Julf From smb at research.att.com Tue Jun 1 22:39:22 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 1 Jun 93 22:39:22 PDT Subject: WH email petition. Message-ID: <9306020539.AA25821@toad.com> In light of the White House getting on the net, how effective do you all think an electronic petition, about the BigBrotherChip, would be? Do you think that they would listen? Do you think that, perhapse, we would simply be put on a list of "trouble makers?" I was thinking of writting a petition and distributing it in every way I can think of, and encouraging people to send it to the White House. Any comments? In general, petitions are a notoriously ineffective way to lobby. That's doubly so for email versions, for obvious reasons. Even without that problem, an electronic petition will (rightly) be ignored on the grounds that it represents the opinions of a small elite minority. With signatures collected in the streets and shopping malls of America, you have at least some chance of reaching a cross-section of people. But on the net? (And even if I'm wrong about the net's population, would they know it?) As for a trouble-maker list -- not likely. Apart from the political hell there'd be to pay if word ever leaked (the right to complain to the government is quite explicit in the Constitution, and is legally far stronger than the still-controversial right to privacy (remember Bork?)), I haven't seen any evidence that broad-scale ``enemies lists'' have been collected since Nixon's day. That may, of course, mean they've just gotten smarter about how they do it... Based on my past experience, your name will be collected -- but just as a person interested in certain issues, so that you can be solicited for funds on certain issues. --Steve Bellovin From anton at hydra.unm.edu Tue Jun 1 23:10:13 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Tue, 1 Jun 93 23:10:13 PDT Subject: Term software development/design In-Reply-To: <5y6H5B1w164w@ideath.goldenbear.com> Message-ID: <9306020647.AA20551@hydra.unm.edu> All of these ideas (on new term programs for grabbing news, and for getting PGP sigs from scrollback, etc etc) are all very interesting and worthy of more work. However, I think the BEST way to do this, is to convince Mustang Software (or whoever) to add hooks for PGP or other encryption packages, and then the rest should soon follow. Most users WILL NOT quit using QModem (or whatever) for a new term program that has nothing special but crypto. BUT if you can get crypto into the popular packages, then lots of users WILL use it since well it's THERE, and easy to get to and they don't have to switch software. As for the creation of new term programs, I'd have to say making it RELY on a FOSSIL driver is a BAD idea. FOSSILs are becoming less useful and needed over time. Almost NO new door software uses FOSSILs, because companies like Compaq are making more-compatible machines with less proprietary garbage in them. FOSSIL support that is OPTIONAL would be very nice, for those using old or wierd machines that can't handle standard comm routines, but forcing FOSSIL (or anything else) on anyone is a bad idea in my opinion. Also, those into Fido-tech netting should try to get the developers of FrontDoor, InterMail, D'Bridge, Opus, Maximus, VBBS, BinkleyTerm, etc to add support for the ^ENC klugeline (an addition to the FTSC-standard Fido mail headers, that notifies mailer software that the message is encrypted, so it can be properly processed). Without this the Fido SecureMail system is going to remain minor and ignored. With it, cryptomail could fast become the norm in Fido NetMail. For this corner or cyberspace direct support for this sort of thing could be the "make or break" for whether crypto becomes accepted. Just some thoughts. -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From mdiehl at triton.unm.edu Tue Jun 1 23:12:47 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 1 Jun 93 23:12:47 PDT Subject: WH email petition. In-Reply-To: <9306020408.AA19558@soda.berkeley.edu> Message-ID: <9306020649.AA28007@triton.unm.edu> > It appears that they are going to count responses and make totals pro > and con any particular issue that people write about. Thus while the > particulars of the petition don't really matter, the basic statements > against restrictions on encryption technology do. > > I also heard no mention that they were going to do any kind of sorting > by person or email address. Thus it appears that you get to vote > early and often in this public opinion poll. Do you think they'd TELL you that they were putting people on lists? Not OUR government.... +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From ryan at rtfm.mlb.fl.us Tue Jun 1 23:16:39 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Tue, 1 Jun 93 23:16:39 PDT Subject: WH email petition. In-Reply-To: <9306020313.AA20120@triton.unm.edu> Message-ID: On Tue, 1 Jun 1993, J. Michael Diehl wrote: > In light of the White House getting on the net, how effective do you all think > an electronic petition, about the BigBrotherChip, would be? Do you think that > they would listen? Do you think that, perhapse, we would simply be put on a > list of "trouble makers?" I was thinking of writting a petition and > distributing it in every way I can think of, and encouraging people to send it > to the White House. Any comments? A good idea, but it appears from the announcement that they are just going to create a database of return addresses and subject lines and sit around and read that instead of reading the actual messages. In that case I would suggest a well written form letter that we could encourage people to forward to the address with their names on it. That way after they see the same subject line 12,000 times they might get the slight urge to read the message going along with it. That would be kind of equivalent to a petition. Somebody good at slicking politicos like to draft a nice letter? -Ryan the Bit Wallah From ld231782 at longs.lance.colostate.edu Tue Jun 1 23:24:34 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Tue, 1 Jun 93 23:24:34 PDT Subject: whistle for Whistleblowing! Message-ID: <9306020701.AA03726@longs.lance.colostate.edu> >A quick update: Telecom Finland finally delivered. My uncontrolled, >no-AUP IP connection via EUnet (Copenhagen-Amsterdam-Alternet) went >operational yesterday. The new 486 box also arrived. Expected to go >into 100% service this weekend! Oh, the bright sun is shining through! This is absolutely perfect timing. I just ran rn and what did it have to report? alt.whistleblowing not in .newsrc -- Add unsubscribed? Cypherpunks, alt.whistleblowing has been created! Special thanks to Miron Cuperman, a First Class Grade A Cypherpunk, who took care of the electronic paperwork on this one after reading my desperate posting(s). (I don't understand though, at my site it didn't appear for over a week since the control message was sent out.) If it's not at your site send mail to your news administrator and ask if there's some kind of conspiracy going on to prevent you from seeing it :) I generally *don't* recommend that the Mycotronx postings be sent there (yet), even if someone can set up an untraceable path. I talked to the poster today and he has many plans for them that might be disrupted by any further publicity. In fact, he told me he *accidentally* posted them to the cypherpunks list! He thought it would just go to the `moderator' (Eric Hughes). Explains a bit. Watch for a FAQ to the group (possibly here first) and advertisements in other groups. Also: HOW TO CONTRIBUTE IMMEDIATELY. Find relevant material from any groups you have ever visited and FORWARD IT. Make sure to be very thorough in citing the source and background of the posting. Let the games begin! The doors are open! Fire away, soldiers! p.s. If anyone wants to run an interesting and critical project, I think that the `control' group should be monitored for message cancels in alt.whistleblower, cancelling parties should be *exposed*, and the cancelled postings in particular should be *preserved*. From nobody at soda.berkeley.edu Tue Jun 1 23:30:32 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Tue, 1 Jun 93 23:30:32 PDT Subject: Software infrastructure Message-ID: <9306020704.AA01148@soda.berkeley.edu> -----BEGIN PGP SIGNED MESSAGE----- Subject: Software infrastructure I like Eric's idea of a terminal program which can support encryption easily. Here are some thoughts. As Eric indicates, the issue is not so much building encryption into the program but rather of having _hooks_ by which extra functionality can be added. Encryption should be just one capability. Another might be to automatically drop into a stand-alone zmodem package like dsz or gsz so we don't have to re-implement zmodem ourselves. We had some related discussion on this last year when we were talking about the "crypto dongle". This was going to be a black box which would sit on the serial line between your PC and modem (or terminal and host computer) and would do encryption/decryption as the characters passed through it. Doing it in the terminal program, I could envision a hook which watched constantly for particular strings to be received from the host, like "-----BEGIN PGP MESSAGE-----". Several such watchdogs could be active at once. When one of them matches, it fires off a program. Or perhaps it just starts logging the incoming data to a file, and when it matches another string it fires a program. A simple scripting language could control these activities. The result would be that when you receive an encrypted message, you just list it out to your terminal and then, automatically, PGP fires up and asks you for your pass phrase (unless you SET it ahead of time in the PC's environment). It then displays the message for you. This simple model has several deficiencies. When I log into a Unix system, or Compuserve, or Portal's "Online" service, and read my mail, it is often shown to me a page at a time. This is so that I can read long messages more easily. Then after each message I can delete it, save it, reply to it, etc. If I do reply or if I want to create a new message it will drop me into a text editor to compose the message. The result is that the mail program you are running on the host computer may do some munging on the PGP message, like inserting "Press RETURN for next page" or perhaps some terminal control characters. These would have to be filtered out before PGP could run on the file, or you would have to be able to suppress them when you read this message. Also, assuming we could capture the message and run PGP on it automatically, the resulting decrypted message will have to be saved and given a file name. Then if the user wants to reply to it he is going to have to leave his terminal and run an editor. (At least, that's what I have to do now.) Plus, this only deals with the message-receiving problem, not the sending problem. I'm not sure what the solution is. Maybe the PC program needs to be more than a terminal program, and become more of a whole mail-processing program. Maybe you should just download your mail file en masse from the host to your PC, pre-process it to replace (in place) the incoming encrypted messages with plaintext versions (annotated to show validated signatures), then run a PC program which will display one message at a time, let you reply, save, etc. This way the decryptions are done before you even look at the mail file and incoming encrypted mail is treated on a first class basis (the same as other mail). Then for outgoing mail you'd like to be able to drop into a user-defined editor which is run with a command line causing his file to be saved to some temp file name. Then we can automatically encrypt the outgoing mail for him based on the destination, add a remailer chain if requested, etc. Then he gives a command and all his replies and new mail are uploaded and sent. This would be pretty tough to do since there are so many different ways of sending and receiving mail on host computers. This would again have to be a customizable part of the program, where we could provide modules to deal with the common cases of Unix running "mail", elm, mh, etc., and perhaps some of the commercial services. BBS's would ideally be handled as well. Hackers could contribute scripts for supporting their favorite mail system. I don't know anything about SLIP, or POP, or any other fancy ways of hooking a PC up to a workstation. I just use it as a terminal. Would these other protocols help solve the problems above, problems of how we marry an encryption program which must run on the PC with mail-handling programs which run on another computer? Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAwkEagTA69YIUw3AQEuxQQAjeC/gwPHkLQZ0IladVRxiRdgARdE7ziu WWdmsHpaZ2tlq8wAXpSFbMpSZ3MS1U1TT/c/wB2DJOCuWkhs2y6WYoZiqrHz3hjA JyBSkpM1F3dYcZ8MchrjLZsur9KwXe0mIvM7VMu2Fdq+sMMgNwzEzqJoWhulAsnl weuBaeOjv7k= =zEUv -----END PGP SIGNATURE----- From mdiehl at triton.unm.edu Tue Jun 1 23:34:48 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 1 Jun 93 23:34:48 PDT Subject: WH email petition. In-Reply-To: Message-ID: <9306020712.AA28617@triton.unm.edu> > A good idea, but it appears from the announcement that they are just going > to create a database of return addresses and subject lines and sit around > and read that instead of reading the actual messages. > > In that case I would suggest a well written form letter that we could > encourage people to forward to the address with their names on it. That > way after they see the same subject line 12,000 times they might get the > slight urge to read the message going along with it. That would be kind > of equivalent to a petition. YES! I may have been unclear in my presentation, but this is what I had in mind! Comments? > Somebody good at slicking politicos like to draft a nice letter? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From rclark at nyx.cs.du.edu Tue Jun 1 23:40:24 1993 From: rclark at nyx.cs.du.edu (Robert W. F. Clark) Date: Tue, 1 Jun 93 23:40:24 PDT Subject: My letter to the President, for all the good it'll do Message-ID: <9306020717.AA03191@nyx.cs.du.edu> Well, this and fifty cents will get you a cup of coffee, but here's my letter to the Pres. ------ I oppose the Clipper chip vehemently. As the President, or the duly authorized representative of the President, you will understand that I find the idea that you will monitor my communications reprehensible and intolerable. You have espoused a policy of covert surveillance of American citizens of which Bush would be proud. You, a protester of the Vietnam War, who understands that the government can, and should be opposed when it is wrong, should understand why privacy is necessary to the people of any democracy, lest it cease to be a democracy. Nevertheless, you approved the Clipper Chip proposal, which is the furthest step backward that even a politician could take. Shame on you! Even George Bush's father, Prescott Bush, who despised and opposed Senator McCarthy's Communist witch-hunt, would loathe such a retrogressive move! We computer professionals, who supported your rise to power, feel betrayed by your sudden reversal, by no means unique among your sudden reversals. By siding with those who would rob Americans of those freedoms which are our inalienable right, you have betrayed democracy and made a sham of the Bill of Rights. If, as a White House official suggested, criminalizing alternative, secure encryption standards is an "option on the table," I am disgusted by your betrayal. You, who seemed proud to have protested an unjust war, and should understand why protest, even anonymous protest, should be an inalienable right, have no right even to consider this as an option. If you consider criminalizing privacy, and encryption, you have signed over the soul of the nation to be monitored at will by the NSA and CIA, organizations which you, at one time in your life, opposed. Perhaps, like many Sixties rebels, you have been bought by the government, and no longer care about the rights of the American people. It would not be the only time this has occurred. While I doubt that you, the President, shall read this, perhaps some subordinate shall. Perhaps, if the miraculous is possible, that subordinate shall deem this worthy of your consideration. While I am not used to pleading, I plead that you reconsider this policy, which, if enacted, would doom privacy in the United States, and turn this nation into the sort of nation that the Soviet Union has finally decided not to be. I beg that you consider, at least for a moment, the evil that you may unleash. You may be motivated by an understandable concern for the protection of the American people from drug dealers and mobsters, but it is not the mobsters you shall crush in supporting the Clipper chip. It is those eager, agile young minds who oppose the government when it is wrong, and only wish to be able to have their voice, without being monitored by the CIA and NSA in case that voice occasionally is overly strident. Thank you, Mr. President. I hope that you have carefully studied the holy Consitution of this nation, which you have sworn to uphold. I fear for the consequences if you have not. Robert W. F. Clark 440 S. Franklin St. Bloomfield, IN 47424 Telephone # (812) 384-3465 email addresses: clark at metal.psu.edu rclark at nyx.cs.du.edu  From clark at metal.psu.edu Tue Jun 1 23:45:22 1993 From: clark at metal.psu.edu (Clark Reynard) Date: Tue, 1 Jun 93 23:45:22 PDT Subject: How about it? My letter to the Pres Message-ID: <9306020801.AA03786@metal.psu.edu> What about some form of my letter as the form letter petition? Not as critical as I was, of course. But STRESS issues he used in his campaign (Prescott Bush, opposing Vietnam); and maybe one of his flunkies will have the smarts to cope with it. The email response for the form letter from postmaster at whitehouse.gov was very fast, so they have put money into it. Maybe they actually DO give a damn. Try it. ---- Robert W. Clark Just Say No! to the rclark at nyx.cs.du.edu Big Brother Chip From mdiehl at triton.unm.edu Tue Jun 1 23:49:17 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 1 Jun 93 23:49:17 PDT Subject: Term software development/design In-Reply-To: <9306020647.AA20551@hydra.unm.edu> Message-ID: <9306020726.AA29102@triton.unm.edu> > All of these ideas (on new term programs for grabbing news, and for > getting PGP sigs from scrollback, etc etc) are all very interesting and > worthy of more work. However, I think the BEST way to do this, is to > convince Mustang Software (or whoever) to add hooks for PGP or other > encryption packages, and then the rest should soon follow. Most users > WILL NOT quit using QModem (or whatever) for a new term program that has > nothing special but crypto. BUT if you can get crypto into the popular > packages, then lots of users WILL use it since well it's THERE, and easy > to get to and they don't have to switch software. Actually, I've implimented much of this in telix, using it's (C-like) script language. From the command line, I can type in the name of a batch file. That batch file starts telix, logs me in, sends any mail I have created/encrypted on my machine, and downloads all my new mail, to be read from another batch file. My mail reader batch file uses pgp to read my mail and presents a nice message selection menu, too. Totally transparent, and automated. I'm quite prowd of it. The only thing to do is clean it up a bit, and impliment reply-quoting. That should be done by the end of the week. If any one is interested in what I have.....ask me. BTW, I have had a few bug reports on my pgp menu batch file for 4dos. I will also have it fixed by the end of the week and will release it next week. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From greg at ideath.goldenbear.com Tue Jun 1 23:49:54 1993 From: greg at ideath.goldenbear.com (Greg Broiles) Date: Tue, 1 Jun 93 23:49:54 PDT Subject: EFF, AT&T, Clipper, and $ Message-ID: Eric Hughes writes: > The EFF is going to be involved with the cryptography issue. More > than that and I defer to John Gilmore, who is on the EFF board and > this list and who can speak more authoritatively than I. The 5/24/93 issue of "The New Republic" has a (largely uninteresting) cover story about Mitch Kapor and the EFF. One interesting tidbit gleaned from that article, however, was that AT&T has contributed money to the EFF. I am particularly curious to see how AT&T and the EFF will deal with each other with respect to the Clipper chip, and the politics around that. If anyone knows anything more about this, I'd love to hear it. -- Greg Broiles greg at goldenbear.com Golden Bear Computer Consulting +1 503 465 0325 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764 From mdiehl at triton.unm.edu Wed Jun 2 00:01:22 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 2 Jun 93 00:01:22 PDT Subject: Software infrastructure In-Reply-To: <9306020704.AA01148@soda.berkeley.edu> Message-ID: <9306020738.AA29392@triton.unm.edu> > Subject: Software infrastructure ...other good stuff deleted...I read mail at 2400B. > The result would be that when you receive an encrypted message, you > just list it out to your terminal and then, automatically, PGP fires up > and asks you for your pass phrase (unless you SET it ahead of time in > the PC's environment). It then displays the message for you. > > This simple model has several deficiencies. When I log into a Unix system, > or Compuserve, or Portal's "Online" service, and read my mail, it is often > shown to me a page at a time. This is so that I can read long messages > more easily. Then after each message I can delete it, save it, reply to > it, etc. If I do reply or if I want to create a new message it will drop > me into a text editor to compose the message. > > The result is that the mail program you are running on the host computer > may do some munging on the PGP message, like inserting "Press RETURN for > next page" or perhaps some terminal control characters. These would have > to be filtered out before PGP could run on the file, or you would have to > be able to suppress them when you read this message. If we are talking about an off-line reader, this is solved by a trivial filter routine. If you want to do this on-line, well it might take time. > Also, assuming we could capture the message and run PGP on it automatically, > the resulting decrypted message will have to be saved and given a file > name. Then if the user wants to reply to it he is going to have to leave > his terminal and run an editor. (At least, that's what I have to do now.) Why save the plaintext? I keep it in cyphertext and decrypt it on demand. And when I want to reply, then I decrypt it, quote it and have the user edit that file, which will presumably be re-encrypted. > Plus, this only deals with the message-receiving problem, not the sending > problem. Actually, these are the same problems in different clothes. > > I'm not sure what the solution is. Maybe the PC program needs to be more > than a terminal program, and become more of a whole mail-processing > program. Maybe you should just download your mail file en masse from the > host to your PC, pre-process it to replace (in place) the incoming encrypted > messages with plaintext versions (annotated to show validated signatures), > then run a PC program which will display one message at a time, let you > reply, save, etc. This way the decryptions are done before you even look > at the mail file and incoming encrypted mail is treated on a first class > basis (the same as other mail). > > Then for outgoing mail you'd like to be able to drop into a user-defined > editor which is run with a command line causing his file to be saved to > some temp file name. Then we can automatically encrypt the outgoing mail > for him based on the destination, add a remailer chain if requested, etc. > Then he gives a command and all his replies and new mail are uploaded and > sent. These last 2 paragraphs describe almost exactly what my scripts do! > This would be pretty tough to do since there are so many different ways > of sending and receiving mail on host computers. This would again have > to be a customizable part of the program, where we could provide modules > to deal with the common cases of Unix running "mail", elm, mh, etc., and > perhaps some of the commercial services. BBS's would ideally be handled > as well. Hackers could contribute scripts for supporting their favorite > mail system. I find that I need to be a bit more modular with my scripts so that I can call a different module depending on which type of system I'm on...Working on it at this moment. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From nobody at soda.berkeley.edu Wed Jun 2 00:10:53 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Wed, 2 Jun 93 00:10:53 PDT Subject: Another chaining utility Message-ID: <9306020744.AA02666@soda.berkeley.edu> I am working on a utility I call "chain" which is inspired by Karl Barrus's hopmail and related scripts. I am sending this message with the command: chain -m -s "Another chaining utility" cypherpunks at toad.com caltech jarthur extropia soda The "-m" means for chain to pipe its output into sendmail so that it is actually sent (otherwise it just writes to standard out and you have to arrange to mail it on your own). The "-s" sets the subject for the last leg of the message to the following arg. Then comes the destination address, then a list of remailer nicknames, which are just substrings of the remailers, read from an initialization file. This message is passing through four remailers. The "-m" feature is implemented only on Unix systems. On DOS you always get the output in a file and then send that however you normally would. I also have a "-e" switch which encrypts the message using a public key looked up by the destination address. Cypherpunks doesn't have a public key so that's not appropriate here. But if I wanted to send an encrypted note to, say, Phil Zimmermann, I could just do: chain -em prz at sage.cgd.ucar.edu portal mead Hi, Phil, give me a call when you have a chance -- Hal ^D and it would go via the Portal and Mead remailers, encrypted at each step, and finally to Phil, encrypted with his public key. Pretty easy. I couldn't get Karl's hopmail.bat to run on my PC (not enough environment space?) so I wrote this in C and it works OK. I'll be sending the code to Eric to be archived in a few days. If anyone has any wish lists for features I will be glad to try adding them. (I am composing this on a Unix system in order to demonstrate the -m switch, so I can't cleartext sign as I normally would. I am in the vi editor and I am sending the message with "1G!G", which tells vi to pipe the whole file into a command, followed by the "chain" command line above, verbatim. That's all there is to it.) Hal Finney 74076.1041 at compuserve.com From anton at hydra.unm.edu Wed Jun 2 01:06:35 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Wed, 2 Jun 93 01:06:35 PDT Subject: GIMME YOUR GOODIES! Message-ID: <9306020843.AA25624@hydra.unm.edu> NitV is still hoarding all sorts of PGP utils for any and all platforms, mail systems, and potential uses. If you make anything new, please send it along (uu it, or upload it to the board, or whatever). I get QUITE a few calls for such material (suprisingly much of the Unix stuff is downloaded, and long distance at that, so I guess there is a lot of value in having a BBS-based, multi-platform crypto-tools site.) I MUCH prefer to get the new material direct from the author, so please do send it!! Help spread crypto to the OtherNets! -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From mark at coombs.anu.edu.au Wed Jun 2 02:39:39 1993 From: mark at coombs.anu.edu.au (Mark) Date: Wed, 2 Jun 93 02:39:39 PDT Subject: FYI: White House Mail Message-ID: <9306020939.AA03615@toad.com> > President Clinton Vice President Gore > > PRESIDENT at WHITEHOUSE.GOV VICE.PRESIDENT at WHITEHOUSE.GOV Hmm, 10 bucks says some larrikin sends fakemail from PRESIDENT to VICE.PRESIDENT asking him 'what this little red button does' etc. Though in real.life I suspect 10 press secretaries sitting behind the mail alias. They're going to need them. Lets hope no one is stupid enough to try busting into there... Mark mark at coombs.anu.edu.au From mark at coombs.anu.edu.au Wed Jun 2 03:56:14 1993 From: mark at coombs.anu.edu.au (Mark) Date: Wed, 2 Jun 93 03:56:14 PDT Subject: Crypto anarchy in a VW? (not the bug) Message-ID: <9306021056.AA05648@toad.com> >Another possibility until then, and one that would be fun for people who >like to play with EPROMS, is a card that had a cable leading to an external >EPROM socket that you could lay on your desk or on top of the case or >wherever. You burn your keys for the HD into a chip and use it as a key, >physically inserting the chip in the socket each time. There are lots >on new ways to make chips easy to plug in and out, I'm sure it wouldn't >be too hard. Heh, I have a system liek this, designed by Viglen in the UK. It was/is originally from the BBC micro to allow easy use of swapping over 'sideways' ROMS instead of opening the case. It's basically a ribbon cable with a 28way rom socket on the end with a edge connector socket on the other. Each ROM is enclosed in it's own sturdy tiny black package with an edge connector that slots into the socket that is mounted in the 'ashtray' of the Beeb. You could easily copy the idea with a rom socket, a length of ribbon cable and a ZIF socket to allow easy usage. The Viglen has pin protection so you dont spike the thing, so it's able to be used on the fly without power cycling. One thing about ROM's, they're faster than disks....easier to hide too :) >I still don't see why all of the actual encryption couldn't be done in >software though... Me either, apart from TEMPEST issues...Linux comes with slot in file system modules (as detailed in a letter to Jim) that you can easily adapt to your own uses. Ive been playing around with this idea for a while. Adding a desfs(tm) (me :) to a linux kernel is not going to be that hard I think.. (touch wood). Mark mark at coombs.anu.edu.au "liek", "smiel" and "soar" are derivatives of JenSpeak(tm). Spread the word. From pfarrell at cs.gmu.edu Wed Jun 2 05:17:31 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Wed, 2 Jun 93 05:17:31 PDT Subject: Software infrastructure Message-ID: <32140.pfarrell@cs.gmu.edu> In Message Tue, 1 Jun 1993 22:13:48 -0500, Eric Hughes wrote: >Let's go back to the DOS-as-terminal issue. The politics and >economics of DOS shareware is such that source code is almost never >made available. > >I propose that interested cypherpunks write a DOS terminal program >which _is_ free software. I think writing a "terminal" program, such as Kermit, is not particularly useful. I am writing a SMTP/POPPER client program that will work over standard serial (dial-up) lines. It will not require SLIP, PPP, or any other magic (mostly because getting _my university_ to provide competent TCP/IP access is impossible). Enhancing it to support SLIP or PPP will be simple, but it is not the market that I'm aiming at. Clearly any decent mail client has to have a roledex of commonly accessed coorespondents. It is trivial to enhance the data structure to add a flag that says "Use encryption" and another with "PGP (or RIPEM) key available" and another to hold a handle (PGP's 0x123456) that identifies the key. Spawning your favorite encryption program is then also trivial. The audience is not the cypherpunks. The audience for strong cryptography is the art, history, econ or english major. It has to be "pig easy" and reliable. My program is written for Windows. Like it or not, Windows has 80% or more of the total computers being sold. I want my mailer client to reach mass markets. The program will be free, and sources will be available under some restrictions that I haven't yet figured out. In a while, I'll be looking for beta testers. Pat Pat Farrell Grad Student pfarrell at cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From dmandl at lehman.com Wed Jun 2 06:07:06 1993 From: dmandl at lehman.com (David Mandl) Date: Wed, 2 Jun 93 06:07:06 PDT Subject: WH email petition. Message-ID: <9306021344.AA16267@disvnm2.shearson.com> > In general, petitions are a notoriously ineffective way to lobby. > That's doubly so for email versions, for obvious reasons. Even > without that problem, an electronic petition will (rightly) be ignored > on the grounds that it represents the opinions of a small elite > minority. With signatures collected in the streets and shopping malls > of America, you have at least some chance of reaching a cross-section > of people. But on the net? (And even if I'm wrong about the net's > population, would they know it?) > --Steve Bellovin In general, I agree that petitions are a major waste of time and energy; I'm also pretty convinced that this White House email link is a big scam. Why are they any more likely to take your mail seriously just because it comes over the phone lines and not in an envelope? Seems like a pretty transparent PR ploy (also an attempt to make it seem like the White House isn't a bunch of dinosaurs now that everybody and her nephew has an email address). But since it won't take much more than a couple of minutes of any of our time, I can't see an electronic petition hurting our cause any--especially because it'll certainly include the names of many esteemed professionals and braniacs with fancy scientific, corporate, and academic credentials. I think this could be a nice propaganda coup if it got publicised. It could at the very least give a big black eye to the forces of evil. --Dave. From hughes at soda.berkeley.edu Wed Jun 2 06:39:06 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 2 Jun 93 06:39:06 PDT Subject: ADMIN: incoming ftp site works now Message-ID: <9306021412.AA13469@soda.berkeley.edu> I've arranged so that the pub/cypherpunks/incoming directory will accept uploads now. So if you have stuff to send, please ftp it to that directory rather than using e-mail. Of course, if you don't have ftp access, please continue to use email. For those of you who tried this before, the problem was that the wuarchive ftpd that the system was running needs a line in its configuration file to say that uploads are peritted in a directory. Eric From hughes at soda.berkeley.edu Wed Jun 2 06:51:21 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 2 Jun 93 06:51:21 PDT Subject: Term software development/design In-Reply-To: <9306020647.AA20551@hydra.unm.edu> Message-ID: <9306021425.AA13721@soda.berkeley.edu> >As for the creation of new term programs, I'd have to say making it RELY >on a FOSSIL driver is a BAD idea. The reason to use FOSSIL, and it is a sufficiently strong reason, is that with some layer of abstraction at that low level, you can't do end-to-end link encryption transparently. For example, if you want to do a download over a secure channel, if you have to use an external protocol, and if that protocol talks directly to the serial port, then you can't use it, because the protocol will see only gibberish. If, on the other had, the protocol driver uses FOSSIL, and if your FOSSIL can set up an encrypted channel, then the protocol will perform as expected without being aware that it's underlying connection is encrypted. >Almost NO new door software uses FOSSILs, because >companies like Compaq are making more-compatible machines with less >proprietary garbage in them. The reason to use FOSSIL is not compatibility, but abstraction. It's the only abstraction for serial communications the PC has, and we'd better take advantage of it. Eric From hughes at soda.berkeley.edu Wed Jun 2 07:12:49 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 2 Jun 93 07:12:49 PDT Subject: Software infrastructure In-Reply-To: <9306020704.AA01148@soda.berkeley.edu> Message-ID: <9306021446.AA14130@soda.berkeley.edu> Let me clarify the discussion here about PC terminal software. There are two distinctions I'd like to make. The first distinction is between a terminal program and a mail/news reader. Terminal access is necessary so that all functions of the dialup service which are not mail/news can still be accessed. An integrated mail/news reader is desirable because this is a primary activity of many users. Ideally, you want both. The second distinction is between stream and file encryption.If you want to encrypt the underlying channel, you need a stream cipher and a D-H key exchange. If you want file encryption, you want a block cipher and public keys for communications. These two distinctions are correlated. The terminal nature of such software requires support for stream encryption. The mail nature of such software requires file encryption. PGP is a file encryptor, not a stream encryptor. You can't use PGP for the terminal line; you can you it for email. >As Eric indicates, the issue is not so much building encryption into the >program but rather of having _hooks_ by which extra functionality can be >added. One useful discussion would be to examine just what hooks are desirable. The capability 'encryption' is too broad; one needs to specify just what variety and what purpose is desired. Re: dealing with mail software intended for humans. >The result is that the mail program you are running on the host computer >may do some munging on the PGP message, like inserting "Press RETURN for >next page" or perhaps some terminal control characters. It is for exactly reasons like this that one of the hooks should be an ability to specify how one gets one's mail. For Unix, I would suggest POP, as Paul Ferguson has mentioned. For online services like compuserve, aol, etc., a separate protocol which spoofs their mail readers into sending you your mail en masse could be written. This also implies the existence of offline mail readers. >Plus, this only deals with the message-receiving problem, not the sending >problem. Trying to spoof a whole mail system on a terminal seems doomed. Offline readers are the way to go. >Then for outgoing mail you'd like to be able to drop into a user-defined >editor which is run with a command line causing his file to be saved to >some temp file name. What editor you use is another hook. I use Desqview, and I love to be able to spoof Desqview into spoofing my editor (which is _always_ running) into editing my reply. So the hook has to be a bit more flexible that running an executable. Eric From pmetzger at lehman.com Wed Jun 2 07:57:59 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Jun 93 07:57:59 PDT Subject: Electronic Contracts In-Reply-To: <9306020055.AA13186@hydra.unm.edu> Message-ID: <9306021534.AA04636@snark.shearson.com> Stanton McCandlish says: > Regarding "test cases" for digital signatures, not sure if this is 100% > relevant but what the hell... > > In this area at least, when the UPS folk bring you a package that you > must sign for, you no longer sign on paper, but on this funky electronic > tablet. Now granted this thing is recording your "real" signature, and > thus differs greatly, but still there may be something to this. Not sure > where one would look for material having to do with such devices, and > their relevance to a court case, but then again no one pays me legal > consulting fees either. >:) Caveat: I'm not a lawyer. In common law, anything you want and intend to be your signature is your signature. Ever work for a very big company? Ever look at your paychecks? They are rubber stamped with someone's signature, not signed. Still, thats perfectly legal. In contract law, contracts do not have to be written -- being written just means that the court has a presumption that the terms of the contract were as written. However, you can make contracts orally if you wish, and they are enforceable provided you can convince a court that the contract really was made. Assuming that you sign a contract with digital signatures, and the court can be made to understand that the digital signatures mean no forgery was possible, its likely a court would enforce them because the court would then have reason to believe that both parties agreed to the contract in question. Repeating my caveat: I'm not a lawyer. Perry From mmidboe at cs.uah.edu Wed Jun 2 08:10:54 1993 From: mmidboe at cs.uah.edu (digital saint Computer Science Dept., Univ. of Alabama-Huntsville) Date: Wed, 2 Jun 93 08:10:54 PDT Subject: Software infrastructure In-Reply-To: <9306021446.AA14130@soda.berkeley.edu> Message-ID: <9306021548.AA19002@uahcs2.cs.uah.edu> If you want the other software developers to pick up encryption then you had better put it into some kinda kit or TPU. That is the easiest way to get those other people like Mustang Software to add hooks into their software. If you distributed some kind of TPU to add onto Async Pro then you just made it really easy to add encryption onto a couple of BBS packages. If you were to make a TPU I think you should have the code to handle file encryption and stream encryption built into it. For Async Pro you could just make up a send_cipher function that encrypts the data then calls Async Pro's serial send function. I also think it would be better to come up with some freeware so people don't have to go buy Async Pro, but that would be a good quick cipher engine for PC serial IO if you just added onto Async Pro without worrying about the serial routines for the moment also. d. saint From eichin at cygnus.com Wed Jun 2 08:39:22 1993 From: eichin at cygnus.com (Mark Eichin) Date: Wed, 2 Jun 93 08:39:22 PDT Subject: CryptoStacker In-Reply-To: Message-ID: <9306021616.AA26896@cygnus.com> >> Thanks for all of the responses on my questions concerning the CryptoStacker On a related note, the current maintainer of the loop file system patches for Linux has released the latest version, which includes DES encryption support (as I understand it, the code lets you mount a file as a file system, and just happens to have support for applying a function to the file... and the patches as released support specifying a DES key at mount time.) It's a start. Patches are on tsx-11.mit.edu and nic.funet.fi (ie. outside the US -- the maintainer lives in Switzerland :-) _Mark_ MIT Student Information Processing Board Cygnus Support From poier at sfu.ca Wed Jun 2 08:57:49 1993 From: poier at sfu.ca (Skye Merlin Poier) Date: Wed, 2 Jun 93 08:57:49 PDT Subject: Security in a VR world Message-ID: <9306021634.AA23208@malibu.sfu.ca> -----BEGIN PGP SIGNED MESSAGE----- For anyone interested, there is a discussion on the multiverse maillist at multiverse at medg.lcs.mit.edu about "portal security", that is, the ability / inability for certain users passing through certain "portals", as well as verification of user identity... Unfortunately, the developer is in Europe, and as we all know, PGP is export-controlled... :( Skye - -- - -----====> Skye Merlin Poier <====----- Undergrad in CMPT/MATH (Virtual Reality) |||| |||| email: poier at sfu.ca p-OO <--> OO-q THINK PGP Public Key available on finger \== ==/ -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAzWoy0bkpXW3omvAQFpVQQAvN+Q+fj+04DGgjXAyDhsBcRG5QEXES3a u6/lTKzhyqZEOCVX+ObivZOLUrc7OsbED0hGE4Wn/jIEeoeM//b9cA10JmTYu1Ce WgXPPuAa+YKAin9dMdIxNNiTzSaQhx+dQ3saPssQ45ErYWCPiix4ceBJWuITZJEG 9RfehK/yLws= =rHJv -----END PGP SIGNATURE----- From fnerd at smds.com Wed Jun 2 10:05:56 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Wed, 2 Jun 93 10:05:56 PDT Subject: Clipper replacement chip Message-ID: <9306021716.AA26131@smds.com> RYAN Alan Porter sez > Just out of curiosity, does anyone on the cypherpunks list posess the > technical skills that would be necessary to begin a project of hacking out > a pin compatible version of the Clipper that didn't have the backdoors > once the chip is out, a la AMD and CYRIX? > ... > So I guess the really important question is: does anybody know how to > reverse engineer a chip and build a duplicate, pin-compatible device from > the ground up while hiding from the feds the whole time and still managing > to make a living? Well, there's an easier end-run: a piggyback board. This would plug into the Clipper's slot, and the Clipper would plug into it. Then it could either run in Clipper or PGP/DH-IDEA/Whatever mode. I don't understand enough about the Clipper protocols and interface to know whether there's room to squeeze in bits to signal which of these two modes, unbeknownst to the rest of the phone, but you could certainly attach a Clip vs. Secure switch. -fnerd From pmetzger at lehman.com Wed Jun 2 10:32:25 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Jun 93 10:32:25 PDT Subject: Security in a VR world In-Reply-To: <9306021634.AA23208@malibu.sfu.ca> Message-ID: <9306021807.AA05105@snark.shearson.com> Skye Merlin Poier says: > -----BEGIN PGP SIGNED MESSAGE----- > > For anyone interested, there is a discussion on the multiverse maillist at > multiverse at medg.lcs.mit.edu about "portal security", that is, the ability / > inability for certain users passing through certain "portals", as well as > verification of user identity... Unfortunately, the developer is in Europe, > and as we all know, PGP is export-controlled... :( No its not. It was written abroad -- its more legal in Europe than in the U.S.... .pm From mccoy at ccwf.cc.utexas.edu Wed Jun 2 10:59:04 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Wed, 2 Jun 93 10:59:04 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: <9306021056.AA05648@toad.com> Message-ID: <199306021836.AA01020@flubber.cc.utexas.edu> Mark writes: > > >I still don't see why all of the actual encryption couldn't be done in > >software though... > > Me either, apart from TEMPEST issues... Speed. No software implementation will be able to match a hardware DES chip in total throughput. I have enough trouble dealing with the drive transfer speeds imposed upon PC unix systems with the lame bus, but even this could keep up if I had to run my file access through a software DES system. There are cards out there that can do this, and it doesn't really make sense not to offload this to an external device. > Linux comes with slot in file system > modules (as detailed in a letter to Jim) that you can easily adapt to your > own uses. Ive been playing around with this idea for a while. Adding a > desfs(tm) (me :) to a linux kernel is not going to be that hard I think.. > (touch wood). Yes, the other thing that pushed me to linux (besides the larger user community) was the support for "drop-in" filesystems. jim From fergp at sytex.com Wed Jun 2 12:02:56 1993 From: fergp at sytex.com (Paul Ferguson) Date: Wed, 2 Jun 93 12:02:56 PDT Subject: Crypto/Clipper debate rages on in comp.risks Message-ID: -----BEGIN PGP SIGNED MESSAGE----- For those of you who don't follow RISKS Digest (comp.risks): you're really missing some good stuff. At the risk of redundantly posting messages which may have already been discussed, I couldn't resist the opportunity to cross-post this portion of a response to Peter Junger's original post on "Risks of teaching the law without breaking it," where Mr. Junger expresses his displeasure and confoundedness of the export restrictions on simple (and all) cryptography. 8<----- Snip, Snip ------------ RISKS-LIST: RISKS-FORUM Digest Tuesday 1 June 1993 Volume 14 : Issue 67 >Date: Tue, 1 Jun 93 14:17:52 BST From: jharuni at micrognosis.co.uk (Jonathan Haruni) Subject: Re: Peter D. Junger's risks of teaching... (RISKS-14.6)5 Organization: Micrognosis International, London Peter D. Junger (junger at samsara.law.cwru.edu) wrote: > [ about his amusing and sad conundrum of being unable to teach law > students about a law without breaking it. ] I think that if you give your students copies of your comp.risks article, they should all be sufficiently disheartened with American law that they will quit the program and you can then present your lectures to a class devoid of foreign (or any) students. Alternatively, you could check passports at the door, and boot out foreign students during the parts of your class which are essential to American Sickurity. By doing so you will raise eyebrows well outside of the computer-and-law sphere of interest and you may bring this ludicrous situation into the limelight. But then, you may get sacked. Probably a much more effective solution to your problem, and one which has recently been proven perfectly legal and acceptable in an American court, would be for you to merely shoot dead all the foreigners in your class, after which you can speak freely. - ----[ remainder of post omitted ]------- -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAz9X5RLcZSdHMBNAQHQnwP9F8asul5g8tl4hhb9cLJZ9rz+0UeNUQb2 aGK+Bhx6onigi/HwseMjZP3BFSDHUzB3IuzpIjkIBj1BBEB24ZCtZVx9i4M9cIwI wObnkA7YQ0LIr2Ut4d37vQRU36VyltprRB7toqhuGWpv1ZMAp91uNQ4H3tIgXMYL 6sUplUkFMGQ= =C1Qo -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From fergp at sytex.com Wed Jun 2 12:03:02 1993 From: fergp at sytex.com (Paul Ferguson) Date: Wed, 2 Jun 93 12:03:02 PDT Subject: Work the Work! Message-ID: <8P6i5B2w165w@sytex.com> -----BEGIN PGP SIGNED MESSAGE----- Date: Tue, 1 Jun 93 21:32:24 -0700 Eric Hughes wrote - > Paul, you of all people don't need to feel slighted when I urge > people to do something, anything, about the wiretap chips. Agreed. There are many, many things that we need to do to support opposition to this ruse. > Here is my own very short version of my policy toward the wiretap > chips: > "The government has no right to restrict my use of cryptography in > any way. They may not forbid me to use whatever ciphers I may like, > nor may they require me to use any that I do not like." Hear, hear. > The hypothetical backdoor in clipper is a charlatan's issue by > comparison, as is discussion of how to make a key escrow system > 'work.' Do not be suckered into talking about an issue that is not > important. If someone want to talk about potential back doors, refuse > to speculate. The existence of a front door (key escrow) make back > door issues pale in comparison. > If someone wants to talk about how key escrow works, refuse to > elaborate. Saying that this particular key escrow system is bad has a > large measure of complicity in saying that escrow systems in general > are OK. Always argue that this particular key escrow system is bad > because it is a key escrow system, not because it has procedural > flaws. > This right issue is that the government has no right to my private > communications. Every other issue is the wrong issue and detracts > from this central one. If we defeat one particular system without > defeating all other possible such systems at the same time, we have > not won at all; we have delayed the time of reckoning. Very lucid and wise observation. I have suggested several times that attention should also be directed to the (what I call) "potential factor" in regards to the entire "key escrow" system. The potential for abuse and unconstitutional invasions of personal privacy are ripe for the picking under this scheme. In my own public comment letter to the Computer System Security and Privacy Advisory Board, I stressed this fact and also pointed out that although the system was probably designed with good intentions (right), it will not prevent zealots and spooks from monitoring communications under certain circumstances. My other peeve is that after this "technology" has been entrenched (read: forced) on the public, I see the rug being pulled out from under the feet of any other crypto system available. That's also why I attach a great deal of importance to some form of PGP being developed where all parties (Phil Z., Jim B., and me) are happy (excluding Uncle S.). (But I suppose that's another topic...) Patriotically yours, -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAzzZJRLcZSdHMBNAQEzEwP7BVrQ4KxuFgf19Dq0avHEq8fN4+k2lVFU UBPAZYWNwzyPV3IkmrFf4RGR84H/pdWm09GmYH5wptOuKEut0M5NzO30Z9+c2SW3 7FYr5TF2rygg0mHn6SDSiZZBLuLt/XqWIwGOzJBtrTnPsrLMqZ18Xk60lH3yqUme FzTiDxDnjqA= =wnNa -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From fergp at sytex.com Wed Jun 2 14:03:00 1993 From: fergp at sytex.com (Paul Ferguson) Date: Wed, 2 Jun 93 14:03:00 PDT Subject: Newsweek article, "The Code of the Future" Message-ID: -----BEGIN PGP SIGNED MESSAGE----- On Tue, 1 Jun 93 18:56:10 -0700, Timothy C. May wrote - > Subject: "Newsweek" Article on Clipper and Encryption When I read this message this morning, I made a bee-line down to the kiosk in the lobby and bought it (the June 7th issue of Newsweek). It must've just hit the stand, because the issues were still bound with rubber bands. (Thanks, Tim, for taking the time to commit it to ASCII, BTW.) This is good. Clipper articles have appeared in The New York Times, The Washington Post and now, Newsweek. This is exactly the exposure that is needed. One thing that you didn't include (its rather trivial), that I tacked onto the end of this post, is a very, very brief history of Cryptography - - - -- "Great Moments in Cryptography 1900 B.C. Menet Khufu, Egypt Into the rock of a nobleman's tomb, a master scribe carved unusual symbols rather than the standard hieroglyphics. The intent was to impart a grandeur to the message, the oldest known cryptographic text. Jan. 17, 1917 London Britain decodes the 'Zimmerman' telegram from Berlin to the German ambassador in Washington. Describing a plan to give Mexico the U.S. Southwest, it helped draw an outraged America into World War I. Dec. 7, 1941 Washington, D.C. Navy spies crack a message from Tokyo to its embassy in Washington saying it will break off talks with the U.S. at 1 p.m. -- dawn at Pearl Harbor. The navy spies miss the import of this; Tojo strikes unopposed. Nov. 4, 1952 Washington, D.C. Truman creates National Security Agency, master of math-based codes." - - -- To which, I add my own date to remember - "Infamous Moments in Cryptography Apr. 16, 1993 Washington, D.C. The Clinton Administration announces introduction of the 'Clipper Chip,' a cryptographic scheme developed by the NSA under the auspices of the National Institute of Standards and Technology (NIST). Under 'Clipper,' monitoring high-tech communications is made simpler for law enforcement agencies and privacy becomes a secondary triviality." I can only keep my fingers crossed that we see more articles like this geared to informing the public of this ruse. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLA0R05RLcZSdHMBNAQE5JgP/TFsJ6aF7+4lMIQjHSQw3qevwT45R+FIg rw5wNDIi7BO3A2rLyDE35rhJsekj6MB3Jg002K1Dy4W0lzT7pb9fkUcwt0H0mQXK 3BuZti59/grD6gfPPgkBHnC8XsH7sHnOV6OsZM1T8eusWofEp541l5bI9RsfnRsM qYnv1S3i+2c= =H9UT -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From eichin at ATHENA.MIT.EDU Wed Jun 2 14:12:15 1993 From: eichin at ATHENA.MIT.EDU (Mark W. Eichin) Date: Wed, 2 Jun 93 14:12:15 PDT Subject: [galvin@TIS.COM: Privacy Enhanced Mail available via anonymous FTP] Message-ID: <9306022149.AA09346@tsx-11.MIT.EDU> It is interesting to note that the LICENSE says: >> This license permits you to: >> b. create and sign certificates for people and entities >> within your own organization; _Mark_ Message-Id: <9306022052.AA09067 at TIS.COM> Reply-To: James M Galvin To: TISPEM.Announcement:;@TIS.COM, ietf at cnri.reston.va.us, pem-dev at TIS.COM, rsaref-users at rsa.com, saag-interest at TIS.COM, psrg-interest at isi.edu Subject: Privacy Enhanced Mail available via anonymous FTP Date: Wed, 02 Jun 93 16:51:17 -0400 From: James M Galvin Sender: pem-dev-relay at TIS.COM -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh HbGVud29vZA==,02 MIC-Info: RSA-MD5,RSA,ndrjfb54QirydT4/KLgg9HJh+5k0ON+bj9Wil5LeVTE 3E0ST0Bmv12KbChUn5MhxpH556ur0TbWTjl8/csLK52ARxGs0VJlzKfNOWL00SbB JfuyLIM6RLF9uE2ZBNNjP Trusted Information Systems, in cooperation with RSADSI, is pleased to announce the availability of Version 6.0 of TIS/PEM, the Internet reference implementation of Privacy Enhanced Mail. This software is available to US and Canadian organizations and citizens via anonymous ftp. All source code is included, including Version 6.7 of the Rand MH message handling system and Version 1.02 of RSAREF. To retrieve TIS/PEM please FTP to host: ftp.tis.com login: anonymous and retrieve the files pub/PEM/README pub/PEM/LICENSE The README file contains further instructions. The LICENSE file contains the restrictions and rules governing use of TIS/PEM. Please read this file before retrieving the code. Send questions to tispem-support at tis.com -----END PRIVACY-ENHANCED MESSAGE----- From nobody at shell.portal.com Wed Jun 2 14:25:57 1993 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Wed, 2 Jun 93 14:25:57 PDT Subject: Software infrastructure Message-ID: <9306021634.AA08896@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- Eric writes: > The second distinction is between stream and file encryption.If you > want to encrypt the underlying channel, you need a stream cipher and a > D-H key exchange. If you want file encryption, you want a block > cipher and public keys for communications. I don't think we should try to put stream encryption into this product. A problem with stream encryption is that it requires special SW on both ends. We would have to not only write a terminal program, but also write software which would transparently encrypt/decrypt which ran on the host and then passed the characters on to whatever command shell would normally run. I could see doing this with Unix (using pty's, a variant on the "script" program many systems have) but it may not be too portable. Stream encryption defends against wiretappers, and may provide some protection against the more trivial root-based attacks on the host computer (ones which just monitor the serial port - although if you use the pty idea there may be an internal serial port that has cleartext and which can be monitored). But you are still vulnerable to being monitored by root. I don't think the benefit gained is great enough, given the cost, to make this a good initial feature for the product. > This also implies the existence of offline mail readers. It is going to be hard to provide an offline mail reader with the friendliness of what the user is used to. Also, offline news reading is probably out of the question in this environment due to the great volume of news. Offline mail also has the problem that some people send great, huge messages that you aren't interested in. Online you just look at the first couple of pages and then delete it. Offline you download the whole thing, often paying for it, before you look at it. Another approach would be to have a "paranoid PGP" available on your host computer. This works much like regular PGP, except it will never ask you for your pass phrase. Any time it would, it instead outputs a magic escape sequence. This is recognized by your Cypherpunks terminal program and causes it to run a local program which includes PGP. The paranoid PGP on the host automatically downloads the file it was going to decrypt or sign to the local machine, which runs PGP, asks for your pass phrase, does the operation, and (perhaps) uploads the results back to the host. The whole thing is transparent if you are running the CP term, and your secret key and pass phrase never left your computer. (You might or might not want the plaintext to be uploaded after decryption - perhaps it could be previewed locally and if it's not too "hot" you can upload it and reply to it on the host.) Under this approach, message ENCRYPTION could be just done on-line since paranoid PGP doesn't need a pass phrase for that. So you can compose and mail your messages without needing any special support, as long as you don't sign them. You are still trusting the host, but not as much as if you left your secret key there and typed your pass phrase into the host computer. This is less secure than if you did everything on your PC but lets you use the powerful editing and mail/news handling capabilities of your host. This approach does have the same disadvantage I listed with respect to stream encryption, that it requires some special software on the host. However, this software should have many fewer host dependencies than a transparent stream encryptor would. Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAypvagTA69YIUw3AQECTgQAq/dvZ1EExP1GYzKlQcxhMIPT9TExxIes 25L8ZwG5syA6+KEcL2pSfnoPe1l9ZixCjefUnNiy9MYAHBh8uo8IEZ/IoCArSbvs ImUjayxZjWugHZaBIUsOo/dk5VbX/1tY3CW1eN2wItvtF1RQYk1QPjCYFgECqKeY UtRAd2p/JqI= =GAGr -----END PGP SIGNATURE----- From MaxDemon at cup.portal.com Wed Jun 2 14:26:01 1993 From: MaxDemon at cup.portal.com (MaxDemon at cup.portal.com) Date: Wed, 2 Jun 93 14:26:01 PDT Subject: PGP Message-ID: <9305261949.2.21834@cup.portal.com> How do I get the server to send me PGP22.ZIP and PGP22SRC.ZIP without breaking up each file into pieces? I'm on a DOS machine and can't recombine them. From John_David_Galt at cup.portal.com Wed Jun 2 14:26:05 1993 From: John_David_Galt at cup.portal.com (John_David_Galt at cup.portal.com) Date: Wed, 2 Jun 93 14:26:05 PDT Subject: help: P.S. Message-ID: <9305262054.2.7349@cup.portal.com> We have ftp here, but pax.tpa.com.au will not accept an ftp connection. If you know of a site that will, that has PGP, please, where is it? thanks. John David Galt From miron at extropia.wimsey.com Wed Jun 2 15:51:42 1993 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Wed, 2 Jun 93 15:51:42 PDT Subject: Mail probs Message-ID: <199306022148.AA07511@xtropia> ----- Transcript of session follows ----- uux: creat (TMP0000001297): Permission denied 554 elee7h5 at rosebud.ee.uh.edu... unknown mailer error 1 ----- Unsent message follows ----- Hopefully the originator of this anon message is on the list. Miron From mdiehl at triton.unm.edu Wed Jun 2 16:29:19 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 2 Jun 93 16:29:19 PDT Subject: WH email petition. In-Reply-To: <9306021344.AA16267@disvnm2.shearson.com> Message-ID: <9306030006.AA03619@triton.unm.edu> According to David Mandl: > In general, I agree that petitions are a major waste of time and energy; > I'm also pretty convinced that this White House email link is a big scam. > Why are they any more likely to take your mail seriously just because it > comes over the phone lines and not in an envelope? Seems like a pretty I don't, but as you mention below, it takes so little time, I thought we could get people involved who may not otherwise give a damn. "It's so easy, just send a quick letter, it will really help us out." Or something like that. > transparent PR ploy (also an attempt to make it seem like the White House > isn't a bunch of dinosaurs now that everybody and her nephew has an email > address). Well, we all know that! ;^) > But since it won't take much more than a couple of minutes of any of our > time, I can't see an electronic petition hurting our cause any--especially > because it'll certainly include the names of many esteemed professionals > and braniacs with fancy scientific, corporate, and academic credentials. > I think this could be a nice propaganda coup if it got publicised. How about each time we manage to get someone to send a letter to the WH, we also request that they send it to one of us, so that we can keep track of it? Is this doable accross the many networks? > It could at the very least give a big black eye to the forces of evil. 'Hope so. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mark at coombs.anu.edu.au Wed Jun 2 18:24:26 1993 From: mark at coombs.anu.edu.au (Mark) Date: Wed, 2 Jun 93 18:24:26 PDT Subject: Term software development/design Message-ID: <9306030124.AA00799@toad.com> Those of you with a 386 or greater and over 40Mb Hd (most of the pc's these days are usable) might want to take a look at running linux/386bsd/netbsd at home and then running term(1). It's a program with it's own packetising, compression of data (which is good for a quick and nasty anti-tap system) and you can telnet, rsh, ftp, finger etc all from the unix command line of your home machine. Uploads etc can all be done at the same time as you read mail on a remote host. the lastest version is term107.tar.z and should be avaliable from most archie sites. It has #defs for suns, nexts, hps, linux etc. When i find the guy who wrote the telnet client for it I'll probably add des encryption to it. The above is for plain modem usage, it's a semi tcp link at home and you can dial anywhere and link up in seconds, no special system file changes, just compile the remote binary and you're away. If you're just using the dialup host as a bouncer then all that is running is one innocuous looking binary, even though you might have several ftp's and telnets etc running at once. Honestly it's an admins nightmare. Linux etc also has slip and inet options if you want to explore those. The only problems I find are people being unable to listen (usefully) to your sessions and killing the line :) Most of the tools are written I find, all thats needed is the adding of encryption to them for a totally secure session. No need to write another term program, just use whats out there. Mark mark at coombs.anu.edu.au From poier at sfu.ca Wed Jun 2 18:39:16 1993 From: poier at sfu.ca (Skye Merlin Poier) Date: Wed, 2 Jun 93 18:39:16 PDT Subject: heh heh.. whoops Message-ID: <9306030216.AA25030@malibu.sfu.ca> heh ... sorry about the PGP export thing... I was a bit flaked out this morning what with midterms and all. Musta been thinking of something else. Sorry all Skye -- -----====> Skye Merlin Poier <====----- Undergrad in CMPT/MATH (Virtual Reality) |||| |||| email: poier at sfu.ca p-OO <--> OO-q THINK PGP Public Key available on finger \== ==/ From ryan at rtfm.mlb.fl.us Wed Jun 2 22:21:16 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Wed, 2 Jun 93 22:21:16 PDT Subject: CryptoStacker, long term vision In-Reply-To: <9306020657.AA05249@ecotone.toad.com> Message-ID: This is tiring drivel concerning the CryptoStacker project. It just started yesterday, so don't expect it to be too mature, we all have other things we have to do to pay the rent, right? Anyway, I am posting this to the list because it is kind of a plea for ideas, among other things, there are some tidbits that we need some help on. This particular message seemed to address both of the main ones, so I picked it. Don't complain about bandwidth, ok? Alright, to summarize the needs of the project at this point--> we need: 1) some ideas on a good algorithm for a quick and easy encryption to be used in a simple straight software on-the-fly disk encryption. I know that it's ironic, but it seems that that I and the people interested in funnelling me ideas are mainly deficient in the encryption area... 2) does anybody know how the hell Stacker or DoubleStor or whatever executes the actual interception of the read/write routines and stacks them? I don't get it at all. I am more than willing to learn to get this thing working though. To summarize this message in particular: Hugh: "Hey, wouldn't bell/whistle XXXXXX be a good idea?" Ryan: "Yeah, but can we get the thing to work at all first?" There, you have it. You don't even have to read it if you're not interested... _______________ Message follows: > Here is one method of encrypting whats on a disk that I see as > usefull for some, but not all of us. There are real problems for > folks like me who have Unix systems as their home systems, but we will > leave that as a extra credit problem. Yeah, I am just concentrating on getting something out there for DOS support. I actually loathe DOS and would rather be supporting UNIX (this would be a lot easier under Unix) but DOS is still a defacto standard and the people who need to be protected will be using DOS a lot... > I see a disk drive (or scsi controler or bus interface or even > something that sits in the middle of a scsi cable) with a PCMCIA slot > in it. Data gets passed about in the clear if no (or a dummy) card is > in the slot. If a real card is in the slot then all data goes though > the card before being sent the rest of the way though the interface > (might also take the data out via the card, but that makes the card > more complex, even if the drive is cheaper, and has other problems). > The card is a key, if its in you can read the disk and see the data > and it all looks fine. If its not in and you read the disk you see > whatever is on the disk, mixed plain and/or cypher text. I like this idea, but I don't know about having ALL data go through the encryption system. What about the idea of setting up a 'secure' partition and a 'fast' partition and having a device controller that would only run stuff sent to the 'secure' partition through the crypto system? I also don't know about the practicality of making the thing easy to download your own crypto into it. I think that if I am using a DES chip that is widely understood and trusted that there would be no need for the further complication of letting people hack at it... It would be a really cool option, and it would be a lot closer to allowing people to seize their own security, but I don't think that I can justify adding such a complicated feature at such an early stage. > You now have a 'key', if you don't want the disk read take the key > out, breakit it even (if broken the card needs to erase its self as it > might be read even in this state by a electron micro scope or some > such). I really like this PCMIA key idea. I don't think that just having a key would be enough though. Say the Secret Service walks in tomorrow and my system is CryptoStacked, and the PCMIA key is dangling out of the slot because I fell asleep programming last night and forgot to take it out and put it in the safe or whatever. all of that hard earned security is naught. I am much more in favour of a password system to assist the key, much like PGP uses a password system to assist the secret keyring. > There are sevral types of cards one could use in such a system, the > ones I would like to see would have all sorts of crypto support > hardware and some sort of processer. I want to be able to download my > own crypto system into the card (which should be program ONCE), so as > I can feal safe in that I control everything that goes on. This might > be slower then doing a dedicated chip, but more usefull. Support > chips(well features) might include hardware DES,RSA, etc. to speed > things up. I am thinking mainly of finding this much rumored DES chip and trying it out on a dedicated board. I had another idea for an initial stepping stone: are ISA cards DMA mapped? If so, howabout a card that simply has the key burned into it's virtual value, but only when it is properly activated? You could easily achieve this by burning a simply program into an EEPROM, and the activation could be something like punching in a code on a keypad attached to the board or something. (this comes to mind because I have a friend that just finished burning some simple programs into EEPROMS and building a simple keycode keypad, integrating them should be a weekend project) That way, I could do the encryption in software for the specified 'secure' partition (until I can get my hands on a DES chip) using the value returned by the EEPROMs as the key. Sound feasable? > If one feals like haveing fun you might be able to use the card > remotely, by sending the data (see why I don't want the card to be the > interface) over the net and decrypting it localy, then useing it > localy or re-encrypting it and sending it back to be used at the other > end again. This is more work, but usefull! Hmm, that could work perhaps, but the main idea was to create a transparant file system encoding system for once the data already is local, there are certainly better packages out there for data transmission security than anything that *I* could cook up... Just look at the flack that the Dolphin guys are getting just for even suggesting something like that... > This would mean that the crypto key cards would need to be designed > to be usefull in disks, or as keys in CPU's. The more general the > better. I agree, but a file system CryptoStacker will be hard enough to implement in the first place, I think that I will need to worry about that first. > If one want to play around one could try to have passwords to turn > the cards on (digital text/voice, or phyical interface on the back of > the card). Ahh, should have read ahead... I like that voice recognition concept though, but that sounds kind of like a bells/whistles kind of thing too... > One problem I see with this is how low a level it works at, for > instance blocks of disk are likely to expand/shrink with ecryption, > but for this sort of interface we have to pad. Uck. Right, that is my main nightmare, what size blocks to use? I just don't quite understand how Stacker does it. the way I see it we have a serious problem because there are at least two different ways of getting data onto or off of a disk. If it was one or the other, I would be able to cope with it by intercepting that method and changing it, but there are at least two fundamentally different ways, reading by bytes and reading by variable length blocks. I'm not sure if it is possible to read by bits or not, I've certainly never needed to do so, but a good scan through the PC interrupts might be necessary... The size of a block of data would not change with DES encryption, would it? I might have a serious misunderstanding about how DES works if the size *DOES** change... Here is a though, the apparant ignorance of which is entirely due to the fact that I just don't understand at all how Stacker works on an intercpet level: How about just encoding each byte seperately, that way I could intercept the byte read/write no problem, and I could intercept the variable block read/write in a similar manner, just break it down into a series of single byte read/write cycles? Is it possible to DES encode a single byte and have it remain a single byte? Is it a reasonably secure idea? I would do some DES research, but I am mail only and it takes WEEKS to poke around ftp sites through the mail, dig? Perhaps someone could send me a nice FAQ? Perhaps someone knows of a nice method by which I *COULD* securely encode a byte to a byte and have it remain a byte using keys and such? I suppose you might have noticed by now, I am a very good software engineer, and a pretty good structure programmer, but only a good machine level programmer, and only a mediocre cryptologist, let's get all of that straight right here. > I have in the back of my head an idea for a NFS like data (in the > simple case disk) server. How this might be done is murkey to me > right now. > My first problem is deciding on where I want the decryption to > happen. We keep talking about doing it in the disk drive, but as my > example above shows there is no reason to do it that way, and it's a > lot safer to pump crypted data through a (maybe leeky) SCSI data cable > then to have it all ready decrypted. > Maybe what this is trying to tell me is that there is a trueism > about decrypting data as close as resonable to the use point (and NOT > the source) as one can. This is all well and good, but I think that getting the damned thing to work at all will be a bitch, much less worrying about perfectly optimal security... > Question is: Is there a good algorithm that can be done totaly in > software, that gains more speed & security from beside memory general > purpose decryption hardware and even more from dedicated cards? This is my question exactly, what encryption algorithm... > This is really a protocall questoin, as we should be able to change > the crypt algorithm weekly if we want (might need to do this!). Oi, please... I am worried about finding ONE algorithm, you are already thinking about implementing any number on infinities... > I wonder how this can work if I decide that I need not one, two or > three crypt keys, but hundreds! I can see that I am going to have > just a few keys for the basic disk keys (can do one per disk) in > hardware, and likely hundreds of others that can't (afford or > effectivly) use dedicated hardware for. Well I don't see why any relatively unlimited number of keys couldn't exist. As for those people that can't afford to use dedicated hardware, there is still the less secure idea of having the key stored on a floppy that would be inserted at load time and read into memory. This would have the obvious disadvantage of having the key sitting around in memory, a sitting duck (especially for people who leave their systems on all of the time, like me, as soon and the Nazis learned about systems like these then 'Run a key scanning program on the system to be confiscated' would just become step one in their procedure, would be a hole even if the keys were password protected) but it would be better than nothing at all, and the speed problems could be dealt with by using the multiple partition method that I described earlier, having a 'secure' virtual disk where all of your data goes, and a seperate 'fast' virtual disk which is unencrypted where all of your programs and such go. > Have fun, theres work to be done! > ||ugh Daniel > hugh at toad.com Yes, but you know, the more I think about it, the easier it looks... my two main problems right now are: 1) What algorithm? How? 2) How the hell to intercept the read/write routines? After that, the rest is just writing code. Code I can do, code is no problem... -Ryan the Bit Wallah From ryan at rtfm.mlb.fl.us Wed Jun 2 22:55:39 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Wed, 2 Jun 93 22:55:39 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: <199306021836.AA01020@flubber.cc.utexas.edu> Message-ID: On Wed, 2 Jun 1993, Jim McCoy wrote: > Mark writes: > > > > >I still don't see why all of the actual encryption couldn't be done in > > >software though... > > > > Me either, apart from TEMPEST issues... > > Speed. No software implementation will be able to match a hardware DES > chip in total throughput. I have enough trouble dealing with the drive > transfer speeds imposed upon PC unix systems with the lame bus, but even > this could keep up if I had to run my file access through a software DES > system. There are cards out there that can do this, and it doesn't really > make sense not to offload this to an external device. Yes, actually it does. Hardware cannot be widely and freely distributed the way software can. I am looking to write something that can protect EVERYONE, not just those people that can afford to buy some dedicated hardware. Would PGP be so widespread today if it required a hardware coprocessor? > > Linux comes with slot in file system > > modules (as detailed in a letter to Jim) that you can easily adapt to your > > own uses. Ive been playing around with this idea for a while. Adding a > > desfs(tm) (me :) to a linux kernel is not going to be that hard I think.. > > (touch wood). > > Yes, the other thing that pushed me to linux (besides the larger user > community) was the support for "drop-in" filesystems. I like the whole Unix idea for PC's in general, and Linux in particular, but the fact remains that the people who need security the most (the average schmuck out there in the business world or the kid running a BBS) are most likely to be using a PC DOS-based system, and I am writing for them. > > jim -Ryan the Bit Wallah From mulivor at orion.crc.monroecc.edu Wed Jun 2 22:57:42 1993 From: mulivor at orion.crc.monroecc.edu (mulivor at orion.crc.monroecc.edu) Date: Wed, 2 Jun 93 22:57:42 PDT Subject: E-Mail Baloney, Part 2 Message-ID: <9306030557.AA08285@toad.com> Here's a press release that came to me yesterday. In particular, see last paragraph. Phil Mulivor --------------------------------------------------------------------- House of Representatives Announces Public Electronic Mail Service To: National Desk Contact: Lance Koonce of the Committee on House Administration, 202-225-7922 WASHINGTON, June 2 /U.S. Newswire/ -- Chairman Charlie Rose and Ranking Minority Member Bill Thomas of the Committee on House Administration announced today the pilot program of the Constituent Electronic Mail System. This groundbreaking new service will allow citizens to communicate directly with their Member of Congress by electronic mail. The House of Representatives has established an electronic gateway to the Internet, the vast computer network that is used currently by over 12 million people worldwide. Participating Members of the House have been assigned public mailboxes which may be accessed by their constituents from their home computers. In addition, many libraries, schools and other public institutions now provide, or soon will provide, public access to the Internet. The Members of the House of Representatives who have agreed to participate in this pilot program are: Rep. Jay Dickey (AR-07), Rep. Sam Gejdenson (CT-02), Rep. Newt Gingrich (GA-06), Rep. George Miller (CA-07), Rep. Charlie Rose (NC-07), Rep. Fortney Pete Stark (CA-13), and Rep. Melvin Watt (NC-12). These Members will be making announcements in their congressional districts within the next few weeks to make their constituents aware of the new service. The Constituent Electronic Mail System represents a significant effort by the House of Representatives to expand communication with constituents. With the tremendous growth of electronic mail over the past several years, and the increasingly inter-connected nature of computer networks, the new service is a natural addition to the current methods of communication available to constituents. At the present time, House Members involved in the pilot program will largely respond to electronic mail messages from their constituents by postal mail, to ensure confidentiality. Constituents of House Members participating in the pilot program who wish to communicate with those Members will be asked to send a letter or postcard stating their interest to the Member's office. The request will include the constituent's Internet "address," as well as that constituent's name and postal address. This process will allow Members to identify an electronic mail user as his or her constituent. The pilot e-mail program will continue until sufficient feedback from participating offices has been collected to allow improvements and modifications to the system. When House Information Systems and the Committee on House Administration are satisfied that the system is sufficiently error-free, other Members of the House will be allowed to add this new service as technical, budgetary and staffing concerns allow. For more information, Internet users are encouraged to contact the House of Representative's new on-line information service. Please send a request for information to CONGRESS at HR.HOUSE.GOV. /U.S. Newswire 202-347-2770/ From julf at penet.FI Thu Jun 3 00:45:33 1993 From: julf at penet.FI (Johan Helsingius) Date: Thu, 3 Jun 93 00:45:33 PDT Subject: whistle for Whistleblowing! In-Reply-To: <9306020701.AA03726@longs.lance.colostate.edu> Message-ID: <9306030914.aa26400@penet.penet.FI> > Cypherpunks, alt.whistleblowing has been created! ... and supported by anon.penet.fi. Julf From mccoy at ccwf.cc.utexas.edu Thu Jun 3 00:58:38 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Thu, 3 Jun 93 00:58:38 PDT Subject: Crypto anarchy in a VW? (not the bug) In-Reply-To: Message-ID: <199306030835.AA23736@tigger.cc.utexas.edu> Ryan Alan Porter writes: > Jim McCoy wrote: [regarding why to use hardware for the encryption] > > Speed. No software implementation will be able to match a hardware DES > > chip in total throughput. [...] There are cards out there that can do > > this, and it doesn't really make sense not to offload this to an > > external device. > > Yes, actually it does. Hardware cannot be widely and freely distributed > the way software can. I am looking to write something that can protect > EVERYONE, not just those people that can afford to buy some dedicated > hardware. This is true, but I am not completely writing-off those without the ability to get a hardware card: they will just have to put up with the, IMHO, unbearable slowness of doing filesystem encryption through software. I am also examining the log-structured filesystem (Rosenblum and Osterhout) to see if using that as the core to add the encryption to will make the system useable without hardware. Additionally, perhaps the fact that there is some real use for a hardware DES card will get people to buy them and increase their availability in general... > Would PGP be so widespread today if it required a hardware coprocessor? No. Then again PGP is for encrypting _files_, not filesystems. We are talking several orders of magnitude difference in the amount of data you are trying to force through them. I guess part of the difference in viewpoints we have is that I am spoiled on unix. I have become used to the high-bandwidth drives and networks that I use every day and would not be able to stand the bottleneck created by doing the encryption in software. > I like the whole Unix idea for PC's in general, and Linux in particular, > but the fact remains that the people who need security the most (the > average schmuck out there in the business world or the kid running a BBS) > are most likely to be using a PC DOS-based system, and I am writing for them. Yes, a crypto drop-in that works like Stacker would be a good thing to have available and I wish you the best of luck in your efforts. On the general DOS side though, I can run DOS under linux and have a DOS filesystem within a linux system as well (linux plug :) Either way, good luck. jim From hughes at soda.berkeley.edu Thu Jun 3 08:57:13 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 08:57:13 PDT Subject: Software infrastructure In-Reply-To: <9306021548.AA19002@uahcs2.cs.uah.edu> Message-ID: <9306031542.AA26387@soda.berkeley.edu> >If you want the other software developers to pick up encryption then >you had better put it into some kinda kit or TPU. Agreed. The less hassle, the more use. Buzzword alert. What is "TPU"? And who makes "Async Pro", and what exactly does that do? Eric From hughes at soda.berkeley.edu Thu Jun 3 08:57:21 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 08:57:21 PDT Subject: CryptoStacker, long term vision In-Reply-To: Message-ID: <9306031522.AA26005@soda.berkeley.edu> A related topic to encrypted disk drives. Anybody who has a desire to see their data around long term makes backups of their drives. At least one of these backups is usually physically near the drive in question. What good it is to have an encrypted disk if the backups are not also encrypted? Backups occur at the file system level, where an encrypted file system does not appear encrypted, so that work here does not directly leverage to encrypted backups. Eric From hughes at soda.berkeley.edu Thu Jun 3 08:57:38 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 08:57:38 PDT Subject: CryptoStacker, long term vision In-Reply-To: Message-ID: <9306031512.AA25490@soda.berkeley.edu> >This is tiring drivel concerning the CryptoStacker project. If you want help, it is wise not to recklessly insult those who are offering it. By your own admission, you do not have a lot of experience here; you seem to be saying "I know exactly what I don't know," which, may I add, is a common delusion of the inexperienced. You seem to have fixed a model of how the encrypted disk would work and don't want to debate it. The model is exactly that which requires the most scrutiny, because it has the most far reaching effects. If the model is flawed somehow, that's what you want to know before you begin, not six months later. I take it that you want people to use this software after it is written. if so, then pay close attention to user acceptance issues such as performance and key handling. You neglect them at your own risk. Your model seems to be that of intercepting interrupts to the disk. This could be made to work, but is the wrong way to do it. If you insist on that, though, any good PC reference book will tell you what the disk interrupt vector in the BIOS is. Ralf Brown's interrupt list also contains the relevant data in schematic form. The proper way to do this is as a device driver, however. Grabbing interrupts is messy and prone to interference. Many anti-virus programs monitor the disk interrupt to make sure that nobody uses it unauthorized. A device driver is the intended way to create new devices, like an encrypted disk. There are complete books about writing device drivers; you will need one of these or some other good DOS programming book which explains how to write one. There are lots of subtleties about them. I would suggest that you first version just be a device driver that has no encryption, but only the hook for it. The device driver skeleton for a disk will be difficult enough, as you have to support a whole lot of operations just so you can have a place to put the encryption. This is exactly the software infrastructure problem in another context. After you have a device driver skeleton working, you can add both hardware and software encryption modules. There is no need to be exclusive about this. It is clear to me from your comments that you haven't timed any DES routines and done a calculation of increased latency times, and although I hate to see code development go to waste, it's your time, not mine. As far as picking an encryption algorithm, use DES. DES is the fastest symmetric keyed block cipher that is thought to be reasonably secure. DES is not particularly fast in software; it was designed as a hardware standard and does lots of bit manipulations. DES is fast enough for serial communications, but that 1000 times less the bandwidth than a hard disk. Of course, you don't want to run DES in codebook (aka naive) mode. (Codebook mode is where you just simply map block to block; the problem is that identical blocks map to identical blocks.) You'll want some sort of other mode, like a counter mode, to make sure you don't get identical ciphertexts. It is also a bad idea to encrypt the whole disk with one key; it makes brute force searches much easier. Your keying material should be long. I earlier suggested one key per track. These keys are going to have to be stored somewhere, and the disk is the wrong place for it, clearly. This implies that the user is going to have to have some key-holding device (likely a diskette) which will be necessary in order to unlock the partition. the keying material should be password protected. This device will be have to used at boot time if anything necessary to boot is stored on the encrypted partition. Keying material will need to be backed up. This should be made as painless as possible, otherwise there will be plenty of people losing whole drives. Keys in the driver should time out after some specifiable period. Files that are open when the time-out occurs and the programs that have them open are going to have to be dealt with gracefully. This model of using a device driver means that there is going to have to be at least two partitions on the disk: one to boot from, and one to be encrypted. The device driver itself and the operating system can't be on the encrypted disk, because those components must be loaded before the encrypted disk is accessible. Most people are not going to go out and buy a new disk to be the encrypted partition. Thus, this is going to mean a full backup of the existing disk, an operation with FDISK to do the partitioning, then, assuming the driver works right the first time, restoring everything else on the encrypted partition. What is the effect of _this_ on user acceptance? Eric From fergp at sytex.com Thu Jun 3 08:57:43 1993 From: fergp at sytex.com (Paul Ferguson) Date: Thu, 3 Jun 93 08:57:43 PDT Subject: Solidarity (kudos) Message-ID: -----BEGIN PGP SIGNED MESSAGE----- I couldn't resist the opportunity to x-post this to the list, especially now that it makes me feel foolish for once suspecting the possibility of foul play at UUNet. My hat is off to Nat and all the folks at UUNet Technologies who share his views. Kudos. 8<------- Begin Forwarded Message ----------- From: nrh at daimajin.UU.NET (Nat Howard) Newsgroups: alt.privacy.clipper Subject: another letter to the president Date: 2 Jun 1993 19:41:01 -0400 Organization: UUNET Technologies Inc, Falls Church, VA, USA Lines: 41 NNTP-Posting-Host: daimajin.uu.net Summary: dump clipper Date: Wed, 02 Jun 1993 12:49:46 EDT To: PRESIDENT at WHITEHOUSE.GOV, VICE.PRESIDENT at WHITEHOUSE.GOV From: Nat Howard Subject: Clipper initiative of 4/16/93 Sirs, As a citizen working in the communications field, I am gravely concerned by the 4/16/93 Clipper Chip initiative. I believe that the initiative as proposed cannot accomplish its stated goals, and will, if carried out, be poisonous to American business attempts to compete in the secure communications field. Far more important is the apparent denial in the press release of our First, Second, Fourth, Ninth, and Tenth Amendment rights: ... nor is the U.S. saying that "every American, as a matter of right, is entitled to an unbreakable commercial encryption product." I urge you to consider these actions instead: 1. Lift export controls on all cryptographic hardware and software. 2. Have the NSA work with NIST to produce a publicly-described algorithm, suitable for either hardware or software implementation, that can serve for the next 15 years as a follow-on to DES. 3. Find some fair and legal way so that all US Citizens can use, royalty-free and without other restriction, the public-key algorithms now patented by PKP. A lot of us have hopes for the human rights aspect of the Clinton-Gore ticket. Please don't let us down: withdraw, abandon, or greatly modify the Clipper Chip initiative. I emphasize that I speak here as a private citizen, and my remarks don't necessarily reflect the feelings of UUNET. 8<------- End of Forwarded Message --------- -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLA4NhZRLcZSdHMBNAQGJjQP/Ty6YCVBsrNfmfWiuyRK/GWHvwkLBy5tE bJOUmwnyP2nD/febFSeIPSoheKEpvVNg6nZUM7BTNPAQ5SM+papyujs5NtQNbiGT TLLS55K0X+904Iszn3ROzc/QJNaQ/RSj+7vuI+yq3L9dTcOrbKNpnU/KePkISeIp toFDESkZDnY= =F+B7 -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From ebrandt at jarthur.Claremont.EDU Thu Jun 3 08:57:46 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Thu, 3 Jun 93 08:57:46 PDT Subject: remailer flakiness Message-ID: <9306031448.AA16547@cygnus.com> I've been off the net for a few weeks, and my remailer's been running on auto-pilot. Checking my mail, I found that a number of messages for the remailer had ended up in my mailbox instead. However, logs also indicate that a fair bit of traffic went through the remailer, apparently successfully. A test of the remailer turned up no problems. If anybody knows or suspects that a message sent through me did indeed not get through, I'll bounce all of it back to myself for reprocessing. Otherwise, this might result in mail duplication. Eli ebrandt at jarthur.claremont.edu From wcs at anchor.ho.att.com Thu Jun 3 08:57:59 1993 From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com) Date: Thu, 3 Jun 93 08:57:59 PDT Subject: Crypto anarchy in a VW? (not the bug) Message-ID: <9306031432.AA23113@anchor.ho.att.com> > >There are a lot of ways to get a signal around the world without using a > >satellite, ask any amateur radio enthusiast. I thought the motivation for satellite at the beginning of this discussion was that it's extremely hard to find out WHO sent a transmission to a satellite - everybody's got a dish pointed UP at the same destination, the FCC isn't likely to go flying helicopters around to locate transmissions that could have come from anywhere in the country, and there's really nothing to direction-find on, and the receivers can similarly be anywhere, since it's a broadcast network. If the satellite uses some kind of protocol such as AlohaNet, you get reasonable shared utilization. (Of course, the alternatives to direction-finding are to go after the bird's owners, or to jam the transmission channel.) Moon-bounce offers similar advantages, and there aren't any owners to trace :-), though jamming is still possible. Another technique that's pretty obscure, and relatively low data rate, but pretty hard to trace, is meteor-burst, which reflects signals of the ionization trails left by micrometeors. Typical systems a few years ago transmitted at 4800 baud, getting effective throughput of maybe 300 bps, since the channel isn't constant. It was used for applications like sending snow depth reports back from mountains, since it needs very little power and isn't particularly bothered by weather conditions. Are networks like amateur packet radio hard to trace, assuming enough repeaters are around? > One of the really great techniques I've hear about recently is a data > channel that runs at 90% T1 speed over the ~900 MHz spread spectrum NCR WaveLAN, which is now also being OEMed by DEC, runs spread spectrum at (I think) 2 Mbps, and can use an optional DES chip for encryption. The PC cards are compatible with some vanilla Ethernet card, so it uses standard Ethernet protocols. In broadcast mode, range is only a few hundred meters, depending on building configurations, but it can also be used with a directional antenna to get 5-6 mile range. Bill Stewart From smb at research.att.com Thu Jun 3 08:58:02 1993 From: smb at research.att.com (smb at research.att.com) Date: Thu, 3 Jun 93 08:58:02 PDT Subject: WH email petition. Message-ID: <9306031427.AA16225@cygnus.com> > they've just gotten smarter about how they do it... Based on my past > experience, your name will be collected -- but just as a person > interested in certain issues, so that you can be solicited for funds > on certain issues. Does this really happen? WOW! Does it happen? Sure did circa 20 years ago, when individual members of Congress had much less computing capacity. I wrote to members of the House Judiciary committee demanding the impeachment of a certain unindicted co-conspirator. Over the next few years, I received a variety of funds solicitation letters, as some of those folks tried to move on to bigger and better offices. The letters invariably spoke of the members' ``bravery and courage of conviction'' during the Watergate investigation, and noted my interest in that subject... From elee9sf at Menudo.UH.EDU Thu Jun 3 08:58:41 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Thu, 3 Jun 93 08:58:41 PDT Subject: HELP: pgp, .forward, mh Message-ID: <199306031404.AA18382@Menudo.UH.EDU> Situation: I'd like mail that arrives at my other account to be encrypted and then forwarded to this account. I have spent a few hours trying various things and nothing seems to work. I've tried this as my .forward file: "| /myhome/pgp -fea barrus | mail elee9sf at menudo.uh.edu" but all that arrives at elee9sf is a blank message. I've tried "| /myhome/remail.script" where remail.script was a one-liner similar to the above. Nothing. Any suggestions? Note: 1) barrus at tree.egr.uh.edu is a NeXT account. Is NeXTSTEP just too different for this stuff to work? 2) I'm running pgp2.1 on tree.egr, and don't have the old docs anymore. Was the -f option not present? 3) Anybody have a makefile for NeXT so I can upgrade? I compiled 2.1 by hand editing some lines, but the task looks pretty daunting with 2.2. I tried 'make mach' but that didn't get very far. So, if that's impossible, how do I get my elee9sf account to do it? I use mh on menudo, and have tried to barrus at tree.egr.uh.edu | A "/path/pgp -fea barrus | /path/rvcstore +tonext" in my .maildelivery but that doesn't seem to fly either. Any suggestions? /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From elee9sf at Menudo.UH.EDU Thu Jun 3 08:59:10 1993 From: elee9sf at Menudo.UH.EDU (elee9sf at Menudo.UH.EDU) Date: Thu, 3 Jun 93 08:59:10 PDT Subject: Another chaining utility Message-ID: <199306031333.AA16241@Menudo.UH.EDU> Hal wrote: > I couldn't get Karl's hopmail.bat to run on my PC (not enough environment > space?) so I wrote this in C and it works OK. Say, is anybody else having this problem? I wonder what the problem is (environment space?) PLEASE let me know about bugs or problems with the scripts. I'm going to be updating the dos versions pretty soon, and will see if I can figure out what the space error means. Thanks, Hal! /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From 76244.315 at CompuServe.COM Thu Jun 3 08:59:14 1993 From: 76244.315 at CompuServe.COM (Doug Porter) Date: Thu, 3 Jun 93 08:59:14 PDT Subject: Term software develo Message-ID: <930603131241_76244.315_CHN36-2@CompuServe.COM> Eric Hughes says: > FOSSIL is . . . the only abstraction for serial communications the PC has . . . There are at least 7 versions of INT 14. Then there's Ungerman-Bass's old INT 6B as well as two flavors of its successor, NASI/NCSI. There are also many variants of COMx device drivers. These are all serial line abstractions for the PC. There are others. FOSSIL may be popular on BBSs, but NASI/NCSI is number one in the market. The oldest version of INT 14 is number two. Who was it said "The nice thing about standards is that there are so many to choose from"? :-) Doug From 76244.315 at CompuServe.COM Thu Jun 3 08:59:18 1993 From: 76244.315 at CompuServe.COM (Doug Porter) Date: Thu, 3 Jun 93 08:59:18 PDT Subject: CryptoStacker, long Message-ID: <930603131226_76244.315_CHN36-1@CompuServe.COM> RYAN Alan Porter (unrelated AFAIK) asks: > 2) How the hell to intercept the read/write routines? I can help with the guts of DOS, BIOS, network interfaces, etc. My development time is committed, but feel free to email me with questions, folks. The simplest approach is probably Microsoft's Network Redirector interface. It's used for MSCDEX, and just about every LAN OS except Novell's, including Microsoft's own LAN Manager. A good reference is "Undocumented DOS" by Andrew Schulman et al. This is the only option discussed here I haven't used personally. It looks ideal for this application. Another possibility is hooking the DOS API itself. This certainly works well; it's the way Netware does it. I've found it a lot of work. See IBM's "Disk Operating System" manual for details. There was a mainframe manual by the same name, so be sure you're getting the PC version. Just under DOS itself is what Microsoft officially refers to as Device Drivers. Device drivers actually can be hooked in at many levels, of course, not just here. In this context MS calls disk drives "block devices". Block device drivers, or character device drivers for that matter, are not at all tough to write. They're probably a good second choice after the Network Redirector. A reference is the book "Writing MSDOS Device Drivers" by Robert Lai. DOS internally often calls software interrupts 25 and 26 for disk io. These are apparently inconsistent from DOS version to version. Skip this layer. If you need to go this far down, go all the way to INT 13. The lowest level of disk io short of hardware is INT 13. A good reference is Phoenix's "CBIOS Reference Manual". Watch out for quirks in INT 13's stack handling. There's also a good bit you have to do to keep DOS and your driver from tripping over each other. Unless others feel it's appropriate to use this bandwidth, email me for details. Doug From wixer!wixer.bga.com!cat at cactus.org Thu Jun 3 09:00:56 1993 From: wixer!wixer.bga.com!cat at cactus.org (Dr. Cat) Date: Thu, 3 Jun 93 09:00:56 PDT Subject: Term software development/design In-Reply-To: <9306020647.AA20551@hydra.unm.edu> Message-ID: <9306030536.AA18666@wixer> Stanton has a good idea, I think, about getting the developers of packages like Qmodem to set up some kind of hooks for encryption. Is anyone else from the list going to the BBSCON in Colorado this August? If not, I'll try to ask about the possibility of supporting encryption in Qmodem, Telix, Procomm, PC Board, TBBS, Major BBS, and Wildcat. (And of course, offer a helpful suggestion or two if they show any interest.) It would be better if someone better schooled in encryption than myself were going to be there, though. Dr. Cat / Dragon's Eye Productions From banisar at washofc.cpsr.org Thu Jun 3 10:35:42 1993 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Thu, 3 Jun 93 10:35:42 PDT Subject: CPSR NIST Crypto Statement Message-ID: <00541.2821903098.3779@washofc.cpsr.org> CPSR NIST Crypto Statement Department of Commerce National Institute of Standards and Technology Computer System Security and Privacy Advisory Board Review of Cryptography Policy June 1993 Statement of CPSR Washington office Marc Rotenberg, director (rotenberg at washofc.cpsr.org) with David Sobel, legal counsel, Dave Banisar, policy analyst Mr. Chairman, members of the Advisory Panel, thank you for the opportunity to speak today about emerging issues on cryptography policy. My name is Marc Rotenberg and I am director of the CPSR Washington office. Although CPSR does not represent any computer firm or industry trade association, we speak for many in the computer profession who value privacy and are concerned about the government's Clipper proposal. During the last several years CPSR has organized several meetings to promote public discussion of cryptography issues. We have also obtained important government documents through the Freedom of Information Act. We believe that good policies will only result if the public, the profession, and the policy makers are fully informed about the significance of these recent proposals. We are pleased that the Advisory Board has organized hearings. This review of cryptography policy will help determine if the Clipper proposal is in the best interests of the country. We believe that a careful review of the relevant laws and policies shows that the key escrow arrangement is at odds with the public interest, and that therefore the Clipper proposal should not go forward. Today I will address issues 1 through 3 identified in the NIST announcement, specifically the policy requirements of the Computer Security Act, the legal issues surrounding the key escrow arrangement, and the importance of privacy for network development. 1. CRYPTOGRAPHY POLICY The first issue concerns the 1987 statute enacted to improve computer security in the federal government, to clarify the responsibilities of NIST and NSA, and to ensure that technical standards would serve civilian and commercial needs. The Computer Security Act, which also established this Advisory Panel, is the true cornerstone of cryptography policy in the United States. That law made clear that in the area of unclassified computing systems, the Department of Commerce and not the Department of Defense, would be responsible for the development of technical standards. It emphasized public accountability and stressed open decision-making. The Computer Security Act grew out of a concern that classified standards and secret meetings would not serve the interests of the general public. As the practical applications for cryptography have moved from the military and intelligence arenas to the commercial sphere, this point has become clear. There is also clearly a conflict of interest when an agency tasked with signal interception is also given authority to develop standards for network security. In the spirit of the Computer Security Act, NIST set out in 1989 to develop a public key standard FIPS. In a memo dated May 5, 1989 and obtained by CPSR through the Freedom of Information Act, NIST said that it planned: to develop the necessary public-key based security standards. We require a public-key algorithm for calculating digital signatures and we also require a public-key algorithm for distributing secret keys. NIST then went on to define the requirements of the standard: The algorithms that we use must be public, unclassified, implementable in both hardware or software, usable by federal Agencies and U.S. based multi-national corporation, and must provide a level of security sufficient for the protection of unclassified, sensitive information and commercial propriety and/or valuable information. The Clipper proposal and the full-blown Capstone configuration, which incorporates the key management function NIST set out to develop in 1989, is very different from the one originally conceived by NIST. % The Clipper algorithm, Skipjack, is classified, % Public access to the reasons underlying the proposal is restricted, % Skipjack can be implemented only in tamper-proof hardware, % It is unlikely to be used by multi-national corporations, and % Its security remains unproven. The Clipper proposal undermines the central purpose of the Computer Security Act. Although intended for broad use in commercial networks, it was not developed at the request of either U.S. business or the general public. It does not reflect public goals. Rather it reflects the interests of one secret agency with the authority to conduct foreign signal intelligence and another government agency responsible for law enforcement investigations. It is our belief that the Clipper proposal clearly violates the intent of the Computer Security Act of 1987. What is the significance of this? It is conceivable that an expert panel of cryptographers will review the Skipjack algorithm and find that it lives up its billing, that there is no "trap door" and no easy way to reverse-engineer. In fact, the White House has proposed just such a review process But is this process adequate? Is this the procedure the Advisory Board would endorse for the development of widespread technical standards? The expert participants will probably not be permitted to publish their assessments of the proposal in scientific journals, further review of the standard will be restricted, and those who are skeptical will remain in the dark about the actual design of the chip. This may be an appropriate process for certain military systems, but it is clearly inappropriate for a technical standard that the government believes should be widely incorporated into the communications infrastructure. Good government policy requires that certain process goals be satisfied. Decisions should be made in the open. The interests of the participating agencies should be clear. Agencies should be accountable for their actions and recommendations. Black boxes and government oversight are not compatible. There is an even greater obligation to promote open decisions where technical and scientific issues are at stake. Innovation depends on openness. The scientific method depends on the ability of researchers to "kick the tires" and "test drive" the product. And, then, even if it is a fairly good design, additional testing encourages the development of new features, improved performance and reduced cost. Government secrecy is incompatible which such a development process. Many of these principles are incorporated into the Computer Security Act and the Freedom of Information Act. The current government policy on the development of unclassified technical standards, as set out in the Computer Security Act, is a very good policy. It emphasizes public applications, stresses open review, and ensures public accountability. It is not the policy that is flawed. It is the Clipper proposal. To accept the Clipper proposal would be to endorse a process that ran contrary to the law, that discourages innovation, and that undermines openness. 2. LEGAL AND CONSTITUTIONAL ISSUES There are several legal and constitutional issues raised by the government's key escrow proposal. The premise of the Clipper key escrow arrangement is that the government must have the ability to intercept electronic communications, regardless of the economic or societal costs. The FBI's Digital Telephony proposal, and the earlier Senate bill 266, was based on the same assumption. There are a number of arguments made in defense of this position: that privacy rights and law enforcement needs must be balanced, or that the government will be unable to conduct criminal investigations without this capability. Regardless of how one views these various claims, there is one point about the law that should be made very clear: currently there is no legal basis -- in statute, the Constitution or anywhere else -- that supports the premise which underlies the Clipper proposal. As the law currently stands, surveillance is not a design goal. General Motors would have a stronger legal basis for building cars that could not go faster than 65 miles per hour than AT&T does in marketing a commercial telephone that has a built-in wiretap capability. In law there is simply nothing about the use of a telephone that is inherently illegal or suspect. The federal wiretap statute says only that communication service providers must assist law enforcement in the execution of a lawful warrant. It does not say that anyone is obligated to design systems to facilitate future wire surveillance. That distinction is the difference between countries that restrict wire surveillance to narrow circumstances defined in law and those that treat all users of the telephone network as potential criminals. U.S. law takes the first approach. Countries such as the former East Germany took the second approach. The use of the phone system by citizens was considered inherently suspect and for that reason more than 10,000 people were employed by the East German government to listen in on telephone calls. It is precisely because the wiretap statute does not contain the obligation to incorporate surveillance capability -- the design premise of the Clipper proposal -- that the Federal Bureau of Investigation introduced the Digital Telephony legislation. But that legislation has not moved forward on Capitol Hill and the law has remained unchanged. The Clipper proposal attempts to accomplish through the standard-setting and procurement process what the Congress has been unwilling to do through the legislative process. On legal grounds, adopting the Clipper would be a mistake. There is an important policy goal underlying the wiretap law. The Fourth Amendment and the federal wiretap statute do not so much balance competing interests as they erect barriers against government excess and define the proper scope of criminal investigation. The purpose of the federal wiretap law is to restrict the government, it is not to coerce the public. Therefore, if the government endorses the Clipper proposal, it will undermine the basic philosophy of the federal wiretap law and the fundamental values embodied in the Constitution. It will establish a technical mechanism for signal interception based on a premise that has no legal foundation. I am not speaking rhetorically about "Big Brother." My point is simply that the assumption underlying the Clipper proposal is more compatible with the practice of telephone surveillance in the former East Germany than it is with the narrowly limited circumstances that wire surveillance has been allowed in the United States. There are a number of other legal issues that have not been adequately considered by the proponents of the key escrow arrangement that the Advisory Board should examine. First, not all lawful wiretaps follow a normal warrant process. It is critical that the proponents of Clipper make very clear how emergency wiretaps will be conducted before the proposal goes forward. Second, there may be civil liability issues for the escrow agents if there is abuse or compromise of the keys. Escrow agents may be liable for any harm that results. Third, there is a Fifth Amendment dimension to the proposed escrow key arrangement if a network user is compelled to disclose his or her key to the government in order to access a communications network. Each one of these issues should be examined. There is also one legislative change that we would like the Advisory Board to consider. During our FOIA litigation, the NSA cited a 1951 law to withhold certain documents that were critical to understand the development of the Digital Signature Standard. The law, passed grants the government the right restrict the disclosure of any classified information pertaining to cryptography. While the government may properly withhold classified information in FOIA cases, the practical impact of this particular provision is to provide another means to insulate cryptographic policy from public review. Given the importance of public review of cryptography policy, the requirement of the Computer Security Act, and the Advisory Board's own commitment to an open, public process, we ask the Advisory Board to recommend to the President and to the Congress that section 798 be repealed or substantially revised to reflect current circumstances. This is the one area of national cryptography policy where we believe a change is necessary. 3. INDIVIDUAL PRIVACY Communications privacy remains a critical test for network development. Networks that do not provide a high degree of privacy are clearly less useful to network users. Given the choice between a cryptography product without a key escrow and one with a key escrow, it would be difficult to find a user who would prefer the key escrow requirement. If this proposal does go forward, it will not be because network users or commercial service providers favored it. Many governments are now facing questions about restrictions on cryptography similar to the question now being raised in this country. It is clear that governments may choose to favor the interests of consumers and businesses over law enforcement. Less than a month ago, the government of Australia over-rode the objections of law enforcement and intelligence agencies and allowed the Australian telephone companies to go forward with new digital mobile phone networks, GSM, using the A5 robust algorithm. Other countries will soon face similar decisions. We hope that they will follow a similar path To briefly summarize, the problem here is not the existing law on computer security or policies on cryptography and wire surveillance. The Computer Security Act stresses public standards, open review, and commercial applications. The federal wiretap statute is one of the best privacy laws in the world. With the exception of one provision in the criminal code left over from the Cold War, our current cryptography policy is very good. It reflects many of the values -- individual liberty, openness, government accountability -- that are crucial for democratic societies to function. The problem is the Clipper proposal. It is an end-run around policies intended to restrict government surveillance and to ensure agency accountability. It is an effort to put in place a technical configuration that is at odds with the federal wiretap law and the protection of individual privacy. It is for these reasons that we ask the Advisory Board to recommend to the Secretary of Commerce, the White House, and the Congress that the current Clipper proposal not go forward. I thank you for the opportunity to speak with you about these issues. I wish to invite the members of the Advisory Committee to the third annual CPSR Privacy and Cryptography conference that will be held Monday, June 7 in Washington, DC at the Carnegie Endowment for International Peace. That meeting will provide an opportunity for further discussion about cryptography policy. ATTACHMENTS "TWG Issue Number: NIST - May 5, 1989," document obtained by CPSR as a result of litigation under the Freedom of Information Act. "U.S. as Big Brother of Computer Age," The New York Times, May 6, 1993, at D1. "Keeping Fewer Secrets," Issues in Science and Technology, vol. IX, no. 1 (Fall 1992) "The Only Locksmith in Town," The Index on Censorship (January 1990) [The republication of these articles for the non-commercial purpose of informing the government about public policy is protected by section 107 of the Copyright Act of 1976] =============================================== From pat at tstc.edu Thu Jun 3 11:27:14 1993 From: pat at tstc.edu (Patrick E. Hykkonen) Date: Thu, 3 Jun 93 11:27:14 PDT Subject: CryptoStacker - Suggestions In-Reply-To: <9306031512.AA25490@soda.berkeley.edu> Message-ID: <9306031827.AA05452@tstc.edu> > This model of using a device driver means that there is going to have > to be at least two partitions on the disk: one to boot from, and one > to be encrypted. The device driver itself and the operating system > can't be on the encrypted disk, because those components must be > loaded before the encrypted disk is accessible. Most people are not > going to go out and buy a new disk to be the encrypted partition. > Thus, this is going to mean a full backup of the existing disk, an > operation with FDISK to do the partitioning, then, assuming the driver > works right the first time, restoring everything else on the encrypted > partition. What is the effect of _this_ on user acceptance? Why not have the device driver create a file (possibly of varying sizes) on the hard drive which the encryption device driver then makes look like another drive?!? This is how the compression programs work, seems to me a pretty viable way to solve the encrypted drive problem as well. A good place to start on this would be something like DOS's VDISK device driver, it maps a portion of RAM into a RAM-disk... a good way to understand how a DOS device driver should map something that has no disk-like characteristics into disk-like characteristics. From hkhenson at cup.portal.com Thu Jun 3 12:01:24 1993 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Thu, 3 Jun 93 12:01:24 PDT Subject: Hardware vs software Message-ID: <9306030216.1.2999@cup.portal.com> RE this topic, there are methods (Merkle's for example) where you can get multiple megabytes per second through a good encryption algorithm in a CPU. DES is kind of optimised for doing it in hardware, so don't take how slow it is in software as the limit for good encryption. Keith (Gnu posted the paper a long time ago in sci.crypt, but I don't know if I can find it on my newer system.) From mab at vax135.att.com Thu Jun 3 12:37:34 1993 From: mab at vax135.att.com (mab at vax135.att.com) Date: Thu, 3 Jun 93 12:37:34 PDT Subject: Unix Crypto File System paper Message-ID: <9306031922.AA09035@vax135.UUCP> Hi, Some of you have sent me mail asking about my cryptographic file system for Unix; it was the subject of a work-in-progress presentation at the January Usenix conference. I have a draft of a paper that you may find helpful; I just got off the phone with our lawyer and finally have the release to send it out, so if you'd like a copy of the draft, send me your email (for postscript) or physical (for dead trees) address. Before you ask: the software also may be released, but that's a longer process and it isn't really "ready for prime time" yet anyway. The paper is just a draft, and also has some bugs in it, but some of it seems relevant to the discussion here on similar projects for PCish machines. Here's the abstract: ======== Although cryptographic techniques are playing an increasingly important role in modern computing system security, user-level tools for encrypting file data are cumbersome and suffer from a number of inherent vulnerabilities. The Cryptographic File System (CFS) offers an alternative to ad hoc user-level encryption for protecting file data. CFS supports secure storage at the system level through a standard Unix file system interface to encrypted files. Users can associate a cryptographic key with any directories they wish to protect. Files in these directories (as well as their pathname components) are transparently encrypted and decrypted with the specified key without further user intervention; cleartext is never stored on a disk or sent to a remote file server. CFS can use any available file system for its underlying storage without modification, including distributed file systems such as NFS. System management functions, such as file backup, work in a normal manner and without knowledge of the key. This paper describes the design and implementation of CFS under Unix. Encryption techniques for file system-level encryption are described, and general issues of cryptographic system interfaces to support routine secure computing are discussed. ======== -matt mab at research.att.com From i6t4 at jupiter.sun.csd.unb.ca Thu Jun 3 15:13:25 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Thu, 3 Jun 93 15:13:25 PDT Subject: snake oil In-Reply-To: <9305281652.AA13454@soda.berkeley.edu> Message-ID: This raises a question... I don't think this has been addressed yet (I am a bit behind in my mail) and might be worthwhile putting in the FAQ... If I just dreamed up a new gee whiz "new" cypher, should I post it to the list for comments, or is this frowned on? (As it happens, I happen to have what I **think** is a new approach to cyphering, and the answer to this question will determine wheter anyone hears about it or not...) Is there a comprehensive list of short "already been done" types of cyphers? (Whether failed or "still" succesful.) A good book? --- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger On Fri, 28 May 1993, Eric Hughes wrote: > >I, for one, will never use any crypto system for which the algorithm > >hasn't been extensively published and scrutinized. > > I am in total agreement. From ryan at rtfm.mlb.fl.us Thu Jun 3 15:21:09 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Thu, 3 Jun 93 15:21:09 PDT Subject: Clipper on CNN HN Message-ID: The current CNN Headline News has a spot on the Clipper chip airing after the Sports section, I just barely caught it by accident. I have to leave now to do some consulting, but I have my VCR set up to record it the next time around. Summary of the tape: ____BEGIN SUMMARY____ The Clinton Administration is developing, along with the NSA and the NIST a chip which will ensure private communications between telephones and fax machines and such. Current plans are for the keys to be held in escrow by two seperate (unnamed) government agencies. Much was made about the objections made by people at the NIST hearings about the questionable constitutionality of the chip and a direct quote was aired by a woman saying during the hearings that 'the chip would expand the powers of the government to invade the privacy of citizens to even greater than what it already is' (paraphrase) and also about the objections of companies who are afraid of being blackballed and prevented from doing business unless they use the chip. There was a small hint of a fear that the 'voluntary' status of using the chip would not last for long. Also, AT&T (surprise) has apparantly announced that it is already developing a system using the chip and showed a prototype on the air. It seemed to be a lot larger than necessary, a huge black box with a little LCD display saying 'secure' and whatnot when you activated clipper security. There was an interview with a fed type who repeated all of the old stale arguments about making conversations secure for him but not for the criminals. ____END SUMMARY____ I think that the spot was definitely leaning toward exposing the objections that people have toward the chip, even if the people at CNN didn't really understand for sure what those objections are. The whole thing might have been a little unclear for the average Joe as to what the real problem is with this newfangled system, and I think that more uninformed coverage like this is likely to turn people against us; they may start to see us as the bad guys, a bunch of people who are against privacy by our objection to this thing. Anyway, now that it has hit CNN, it is officially mainstream and it may well become a hot, trendy news item. What we need now are hoardes of people who will volunteer to be consulted with as 'experts' on the issue for local news and such. Gotta go now, gotta write some code... Try to catch the spot. -Ryan the Bit Wallah From marc at GZA.COM Thu Jun 3 15:53:03 1993 From: marc at GZA.COM (Marc Horowitz) Date: Thu, 3 Jun 93 15:53:03 PDT Subject: snake oil In-Reply-To: Message-ID: <9306032252.AA12490@dun-dun-noodles.aktis.com> >> If I just dreamed up a new gee whiz "new" cypher, should I post it to the >> list for comments, or is this frowned on? (As it happens, I happen to >> have what I **think** is a new approach to cyphering, and the answer to this >> question will determine wheter anyone hears about it or not...) This list is, IMHO, for the discussion of privacy enforced by technology in the hands of the user.. New approaches (like remailers or money algorithms) are within the domain of this group. New encryption algorithms are better discussed in the newsgroup sci.crypt. I admit that I'm a bit skeptical. So far, every new encryption scheme someone has proposed here has either been trivially defeated, or done before. I'm tired of showing how most schemes are reducible to a one-time pad or codebook :-) In any case, I think there are more experienced cryptographers on sci.crypt than on this list, but I could be wrong. Marc From m5 at vail.tivoli.com Thu Jun 3 15:59:13 1993 From: m5 at vail.tivoli.com (Mike McNally) Date: Thu, 3 Jun 93 15:59:13 PDT Subject: Clipper on CNN HN In-Reply-To: Message-ID: <9306032258.AA19159@vail.tivoli.com> > The current CNN Headline News has a spot on the Clipper ... > > I think that the spot was definitely leaning toward exposing the > objections ... I hope they've got a new clip. The one I saw about 2 weeks ago was lead into with the statement that "some fear the new scheme might compromise the privacy rights of criminals." Duhhh. The first sound bite was an FBI dude saying that he didn't think that "child molesters, drug lords, bombers, snipers, terrorists, and kidnappers" have any right to privacy. It went downhill from there, ending with a weak 5 second statement from somebody at CPSR (weak, no doubt, because of editing, not lack of CPSR concern). Mike McNally From eichin at cygnus.com Thu Jun 3 16:38:58 1993 From: eichin at cygnus.com (Mark Eichin) Date: Thu, 3 Jun 93 16:38:58 PDT Subject: [comp.os.linux.announce] New loop devices, even with DES encryption Message-ID: <9306032338.AA19180@cygnus.com> If you actually want to see the linux loopback code I mentioned, here's the real announcement. _Mark_ ------- Start of forwarded message ------- From: almesber at nessie.cs.id.ethz.ch (Werner Almesberger) Newsgroups: comp.os.linux.announce Subject: New loop devices, even with DES encryption Keywords: loop devices, DES, mount regular files Date: 1 Jun 93 20:13:47 GMT Followup-To: comp.os.linux Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH Version 0 of the new loop devices patch is in tsx-11.mit.edu:/pub/linux/BETA/loop and nic.funet.fi:/pub/OS/Linux/BETA/loop The files are: lo.0.tar.z The loop devices patch des.0.tar.z DES-encryption for the kernel Note: If you're FTPing from outside the U.S. or Canada, please get the DES patch from nic.funet.fi, because of the well-known US export restrictions. (DES encryption is optional. The loop devices also work without it.) Loop devices give you the ability to mount file systems from regular files. Additionally, you can use them to have more than one file system on one partition and to have transparent on-line encryption of all your data. The loop devices patch is relative to ALPHA 0.99pl10, but it'll probably work with 0.99pl9 and 0.99pl10 too. The DES patch should work with any recent kernel. This is a new implementation of loop devices by Theodore Ts'o, I'm just maintaining the code. Unlike my old loop devices, which are also in some versions of SLS, the new loop devices will continue to work after variable block sizes are added to the kernel. The DES code is derived from Eric Young's DES library. I originally wanted to use UFC crypt, but its memory requirements make it a bit difficult to handle. Maybe later. - Werner -- _________________________________________________________________________ / Werner Almesberger, ETH Zuerich, CH almesber at nessie.cs.id.ethz.ch / /_IFW_A44__Tel._+41_1_254_7213__________________almesber at bernina.ethz.ch_/ ------- End of forwarded message ------- From pmetzger at lehman.com Thu Jun 3 16:55:05 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Thu, 3 Jun 93 16:55:05 PDT Subject: snake oil In-Reply-To: Message-ID: <9306032354.AA12581@snark.shearson.com> Nickey MacDonald says: > This raises a question... I don't think this has been addressed yet (I > am a bit behind in my mail) and might be worthwhile putting in the FAQ... > > If I just dreamed up a new gee whiz "new" cypher, should I post it to the > list for comments, or is this frowned on? (As it happens, I happen to > have what I **think** is a new approach to cyphering, and the answer to this > question will determine wheter anyone hears about it or not...) My suggestion is this. Its perfectly appropriate to post the cypher to the list PROVIDED you take the right attitude, which is to say something like: "The following is something I just thought up. I'm not a pro, and I worry that this thing has holes. Anyone care to give me hints on what they might be?" My objection has never been to people developing new cypher systems. Its always been to people claiming, in the absense of very strong attempts to break their system, that their system is secure. Provided you aren't trying to encourage people to use a new system you are developing, what harm can discussing it possibly do? On the other hand, great harm can be caused by fools pushing systems they have designed in the absense of expertise -- that was specifically the sort of objection I had to the whole "Dolphin Encrypt" thing. Sci.crypt is likely a better place to post a query about a new cypher, of course. > Is there a comprehensive list of short "already been done" types of > cyphers? (Whether failed or "still" succesful.) A good book? I would suggest looking in the sci.crypt FAQ -- its got lots of good intro material and reading lists. Perry From mark at coombs.anu.edu.au Thu Jun 3 17:15:10 1993 From: mark at coombs.anu.edu.au (Mark) Date: Thu, 3 Jun 93 17:15:10 PDT Subject: Pc environ (fwd) Message-ID: <9306040014.AA10402@toad.com> For those others that insist on living in 640K... :) Forwarded message: >From mark Wed Jun 2 20:29:47 1993 >Subject: Pc environ >To: 74076.1041 at compuserve.com >Date: Wed, 2 Jun 1993 20:29:47 +1000 (EST) >>I couldn't get Karl's hopmail.bat to run on my PC (not enough environment >>space?) so I wrote this in C and it works OK. >Hey Hal, >Um although I abhor dos, I happen to know something of it... you might want >to put the line: >shell=c:\command.com /e:1024 /p >in your config.sys... that will give you a K of environment space instead >of the usual (256bytes?) they usually give you. Increase the 1024 as >needed. >Mark >mark at coombs.anu.edu.au From nobody at shell.portal.com Thu Jun 3 17:17:36 1993 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Thu, 3 Jun 93 17:17:36 PDT Subject: Software infrastructure Message-ID: <9306040011.AA22327@jobe.shell.portal.com> In thinking more about Eric's proposal for a terminal program, I can see the value in putting in the hooks for stream encryption even if we don't implement it right away. That should be one of the points of this software, to have it be easily expandable. So we would want to make it so that a layer could be inserted just above the serial I/O layer which would do transparent encryption. The mechanism for creating the shared keys could be added later, perhaps. We are seeing a lot of different suggestions here, which is good at this point. Some of the issues: Overall functionality To keep our focus: we want something which will help the average computer user who has a PC or something similar at home be able to use encryption easily in sending and receiving email. The problem is that people send and receive mail in very many different ways. So we propose to provide a very flexible and extensible solution that can be adapted to many situations. This leads to the idea of a terminal program with built-in encryption, since most people can use a terminal program to get their mail. This would not be aimed at people running UUCP or similar fancy protocols on their home machines. They must be pretty sophisticated to get this stuff working. PGP and RIPEM already come with a bunch of scripts to let them be used in Unix and similar environments. (Maybe I'm mistaken, though, in thinking that good solutions already exist for these people. I don't know much about this mode of operation.) Build or Buy Do we roll our own or do we try to tap into an existing program? Among existing terminal programs, do we: try to provide add-ons to widely used commercial or shareware programs (for which we don't have source); try to convince the authors of these programs to make the changes we desire; or find such a program which has source available (e.g. kermit) and take that as our starting point? Target OS We have seen suggestions for DOS, Windows, Unix, and Linux (about which I know nothing). DOS and Windows are the biggest target market and the most likely to be used by the naive users we are trying to help, IMO. It would not be too hard to write for DOS but to isolate the OS dependencies so it could be easily moved to Unix (and perhaps Linux). But the DOS vs Windows decision is more fundamental. More generally, it is the command-line vs GUI decision. It's very hard to write code which is portable across these two approaches. I would lean towards the command line approach because it is easier to write portable code, in my experience (portable between DOS and Unix, say, is easier than portable between Windows, X, and Mac). But just fixing on Windows is another option. Serial Interface Focusing on DOS, apparently there are several ways of interfacing to the serial port. I know nothing about these. The main issues would be portability - does it require the user to have some third-party software, or to run on only a limited subset of PC clones - and efficiency - can we run at 9.6 or 14.4 Kbaud? What solutions accomplish both of these? And what if we went with Windows? Does that narrow our options? User Interface I still think this is one of the harder issues. How exactly can we make this easy to use? Can anyone suggest a non-magical (e.g. no mind-reading) but still ideal interface for encryption? I kind of liked Greg's suggestion of using the rollback buffer for decryption - when it sees an encrypted message go by it automatically decrypts it and offers it to the user to see. I'm not exactly sure what you do with it then, though. It would be helpful for me to hear more about how people read and send mail on their home computers, in some detail. If Mike Diehl got enough responses to his survey that would be good to hear about, too. Hal Finney 74076.1041 at compuserve.com From hughes at soda.berkeley.edu Thu Jun 3 18:05:09 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 18:05:09 PDT Subject: Hardware vs software In-Reply-To: <9306030216.1.2999@cup.portal.com> Message-ID: <9306040101.AA05981@soda.berkeley.edu> >DES is kind of optimised for doing it in hardware, so don't take >how slow it is in software as the limit for good encryption. I wasn't saying that DES was the fastest of all possible secure ciphers. I was saying that DES is the fastest of all ciphers which are widely believed to be secure. This aspect of security is moderated by the key length of DES, which is too short to be secure against a well-funded opponent at present, but which is perfectly adequate for other purposes. Eric From hughes at soda.berkeley.edu Thu Jun 3 18:10:18 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 18:10:18 PDT Subject: snake oil In-Reply-To: Message-ID: <9306040106.AA06151@soda.berkeley.edu> > (As it happens, I happen to >have what I **think** is a new approach to cyphering, Post away. If you upload a copy of the source to the directory pub/cypherpunks/incoming on the ftp site, I'll make it available to everyone. I would like to see this regardless of whether it actually is secure. It is a well-founded maxim that no one should design a cipher without having broken a few first. There is a need, apropos of training the desginers, for insecure ciphers, not so they can be deployed, but so that other insecure ciphers will not be. Eric From hughes at soda.berkeley.edu Thu Jun 3 18:25:05 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 18:25:05 PDT Subject: Clipper on CNN HN In-Reply-To: Message-ID: <9306040121.AA06595@soda.berkeley.edu> >The current CNN Headline News has a spot on the Clipper chip airing after >the Sports section, It is likely that this is a new clip rather than the old one. There is a large class of stories for which the print media drive the televisual. See _Bad Day at Black Rock_ for a first hand account of this. The CBS News staff read the New York Times every morning to figure out what to cover. In all likelihood they've just picked up the story from Newsweek, slant and all. It is because of mechanisms such as these that it is vital that people get out there and start talking to local press, of whatever kind. The media predate on each other's research. Getting the story out _anywhere_ is useful, because it will frequently trigger more coverage, and we desire the escalation of coverage. We must make ourselves heard widely because if we can bring the wiretap chip to public debate, we will have won. The languor of apathy creates a veil of secrecy for the public equally as effective as lies and denials. If we can get enough press coverage about this, it will become an "issue". One of the best things we could hope for is that "Nightline" will have Ray Kammer v. Whit Diffie. Public opinion will not sit well with making it illegal to keep secrets. Phone calls to CNN, asking for explanations of that short story will help, hint, hint. Eric From i6t4 at jupiter.sun.csd.unb.ca Thu Jun 3 18:38:24 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Thu, 3 Jun 93 18:38:24 PDT Subject: Work the work! In-Reply-To: <9306020432.AA20624@soda.berkeley.edu> Message-ID: I have shied away from any "political" action against Clipper because I am unsure how a Canadian can help... I would like to think that the Canadian government will not follow the US lead, but I'm sure that its just a matter of time. I am open to suggestions... How do I avoid being told that I'm fighting "someone elses" war? --- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger On Tue, 1 Jun 1993, Eric Hughes wrote: > If you are doing something, continue. If you are not, start. From anton at hydra.unm.edu Thu Jun 3 18:50:17 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Thu, 3 Jun 93 18:50:17 PDT Subject: the right platform for these projects Message-ID: <9306040150.AA04811@hydra.unm.edu> I agree wholeheartedly that a commandline, portable, version should come first. Porting that separately to X, Win, Mac, etc will not be nearly the chore that porting a Windows app to Unix will be. Re: the ubiquity of Windows: LOTS of people have Windows. But... The idea that new machine sales are mostly Windows machines is given the lie somewhat by the fact that they are also all DOS machines, and that Windows is just bundled. Many people don't install it due to the disk space leeching. And a LOT of people with Windows don't use it for comm stuff because Windows + comm = nightmare. So yes, make a Windows version. NO don't start with a windows version. One of your biggest markets will be the BBS crowd, 90+% of whom use DOS, not Windows, for comm apps. And I still heartily recommend tackling this from several different angles. Sure make a new term, but also get Telix, et all to go along with it. Get Fido-tech mailer makers to support the ^ENC "standard", etc. -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From hughes at soda.berkeley.edu Thu Jun 3 18:58:26 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 18:58:26 PDT Subject: Work the work! In-Reply-To: Message-ID: <9306040154.AA07862@soda.berkeley.edu> >I have shied away from any "political" action against Clipper because I am >unsure how a Canadian can help... Preempt government restrictions by fighting for the explicit right to strong cryptography. Point out how those foolish folks south are going to screw themselves over by government mandated cryptography. One of the arguments that is being made in this country against the wiretap chip is that it will harm overseas business. In Canada you can turn this around and show what a great economic boon you have available. You can point out that the US has abandoned their foreign markets in secure communications, which will, of course, be the only kind of communications of the future. Get Northern Telecom on your side. Eric From fnerd at smds.com Thu Jun 3 19:31:09 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Thu, 3 Jun 93 19:31:09 PDT Subject: Secure transport layer paper Message-ID: <9306032110.AA06199@smds.com> There's a paper in the Feb. '93 _IEEE Transactions on Software Engineering_: "Trust Requirements and Performance of a Fast Subtransport-Level Protocol for Secure Communication" by P. Venkat Rangan It's about a protocol called Authenticated Datagram Protocol, and issues about using it in a "subtransport level." He's tried it on Suns. The work was done at Berkeley in 1990, the guy's at UCSD now. -fnerd From mark at coombs.anu.edu.au Thu Jun 3 19:53:30 1993 From: mark at coombs.anu.edu.au (Mark) Date: Thu, 3 Jun 93 19:53:30 PDT Subject: CryptoStacker, long term vision Message-ID: <9306040253.AA14575@toad.com> >A related topic to encrypted disk drives. Anybody who has a desire to >see their data around long term makes backups of their drives. At >least one of these backups is usually physically near the drive in >question. > >What good it is to have an encrypted disk if the backups are not also >encrypted? > >Backups occur at the file system level, where an encrypted file system >does not appear encrypted, so that work here does not directly >leverage to encrypted backups. This problem is most easily solved by copying the entire partion/file that is encrypted as blocks. These blocks are size according to the destination media. If you use floppies you break the encrypted fs/file into (e.g.) 1.44 meg chunks, if you use tape you can throw the whole block at the media, similarly with another hardisk. The unix/linux/386bsd 'dd' program is especially useful for this purpose and I assume there are similar utils for dos. For replacement you simply dump the whole lot back as one encrypted file system. This method should be faster than grabbing individual files and backing them up as the program just has to seek to a specified place and start reading a defined amount of [encrypted] data. Mark mark at coombs.anu.edu.au From kelly at netcom.com Thu Jun 3 20:28:17 1993 From: kelly at netcom.com (Kelly Goen) Date: Thu, 3 Jun 93 20:28:17 PDT Subject: (fwd) [comp.os.linux.announce] New loop devices, even with DES encryption Message-ID: <9306040328.AA26468@netcom.netcom.com> Organization: NETCOM On-line Communication Services (408 241-9760 guest) Path: netcom.com!netcomsv!decwrl!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!agate!usenet From: almesber at nessie.cs.id.ethz.ch (Werner Almesberger) Newsgroups: comp.archives Subject: [comp.os.linux.announce] New loop devices, even with DES encryption Followup-To: comp.os.linux.announce Date: 4 Jun 1993 01:35:22 GMT Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH Lines: 42 Sender: adam at soda Approved: adam at soda Distribution: world Message-ID: <1um8sq$86e at agate.berkeley.edu> References: <1993Jun1.201347.7433 at klaava.Helsinki.FI> NNTP-Posting-Host: soda.berkeley.edu X-Original-Newsgroups: comp.os.linux.announce X-Original-Date: Tue, 1 Jun 1993 20:13:47 GMT Archive-name: auto/comp.os.linux.announce/New-loop-devices-even-with-DES-encryption Version 0 of the new loop devices patch is in tsx-11.mit.edu:/pub/linux/BETA/loop and nic.funet.fi:/pub/OS/Linux/BETA/loop The files are: lo.0.tar.z The loop devices patch des.0.tar.z DES-encryption for the kernel Note: If you're FTPing from outside the U.S. or Canada, please get the DES patch from nic.funet.fi, because of the well-known US export restrictions. (DES encryption is optional. The loop devices also work without it.) Loop devices give you the ability to mount file systems from regular files. Additionally, you can use them to have more than one file system on one partition and to have transparent on-line encryption of all your data. The loop devices patch is relative to ALPHA 0.99pl10, but it'll probably work with 0.99pl9 and 0.99pl10 too. The DES patch should work with any recent kernel. This is a new implementation of loop devices by Theodore Ts'o, I'm just maintaining the code. Unlike my old loop devices, which are also in some versions of SLS, the new loop devices will continue to work after variable block sizes are added to the kernel. The DES code is derived from Eric Young's DES library. I originally wanted to use UFC crypt, but its memory requirements make it a bit difficult to handle. Maybe later. - Werner -- _________________________________________________________________________ / Werner Almesberger, ETH Zuerich, CH almesber at nessie.cs.id.ethz.ch / /_IFW_A44__Tel._+41_1_254_7213__________________almesber at bernina.ethz.ch_/ From ryan at rtfm.mlb.fl.us Thu Jun 3 20:31:19 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Thu, 3 Jun 93 20:31:19 PDT Subject: CryptoStacker, long term vision In-Reply-To: <9306031900.AA02558@ishara.poly.edu> Message-ID: On Thu, 3 Jun 1993, A1 ray arachelian wrote: > > 2) does anybody know how the hell Stacker or DoubleStor or > > whatever executes the actual interception of the read/write > > routines and stacks them? I don't get it at all. I am > > more than willing to learn to get this thing working though. > > > > Anyhow to make the story short, if I wrote an image mounter device driver which > would be able to grab DIM files and pretend that they were on the A: or B: drive > then we could also install the programs without breaking out the recylced disk > box. :-) Couldn't you just do that with the assign command in DOS? or is that a new command? > I never got around to it because of other projects, but, what you need to do is > to write a device driver that becomes accessible via the IOCTL calls. That's > the way logical drivers (such as Stacker) install themselves. Yeah, I am assuming that is the way I will have to organize the system. I want it to be totally transparant, that seems like a good way. > Also, the program you're writing (I believe) has been already written and is > part of Norton Utilities, but uses either DES or some other weak form of > encryption. You might want to buy Norton Utilities and play with that program > and see what makes it tick. Basically a program like MSD (Microsoft Diags) > can tell you exactly what interrupts it patches itself into. I have heard this from someone else. It kind of takes the wind out of my enthusiasm, but not too much... I still think that there is a need for a good, strong system out there with some seriously dedicated password key protection and such. Also, it needs to be freeware (or shareware, depending on how long it takes to write) so that security won't just be in the hands of the people who can afford to buy it from companies. I also think that it would be a lot more valuable if it were distributed with code so that any user who wanted could inspect it for trapdoors. > On to the sector remapping. The way stacker and doubledisk and the other > suite of driver level compressors work is basically, they allocate a huge > file on the hard drive, and then do a remapping at the sector level. That > is you've got the data itself and an index table into the data for every > sector. When a sector is written to the drive, the driver compresses the > sector, so say, it was 512 bytes, it now becomes 128 bytes (if we're lucky) > so what Stacker does is, looks in its index table, finds 128 bytes free in > the huge file it allocated, writes the data there, and then sticks the > position of the data, and it's size (after compression) in the index table. > (Of course it also marks that 128 bytes as taken.) Umm, perhaps this is overly optimistic, but I was hoping that I would be able to use an algorithm that did 1 byte in / 1 byte out encryption so that I wouldn't have to deal with sector remapping. This would greatly speed up the process, make it more crashproof, and besides, it would be a hell of a lot easier... I was thinking that I would even basically leave the FAT and such intact, or at least only slightly modified. > I believe it also does some other funky stuff like changes the allocation > table or the bytes free to twice the space it's got left, so that DOS > doesn't choke when it thought it had 10,000 sectors free and the hard > drive ran out of space when it tried to write #4,999. :-) > > So you might want to do this with RSA. But better yet, why don't you > find a quick compressor algorithm (say some sort of LZ type method) > and stick that in as well. This way you are writing a public domain > version of stacker >WITH< encryption. (Since you'd have to remap > the sectors anyhow, you might as well compress them too...) I have been pointed in the direction of the IDEA engine in PGP, which will take 1 byte in / 1 byte out. This would be ideal (snicker) for the reasons that I mentioned before. As for compressing also, that is a really good idea, but I think that I will leave that one up to posterity, or at least to the next guy that tries to midofy the thing, I am concerned enough with getting it to work at all, and compression would add the problem of having to do sector remapping, which I would like to avoid at first. > The above is just a theory and hasn't been tested. I believe that > this is what Stacker does, but I'm not exactly sure. :-) But it > does sound logically right. Sounds good to me, and it is consistent with the advice of others (thanks a lot guys, I really appreciate the help) and the books that I have found since this started two days ago... > So if I'm wrong, let me know as you've got my curiosity up in this > matter. I'll keep everyone updated no problem. How else am I going to get suggestions and help? -Ryan the Bit Wallah From ryan at rtfm.mlb.fl.us Thu Jun 3 20:31:19 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Thu, 3 Jun 93 20:31:19 PDT Subject: CryptoStacker - Suggestions In-Reply-To: <9306031827.AA05452@tstc.edu> Message-ID: On Thu, 3 Jun 1993, Patrick E. Hykkonen wrote: > > This model of using a device driver means that there is going to have > > to be at least two partitions on the disk: one to boot from, and one > > to be encrypted. The device driver itself and the operating system > > can't be on the encrypted disk, because those components must be > > loaded before the encrypted disk is accessible. Most people are not > > Why not have the device driver create a file (possibly of varying sizes) on > the hard drive which the encryption device driver then makes look like another > drive?!? This is how the compression programs work, seems to me a pretty Hmm, nix on that, I would have to do some sector remapping, which would not only slow it down and make it more vulnerable, it would just be more crap that I would have to deal with which might crash the thing in the long run. Besides, I think that most people using this would actually PREFER to have more that one partition, with one unprotected. This would allow you to use the setup that I have mentioned before, with one 'fast' partition and one 'secure' partition. You would simply have to make sure that the system was booted from a 'fast' partition. Quick, simple, stuff that you don't have to be a genius to make work. (remember we are talking about protecting non-cypherpunks here as well as us computer gurus) I would like to implement a system in the future which would do compression as well as encryption (are there any good algorithms that just happpen to do both at the same time? Maybe somebody should get on that, it would certainly be useful) and that would require a system like you mention, but I will stay with simple for the first version. -Ryan the Bit Wallah From ryan at rtfm.mlb.fl.us Thu Jun 3 20:31:21 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Thu, 3 Jun 93 20:31:21 PDT Subject: CryptoStacker, long term vision In-Reply-To: <9306031522.AA26005@soda.berkeley.edu> Message-ID: On Thu, 3 Jun 1993, Eric Hughes wrote: > A related topic to encrypted disk drives. Anybody who has a desire to > see their data around long term makes backups of their drives. At > least one of these backups is usually physically near the drive in > question. > > What good it is to have an encrypted disk if the backups are not also > encrypted? > > Backups occur at the file system level, where an encrypted file system > does not appear encrypted, so that work here does not directly > leverage to encrypted backups. This is a good point. The only thing that I can think of in response is that there is now a need for a cryptobackup system. I can easily see how this could be accomplished with disk spanning, but I'm not sure that we could create something to work with all of the different tape drive standards. Perhaps just write a freeware system that could handle disk spanning and a few major, common tape systems (Colorado, etc...) I have to admit, that does present a minor problem. There is, of course, another way to do it which would speed things up by not having the date come from the disk, get decrypted by my driver and then get immediately encrypted agian before they get to the backup, and that is to simply operate the backup system as normally from the 'fast' partition with the encryption driver turned OFF. You back up the secure partition that way, and then whatever goes to the tape is pure garbage, and then you just turn the driver back on by rebooting. When you want to restore you simply turn the driver off, restore to the secure partition, and reboot to get your data again. No matter what kind of a system you are using, you are still going to need some unencrypted disk space to boot from, so that is where you stick your backup programs. Hell, the more I think about it, it won't be any problem at all... > > Eric -Ryan the Bit Wallah From ryan at rtfm.mlb.fl.us Thu Jun 3 20:43:10 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Thu, 3 Jun 93 20:43:10 PDT Subject: CryptoStacker, long term vision In-Reply-To: <9306031512.AA25490@soda.berkeley.edu> Message-ID: On Thu, 3 Jun 1993, Eric Hughes wrote: > >This is tiring drivel concerning the CryptoStacker project. > > If you want help, it is wise not to recklessly insult those who are > offering it. By your own admission, you do not have a lot of > experience here; you seem to be saying "I know exactly what I don't > know," which, may I add, is a common delusion of the inexperienced. Oh please, not a flame... I'm trying to create something here, and I need a lot of help, since everyone seems to know exactly how this should be done but none of them want to actually get off of their heinies and write it. The last thing that I need is to start getting flamed, the whole project will rapidly go down the tubes... > You seem to have fixed a model of how the encrypted disk would work > and don't want to debate it. The model is exactly that which requires > the most scrutiny, because it has the most far reaching effects. If > the model is flawed somehow, that's what you want to know before you > begin, not six months later. I am paying very close attention to the suggestions on overall format, you may have noticed that my concept has changed from a hardware PGP encryption of the entire disk with PCMIA keys to a more realistic DES software encryption through device drivers and multiple partitions. I am certainly not closed off to ideas, and the last thing I need, as I said before, is to start getting flamed. > I take it that you want people to use this software after it is > written. if so, then pay close attention to user acceptance issues > such as performance and key handling. You neglect them at your own > risk. I am certainly not neglecting either issue, performance is one of the main reasons why I am interested in NOT doing sector remapping and compression along with the encryption, and I am trying to find a convinient method for keeping keys that an end user would be happy with. Among the suggestions at hand: An ISA card with the key burned into EEPROMS and a keypad attached for verification of user ID PCMIA cards holding keys and a mandatory PCMIA slot Users typing long keys in manually Keys held on floppy disks Keys held on the HD itself I believe that keys held on floppies with password verification to be the most feasable, the easiest and the most likely to be understood and accepted by end users. Please stop flaming me, I'm doing the best I can here... > I would suggest that you first version just be a device driver that > has no encryption, but only the hook for it. The device driver > skeleton for a disk will be difficult enough, as you have to support a > whole lot of operations just so you can have a place to put the > encryption. This is exactly the software infrastructure problem in > another context. Yes, I can see the advantages of using a device driver for this application. I am now doing research on just that. The idea of setting up the initial version to simply pass through data unharmed is also a very useful suggestion. Thank you. > After you have a device driver skeleton working, you can add both > hardware and software encryption modules. There is no need to be > exclusive about this. It is clear to me from your comments that you > haven't timed any DES routines and done a calculation of increased > latency times, and although I hate to see code development go to > waste, it's your time, not mine. > > As far as picking an encryption algorithm, use DES. DES is the > fastest symmetric keyed block cipher that is thought to be reasonably > secure. DES is not particularly fast in software; it was designed as > a hardware standard and does lots of bit manipulations. DES is fast > enough for serial communications, but that 1000 times less the > bandwidth than a hard disk. Is it just my impression or did you just tell me that 1) DES is too slow to use, I am stupid for trying. 2) DES is what I should use. What the hell did I do to deserve getting flamed by someone who I so respected about ten minutes ago? Do you instinctively do this because I don't yet understand a few highly technical concepts yet? Would you rather this whole project just get scrapped just because I am not yet as proficient in this area as you? How did you learn, did people flame you when you tried to create something and asked for advice? What the hell, I'm just trying to help. You talk about how I should be careful about inadvertently trampling on the people giving me advice. I am sorry I certainly did not mean to (and I think that you will notice that later in the message I specifically thanked him several times for his input) but what about you specifically and intentionally insulting the guy who is actually trying to WRITE the thing? I have other things to do, I am a professional programmer and I get payed plenty to write code for other people. What I am doing here is trying to write some code for EVERYONE for FREE and I am VOLUNTEERING my time. (lots of it, I might add) > Of course, you don't want to run DES in codebook (aka naive)mode. > (Codebook mode is where you just simply map block to block; the > problem is that identical blocks map to identical blocks.) You'll > want some sort of other mode, like a counter mode, to make sure you > don't get identical ciphertexts. It is also a bad idea to encrypt the > whole disk with one key; it makes brute force searches much easier. I see. How do codebook and counter mode relate to the layering that I hear about (ie, single, double, triple DES) are these simply single or multiple layers of these modes, or did I miss something? (I still have a shortage of good cypto books at my command, I have three that I think will be very helpful on order at the local university library) > Your keying material should be long. I earlier suggested one key per > track. These keys are going to have to be stored somewhere, and the > disk is the wrong place for it, clearly. This implies that the user > is going to have to have some key-holding device (likely a diskette) > which will be necessary in order to unlock the partition. the keying > material should be password protected. This device will be have to > used at boot time if anything necessary to boot is stored on the > encrypted partition. I agree about length and multitude. How does the key length affect the speed of the algorithm? I am also concerned about having the keys sitting around in memory once they are read from the disk. This would just open the system up to somebody running a key scanning program on your system and grabbing the keys right out of memory. I'm still not sure what to do about this. It is a really good reason to go to PCMIA cards with the PCMIA DMA mapped in the future, but I can't quite think of a good solution right now... > Keying material will need to be backed up. This should be made as > painless as possible, otherwise there will be plenty of people losing > whole drives. Yes, that shouldn't be any problem. I am thinking more an more that the guys who wrote Stacker knew what they were doing... I forsee a seperate utility program which would sit around on the uncompressed partition for dealing with keys and such, this would be where I would handle key backups. > Keys in the driver should time out after some specifiable period. > Files that are open when the time-out occurs and the programs that > have them open are going to have to be dealt with gracefully. I thought of this as well as a possible solution to the problem of having the key sitting around in memory, but it really seems to me like a great way to lose data by crashing programs. I just don't see how I could make it timeout gracefully and not crash whatever is running. Something that I did think of though, is tying the timer into the int 24 routine which terminates program execution, so that if enough time had passed it would shut down the drive, but only AFTER you have exited your program. This would provide the timer support and still not be horrible likely to wreck the hell out of something and kill some data. > This model of using a device driver means that there is going to have > to be at least two partitions on the disk: one to boot from, and one > to be encrypted. The device driver itself and the operating system > can't be on the encrypted disk, because those components must be > loaded before the encrypted disk is accessible. Most people are not > going to go out and buy a new disk to be the encrypted partition. > Thus, this is going to mean a full backup of the existing disk, an > operation with FDISK to do the partitioning, then, assuming the driver > works right the first time, restoring everything else on the encrypted > partition. What is the effect of _this_ on user acceptance? This looks awfully flamish to me too, but I'll let it pass... I think that this is likely to be the biggest problem with my system as I am considering it. An obvious way around this would be to use a system which does sector remapping and stores the entire file system in one huge file a la Stacker, so that we don't need to actually physically partition the disk. I can think about how to implement a system like this after I get a non-sector indexing system working. I think that a system like the aforementioned would be possible to painlessly install with an installation program just like the one that Stacker uses to painlessly turn your disk into two virtual disks, one stacked and the other the boot disk, with no backing up and repartitioning involved. > Eric Much as the flamage has ticked me off, you have provided some of the most helpful information and suggestions to date and I very much appreciate your help. I still truly don't understand what I did to provoke you, other than working on a crypto project, but I do appreciate your help. I can only hope that I caught you late at night or something or perhaps just misunderstood the severity of your insults. -Ryan From newsham at wiliki.eng.hawaii.edu Thu Jun 3 21:31:26 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Thu, 3 Jun 93 21:31:26 PDT Subject: good day Message-ID: <9306040431.AA17279@toad.com> Ahh.. what a good day it was today! I am currently logged in to my UNIX account from home. I am sitting here mailing you guys, and everything I type is being sent over the modem in encrypted form. I worked out some very irritating bugs in my software and have my link protocol up and running pretty reliably. It still needs some cleaning up. I will be cleaning it up a little and running it on a few different platforms to test it out. The code is basically the same as the unix end I mailed out to several people earlier (with just 3 or 4 lines changed), but I now have a good, functional VT100 end for my amiga. I will post here after I clean up and test the code a little and get it ready for "release". So if you're interested, basically just wait. But I am looking for people who are willing to port to other platforms. The common code should need no porting, what needs to be done really is to find a good P.D. term program in source form and modify it (this is what I have done). The common code was written with this in mind and it shouldnt be terribly hard (simply replacing writes to screen and serial with encoding/decoding routines and then outputting the results, and small things like providing the user a way to turn on and off the encryption). Tim From mdiehl at triton.unm.edu Thu Jun 3 21:53:22 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Thu, 3 Jun 93 21:53:22 PDT Subject: Software infrastructure In-Reply-To: <9306040011.AA22327@jobe.shell.portal.com> Message-ID: <9306040452.AA13658@triton.unm.edu> According to nobody at shell.portal.com: > > It would be helpful for me to hear more about how people read and send > mail on their home computers, in some detail. If Mike Diehl got > enough responses to his survey that would be good to hear about, too. I've gotten a bunch! I'm storing the messages in a file which will later be edited. Then I'll tally everything up. Expect results on the list monday. Of course this means that if you haven't replied to my poll, you need to do so by saturday night, mountain time. Well, now I will describe how I send/receive mail on my system, the killer 8086-8 from Hell! ;^) I've been hyping my setup on this list for about a month. But since I've partially implimented a system like what we have been discussing, I'll give more details. First, my system configuration: MACHINE: AT&T 6300 PC HARDWARE: 640K, CGA, 1-360K fd, 1-20M hd. OS: PMS-DOS 3.1 and 4DOS 4.02 COMM PROGRAM: Telix 3.15 As you can see, I am developing for the low-end computer...... ;^) My email system is composed of (basicly) 2 files, a telix script, and a 4dos batch file. The telix script, at the moment, assumes it is already logged into my unix account. Then it does a 'frm' command and finds out how many NEW messages are in; it would actually be easier to simply dload all of my messages, but this is a bit more usefull. Anyway, it dloads them one at a time onto my pc using zmodem. Once on my machine, the script extracts From: and Subject: information from the message. Then it finds a unique filename to give the new message. This information is then stored in a form usable by the batch file, later. After it has done all this, it quits elm, and does some housekeeping. At this point, the communications program is finished and the mail is on my pc ready to read. Under an automatic implimentation (for, say a pay-as-you-go system) this can be done without any human intervention. After the messages have been collected, I, of course, want to read them. To do this, I run the mail.bat program. I am then presented with a menu allowing me to Create, Encrypt, Send, Read, Delete mail. Create, Encrypt, and Delete are trivial and don't lend much to this discussion. Read presents a menu of messages from the data file created by the telix script. At the moment, when a user selects a message to read, I use pgp to view it even if it is not encrypted. That can be fixed later. To send a message, you first have to have a file containing the message, duh. The user is asked for the name of this file, the address of the recipient, and a subject to use. This is information is then stored in a form usable by a third telix script. Ok, I lied, there are 3 files needed by my system. ;^) The actuall sending process is simple. The telix script reads the message information and starts elm, supplying the address and subject when asked. Then when it gets into vi, it ascii uploads the message directly into vi. This may seem kludgy, but it is rather portable since almost every online service lets you enter a message into an editor. Overall, the system works pretty well. I've still got a few bugs, mostly speed- related. But there is room for a lot of improvement. Here is what I would like to impliment. I'd like to have "encryption detection" which would allow my system to use the appropriate decryption software for message reading. If a message isn't coded, it should use list.com. I'd also like to expand "encryption detection" to recognize several types of encryption, pgp, pem, ripem, des, my-bitchin-crypto, etc. The telix script could tag the message as it s dloaded. I'd like to be able to use the system on many online services. The telix script could check the phone directory to see which system is it on. Then, when any system-specific stuff has to be done, such as starting the mail program on the host, a special function can be called to do that function on that host. The ascii up/down loading is fairly constant, and the local file manipulation doesn't depend on the host. At the moment, I am working on a Reply function. I know how I'm going to do it, I just haven't done it yet. More later. Well, if you have followed my this far, you either crazy or interested. ;^) It puzzles me why we are contemplating writing our own comm package when so many good ones are out there that can be made to serve our purposes. I'm open to comments..... Fire away! +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From hughes at soda.berkeley.edu Thu Jun 3 22:17:48 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 22:17:48 PDT Subject: CryptoStacker, long term vision In-Reply-To: Message-ID: <9306040514.AA18001@soda.berkeley.edu> > I am trying to find a convinient method for >keeping keys that an end user would be happy with. There need not be a single method used. This is the whole point of making a system with hooks--hooks for encryption, hooks for key management, hooks for drive control. Not only does this make for more flexible software, but its effect on modularity is striking. One requirement of any keying method, however, is that the keys be physically removable from the locale of the machine. That nixes a couple of the suggestions you mentioned. Any keying material for the volume of data represented by a hard disk will be longer than human memory or tolerance of delay. In an encrypted telecommunications system, the keys should be changed frequently. This is not necessary in the case of encrypted disks. You will know when your drive has been compromised; it won't be there any more. Unlike telecommunications, where one assumes that the eavesdropper has access to all of the data flow at all times, an encrypted hard disk gets looked at once. Of the two remaining solutions on the list, PCMCIA and floppy, there is no reason to chose one over the other. Properly modular software should be able to support both. Floppies will come first because there's no new hardware, but I personally would be much more comfortable using the more robust medium of EEPROM on a removable card. >Yes, I can see the advantages of using a device driver for this >application. The suggestion to use the MSDOS network redirector is also worth heeding. The CD extensions, for example, use it even though that drive is sitting right there in the machine. Using the redirector would allow one to support both separate partitioning and filesystem within a file. Here's another case where modularity wins. Many people may only need a bit of encrypted data, and a one or two Mb file might do it for them. (Sector remapping, BTW, is no big deal.) Again, you don't have to do both at the outset. re: choosing DES for the cipher >Is it just my impression or did you just tell me that > 1) DES is too slow to use, I am stupid for trying. Yes and no. > 2) DES is what I should use. Yes, at first. I remain to be convinced that software encryption of any kind is feasible for efficient bulk hard disk encryption. To be sure, there will always be the need for less efficient but secure storage. As I said in another posting, DES is the fastest trusted symmetric keyed block cipher around. I do not think you are stupid for trying DES. I _will_ think you are stupid, however, if you go ahead and implement it without first doing some estimates on the amount of time it will take and the effect on disk performance and latency. It is planning I am talking about here, not any particular final decision. You should allow hooks in the system for different block ciphers. If you do this, then some sort of algorithm byte should be present in the partition information. >How do codebook and counter mode relate to the layering that I >hear about (ie, single, double, triple DES) Single and multiple DES are still block operations. Codebook and counter modes refer to ways that block ciphers may be used; they are not specific to DES. Re: large amounts of keying material >I agree about length and multitude. How does the key length affect the >speed of the algorithm? There are two lengths here, do not confuse them. The first is the length of the key to the block cipher. The second is the total length of all such keys in aggregate. The first length is not directly relevant; it is the speed of the cipher which it keys that is. For simple iterated DES, however, these coincide. Single DES takes one third as long as triple DES. As far as aggregate length goes, the only time here is for one array indirection, which is miniscule in comparison to the encryption time. >I am also concerned about having the keys sitting around in memory once >they are read from the disk. For a standalone machine, this is not a concern. For a networked machine, one may simply consider that all of memory is available to an intruder. No memory protection is available. There is no way around such a fundamental limitation other than hardware. Therefore, don't worry about it, and inform the user of the issue. >> Keys in the driver should time out after some specifiable period. As I did not mention previously, this is an extremely difficult problem in DOS. >> Files that are open when the time-out occurs and the programs that >> have them open are going to have to be dealt with gracefully. >[...] tying the timer into the int 24 routine which >terminates program execution, so that if enough time had passed it would >shut down the drive, but only AFTER you have exited your program. No good. I use Desqview, which multitasks the machine. There's good reason not to require single tasking for this project. Many TSR do effective multitasking already. This is a really sticky problem. The criterion here is that programs with open files whould still be able to access them, and possibly even to write to them. No other access would be permitted. This requires abstraction at the file system level, not the device level, and thus would require mixing abstraction levels. Ick. The logging file systems mentioned in the context of Unix are what is needed here, because the recent activity need not be encrypted. If graceful shutdown cannot be achieved, there will still be times when ungraceful shutdown will be useful. One should not judge in advance another's relative values of information compromise and a slightly corrupted disk. At the very least, there should exist a program to zero out the keying material. Re: conversion from non-encrypted to encrypted >I think that this is likely to be the biggest problem with my system >as I am considering it. [...] I think that a system like the >aforementioned would be possible to painlessly install with an >installation program [...] with no backing up and repartitioning >involved. That's fine, but that program is going to have to get written as well, and it's going to have to be as reliable as a disk optimization program. After each sector write the disk is going to have to be in a stable configuration, so if power fails at that moment, all is not lost. This will not be easy, since you'll be dinking with the partition table all the time. If you can get such a thing working, it would enormously increase the actual usage of the encrypted disk drivers. It is an elegant idea, but a difficult one to implement. Eric From hughes at soda.berkeley.edu Thu Jun 3 22:25:56 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 22:25:56 PDT Subject: Software infrastructure In-Reply-To: <9306040452.AA13658@triton.unm.edu> Message-ID: <9306040522.AA18339@soda.berkeley.edu> >It >puzzles me why we are contemplating writing our own comm package when so many >good ones are out there that can be made to serve our purposes. Reliability. Scripts do not easily handle error conditions that might result in lost mail. They're fine for a few, but they aren't for all. Integration. Remembering what to do next is a large hurdle. Eric From eb at well.sf.ca.us Thu Jun 3 22:41:19 1993 From: eb at well.sf.ca.us (Eric Blossom) Date: Thu, 3 Jun 93 22:41:19 PDT Subject: DOS disk encryptor Message-ID: <93Jun3.224101pdt.13930-2@well.sf.ca.us> Ryan, Good luck on building the DOS disk encryptor. I belive that what you need to do is write a standard DOS disk driver (that can be installed in CONFIG.SYS) that implements the READ and WRITE primitives. I belive that they use the same entry point (the STRATEGY entry) in the driver. You would basically just call the BIOS routines to do the actual i/o. You don't have to worry about the FAT etc, just encrypt everything. You will probably want to use DES or IDEA and run it in CBC mode or Counter Mode. You would use the DISK BLOCK NUMBER as a piece of the key material (or part of the Initialization Vector), hence, even if the same data appeared multiple places on the drive, it would appear different on the surface. There is a good description of operation modes in "Modern Cryptology: a Tutorial" by Gilles Brassard (Springer Verlag Lecture Notes in Computer Science #325, 1988). Denning's book covers it too. I'd probably start out getting it running on a floppy. After that, just use a separate partition to make life easier. The driver is handed physical (or logical) block numbers, and these map directly to the physical drive block number by adding the offset of the beginning of partition. At driver init time, you read the partition table on the hard disk, looking for a "system type" that identifies the partition as one of your encrypted ones. Prompt for the pass phrase, and store it in the driver. I assume that your concern is somebody physically grabbing the disk drive. I don't have a problem with the pass phrase in memory, as long I have physical control of the system. In some of the DOS references, there used to be a sample RAM DISK device driver. You could use it as the skeleton to get the entry points right, and then just encrypt the block and call the BIOS to do the i/o. Have fun, Eric Blossom From hughes at soda.berkeley.edu Thu Jun 3 22:41:55 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 3 Jun 93 22:41:55 PDT Subject: Term software develo In-Reply-To: <930603131241_76244.315_CHN36-2@CompuServe.COM> Message-ID: <9306040538.AA19367@soda.berkeley.edu> >FOSSIL may be popular on BBSs, but NASI/NCSI is number one in >the market. The oldest version of INT 14 is number two. What are NASI/NCSI? Does it cost to use them? Is source available? Eric From bei at dogface.austin.tx.us Thu Jun 3 22:42:28 1993 From: bei at dogface.austin.tx.us (Bob Izenberg) Date: Thu, 3 Jun 93 22:42:28 PDT Subject: subscribe Message-ID: subscribe l-cpunks at dogface.austin.tx.us From nobody at soda.berkeley.edu Thu Jun 3 23:04:13 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Thu, 3 Jun 93 23:04:13 PDT Subject: Software infrastructure Message-ID: <9306040600.AA20309@soda.berkeley.edu> From: Hal Finney, <74076.1041 at compuserve.com> Mike Diehl's system sounds pretty good to me. You can create messages, encrypt them, upload and send them, as well as downloading, decrypting, and reading messages, all with a nice menu-based interface. That's what we want, right? It sounds like the system would be easily adaptable to other types of hosts, too. BBS operators could customize the scripts for their particular systems and offer the package. We could create versions for users of other mail packages than elm on Unix systems, as well as for some of the commercial systems. You could cover a lot of people this way. > Well, if you have followed my this far, you either crazy or interested. ;^) > It puzzles me why we are contemplating writing our own comm package when so > many good ones are out there that can be made to serve our purposes. I'm > open to comments..... Fire away! The only real problem I see is the use of Telix. How much does this program cost? We can't give away a disk with Telix on it. What about Kermit? It's free and it has a scripting language, but it doesn't sound nearly as advanced as Telix's. Would it be good enough? Or are their other free programs which we could use? If we could adapt Kermit or some other free program to do what Mike is describing, we could give away floppies with secure and easy-to-use encrypted email handling capabilities, as well as making them available on the net. People could just get the version they need for their particular mail access.method. The package would include the communication program, the scripts, and the encryption software. The user interface would be as Mike described, all menu driven and easy to use. I think this would be a good way to go if we could get past the hurdle of finding a free comm program that would be adequate. Note added in proof :) Eric mentioned concerns about reliability. Scripts can in principle be made flexible enough to handle many sorts of errors. You just need a lot of states and a lot of result checking. This technique of automatically attaching to a host system and downloading data is widely used by computer novices. I just saw an ad today for a product which lets you create your own "newspaper front page" graphically, then will log on to Compuserve and fill in the news, sports, and business figures you have specified, and do so at regular intervals, automatically, running in the background. I often use a package called Tapcis which automatically logs onto compuserve, getting my mail and sending new mail, reading various topics of interest that I have selected. I used to use a Mac program called Navigator which did the same. Granted, none of these are scripts, they are all custom programs, but the kinds of checking they do should be doable in scripts as well. (I wasn't sure whether Eric's point was that high level scripting languages are excessively clumsy, or the more general point that automated mail access was the wrong way to go. I am addressing the latter here.) Hal From poier at sfu.ca Fri Jun 4 00:23:02 1993 From: poier at sfu.ca (Skye Merlin Poier) Date: Fri, 4 Jun 93 00:23:02 PDT Subject: Procomm and encryption Message-ID: <9306040722.AA00676@malibu.sfu.ca> This discussion of integrating encryption with a comm package made me remember: Procomm Plus 2.0 allows "hooks" to be assigned to meta-keys. I have the exact interface hook.c around here somewhere, if someone wants me to post it. Skye -- -----====> Skye Merlin Poier <====----- Undergrad in CMPT/MATH (Virtual Reality) |||| |||| email: poier at sfu.ca p-OO <--> OO-q THINK PGP Public Key available on finger \== ==/ ivel' or some such. I would like to make it clear that the 'tiring drivel' that I was referring to was MY post and not the letter from Hugh and I merely intended the note to serve as a warning to people not interested in the project. I see now that it is, indeed possible that this informal not may have been misunderstood and I hope that you will understand my real intent now and not hold it against me. I am truly greatful for the help that I have received on this effort and hope that we will have another product of guerilla programming soon. Again, sorry for the misunderstanding, especially to Hugh, and keep those suggestions coming, there is work to be done... -Ryan the Bit Wallah From greg at ideath.goldenbear.com Fri Jun 4 00:45:00 1993 From: greg at ideath.goldenbear.com (Greg Broiles) Date: Fri, 4 Jun 93 00:45:00 PDT Subject: Term software, disk driver encryption Message-ID: Am suprised no-one's mentioned DISKREET, the encrypted disk driver software included with the Norton Utilities. It does DES, though the manual doesn't mention which flavor of DES it uses. I have been using it for roughly 2 years now without any trouble. It's been well-behaved and is probably already on lots of folks' disks, by virtue of being included with the rest of the Norton stuff. I think "TPU" refers to Turbo Pascal Units. "Async Pro" is, if I remember right, the name of an add-on async communications library for Turbo Pascal. Telix is not free, but is freely distributable, as it's shareware. -- Greg Broiles greg at goldenbear.com Golden Bear Computer Consulting +1 503 465 0325 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764 From tcmay at netcom.com Fri Jun 4 01:39:37 1993 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 4 Jun 93 01:39:37 PDT Subject: snake oil (Posting ciphers to the list) In-Reply-To: <9306032354.AA12581@snark.shearson.com> Message-ID: <9306040840.AA29946@netcom3.netcom.com> Perry Metzger writes on the matter of posting newly-invented ciphers to the Cypherpunks list: > My suggestion is this. > > Its perfectly appropriate to post the cypher to the list PROVIDED you > take the right attitude, which is to say something like: > > "The following is something I just thought up. I'm not a pro, and I > worry that this thing has holes. Anyone care to give me hints on what > they might be?" Good advice! Some hubris might pique the interest of readers. > Sci.crypt is likely a better place to post a query about a new cypher, > of course. Yes, except that they for the most part hate it when folks post "I dare you to break my new cipher" messages. Understandably so, for the reasons Perry gave (smugness, etc.) and also because: a. usually not enough ciphertext can be posted to allow a reasonable cryptanalysis b. the odds of a newbie inventing something really new are slim (yes, it _may_ happen, but it's not likely) c. people have better things to do that spend hours or days trying to break a system which has these problems (and may just be deliberate garbage). (Cryptanalysis is economics, as some folks like to say. If a message is important, or a particular cryptosystem has passed some initial tests--such as the algorithm being published, the basic mathematics presented as plausible, etc.--then more effort can be justified. But not on Joe Cipher's latest effort.) (this quote is from Nicky M.) > > Is there a comprehensive list of short "already been done" types of > > cyphers? (Whether failed or "still" succesful.) A good book? Kahn's "The Codebreakers" for a historical perspective, the various crypto books referred to here for mathematical background (Denning, Brassard, Salomaa, Simmons, Patterson, etc.), and "Cryptologia" for insights into amateur cryptanalysis and cipher-building. Be aware that most amateurs--and I hardly speak from experience, just reading of the literature--end up reinventing the old _types_ of ciphers....the new ones, with s-boxes, or based on hard math problems (like RSA), typically require a lot of background in math. Hope this helps, and hope this eases any hard feelings folks may have when their Super Duper Encrypter is not analyzed by a dozen Cypherpunks. Or even one. -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 anton at hydra.unm.edu Fri Jun 4 03:32:25 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Fri, 4 Jun 93 03:32:25 PDT Subject: Software infrastructure In-Reply-To: <9306040600.AA20309@soda.berkeley.edu> Message-ID: <9306041032.AA14588@hydra.unm.edu> You CAN give away disks with Telix, it is shareware, just like QModem (pre-QMPro), and ProComm. Just have to let the recipient know it is not freeware but requires registration for continued use. Might have to obtain permission for such distribution, depends on the licensing. As for "is kermit good enough?" No. Almost NO ONE in the DOS world uses it any more, it is a total anachronism. Of all the 400 or so users on my board, many from other parts of the country, even other countries, not ONE uses kermit (I have "What comm program do you use?" as one of the initial login questions). The only practical use of Kermit is for computer newbies to use it to access the dialup lines at their school (UNM gives out free copies of it), but most such people soon switch to another program. Thing is Kermit is just plain old, and a pain in the butt. When I started BBSing, the Kermit protocol was supported on most BBSs; today I cannot think of a single BBS around here that has it anymore (I'm the defacto city BBSlist maker, so I'd know :) Perhaps this area is atypical, and Kermit is all the rage elsewhere, but considering how BEHIND the times Albuquerque is, I tend to doubt it. Freeware and shareware comm programs available from any BBS or FTP site will DUST Kermit, and I think it's a dead end. All I can say, is any crypto package based on a hack of Kermit will go nowhere. I know it's free and readily available, but well so's a kick in the ass. >;) -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From 76244.315 at CompuServe.COM Fri Jun 4 04:05:33 1993 From: 76244.315 at CompuServe.COM (Doug Porter) Date: Fri, 4 Jun 93 04:05:33 PDT Subject: Term software dev Message-ID: <930604110243_76244.315_CHN40-3@CompuServe.COM> Eric Hughes asks: > What are NASI/NCSI? Does it cost to use them? Is source available? It's an API originally developed by Network Products Corporation and based on an earlier spec from Ungerman-Bass. NPC used it in building an async comm server for LANs. NPC called the API "Network Communications Server Interface" or NCSI. Novell licensed the technology from NPC and renamed the API to "Novell Asynchronous Server Interface" or NASI. Other async server vendors picked up on it about then as a result of Novell's evangelism. Serial communications software packages from Crosstalk to Procomm to tiny niche products started to support it. Then because of the end user package support, the standard was used for different kinds of serial connections. For example, we (CyberCorp) built a NASI/NCSI interface for intelligent Digiboards a while back. I've never heard of anyone being charged to use the spec for whatever they like. At least part of the spec, the part promoted by Ungerman-Bass, seems to be in the public domain. We originally got the spec from Novell when we built a Netware compatible async server. I don't know of any free source code, but code for either end of the spec is only one or two thousand lines of C. Doug From hughes at soda.berkeley.edu Fri Jun 4 06:54:47 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 4 Jun 93 06:54:47 PDT Subject: CryptoStacker, long term vision In-Reply-To: Message-ID: <9306041351.AA05555@soda.berkeley.edu> >I also think that it would be a lot more valuable if it were distributed >with code so that any user who wanted could inspect it for trapdoors. The nature of crypto software is that is valueless unless you trust it. You don't have to trust a word processor, because you can see immediately that what you typed on the screen comes out the printer. For security software, however, breaches are invisible, or more precisely visible only after the damage has been done. This is the reason that I disregard DISKREET from Norton. There's no source, and largish companies are notorious for pushing compromised software. Norton's unlikely to ship source, so unless someone decompiles it, I'm not biting. >Umm, perhaps this is overly optimistic, but I was hoping that I would be >able to use an algorithm that did 1 byte in / 1 byte out encryption so >that I wouldn't have to deal with sector remapping. You need to do a bit of research into what a block device driver actually does. It deals only with blocks of characters, not with individual ones or arbitrary length strings. The block interface at the driver level is different than the file access at the API level. Don't confuse the two levels. DOS already does the buffering required to turn a block device into a file system. You don't need to replicate it. As a result, the cipher you choose needs to be a block cipher. DES works on blocks of 8 bytes at a time. A typical sector is 512 bytes. So you are going to have 32 DES (or iterated DES) operations per sector. > I was thinking that I would even basically leave >the FAT and such intact, or at least only slightly modified. Again, at the driver level, you don't know that a FAT even exists. Ray Duncan's book _Advanced MSDOS Programming_ contains a good chapter on device drivers. You should be able to find code for a skeleton block device driver on the net; check the msdos programming groups for more info. >I'll keep everyone updated no problem. How else am I going to get >suggestions and help? I would also suggest that you find programming partners. If for no other reason than to do code review, someone else ought to be involved. You wouldn't want to make the group too large, but three or four is not overlarge. The archive at soda is available for group work, if desired. Eric From pfarrell at cs.gmu.edu Fri Jun 4 06:57:03 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Fri, 4 Jun 93 06:57:03 PDT Subject: Software infrastructure Message-ID: <35870.pfarrell@cs.gmu.edu> I beg to differ. Stanton McCandlish writes: >As for "is kermit good enough?" No. Almost NO ONE in the DOS world uses >it any more, ..flames elided... I agree that the PC-centric BBS world has decided that Kermit is obsolete. Kermit is continually improving and is very nearly as fast as ZMODEM. It is available for nearly all platforms, is free, and source is availilbe. It includes NASI support directly. It has a very nice (powerful) scripting language. It also works over TCP/IP networks for folks with the luck to be Ethernet'd into the Internet (like most of the faculty and staff here at GMU). It also has very strong backward compatibility. I expect that Kermit is good enuff if you are interested in commandline scripts for plain old DOS. And the scripting language is also supported by the C version that run on nearly all Unixs and most other boxes. This would allow a single script to support a lot of users. I'm not interestedin DOS and command lines, but if some other cypherpunk wants to try, I'm sure not going to complain. Pat Pat Farrell Grad Student pfarrell at cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From elee9sf at Menudo.UH.EDU Fri Jun 4 07:31:51 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Fri, 4 Jun 93 07:31:51 PDT Subject: THANKS: pgp, mh, .forward Message-ID: <199306041431.AA22111@Menudo.UH.EDU> Thanks Hal, Stanton, Miron - I finally got it to work, on the menudo side, not the NeXT. I don't know what the deal is with the NeXT; 'cat .plan | myscript' worked (myscript had all the necessary stuff) but having this .forward file didn't: "|/bigpath/barrus/myscript" But, I got it to work from menudo with this in my .maildelivery file: to "barrus at tree.egr.uh.edu" | A "PGPPATH=/fajitas/elee9sf/Crypto/pgp22 /fajitas/elee9sf/bin/pgp -fea barrus | /usr/lib/mh/rcvstore +fromnext" Mail sent to barrus at tree.egr.uh.edu gets piped through pgp, encrypted, and then stored in the mail folder 'fromnext'. The PGPPATH did seem to be the missing factor! Now, for those who wonder why in the world I'd want to do this... I've been involved in a quasi-flame session on USENET (in comp.admin.policy and other cross-posted groups) concerning a student who was suspended here. My posts became more and more sarcastic, and as I was contemplating sending out a post which may have been on the edge, and not wanting to make the sh*tlist here - or get higher up on it :-) - I was going to route it through penet from my tree account. But then responses to the post would have eventually been dropped here on menudo, since I have my mail forwarded. Now I'm not suggesting that the admins here are watching my mail, but it wouldn't be difficult for the admins to do some traffic analysis (crypto sophistication!), noting that Karl's mail file grows coincident in time and size to responses to XYZ post... enter encryption! So it would be better to get the encryption going on the NeXT side, but this solution is good enough for me. Final note: I forgot penet is restricting posts for the time being, but in any event this system is working.) /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From strick at osc.com Fri Jun 4 09:36:24 1993 From: strick at osc.com (henry strickland) Date: Fri, 4 Jun 93 09:36:24 PDT Subject: Term software develo In-Reply-To: <9306040538.AA19367@soda.berkeley.edu> Message-ID: <9306041644.AA19277@osc.com> With the idea of building a Macintosh terminal emulator with an encrypted transport stream, I've been looking over the sources to "info-mac/terminal-22.hqx" from "sumex-aim.stanford.edu". Realizing that it is not most people's terminal emulator of choice, and that authors may not want to give up their terminal source code, I've been thinking about what kind of an API could be negotiated between terminal-program authors and encryption-mechanism authors. Suppose a terminal program looks for resources (using macintosh-like terminology for a moment) of some type 'Encr', and load them. It expects to find subroutines there, that the cypherpunk can add to any conforming terminal emulator. Something like this: resource #1: function initialize() -- grab resources resource #2: function set_key(char key[8]) resource #3: function encrypt(long block_no, char block[8]) resource #4: function decrypt(long block_no, char block[8]) resource #5: function finalize() -- shutdown, release resources This would support experimentation without necessarily having the source code to a terminal emulator. ( If PC and MAC people took the "all software source must be free" approach that we do in the UNIX world, this would be less a problem.... ) Obvoius Problems not addressed by these 5 functions: -- does not address a linklevel standard for packetizing the stream and numbering the datagrams. I assume this sort of transport is necessary. (It would be amusing to see a demonstration that it is not!) It's actually a nice side-effect; I'm sick of transmission errors, even when I'm in supposedly error-free modes. -- does not talk about key exchange. -- does not talk about crypto-strong authentication of the user to the system you're dialing into. It does assume 8-byte keys and 8-byte cypherblocks; but that's easy to fix. The approach I'm NOT considering at the moment is writing a new communications device which is a wrapper around the exisiting comm port, but that is a MUCH better approach. But I'm not up to that level in my mac-programming yet, and I was looking for somthing I thought I could finish. Anyway, my essential point is, let's publish and compare our link-level standards and our encryption models, so that we can debate them, and end up with a set of plug-compatible tools for different platforms, with hooks for substituting mechanisms. strick p.s. if anyone has summaires/comparisons/case studies of different "guaranteed stream" link protocols (kermit, XMODEM, YMODEM, ZMODEM, TCP), I'd be interested. Code would be even better. (however, trying to reappropriate TCP/SLIP/HeaderPrediction seems to massive an undertaking; I'd like something simpler.) This is one wheel I hate to reinvent.... From jhart at agora.rain.com Fri Jun 4 09:44:09 1993 From: jhart at agora.rain.com (Jim Hart) Date: Fri, 4 Jun 93 09:44:09 PDT Subject: Lobbying for Cryptoprivacy, non-U.S. Message-ID: >I have shied away from any "political" action against Clipper because I am >unsure how a Canadian can help... Non-U.S. citizens can lobby hard to get all phones containing key-escrow (aka wiretap) chips banned in your country. You have a very good argument: do y'all want Yankee spooks listening in on your phone calls? Make sure the following specifics are included in the legislation: * Try to get key escrow banned *in general*, instead of just from foreign countries. In smaller countries this will be easier since its doubtful small governments can set up a spook/chip-maker axis to rival the NSA/Mykotronx/VLSI axis in the U.S. In fact probably only the U.S., cooperating major European countries and Japan have such a capability. * Be careful with the wording of the legislation; be sure to specify *key-escrow* and not any other forms of cryptography. * If political feasible the legislation should specifically encourage private, commercial forms of cryptography. Jim Hart jhart at agora.rain.com From stig at netcom.com Fri Jun 4 09:58:07 1993 From: stig at netcom.com (Stig) Date: Fri, 4 Jun 93 09:58:07 PDT Subject: HELP: pgp, .forward, mh In-Reply-To: <199306031404.AA18382@Menudo.UH.EDU> Message-ID: <9306041658.AA28725@netcom.netcom.com> To quote: Karl Barrus Regarding: HELP: pgp, .forward, mh > > > Situation: I'd like mail that arrives at my other account to be > encrypted and then forwarded to this account. I have spent a few > hours trying various things and nothing seems to work. > > I've tried this as my .forward file: > > "| /myhome/pgp -fea barrus | mail elee9sf at menudo.uh.edu" > > but all that arrives at elee9sf is a blank message. > > I've tried > > "| /myhome/remail.script" > The problem is that when sendmail executes your filter, your environment is all messed up. HOME and USER aren't even initialized. PATH is probably /bin:/usr/bin. > > So, if that's impossible, how do I get my elee9sf account to do it? I > use mh on menudo, and have tried > > to barrus at tree.egr.uh.edu | A "/path/pgp -fea barrus | /path/rvcstore +tonext" This works when you send mail to yourself because your environment gets passed along to your mail filter. Here's a good wrapper script to use .... #!/bin/sh HOME=YOUR-DIRECTORY PGPPATH=YOUR-PGP-DIRECTORY PATH=$HOME/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin:/etc:/usr/etc export HOME PATH PGPPATH cd $HOME exec >> $HOME/Inbox/FILTERLOG 2>&1 # this logs error messages so # that you can learn from them FF=/tmp/FILTER.$$ touch $FF chmod 600 $FF (tee $FF; echo '') >> Inbox/everything # this saves your mail in case # it gets dropped on the floor PGP COMMAND GOES HERE rm $FF exit 0 /* Jonathan Stigelman, Stig at netcom.com, PGP public key by finger */ /* fingerprint = 32 DF B9 19 AE 28 D1 7A A3 9D 0B 1A 33 13 4D 7F */ From bhoward at is.morgan.com Fri Jun 4 10:07:22 1993 From: bhoward at is.morgan.com (Bruce Howard) Date: Fri, 4 Jun 93 10:07:22 PDT Subject: Software infrastructure In-Reply-To: <9306041032.AA14588@hydra.unm.edu> Message-ID: <9306041706.AA14066@is1.is.morgan.com> > As for "is kermit good enough?" No. Almost NO ONE in the DOS world uses > it any more, it is a total anachronism. Of all the 400 or so users on my > board, many from other parts of the country, even other countries, not > ONE uses kermit (I have "What comm program do you use?" as one of the > initial login questions). programs come and go but protocols live forever. i don't think you've looked around enough; in my own experience, kermit has been available and in-use within every computing environment i've operated or observed. there are varying degrees of usage but its always kept around, often because it seems to work in strange communications conditions where other protocols fail. > ...The only practical use of Kermit is for > computer newbies to use it to access the dialup lines at their school > (UNM gives out free copies of it), but most such people soon switch to > another program. > ... > Thing is Kermit is just plain old, and a pain in the butt. When I > started BBSing, the Kermit protocol was supported on most BBSs; today I > cannot think of a single BBS around here that has it anymore (I'm the > defacto city BBSlist maker, so I'd know :) there are many places outside of the bbs world where people need to shuffle files around and might desire encryption. your opinions not withstanding, i believe that kermit is more pervasive that you think. if the purpose of this exercise is to maximize the audience to which we make available easy and useful encryption facilities, then kermit and things of its ilk need to be supported. cheers, bruce From julf at penet.FI Fri Jun 4 10:19:59 1993 From: julf at penet.FI (Johan Helsingius) Date: Fri, 4 Jun 93 10:19:59 PDT Subject: THANKS: pgp, mh, .forward In-Reply-To: <199306041431.AA22111@Menudo.UH.EDU> Message-ID: <9306041855.aa26911@penet.penet.FI> > Final note: I forgot penet is restricting posts for > the time being, but in any event this system is working.) Anon.penet.fi is forwarding postings to news.admin.policy among other groups. Julf From julf at penet.FI Fri Jun 4 10:21:12 1993 From: julf at penet.FI (Johan Helsingius) Date: Fri, 4 Jun 93 10:21:12 PDT Subject: Software infrastructure In-Reply-To: <9306040452.AA13658@triton.unm.edu> Message-ID: <9306041924.aa27246@penet.penet.FI> > Well, now I will describe how I send/receive mail on my system, the killer > 8086-8 from Hell! ;^) I've been hyping my setup on this list for about a > month. > But since I've partially implimented a system like what we have been > discussing, I'll give more details. I'm rather surprised that nobody has mentioned UUPC. It's PD, runs on plain-vanilla DOS, and allows automatic, batched mail traffic (and even netnews) to/from your local PC. On your host (typically an UNIX box) you configure sendmail/smail/binmail/whatever to forward your mail over uucp to your home machine. On the home machine, you simply configure UUCP to poll when needed, and transfer the stuff down onto your local disk. From there you can use UUPC's local mail reader (or any mail package you want), and the replies get spooled to a spool directory, and uploaded automatically the next time you (or the software) opens the connection. Automatic polling, automatic bi-directional batch file transfer, insertion of encryption trivial.... I use it to read and reply to my mail while on the beach, using a notebook computer and a cellular phone... The ability to efficiently batch transfer the stuff makes a *big* difference if you are paying cellular rates... Julf From gnu Fri Jun 4 10:31:31 1993 From: gnu (John Gilmore) Date: Fri, 4 Jun 93 10:31:31 PDT Subject: Helping from Canada re Clipper In-Reply-To: <9306040154.AA07862@soda.berkeley.edu> Message-ID: <9306041731.AA07586@toad.com> > One of the arguments that is being made in this country against the > wiretap chip is that it will harm overseas business. In Canada you > can turn this around and show what a great economic boon you have > available. Another argument the U.S. government is making is that they surveyed encryption policy in various countries and "it's not beyond the pale to limit domestic encryption -- France does it, for example". If Canada takes a strong stance on domestic encryption, then it is a counter-example rather than an example of repression. The Australian example of deploying GSM in the face of law-enforcement objections has already been used in testimony to NIST (and I'm sure we'll use it to convince Congress as well). You could also argue for removing Canadian restrictions on export of cryptography. Currently the Canadian regulations are just rubber-stamps of the US regulations. This has the advantage that it's legal to export US crypto to Canada -- e.g. crypto code developed in the U.S. can be legally moved outside the range of U.S. law. This was useful for PGP; it is legal to use and possess PGP in Canada since US patent law doesn't apply. But it limits the development of an export crypto industry for Canadians, and it furthers the image of Canada as being under the U.S. government's thumb. John Gilmore From hughes at soda.berkeley.edu Fri Jun 4 10:50:04 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 4 Jun 93 10:50:04 PDT Subject: Software infrastructure In-Reply-To: <9306041924.aa27246@penet.penet.FI> Message-ID: <9306041746.AA13444@soda.berkeley.edu> >On your host (typically an UNIX box) you configure >sendmail/smail/binmail/whatever to forward your mail over uucp to your >home machine. This is a huge hurdle for people who don't own their own machines and haven't convinced a sympathetic sysadmin to do the configuration. A solution that works from a dialup login account can still be a batch solution and should require no extra involvement from the sysadmins. Eric From tcmay at netcom.com Fri Jun 4 10:56:18 1993 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 4 Jun 93 10:56:18 PDT Subject: The "WARLOCK" Cipher Message-ID: <9306041756.AA23752@netcom3.netcom.com> Cypherdroids, Earlier today I commented on the advisability of posting new ciphers to this group, or to sci.crypt. (I haven't gotten my message yet, so I don't know if it went through.) By coincidence, a very long posting on sci.crypt has appeared, announcing a new matrix-based crypto system, called "WARLOCK" by its inventors. They provide an extensive introduction to the mathematics used and offer various analyses. This is a first step toward making their system worth analyzing. I suggest following the debate on this system will be educational. And perhaps their system will even survive to become a reasonable alternative. -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 haahr at mv.us.adobe.com Fri Jun 4 11:03:35 1993 From: haahr at mv.us.adobe.com (Paul Haahr) Date: Fri, 4 Jun 93 11:03:35 PDT Subject: Lobbying for Cryptoprivacy, non-U.S. Message-ID: <9306041803.AA28955@astro.mv.us.adobe.com> > In smaller countries this will be easier since its doubtful > small governments can set up a spook/chip-maker axis to rival the > NSA/Mykotronx/VLSI axis in the U.S. In fact probably only the U.S., > cooperating major European countries and Japan have such a capability. what about Canada? or has it been absorbed into the US? :-) Russia probably has the chip-making skills (and, certainly, the spookish ones) to fit, but they probably count as a ``cooperating major European countr[y]'' now. From newsham at wiliki.eng.hawaii.edu Fri Jun 4 11:12:44 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Fri, 4 Jun 93 11:12:44 PDT Subject: The "WARLOCK" Cipher In-Reply-To: <9306041756.AA23752@netcom3.netcom.com> Message-ID: <9306041812.AA08603@toad.com> > > > Cypherdroids, > > By coincidence, a very long posting on sci.crypt has appeared, > announcing a new matrix-based crypto system, called "WARLOCK" by its > inventors. Is this the RSA matrix scheme outlined in CRYPTO '91 ? From tribble at memex.com Fri Jun 4 12:36:29 1993 From: tribble at memex.com (E. Dean Tribble) Date: Fri, 4 Jun 93 12:36:29 PDT Subject: Lobbying for Cryptoprivacy, non-U.S. Non-U.S. citizens can lobby hard to get all phones containing key-escrow (aka wiretap) chips banned in your country. You have a very good argument: do y'all want Yankee spooks listening in on your phone calls? Make sure the following specifics are included in the legislation: In-Reply-To: Message-ID: <9306041842.AA25453@memexis.memex.com> * Try to get key escrow banned *in general*, instead of just from foreign countries. In smaller countries this will be easier since its doubtful small governments can set up a spook/chip-maker axis to rival the NSA/Mykotronx/VLSI axis in the U.S. In fact probably only the U.S., cooperating major European countries and Japan have such a capability. * Be careful with the wording of the legislation; be sure to specify *key-escrow* and not any other forms of cryptography. This is extremely dangerous. Much of legislation is compromise. Any such bill is probably so close to a bill that outlaws cryptography (or could be interpreted as a precedent for such a bill) that the risks are probably far greater than the rewards. The strategy the Eric Hughes proposed sounds much better. From hughes at soda.berkeley.edu Fri Jun 4 13:14:34 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 4 Jun 93 13:14:34 PDT Subject: Lobbying for Cryptoprivacy, non-U.S. In-Reply-To: <9306041842.AA25453@memexis.memex.com> Message-ID: <9306042010.AA21696@soda.berkeley.edu> >>* Be careful with the wording of the legislation; be sure to >> specify *key-escrow* and not any other forms of cryptography. >This is extremely dangerous. Much of legislation is compromise. Any >such bill is probably so close to a bill that outlaws cryptography (or >could be interpreted as a precedent for such a bill) The point Dean makes is important. You want a positive right for individuals to use cryptography in any form, not just a 'negative right' which restricts government from creating key registration requirements. Such a positive right will _a fortiori_ exclude key escrow systems, and that's what you want. You want to make sure that all _restrictions_ on cryptography are disallowed, that there are no _restricted_ forms of cryptography. The point is subtle, but profound. Both techniques get rid of key registration, but one is a restriction on cryptography and the other is not. There is another point to remember about constitutional democracies. That which the legislature may do, the legislature may also undo. The level at which the prohibition against cryptography restrictions is appropriate is at the constitutional level. A constitutional provision binds the government; lesser solutions are less effective, even when they should be sought out as intermediaries. At the first CFP conference, Lawrence Tribe made this point extremely well, that the fundamental right of citizens should be invariant to technology. Eric From gdale at apple.com Fri Jun 4 14:15:21 1993 From: gdale at apple.com (Geoff Dale) Date: Fri, 4 Jun 93 14:15:21 PDT Subject: Crypto API (was: Software infrastructure) Message-ID: <9306042115.AA26274@apple.com> I was thinking about a crypto project I have on the backburner (actually it's just in the concept stage), a program to hide encrypted data in raster image files. I really don't want to muck with writing or porting an encryption package, I just want to do the part that sticks the data into the image. HERE'S THE BEEF: I think a lot of the various mail readers and what not would be likely to encorporate encryption, if only it were mind-bogglingly simple. An API (Application Programming Interface) could be proposed by cypherpunks or others. The same folks should probably provide at least one encryption library for use. It would be nice if this API allowed for multiple encryption schemes (user selectable), like the way Apple's Communications Toolbox allows users to switch between various connection protocols. I'm much too busy to embark on something like this (largely because I'm not a cypher expert), but if I can help convince somebody to do it, or to provide feedback on the interface, I'm available. ________________________________________________________________________ Geoff Dale -- insert standard disclaimers here -- gdale at apple.com "Mind your nerve ends, love bunch" -- Dr. Caligari From esr at snark.thyrsus.com Fri Jun 4 14:36:46 1993 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Fri, 4 Jun 93 14:36:46 PDT Subject: Lobbying for Cryptoprivacy, non-U.S. In-Reply-To: <9306042010.AA21696@soda.berkeley.edu> Message-ID: > At the first CFP conference, Lawrence Tribe made this point extremely > well, that the fundamental right of citizens should be invariant to > technology. That's surprising. Tribe publicly peddles the leftist arguments for gun control, including the one that the Founding Fathers never intended the Second Amendment for weapons of today's lethality. I wonder why he doesn't see the parallel. -- Eric S. Raymond From gdale at apple.com Fri Jun 4 16:40:59 1993 From: gdale at apple.com (Geoff Dale) Date: Fri, 4 Jun 93 16:40:59 PDT Subject: Term software develo Message-ID: <9306042340.AA15816@apple.com> >I've been thinking about what kind of an API could be negotiated >between terminal-program authors and encryption-mechanism authors. > >Suppose a terminal program looks for resources (using macintosh-like >terminology for a moment) of some type 'Encr', and load them. >It expects to find subroutines there, that the >cypherpunk can add to any conforming terminal emulator. >Something like this: > > resource #1: function initialize() -- grab resources > resource #2: function set_key(char key[8]) > resource #3: function encrypt(long block_no, char block[8]) > resource #4: function decrypt(long block_no, char block[8]) > resource #5: function finalize() -- shutdown, release resources > Woops, this is what I get by not reading all my mail before posting. I just posted the same suggestion with considerably less detail. Anyway, I second what henry says. ________________________________________________________________________ Geoff Dale -- insert standard disclaimers here -- gdale at apple.com "Mind your nerve ends, love bunch" -- Dr. Caligari From pmetzger at lehman.com Fri Jun 4 16:41:16 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Fri, 4 Jun 93 16:41:16 PDT Subject: Lobbying for Cryptoprivacy, non-U.S. In-Reply-To: Message-ID: <9306042339.AA19731@snark.shearson.com> Eric S. Raymond says: > > At the first CFP conference, Lawrence Tribe made this point extremely > > well, that the fundamental right of citizens should be invariant to > > technology. > > That's surprising. Tribe publicly peddles the leftist arguments for gun > control, including the one that the Founding Fathers never intended the > Second Amendment for weapons of today's lethality. I wonder why he > doesn't see the parallel. Because he's a liberal, not a libertarian. Perry From mdiehl at triton.unm.edu Fri Jun 4 17:36:11 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 4 Jun 93 17:36:11 PDT Subject: Software infrastructure In-Reply-To: <9306040522.AA18339@soda.berkeley.edu> Message-ID: <9306050035.AA12506@triton.unm.edu> According to Eric Hughes: >>Itpuzzles mewhy weare contemplating writing our own comm package when so many >>good ones are out there that can be made to serve our purposes. > > Reliability. Scripts do not easily handle error conditions that might > result in lost mail. They're fine for a few, but they aren't for all. Well, this is a problem with any nontrivial program. But a script has going for it several very high-level constructs. As people use any software, the author will undoubtably have to improve it. So, what is the difference if he has to improve a script or a comm program? > > Integration. Remembering what to do next is a large hurdle. That's why we have scripts in the first place! Scripts' main purpose is to automate things. How is this different with a comm program? You still have to remember how to use it.... +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Fri Jun 4 18:01:06 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 4 Jun 93 18:01:06 PDT Subject: Software infrastructure In-Reply-To: <9306040600.AA20309@soda.berkeley.edu> Message-ID: <9306050100.AA12806@triton.unm.edu> According to nobody at soda.berkeley.edu: > > From: Hal Finney, <74076.1041 at compuserve.com> > > Mike Diehl's system sounds pretty good to me. You can create messages, > encrypt them, upload and send them, as well as downloading, decrypting, and > reading messages, all with a nice menu-based interface. That's what we > want, right? > > It sounds like the system would be easily adaptable to other types of hosts, > too. BBS operators could customize the scripts for their particular systems > and offer the package. We could create versions for users of other mail > packages than elm on Unix systems, as well as for some of the commercial > systems. You could cover a lot of people this way. Making it adaptable is what I mean by "cleaning it up a bit." ;^) > > Well, if you have followed my this far, you either crazy or interested.;^) > > It puzzles me why we are contemplating writing our own comm package when so > > many good ones are out there that can be made to serve our purposes. I'm > > open to comments..... Fire away! > > The only real problem I see is the use of Telix. How much does this program > cost? We can't give away a disk with Telix on it. Telix is "user supported software." Registering it costs $39. > > What about Kermit? It's free and it has a scripting language, but it > doesn't sound nearly as advanced as Telix's. Would it be good enough? Or > are their other free programs which we could use? I remember kermit's script language as being kinda messy... At the end of this message, I will include a portion of my, uncommented, script to compare. Also, kermit is (I think) restricted to one xfer protocol, which may not be a good idea. > If we could adapt Kermit or some other free program to do what Mike is > describing, we could give away floppies with secure and easy-to-use > encrypted email handling capabilities, as well as making them available on > the net. People could just get the version they need for their particular > mail access.method. The package would include the communication program, > the scripts, and the encryption software. The user interface would be as > Mike described, all menu driven and easy to use. Well, either way, I will contribute my user-interface if you'all want it. I'm not married to telix, but I do think it is very good. We could write comparable scripts in every major comm program script language.... I'd have to document my interface. But if I decide to port my interface to C, I'd like to change a few things, so maybe this is a bit premature..... > I think this would be a good way to go if we could get past the hurdle of > finding a free comm program that would be adequate. > Note added in proof :) I don't understand this last comment. Maybe it's obvious and I'm just tired... Part of my script system is after my signature. Note that I hacked in a C preprocesser, and this is the output from it, just before the script is compiled Yes, Telix scripts are compiled! ;^) +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ str PROMPT[] = "%"; str PASSWRD[15]; command( str cmd ) { enter( cmd ); while ( ! waitfor(PROMPT, 90)); } enter( str cmd ) { cputs( cmd ); cputs( "^M" ); } match( str rec, str snd ) { while ( ! waitfor(rec, 90)); enter( snd ); } str name[40] = "", file[40] = "", subject[40] = "", buff[80]; int f, i; main() { if ( ! carrier()) if ( dial("1", 10, 0) < 1) { prints("Could not dial in."); exittelix(); } cputs("^M"); command("biff n"); if ( ! waitfor("%", 90)) { prints("No prompt after login"); return; } /*/ routing format is: filename\n address\n subject\n /*/ if ((f = fopen("c:\uload\mail\routing", "r")) ==0) return; while (feof(f) == 0) { fgets(file, 40, f); if (feof(f) != 0) continue; fgets(name, 40, f); if (feof(f) != 0) continue; fgets(subject, 40, f); if (feof(f) != 0) continue; buff = ""; strcat(buff, "elm "); strcat(buff, name); enter(buff); match("Subject:", subject); delay_scr(10); cputs("i"); _asc_scrtrans=1; _asc_slftrans=0; send('A', file); command("^[:wq^Ms^M"); fdelete(file); } fdelete("c:\uload\mail\routing"); f = fclose(f); } From mdiehl at triton.unm.edu Fri Jun 4 18:02:43 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 4 Jun 93 18:02:43 PDT Subject: Procomm and encryption In-Reply-To: <9306040722.AA00676@malibu.sfu.ca> Message-ID: <9306050102.AA12819@triton.unm.edu> According to Skye Merlin Poier: > >This discussion of integrating encryption with a comm package made me remember: > Procomm Plus 2.0 allows "hooks" to be assigned to meta-keys. I have the exact > interface hook.c around here somewhere, if someone wants me to post it. Post it. Thanx. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From banisar at washofc.cpsr.org Fri Jun 4 18:03:03 1993 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Fri, 4 Jun 93 18:03:03 PDT Subject: NIST CSSPAB 6/4/93 Resoluti Message-ID: <00541.2822071666.3817@washofc.cpsr.org> NIST CSSPAB 6/4/93 Resolutions NIST Crypto Resolutions Computer System Security and Privacy Advisory Board June 4, 1993 Resolution #1 At Mr. Kammer's request we have conducted two days of hearings. The clear message of the majority of input was that there are serious concerns regarding the Key Escrow Initiative and the Board concurs with these concerns. Many of these issues are still to be fully understood and more time is needed to achieving that understanding. Accordingly, this Board resolves to have an additional meeting in July 1993 in order to more completely respond to Mr. Kammer's request and to fulfill its statutory obligations under P.L. 100-235. The Board recommends that the inter-agency review take note of our input collected, our preliminary finding, and adjust the timetable to allow for resolution of the significant issues and problems raised. Attached to this resolution is a preliminary distillation of the serious concerns and problems. Resolution #2 Key escrowing encryption technology represents a dramatic change in the nation's information infrastructure. The full implications of this encryption technique are not fully understood at this time. Therefore, the Board recommends that key escrowing encryption technology not be deployed beyond current implementations planned within the Executive Branch, until the significant public policy and technical issues inherent with this encryption technique are fully understood. [Attachment to Resolution #1]] - A convincing statement of the problem that Clipper attempts to solve has not been provided. - Export and important controls over cryptographic products must be reviewed. Based upon data compiled from U.S. and international vendors, current controls are negatively impacting U.S. 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 a critical and significant component of the National Information Infrastructure and the U.S. 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. It does not appear to be clearly defined at this time and, since it is an integral part of the security of the system, it appears to require further development and consideration of alternatives to the key escrow scheme (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 systems 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. ======================================================= NIST Resolutions on Key Escow Issues and Clipper provided by CPSR Washington office 666 Pennsylvania Ave., SE Suite 303 Washington, DC 20003 rotenberg at washofc.cpsr.org ======================================================= From mdiehl at triton.unm.edu Fri Jun 4 18:09:16 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 4 Jun 93 18:09:16 PDT Subject: Software infrastructure In-Reply-To: <9306041032.AA14588@hydra.unm.edu> Message-ID: <9306050109.AA12890@triton.unm.edu> According to Stanton McCandlish: > > As for "is kermit good enough?" No. Almost NO ONE in the DOS world uses > it any more, it is a total anachronism. Of all the 400 or so users on my > board, many from other parts of the country, even other countries, not > ONE uses kermit (I have "What comm program do you use?" as one of the > initial login questions). The only practical use of Kermit is for > computer newbies to use it to access the dialup lines at their school > (UNM gives out free copies of it), but most such people soon switch to > another program. Correction, many people on this list use kermit... And of course, I should know! ;^) I do suggest that people get a (better) different comm program, as kermit is IMHO rather limited. > Thing is Kermit is just plain old, and a pain in the butt. When I > started BBSing, the Kermit protocol was supported on most BBSs; today I > cannot think of a single BBS around here that has it anymore (I'm the > defacto city BBSlist maker, so I'd know :) True on all points. ;^) > Perhaps this area is atypical, and Kermit is all the rage elsewhere, but > considering how BEHIND the times Albuquerque is, I tend to doubt it. > Behind the times? Hell, we just got Caller-ID. Yipee! > Freeware and shareware comm programs available from any BBS or FTP site > will DUST Kermit, and I think it's a dead end. All I can say, is any > crypto package based on a hack of Kermit will go nowhere. I know it's > free and readily available, but well so's a kick in the ass. >;) > Agreed. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From tcmay at netcom.com Fri Jun 4 18:16:57 1993 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 4 Jun 93 18:16:57 PDT Subject: (fwd) NIST CSSPAB Resolutions 6/4/93 Message-ID: <9306050117.AA03457@netcom3.netcom.com> Here's something important from sci.crypt! -Tim May Xref: netcom.com alt.privacy:7178 alt.security:9808 comp.org.eff.talk:18101 sci.crypt:15143 alt.privacy.clipper:555 Path: netcom.com!netcomsv!decwrl!elroy.jpl.nasa.gov!usc!math.ohio-state.edu!sol.ctr.columbia.edu!news.kei.com!eff!wilson.eff.org!Banisar From: Dave Banisar Newsgroups: alt.privacy,alt.security,comp.org.eff.talk,sci.crypt,alt.privacy.clipper Subject: NIST CSSPAB Resolutions 6/4/93 Date: 5 Jun 1993 00:48:11 GMT Organization: CPSR Washington Office Lines: 101 Distribution: world Message-ID: <1uoqgb$peg at kragar.eff.org> NNTP-Posting-Host: wilson.eff.org X-UserAgent: Nuntius v1.1.1d17 X-XXMessage-ID: X-XXDate: Fri, 4 Jun 93 01:54:42 GMT NIST Crypto Resolutions Computer System Security and Privacy Advisory Board June 4, 1993 Resolution #1 At Mr. Kammer's request we have conducted two days of hearings. The clear message of the majority of input was that there are serious concerns regarding the Key Escrow Initiative and the Board concurs with these concerns. Many of these issues are still to be fully understood and more time is needed to achieving that understanding. Accordingly, this Board resolves to have an additional meeting in July 1993 in order to more completely respond to Mr. Kammer's request and to fulfill its statutory obligations under P.L. 100-235. The Board recommends that the inter-agency review take note of our input collected, our preliminary finding, and adjust the timetable to allow for resolution of the significant issues and problems raised. Attached to this resolution is a preliminary distillation of the serious concerns and problems. Resolution #2 Key escrowing encryption technology represents a dramatic change in the nation's information infrastructure. The full implications of this encryption technique are not fully understood at this time. Therefore, the Board recommends that key escrowing encryption technology not be deployed beyond current implementations planned within the Executive Branch, until the significant public policy and technical issues inherent with this encryption technique are fully understood. [Attachment to Resolution #1]] - A convincing statement of the problem that Clipper attempts to solve has not been provided. - Export and important controls over cryptographic products must be reviewed. Based upon data compiled from U.S. and international vendors, current controls are negatively impacting U.S. 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 a critical and significant component of the National Information Infrastructure and the U.S. 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. It does not appear to be clearly defined at this time and, since it is an integral part of the security of the system, it appears to require further development and consideration of alternatives to the key escrow scheme (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 systems 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. ======================================================= NIST Resolutions on Key Escow Issues and Clipper provided by CPSR Washington office 666 Pennsylvania Ave., SE Suite 303 Washington, DC 20003 rotenberg at washofc.cpsr.org ======================================================= -- .......................................................................... 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 mdiehl at triton.unm.edu Fri Jun 4 18:18:28 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 4 Jun 93 18:18:28 PDT Subject: Software infrastructure In-Reply-To: <35870.pfarrell@cs.gmu.edu> Message-ID: <9306050118.AA13037@triton.unm.edu> According to Pat Farrell: > >As for "is kermit good enough?" No. Almost NO ONE in the DOS world uses > >it any more, > ..flames elided... > > I agree that the PC-centric BBS world has decided that Kermit is obsolete. Maybe it's just us... ;^) > Kermit is continually improving and is very nearly as fast as ZMODEM. Maybe I have a slow version, but I have NEVER gotten comparable results 'tween kermit and zmodem, or even ymodem. Usually it's a 2:1 difference. > It is available for nearly all platforms, is free, and source is availilbe. > It includes NASI support directly. It has a very nice (powerful) scripting > language. It also works over TCP/IP networks for folks with the luck > to be Ethernet'd into the Internet (like most of the faculty and staff here > at GMU). It also has very strong backward compatibility. This is worth considering... > I expect that Kermit is good enuff if you are interested in commandline > scripts for plain old DOS. And the scripting language is also > supported by the C version that run on nearly all Unixs and most other > boxes. This would allow a single script to support a lot of users. > I'm not interestedin DOS and command lines, but if some other > cypherpunk wants to try, I'm sure not going to complain. What do you mean by "commandline script?" +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Fri Jun 4 18:21:37 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 4 Jun 93 18:21:37 PDT Subject: CryptoStacker, long term vision In-Reply-To: <9306041351.AA05555@soda.berkeley.edu> Message-ID: <9306050121.AA13122@triton.unm.edu> According to Eric Hughes: > This is the reason that I disregard DISKREET from Norton. There's no > source, and largish companies are notorious for pushing compromised > software. Norton's unlikely to ship source, so unless someone > decompiles it, I'm not biting. HMMmmm..... Well, how big is it? Is it a .exe or .com? It might be very instructive to see how they do it... > four is not overlarge. The archive at soda is available for group > work, if desired. That is very generous! +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Fri Jun 4 18:25:05 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 4 Jun 93 18:25:05 PDT Subject: THANKS: pgp, mh, .forward In-Reply-To: <199306041431.AA22111@Menudo.UH.EDU> Message-ID: <9306050124.AA13209@triton.unm.edu> According to Karl Barrus: > Mail sent to barrus at tree.egr.uh.edu gets piped through pgp, encrypted, > and then stored in the mail folder 'fromnext'. The PGPPATH did seem > to be the missing factor! > Would someone explain how to do this. I need an idiot's description. I tried to get my mail to go through a filter once....twice actually. Never did get it to work. I did loose a lot of mail, tho. ;^( Thanx in advance. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From elee9sf at Menudo.UH.EDU Fri Jun 4 21:06:13 1993 From: elee9sf at Menudo.UH.EDU (elee9sf at Menudo.UH.EDU) Date: Fri, 4 Jun 93 21:06:13 PDT Subject: INFO: .forward Message-ID: <199306050406.AA21108@Menudo.UH.EDU> > Would someone explain how to do this. I need an idiot's > description. I tried to get my mail to go through a filter > once....twice actually. Never did get it to work. Well, I'll give it a shot. Sendmail optionally reads a file in your home directory named .forward, and follows the instructions there. Typically, a .forward contains another address, in which case mail sent gets forwards to the address in the .forward file. For example, my .forward file on tree.egr.uh.edu is elee9sf at menudo.uh.edu so any mail sent to barrus at tree.egr.uh.edu gets forwarded to elee9sf at menudo.uh.edu. A more interesting application is to forward your mail to a command (pipe mail to a command). In that case, the .forward file reads "|/path/mycommand options" and mail gets piped to mycommand for further processing. For instance, the vacation program works by piping incoming mail to vacation, which both files and responds for you. Also, the cypherpunk remailers work by using a .forward file to pipe incoming mail to the scripts which make up the remailer. Yet another example is the slocal program which is part of the mh mail system; incoming mail gets piped to slocal, which in turn relies on a configuration file (.maildelivery) which contains instructions for handling the mail. My idea was to have all mail sent to barrus at tree.egr.uh.edu piped through pgp and then mailed to elee9sf at menudo.uh.edu. The rough idea is to do this: "|/path/pgp -fea barrus | mail elee9sf at menudo.uh.edu" Here, incoming mail gets piped to 'pgp -fea barrus' which encrypts the message with my public key, and the result is piped to 'mail elee9sf at menudo.uh.edu' which then mails the encrypted result to me. For various reasons I'm still exploring, this didn't work (even with PGPPATH set, piping to a script, etc. I've got more things to try to see why it isn't working.) on the NeXT. So, I tried to do this from the menudo.uh.edu side. Using the slocal program and the associated .maildelivery file, I have mail which comes from barrus at tree.egr.uh.edu (remember my mail from tree is forwarded to menudo) piped through 'pgp -fea barrus' and then the result is piped into an mh command which stores the mail in a folder. Of course, this isn't a substitute for end-to-end encryption. Here, mail travels all the way to me before getting encrypted, so if somebody wanted to snoop me they could just stand between the sender and my account and eavesdrop. A better solution would be to have the sender encrypt the message! But as I mentioned I was trying to set this up so that replies to a USENET posting got encrypted before finally getting dropped on menudo. An improvement would be for me to get the encryption and remailing working on the NeXT, but again, this is inferior to having the sender encrypt in the first place. You mentioned trying to put your mail through a filter - were you trying to use the filter command of elm? Sometimes you have to watch subtle things like file permissions (slocal will not use a .maildelivery file that is group or other readable) or pathnames (try putting the fill path names when you use commands). /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From nobody at soda.berkeley.edu Fri Jun 4 21:26:45 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Fri, 4 Jun 93 21:26:45 PDT Subject: chain.zip uploaded Message-ID: <9306050423.AA22143@soda.berkeley.edu> I just put chain.zip into the /pub/cypherpunks/incoming. This is source and an MSDOS executable for the "chain" utility I mentioned last week, which works similarly to Karl Barrus's scripts for sending messages through several remailers. This program includes options for encrypting the message for the recipient, and if run on a Unix system it can automatically send the message to the first remailer in the chain. I'm going to be off the list for a few days for personal reasons, but if anyone has any comments or problems with the program, let me know and I'll look into it when I get back. Hal Finney 74076.1041 at compuserve.com From julf at penet.FI Sat Jun 5 00:06:33 1993 From: julf at penet.FI (Johan Helsingius) Date: Sat, 5 Jun 93 00:06:33 PDT Subject: Lobbying for Cryptoprivacy, non-U.S. In-Reply-To: <9306041803.AA28955@astro.mv.us.adobe.com> Message-ID: <9306050926.aa04642@penet.penet.FI> > Russia probably has the chip-making skills (and, certainly, the spookish > ones) to fit, but they probably count as a ``cooperating major European > countr[y]'' now. Uh... Based on my experience they probably count as "a number of not-very-cooperating European countries" ;-) Julf From julf at penet.FI Sat Jun 5 00:06:42 1993 From: julf at penet.FI (Johan Helsingius) Date: Sat, 5 Jun 93 00:06:42 PDT Subject: Software infrastructure In-Reply-To: <9306041746.AA13444@soda.berkeley.edu> Message-ID: <9306050928.aa04663@penet.penet.FI> > >On your host (typically an UNIX box) you configure > >sendmail/smail/binmail/whatever to forward your mail over uucp to your > >home machine. > > This is a huge hurdle for people who don't own their own machines and > haven't convinced a sympathetic sysadmin to do the configuration. Yes. Sorry. Brain disengaged. Been my own sysadmin for 10 years now, so it just didn't occur to me... :-( Julf From julf at penet.FI Sat Jun 5 00:07:48 1993 From: julf at penet.FI (Johan Helsingius) Date: Sat, 5 Jun 93 00:07:48 PDT Subject: Anon.penet.fi and penet.anonymous.net Message-ID: <9306050942.aa04754@penet.penet.FI> Since I announced my intention to re-establish the full anon.penet.fi service, I have received several messages with very valuable and useful ideas. I just want to clarify my situation. What I'm doing now is to simply re-establish the old service, without any changes/improvements (except for an AUP-free connection and a faster box). This gives me time to work on the improved Mk II with support for PGP, multiple ID's, selectable double/single blind etc. I expect to bring up Mk II as penet.anonymous.net this fall, but I need some time to implement the stuff, write documentation etc., and I have to take care of my "daytime" jobs as well. Somebody has to pay for all that new hardware and that international connection... Not mentioning my rent ;-) Julf From mdiehl at triton.unm.edu Sat Jun 5 00:25:33 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sat, 5 Jun 93 00:25:33 PDT Subject: Dig. Cash Question. Message-ID: <9306050725.AA19507@triton.unm.edu> I'm reading the paper that was announced on this list about Digital Cash last week. It was writen by Stefan Brands. I think I have a strong Math background, but I don't know what is meant by a "descrete log" in a group G. I understand what a group is. I just don't know what properties an element, a, would have if it were the log sub p of e. Can someone help me. Otherwise, this is a very interesting article. Thanx in advance. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From pfarrell at cs.gmu.edu Sat Jun 5 00:27:08 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Sat, 5 Jun 93 00:27:08 PDT Subject: Software infrastructure Message-ID: <84861.pfarrell@cs.gmu.edu> >Maybe I have a slow version, but I have NEVER gotten comparable results 'tween >kermit and zmodem, or even ymodem. Usually it's a 2:1 difference. It is important to have recent version on both the PC and host side. The versions that I run on my PC is 3.12. The Unix host version is close to 5A... I had to slurp the latest Sun version from Columbia to get decent performance. The version supported by my Sysadmin was obsolete. I haven't claimed that Kermit is faster, but with sliding windows, large buffers, and other tricks, the night and day difference goes away. >>glowing BS about TCP/IP, NASI, etc. elided... >This is worth considering... I agree. That is why I posted. Perhaps a Kermit guru lives within the list. >> I expect that Kermit is good enuff if you are interested in commandline >> scripts for plain old DOS. And the scripting language is also >> supported by the C version that run on nearly all Unixs and most other >> boxes. This would allow a single script to support a lot of users. >What do you mean by "commandline script?" I mean that a script that works like unix or DOS command line programs should (speculation alert!) be possible. We can handle obscure options, switches, etc. My target audience can't. Kermit has automatic scripts and macros that should be able to handle what we need. Heaven help us when there are errors tho.... Pat Pat Farrell Grad Student pfarrell at cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From mdiehl at triton.unm.edu Sat Jun 5 00:27:42 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sat, 5 Jun 93 00:27:42 PDT Subject: Tempest@home? Message-ID: <9306050727.AA19541@triton.unm.edu> I'm really intrigued by the technology known as TEMPEST. If a guy had a mind to, is it possible to put together a do-it-yourself "tempest-aware" machine? That is, could a guy buy supplies that would make his machine "quiet?" If so, would someone please tell me how! This would be very usefull to many cypherpunks and would be of (IMHO) general interest. Thanx in advance. BTW, this message was mailed by my pgp-aware, automatic mail script. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Sat Jun 5 00:37:36 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sat, 5 Jun 93 00:37:36 PDT Subject: Software infrastructure In-Reply-To: <84861.pfarrell@cs.gmu.edu> Message-ID: <9306050737.AA19773@triton.unm.edu> According to Pat Farrell: > >>Maybe I have a slow version, but I have NEVER gotten comparable results 'tween >>kermit and zmodem, or even ymodem. Usually it's a 2:1 difference. > > It is important to have recent version on both the PC and host side. > The versions that I run on my PC is 3.12. The Unix host version is > close to 5A... I had to slurp the latest Sun version from Columbia > to get decent performance. The version supported by my Sysadmin was > obsolete. I haven't claimed that Kermit is faster, but with sliding windows, > large buffers, and other tricks, the night and day difference goes away. I'll take your word for it. ;^) I can only speak from experience. > >What do you mean by "commandline script?" > > I mean that a script that works like unix or DOS command line programs > should (speculation alert!) be possible. We can handle obscure options, > switches, etc. My target audience can't. Kermit has automatic scripts > and macros that should be able to handle what we need. Heaven help us > when there are errors tho.... We simply make a batch file which starts our comm program with all the right settings? Simple. If there are errors, we program around them just like we do in the real world (tm) If we don't we hear about it from our users! ;^) I still have a few possible errors which I haven't programed around on my scrYpt, but they are so rare.... ya, I know. I'll fix em before I release. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From poier at sfu.ca Sat Jun 5 03:18:43 1993 From: poier at sfu.ca (Skye Merlin Poier) Date: Sat, 5 Jun 93 03:18:43 PDT Subject: here ya go Message-ID: <9306051015.AA15046@malibu.sfu.ca> heres the procomm+ 2.0 hook prog... -----snip snip----- /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 HOOK.C - Programmer's interface for PROCOMM PLUS 2.0 22 22 COPYRIGHT (C) 1990 DATASTORM TECHNOLOGIES, INC. 22 22 22 22 PROCOMM PLUS passes the "hook" program the address in memory of 22 22 the PCPLUS.PRM file structure, and the ASPECT N0-N9 and S0-S9 22 22 arrays. This sample code makes local copies of these so it can 22 22 use the small memory model and not have access those locations 22 22 directly (look at the movedata() function calls.) 22 22 22 22 This file also contains other PROCOMM PLUS information that 22 22 programmers may wish to make use of. 22 22 22 22 NOTE: This code example is written for Microsoft C, which 22 22 defaults to "word alignment" of integer size items and causes 22 22 extra bytes to be inserted in structures to insure field 22 22 alignment. Turbo C, Zortech C, and other compilers that default 22 22 to "packed" or byte alignment must be explicitly set to word 22 22 alignment (usually the -a compiler option). 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 IMPORTANT NOTICE: The concepts and the text contained in this 22 22 file are hereby released into the Public Domain for use by 22 22 programmers in developing PROCOMM PLUS-compatible code. 22 22 Programs developed using this file may be distributed freely by 22 22 programmers without any financial or legal obligation to 22 22 Datastorm Technologies, Inc. However, this in no way implies 22 22 that any other material in the PROCOMM PLUS package may be 22 22 distributed in such manner, or that PROCOMM PLUS or any other 22 22 Datastorm product may be bundled for distribution with programs 22 22 developed using this file. 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ #include "stdio.h" #include "stdlib.h" #include "dos.h" /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 Structure for PROCOMM PLUS PCPLUS.PRM information 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ struct PARMLIST { /* line settings */ int port; /* com port, 0=COM1 etc */ unsigned int baud; /* index into baud_rate[] array */ int parity; /* parity: NOEMS = 01234 */ int sbits; /* stop bits as int */ int dbits; /* data bits as int */ /* Modem General Options */ int mdm_timeout; /* secs to wait for connect */ int mdm_pause; /* secs to pause between calls */ int abdetect; /* autobaud for dialing: FALSE/TRUE */ int ddtrflg; /* 1=drop dtr in dial dir */ char redialc; /* character to send in redial */ int cdover; /* override CD and send init string ? */ int maxcalls; /* max retries for dial dir */ /* Modem Command Options */ char mdminit[47]; /* modem init string */ char mdmcmd[25]; /* modem dialing command */ char mdmsuf[25]; /* modem dial command suffix */ char hu_str[25]; /* modem hangup string */ char ans_str[25]; /* modem auto anser string */ char no_ans_str[25]; /* modem no auto answer string */ /* Modem Result Messages */ char mdm_msg[11][16]; /* modem messages, 0-6 = connect */ /* Modem Port Assignments */ int baseaddr[8]; /* com port base addresses */ int irqnumbr[8]; /* com port irq selection */ /* Terminal General Options */ int termtype; /* terminal type */ int echo_flag; /* duplex: 0=FULL, 1=HALF */ int use_xon; /* use flow control: FALSE/TRUE */ int hardflow; /* use hasrware flow ctrl: FALSE/TRUE */ int wrap; /* use line wrap FALSE/TRUE */ int scrlflag; /* scroll page FALSE/TRUE */ int lfflag; /* add LF to CR coming in: FALSE/TRUE */ char dest_bs; /* use destructive BS: FALSE/TRUE */ int brklen; /* BREAK length in ms */ int enq_on; /* respond to ENQ: NONE/ANSWERBACK/CIS B */ int use_uline; /* 1=EGA/VGA true underlining */ int col132mode; /* 0=80 col, 1=132 col */ int ansi8bit; /* 1=ANSI 8 bit mode, 0=ANSI 7 bit mode */ /* Terminal Color Options */ int tcnorm; /* Terminal normal attribute */ int tcbold; /* Terminal bold attribute */ int tchalf; /* Terminal wrt prt/half intense attribute */ int tcrev; /* Terminal reverse attribute */ int tculine; /* Terminal underscore attribute */ /* Display/Sound Options */ int explode; /* use exploding windows: FALSE/TRUE */ int soundon; /* use sound: FALSE/TRUE */ int alarmon; /* use alarm: FALSE/TRUE */ int attenlen; /* seconds for alarm sound */ int snow; /* flag for using fast display updates */ int sline_off; /* 0=use status line, 1=use 25 lines of data */ int bigcur; /* 0=line, 1=block */ unsigned int rfarsize; /* far mem for redisplay buffer */ int startextralines; /* startup in extraline mode? */ int extralines; /* 25, 28, 43 or 50 line mode */ /* General Options */ char prtfilename[13]; /* name of PRN device */ int cd_at_exit; /* 0=ignore, 1=hangup, 2=ask */ int fastkbd; /* AT keyboard speedup */ int remcmd; /* flag for using remote script commands */ int xlatflag; /* use xlate: FALSE/TRUE */ char xlatps; /* pause character */ int keypause; /* pause between chars in ms */ int nophonelog; /* flag for using phone log */ int filelu; /* flag for using auto filename lookup */ int use123; /* use lotus menus ? */ char key123; /* lotus menu key */ int dtrflag; /* drop DTR in hangup: FALSE/TRUE */ int page_is_xfer; /* 1=PgUp/Dn xfer, 0=Ctrl-PgUp/Dn xfer */ char chat_blk_mode; /* flag for char/block mode in "chat" */ /* Host Mode Options */ int hardwire; /* host connection type: MODEM/DIRECT */ int autobaud; /* use autobaud in host mode */ char host_id[51]; /* host welcome string */ int opensys; /* host is open system: FALSE/TRUE */ char hostup[51]; /* host mode upload default dir */ char hostdn[51]; /* host mode download default dir */ int hosttimeout; /* host inactivity timeout (in minutes) */ int hostbyemode; /* what to do after end of call */ int hostnewuserdl; /* can new user xfer files? */ /* File/Path Options */ char log_name[65]; /* default log file name */ char scr_name[65]; /* default screen dump fiel name */ char dl_path[65]; /* default d/l path */ char viewname[65]; /* view prog name */ char ed_name[65]; /* editor name */ /* Color Options */ int hmclr; /* colors */ int hmhi; int pdclr; int pdhi; int slclr; int slhi; int tcclr; int tchi; int xclr; int xhi; int ddclr; int ddhi; int kmclr; int kmhi; int pmclr; /* colors for pulldown menus */ int pmhi; /* colors for pulldown menus */ int pmrev; /* colors for pulldown menus */ /* ASCII Options */ int ascii_echo; /* echo ascii uploads: FALSE/TRUE */ int blankx; /* expand blank lines in ASCII uploads */ int tabx; /* expand tabs in ASCII uploads */ int cpace; /* char pace time for ASCII uploads */ int pchar; /* pace character for ASCII uploads */ int pace; /* line pace for ascii u/l */ int up_cr; /* CR define for ascii u/l: */ int up_lf; /* LF define for ascii u/l: */ int dn_cr; /* CR define for ascii d/l: */ int dn_lf; /* LF define for ascii d/l: */ int strip8; /* strip 8th bit in ASCII xfers */ int ascii_dl_to; /* auto timeout value for ascii dloads */ /* Kermit Options */ int srpsiz; /* kermit stuff */ char spadchar; /* kermit stuff */ int ksoh; int spad; char squote; char sqt8bitchar; char sseol; int sbctr; /* kermit stuff */ int sbinary; int turnch; /* kermit stuff */ /* Zmodem Options */ int zadl; /* ZMODEM auto download flag */ int zds; /* ZMODEM time/date stamp flag */ int zcr; /* ZMODEM crash recovery flag (0, 1, 2, 3) */ int zscr; /* ZMODEM send crash recovery flag (0, 1 */ int ztw; /* ZMODEM tx window size (0, 2048, 4096) */ int zcrc; /* ZMODEM crc type (0 = 32 bit, 1 = 16 bit) */ /* int zmt; ZMODEM moby turbo compatibility flag */ /* External Protocol Options */ char epname[3][9]; /* display name */ char epupload[3][16]; /* upload command */ char epdnload[3][16]; /* download command */ int epmode[3]; /* 0,1,2=ASPECT,Program,Hook */ /* General Protocol Options */ int relax; /* XMODEM relaxed mode: FALSE/TRUE */ int trash; /* garbage placeholder */ /* Editor Options */ unsigned char textmode; /* input mode 0:Aspect 1:word */ unsigned char omiteof; /* don't write EOF flag */ unsigned char exptabs; /* expand tab characters */ unsigned char wordwrap; /* word wrap enable flag */ unsigned char justify; /* right margin justify flag */ unsigned tabsize; /* tab-stop constant */ unsigned pindent; /* programming indent level */ unsigned windent; /* indent level (zero-based) */ unsigned lmargin; /* left margin (zero-based) */ unsigned rmargin; /* right margin (zero-based) */ unsigned es0; /* status line headers */ unsigned es1; /* status line file information */ unsigned es2; /* status line message area */ unsigned et0; /* normal text display */ unsigned et1; /* reverse video text display */ unsigned et2; /* highlighted text display */ unsigned ep0; /* prompt window display */ unsigned ep1; /* prompt input field */ unsigned em0; /* default message attribute */ unsigned em1; /* message MSG attribute */ unsigned em2; /* message EMSG attribute */ #if defined(ACSI) char acsi_callname[17];/* ACSI server name */ #endif int mouse_x_sensitivity; /* x mickey sensitivity */ int mouse_y_sensitivity; /* y mickey sensitivity */ int xfer_cd; /* flag for testing CD in Xfers */ int clip_separator; /* char sent between clipboard entries */ int ax132; /* Value for AL for forced video mode */ int hcmdrte; /* TRUE if using HCOMMAND.RTE */ } ; /* End of parmlist */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 Structure for PROCOMM PLUS dialing directory entry. 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ struct DDREC { char ddname[25]; /* name */ char ddphone[21]; /* phone number */ int ddbaud; /* baud rate as int */ char ddparity; /* parity as short int */ char dddata; /* data bits as short int */ char ddstop; /* stop bits as short int */ char dddup; /* duplex as short int: 0 = full */ char ddscript[9]; /* ASPECT file w/o ext */ char ddlast[9]; /* last call: mm/dd/yy */ int ddtotal; /* total connects */ char ddproto; /* default protocol as short int */ char ddterm; /* terminal type as short int */ char ddmode; /* 0 = mode, 1 = direct */ char ddpassword[11]; /* like it says */ char ddmacfile[9]; /* keyboard macro file */ char ddkbdfile[9]; /* keyboard mapping file */ char ddport; /* com port to use */ char ddnotefile[9]; /* note file */ }; /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 Structure for PROCOMM PLUS .KBD file terminal entry: 22 22 22 22 struct TERMTABLE 22 22 { 22 22 char def[79][12]; 22 22 }; 22 22 22 22 All fields are fixed length and are padded with NULLs. 22 22 22 22 The file is built in the terminal order in the term_desc array 22 22 below. Each terminal entry has the keys stored in the following 22 22 order: 22 22 22 22 KEYPAD ASTERISK (*) 22 22 KEYPAD MINUS (-) 22 22 KEYPAD PLUS (+) 22 22 KEYPAD PERIOD (.) 22 22 KEYPAD SLASH (//) 22 22 KEYPAD ENTER (CR) 22 22 22 22 TAB 22 22 BACKTAB 22 22 INSERT 22 22 DELETE 22 22 BACKSPACE 22 22 22 22 CTRL-HOME 22 22 CTRL-END 22 22 CTRL-PGUP 22 22 CTRL-PGDN 22 22 CTRL-BACKSPACE 22 22 22 22 F1 22 22 F2 22 22 F3 22 22 F4 22 22 F5 22 22 F6 22 22 F7 22 22 F8 22 22 F9 22 22 F10 22 22 F11 22 22 F12 22 22 22 22 KEYPAD 0 22 22 KEYPAD 1 22 22 KEYPAD 2 22 22 KEYPAD 3 22 22 KEYPAD 4 22 22 KEYPAD 5 22 22 KEYPAD 6 22 22 KEYPAD 7 22 22 KEYPAD 8 22 22 KEYPAD 9 22 22 22 22 SHIFT-F1 22 22 SHIFT-F2 22 22 SHIFT-F3 22 22 SHIFT-F4 22 22 SHIFT-F5 22 22 SHIFT-F6 22 22 SHIFT-F7 22 22 SHIFT-F8 22 22 SHIFT-F9 22 22 SHIFT-F10 22 22 SHIFT-F11 22 22 SHIFT-F12 22 22 22 22 GREY CURSOR UP 22 22 GREY CURSOR DOWN 22 22 GREY CURSOR LEFT 22 22 GREY CURSOR RIGHT 22 22 GREY INSERT 22 22 GREY DELETE 22 22 GREY HOME 22 22 GREY END 22 22 GREY PGUP 22 22 GREY PGDN 22 22 22 22 CTRL-F1 22 22 CTRL-F2 22 22 CTRL-F3 22 22 CTRL-F4 22 22 CTRL-F5 22 22 CTRL-F6 22 22 CTRL-F7 22 22 CTRL-F8 22 22 CTRL-F9 22 22 CTRL-F10 22 22 CTRL-F11 22 22 CTRL-F12 22 22 22 22 CURSOR UP 22 22 CURSOR DOWN 22 22 CURSOR LEFT 22 22 CURSOR RIGHT 22 22 22 22 HOME KEY 22 22 END KEY 22 22 ENTER KEY (CR)" 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ unsigned char *termdesc[] = { "TTY ", /* TTY 0 */ "VT52 ", /* VT52 1 */ "VT100 ", /* VT100 2 */ "VT102 ", /* VT102 3 */ "VT220 ", /* VT220 4 */ "VT320 ", /* VT320 5 */ "ANSI ", /* BBS 6 */ "IBM PC ", /* IBMPC 7 */ "WYSE 75 ", /* WYSE75 8 (ANSI terminal) */ "ATT 605 ", /* ATT605 9 (ANSI terminal) */ "ATT 4410", /* ATT4410 10 (ANSI terminal) */ "TVI 922 ", /* TV922 11 (ANSI terminal) */ "HEATH 19", /* H19 12 */ "IBM 3101", /* IBM3101 13 */ "IBM 3161", /* IBM3161 14 */ "DG D100 ", /* DGD100 15 */ "DG D200 ", /* DGD200 16 */ "DG D210 ", /* DGD210 17 */ "ADDS 60 ", /* ADDS60 18 */ "ADDS 90 ", /* ADDS90 19 */ "ADM 3A ", /* ADM3 20 */ "ADM 5 ", /* ADM5 21 */ "ADM 31 ", /* ADM31 22 */ "ESPRIT 3", /* ESPRIT3 23 */ "3270/950", /* IBM3270 24 */ "TVI 910 ", /* TV910 25 */ "TVI 912 ", /* TV912 26 */ "TVI 920 ", /* TV920 27 */ "TVI 925 ", /* TV925 28 */ "TVI 950 ", /* TV950 29 */ "TVI 955 ", /* TV955 30 */ "WYSE 50 ", /* WYSE50 31 */ "WYSE 100" /* WYSE100 32 */ }; /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 p.baud from the "parmlist" structure above is an index into the 22 22 following 2 arrays. 22 22 22 22 i.e. the current baud rate for PROCOMM PLUS is baud_rate[p.baud]. 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ char *baud_desc[] = /* baud rates as strings */ { "300\0\0\0", "1200\0\0", "2400\0\0", "4800\0\0", "9600\0\0", "19200\0", "38400\0", "57600\0", "115200" }; long baud_rate[] = /* baud rates as longs */ { 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 }; /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 HOOK.C declarations and defines 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ #define PARMSIZE sizeof(struct PARMLIST) #define VMAX 10 #define SLEN 81 #define NSIZE VMAX * 2 #define SSIZE VMAX * SLEN struct PARMLIST near p; /* PCPLUS.PRM structure */ int asp_nums[VMAX]; /* ASPECT N0-N9 array */ unsigned char asp_strings[VMAX][SLEN]; /* ASPECT S0-S9 array */ unsigned int ptr_seg1; /* segment addr */ unsigned int ptr_off1; /* offset addr */ unsigned int ptr_seg2; /* segment addr */ unsigned int ptr_off2; /* offset addr */ unsigned int ptr_seg3; /* segment addr */ unsigned int ptr_off3; /* offset addr */ char far *suptr; /* ptr to far storage */ int type; /* flag from PROCOMM PLUS */ struct SREGS seg; /* structure for DS value */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 main() program routine 22 22 22 22 Hook programs receive the following arguments: 22 22 22 22 ARG 1: The string "PCPLUS". 22 22 ARG 2: Far pointer in ASCII to the ASPECT N0-N9 array. 22 22 ARG 3: Far pointer in ASCII to the ASPECT S0-S9 array. 22 22 ARG 4: Far pointer in ASCII to the PCPLUS.PRM structure. 22 22 ARG 5: Integer in ASCII indicating where hook was called from. 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ void main(argc,argv) int argc; char *argv[]; { /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 get value of segment registers into structure (we need DS value). 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ segread(&seg); /* get value of DS register */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 get segment and offset of ASPECT N0-N9 array... 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ suptr = (char far *) atol(argv[2]); /* convert str to ptr */ ptr_seg1 = FP_SEG(suptr); /* get segment addr */ ptr_off1 = FP_OFF(suptr); /* get offset addr */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 copy ASPECT array into local array 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ movedata(ptr_seg1,ptr_off1,seg.ds,(unsigned int)&asp_nums[0],NSIZE); /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 get segment and offset of ASPECT S0-S9 array... 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ suptr = (char far *) atol(argv[3]); /* convert str to ptr */ ptr_seg2 = FP_SEG(suptr); /* get segment addr */ ptr_off2 = FP_OFF(suptr); /* get offset addr */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 copy ASPECT array into local array 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ movedata(ptr_seg2,ptr_off2,seg.ds,(unsigned int)&asp_strings[0][0],SSIZE); /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 get segment and offset of PCPLUS.PRM structure from PROCOMM PLUS 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ suptr = (char far *) atol(argv[4]); /* convert str to ptr */ ptr_seg3 = FP_SEG(suptr); /* get segment addr */ ptr_off3 = FP_OFF(suptr); /* get offset addr */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 copy PROCOMM PLUS' structure into local structure 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ movedata(ptr_seg3,ptr_off3,seg.ds,(unsigned int)&p.port,PARMSIZE); /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 "TYPE" lets you know where the hook program was called from in 22 22 PROCOMM PLUS: 22 22 22 22 TYPE VALUE CALLING LOCATION 22 22 --------------------------------- 22 22 0 Upload Protocol 22 22 1 Download Protocol 22 22 2 Aspect Script 22 22 3 Meta Key Hook 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ type = atoi(argv[5]); /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 The following code is a simple example of what you can do with 22 22 a "hook" program. It assumes it was called fram an ASPECT script 22 22 and was passed some information in ASPECT variables N7 and S7. 22 22 It displays that information, then displays some information 22 22 about current settings in PROCOMM PLUS. It then puts new data 22 22 into N7 and S7 and passes it back to PROCOMM PLUS. 22 22 22 22 This is a sample ASPECT program that you can use with this hook 22 22 program to show how things get passed back and forth: 22 22 22 22 proc main 22 22 locate 0 0 22 22 n7 = 777 22 22 strcpy s7 "This message is from the ASPECT file." 22 22 hook "hook.exe" 22 22 fatsay 10 0 31 "ASPECT variable N7 passed from hook: %d" n7 22 22 fatsay 11 0 31 "ASPECT variable S7 passed from hook: %s" s7 22 22 endproc 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ /* sample: */ printf("\nASPECT variable N7 passed to hook: %d",asp_nums[7]); printf("\nASPECT variable S7 passed to hook: %s",asp_strings[7]); printf("\n\n\nPROCOMM PLUS INFO:\n"); printf("\nBaud Rate: %s, Terminal: %s",baud_desc[p.baud],termdesc[p.termtype]); printf("\nPort: COM%d, Modem Init String: %s",p.port+1,p.mdminit); /* put some info into variables for return to ASPECT... */ asp_nums[7] = 99; strcpy(asp_strings[7],"This message is from the hook program."); /* copy local variables back into ASPECT variables... */ movedata(seg.ds,(unsigned int)&asp_nums[0],ptr_seg1,ptr_off1,NSIZE); movedata(seg.ds,(unsigned int)&asp_strings[0][0],ptr_seg2,ptr_off2,SSIZE); /* signal normal exit (can be tested for with ASPECT "if success" command) */ /* 0 signal sucess, 1 signals failure. */ exit(0); } -- -----====> Skye Merlin Poier <====----- Undergrad in CMPT/MATH (Virtual Reality) |||| |||| email: poier at sfu.ca p-OO <--> OO-q THINK PGP Public Key available on finger \== ==/ From hkhenson at cup.portal.com Sat Jun 5 08:17:28 1993 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Sat, 5 Jun 93 08:17:28 PDT Subject: DISKREET--Norton Message-ID: <9306050727.1.2868@cup.portal.com> Norton might let interested people exhamine the code, far as I know nobody has asked, but one mode is DES. It seems to me if Norton were ok, you could encrypt with Norton and decrypt with any other hardware/software implimention of DES. Unless Norton does something really dumb like stashing the key on disk somewhere, it would seem to me that this would varify Norton doing DES per the book. Have I missed something? Keith From i6t4 at jupiter.sun.csd.unb.ca Sat Jun 5 08:37:18 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Sat, 5 Jun 93 08:37:18 PDT Subject: CryptoStacker, long term vision In-Reply-To: Message-ID: > As for those people that can't afford to use dedicated hardware, there is > still the less secure idea of having the key stored on a floppy that would > be inserted at load time and read into memory. This would have the > obvious disadvantage of having the key sitting around in memory, a sitting > duck (especially for people who leave their systems on all of the time, > like me, as soon and the Nazis learned about systems like these then 'Run > a key scanning program on the system to be confiscated' would just become > step one in their procedure, would be a hole even if the keys were > password protected) but it would be better than nothing at all, and the > speed problems could be dealt with by using the multiple partition method > that I described earlier, having a 'secure' virtual disk where all of your > data goes, and a seperate 'fast' virtual disk which is unencrypted where > all of your programs and such go. Hmmm... I have a suggestion to make keeping the key in memory a little more safe, though I don't think there is way to prevent a properly resourced person/agency/enemy from getting it (or any other data in the RAM of the computer). You first need a machine which has a supervisor state, which *only* the OS can run in. Your cryptostacker will be part of the OS and as such, user processes cannot access its memory. This way, the attacking agency will have difficulty just running any old program to copy all of the CPU's memory to a disk. The only way to add new programs to the supervisor state (OS) would be if the machine is power up in a special way (with a certian boot disk for example) so that once the machine is running there is *no* software method to read any OS data. You would also want to avoid storing the crypto key at a fixed memory location. Allocate some memory at a variable location at each startup and store this location *only* in a register. This should make it even more difficult to get the key, because you would need to be able to check the supervisor stack to find the right register to find the location of the key. This raises the question of just how much work an agency goes through when it is first confiscating a machine to ensure that they can get at all the machines data. If the first thing they do is turn the machine off to be able to pack it up, then you are all set. (Assuming you didn't manage to turn it off before you lost control of the machine.) What kinds of things can you do to your home machine to make more tamper proof? If you have an "easy access" case, how about installing a micro switch that will reset the machine (or power cycle the system) when its opened. --- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger From i6t4 at jupiter.sun.csd.unb.ca Sat Jun 5 09:00:14 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Sat, 5 Jun 93 09:00:14 PDT Subject: CryptoStacker, long term vision In-Reply-To: <9306031512.AA25490@soda.berkeley.edu> Message-ID: > Your keying material should be long. I earlier suggested one key per > track. These keys are going to have to be stored somewhere, and the > disk is the wrong place for it, clearly. This implies that the user > is going to have to have some key-holding device (likely a diskette) > which will be necessary in order to unlock the partition. the keying > material should be password protected. This device will be have to > used at boot time if anything necessary to boot is stored on the > encrypted partition. > Keying material will need to be backed up. This should be made as > painless as possible, otherwise there will be plenty of people losing > whole drives. This probably goes without saying, but just to make sure... Since you are talking about using a partition, and partitions do not often change in size (it implies a lot of backup and restore work to change a partition size normally) then you could generate all the keys for all the (known and fixed number of) tracks in advance. The first thing the user should do after generating all the keys is to make **many** backups, perhaps all with different keys to encrypt the keys. No one wants to lose a whole partition because a floppy wore out and broke down! The other interesting thing about encrypting per track... it exemplifies the trade offs often associated with computing... Usually they preach that all files should be contiguous (all sectors on the same track if possible) but for the most secure encryption of a file in this cryptostacker you would want files to be on as many different tracks as possible. --- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger From i6t4 at jupiter.sun.csd.unb.ca Sat Jun 5 09:05:14 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Sat, 5 Jun 93 09:05:14 PDT Subject: Another chaining utility In-Reply-To: <199306031333.AA16241@Menudo.UH.EDU> Message-ID: I read this, and without knowing if anyone else has replied, it looks like a need for an explanation of how to get more environment space in DOS. Is it that you don't know how to increase the DOS environment size, or does it still not work even if you have increased it? OBdisclaimer: I don't know 4DOS, just regular old MS/PC DOS... and maybe a little DRDOS. :-) --- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger On Thu, 3 Jun 1993 elee9sf at Menudo.UH.EDU wrote: > > I couldn't get Karl's hopmail.bat to run on my PC (not enough environment > > space?) so I wrote this in C and it works OK. > > Say, is anybody else having this problem? I wonder what the problem > is (environment space?) PLEASE let me know about bugs or problems > with the scripts. I'm going to be updating the dos versions pretty > soon, and will see if I can figure out what the space error means. From strick at osc.versant.com Sat Jun 5 14:04:37 1993 From: strick at osc.versant.com (henry strickland) Date: Sat, 5 Jun 93 14:04:37 PDT Subject: DISKREET--Norton In-Reply-To: <9306050727.1.2868@cup.portal.com> Message-ID: <9306052112.AA29094@versant.com> # From: hkhenson at cup.portal.com # Subject: Re: DISKREET--Norton # # , it would seem # to me that this would varify Norton doing DES per the book. Have # I missed something? DES defines an encryption algorithm, but not how it is deployed in an environment. Questions I would have: -- Is the key that the user types in used DIRECTLY as a 8-ASCII-character DES key? If you don't type 8 characters for the key, how is it padded? -- Does it use CBC mode, or what? -- Where does it get an initialization vector? -- Assuming CBC or some other chaining mode, is an entire file encrypted as a single unit? Or is each file block encrypted, beginning with a quickly-determined initialization vector, and what are they? -- If the length of the file is not a multiple of 8 bytes (the DES cyperblock size), how is the boundary condition handled? -- Are filenames encrypted? How? Other directory information? If the source to Norton were not published, but rigorous specs were available that could be verified by trying it an a bunch of files, and if one can account for all bytes on disk that change when the package is used (so that we know it is not escrowing keys or doing anthing stupid with them), then I might feel comfortable about the product. I don't think this is unreasonable to ask. It would particularly make me feel safe about the problems we heard described earlier, where someone was unable to decrypt files. If I can deploy and use my own decryption mechanism to doublecheck Norton, then it's more likely my own fault if I cannot recover some file. strick From smb at research.att.com Sat Jun 5 14:35:14 1993 From: smb at research.att.com (smb at research.att.com) Date: Sat, 5 Jun 93 14:35:14 PDT Subject: Dig. Cash Question. Message-ID: <9306052135.AA26361@toad.com> I'm reading the paper that was announced on this list about Digital Cash last week. It was writen by Stefan Brands. I think I have a strong Math background, but I don't know what is meant by a "descrete log" in a group G. I understand what a group is. I just don't know what properties an element, a, would have if it were the log sub p of e. Can someone help me. Otherwise, this is a very interesting article. Thanx in advance. You might want to fix your mailer; according to the strict letter of RFC822, human-readable names shouldn't contain periods unless quoted.... Anyway -- suppose that in some group, you know that a^n=b, where a and b are members of the group, and n is an integer. a^n indicates the group operation iterated n times. The discrete log problem is recovering n, given ``a'' and a^n=b. In some groups, this is a very hard problem. The group most commonly used in cryptography is the field GF(p), i.e., the field of integers modulo p, where p is some large number, preferably a prime, and ``a'' is a ``primitive root'' of the field. The problem is thus to find n, given ``a'' and a^n modulo p. Other instances of discrete log are useful as well; NeXT, for example, uses the same basic equation in a field over some family of elliptic curves. Their much-ballyhooed invention was to find a set of such curves for which the exponentiation operation can be performed very efficiently. Oddly enough, solving discrete log in GF(p) seems to be vaguely akin to factoring. p doesn't have to be a prime, but you can use smaller numbers if it is. Early attempts used 2^n, since that makes the modulus operation trivial, but if you do that, you need such a large n that it doesn't pay. For p a prime, 512 bits is probably secure now, though possibly not against NSA. 1024 bits is likely to be secure forever, barring major theoretical breakthroughs. --Steve Bellovin From mdiehl at triton.unm.edu Sat Jun 5 15:06:37 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sat, 5 Jun 93 15:06:37 PDT Subject: Dig. Cash Question. In-Reply-To: <9306052136.AA04744@triton.unm.edu> Message-ID: <9306052206.AA05155@triton.unm.edu> According to smb at research.att.com: > > I'm reading the paper that was announced on this list about > Digital Cash last week. It was writen by Stefan Brands. I > think I have a strong Math background, but I don't know what is > meant by a "descrete log" in a group G. I understand what a > group is. I just don't know what properties an element, a, > would have if it were the log sub p of e. Can someone help > me. Otherwise, this is a very interesting article. Thanx in > advance. > > You might want to fix your mailer; according to the strict letter of > RFC822, human-readable names shouldn't contain periods unless quoted.... I sent word to those "in charge." ;^) Maybe after I graduate, they will fix it.... > Anyway -- suppose that in some group, you know that a^n=b, where a > and b are members of the group, and n is an integer. a^n indicates > the group operation iterated n times. The discrete log problem is > recovering n, given ``a'' and a^n=b. > > In some groups, this is a very hard problem. The group most commonly > used in cryptography is the field GF(p), i.e., the field of integers > modulo p, where p is some large number, preferably a prime, and ``a'' If I understand this correctly, if p is not a prime, then n may not be unique. > is a ``primitive root'' of the field. The problem is thus to find > n, given ``a'' and a^n modulo p. Other instances of discrete log > are useful as well; NeXT, for example, uses the same basic equation > in a field over some family of elliptic curves. Their much-ballyhooed > invention was to find a set of such curves for which the exponentiation > operation can be performed very efficiently. > Thanx for the (very!) clear explaination. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From smb at research.att.com Sat Jun 5 16:06:05 1993 From: smb at research.att.com (smb at research.att.com) Date: Sat, 5 Jun 93 16:06:05 PDT Subject: Dig. Cash Question. Message-ID: <9306052306.AA26846@toad.com> > Anyway -- suppose that in some group, you know that a^n=b, where a > and b are members of the group, and n is an integer. a^n indicates > the group operation iterated n times. The discrete log problem is > recovering n, given ``a'' and a^n=b. > > In some groups, this is a very hard problem. The group most commonl y > used in cryptography is the field GF(p), i.e., the field of integers > modulo p, where p is some large number, preferably a prime, and ``a' ' If I understand this correctly, if p is not a prime, then n may not be unique. Well, n isn't unique even if p is prime. Consider a=10,p=11. 10^2=10^4=10^6=10^8=10^10=1 mod 11. You only get a maximum-length cycle if ``a'' is a primitive root, hence the restriction I stated in the part I deleted... It doesn't matter that n isn't unique, though you do want a good distribution. Primitive roots have a maximal distribution, which is why they're good. But a reduction by, say, a factor of 2 doesn't matter in practice. (For p=11, try a=3.) The implementation of secure RPC in SunOS uses Diffie-Hellman (which relies on the difficulty of the discrete log problem) with base that's not a primitive root. To be sure, their key exchange was cryptanalyzed, but that's because they picked a 192-bit modulus, not because of the exponentiation base. If I recall correctly, if p=kq+1, for q a prime and k a small integer, there are (q-1)/k primitive roots in GF(p). That suggests generating p=2q+1, p and q prime, which gives a very good density. And checking if a number is a primitive root is easy (again, to my recollection; I'm not a number theorist) if you know the factorization of p-1, which of course we do in this case. From anton at hydra.unm.edu Sat Jun 5 17:41:00 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Sat, 5 Jun 93 17:41:00 PDT Subject: Software infrastructure In-Reply-To: <35870.pfarrell@cs.gmu.edu> Message-ID: <9306060040.AA07296@hydra.unm.edu> I am NOT interested in arguing the merits or lack thereof of Kermit. Kermit IS used, but rarely on PCs, and VERY rarely in what appears to be the target market. Remember that we're talking about a general-user, friendly application for the compuklutz. After being spoiled by QModem, there is no way in hell, heaven or otherwise that many of them will use Kermit or something based on it, unless it offers all that QM does (incl. Zmodem, external protocols, cute menuing interface, etc.) I think there's a confusion here, namely that Kermit is useful on some sorts of machines, and for specific purposes, but this idea is getting mixed up with what is the most useful DOS comm program(s), the one(s) most used. THATs where the market is. Its not a matter of "is kermit cool, is kermit good enough, is kermit free?", its a matter of "will the target users actually use it, or anything based on it?" I'd suggest again that the answer is "no". That's all. Not meaning to insult anyone who's fave term prog. is kermit. Just trying to suggest a clarified view of the PC telecom program market. People make new comm programs all the time, many with a LOT of features. But they ain't the Big Three, so they get ignored. Perhaps sadly. -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From 76244.315 at CompuServe.COM Sat Jun 5 18:54:38 1993 From: 76244.315 at CompuServe.COM (Doug Porter) Date: Sat, 5 Jun 93 18:54:38 PDT Subject: CryptoStacker Message-ID: <930606015152_76244.315_CHN23-4@CompuServe.COM> The mother lode of source code for MSDOS redirectors, drivers, and related code appears to be the BCPPDOS forum on CompuServe. Some of the authors state that their software has been placed in the public domain, although for some reason they usually left in their copyright notices. It's a very good idea to have the author's explicit permission on file before redistributing any of this software. In the C programming library: CPHANT.ZIP C source for MSDOS network redirector DRIVER.ZIP C/Asm source for generic driver skeleton RDCF2.ZIP C source for complete MSDOS file system In the General library: CRAMDI.ZIP C source to RAM disk driver FDCBIOS.ZIP Asm source to floppy disk driver Doug From mmidboe at cs.uah.edu Sat Jun 5 21:11:25 1993 From: mmidboe at cs.uah.edu (digital saint Computer Science Dept., Univ. of Alabama-Huntsville) Date: Sat, 5 Jun 93 21:11:25 PDT Subject: Software infrastructure Message-ID: <9306060412.AA06825@uahcs2.cs.uah.edu> CY>Buzzword alert. What is "TPU"? And who makes "Async Pro", and what CY>exactly does that do? Well, in the PC world, a TPU is just a Turbo Pascal Unit. It's become kind of a standard for making easy add-ons to programs since a lot of programmers use Turbo Pascal. Async Pro is written by Turbo Power software. Anyways, does anyone have any basic ideas on what functions would be really important for some kind of programmers toolkit? To narrow things down you might want to make a PGP toolkit that manipulates PGP keys and makes using PGP easier from other programs. So, does anyone have feedback on some good general PGP encrypted file manipulation functions? Once you make them easy to integrate into other programs I'm sure more and more people will pick it up. Reading through the vast amounts of C code on PGP is quite a daunting task. From anton at hydra.unm.edu Sat Jun 5 22:31:18 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Sat, 5 Jun 93 22:31:18 PDT Subject: NitV is DOWN! Message-ID: <9306060531.AA12404@hydra.unm.edu> > DON'T call for PGP toys from my system any time this week, and likely next. > The system is DOWN, due to a motherboard video-related problem (among others). > Serves me right for buying mailorder, with a 1yr warranty (it's been 1 > year and 2 months. Of course.) NitV should be up and running and all > the crypto files available again within a couple weeks. Blagh. > Of course, what REALLY must've happened is the SS sneaked into my house in > the middle of the night and ran a magnet over my BIOS... >;) > > -- > When marriage is outlawed only outlaws will be inlaws! > Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS > Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 > Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA > Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) > Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) > -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From mdiehl at triton.unm.edu Sat Jun 5 23:30:08 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sat, 5 Jun 93 23:30:08 PDT Subject: Dig. Cash Question. In-Reply-To: <9306052306.AA05980@triton.unm.edu> Message-ID: <9306060630.AA10639@triton.unm.edu> According to smb at research.att.com: > > If I understand this correctly, if p is not a prime, then n may not be > unique. > > Well, n isn't unique even if p is prime. Consider a=10,p=11. > 10^2=10^4=10^6=10^8=10^10=1 mod 11. You only get a maximum-length > cycle if ``a'' is a primitive root, hence the restriction I stated > in the part I deleted... That is, if a is a generator of G, or as close to one as possible. My thinking was obviously clowded... Not that I have a beer in me, I remember that for any element, a of group G, a will have order n, such that n|ord(G). This implies that there are n different (positive) powers of a which yield a particular number, b in our case. Each of which would qualify as a log. I think I understand. > It doesn't matter that n isn't unique, though you do want a good > distribution. Primitive roots have a maximal distribution, which is Then which root are we to use in discussion? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From gnu Sun Jun 6 00:35:23 1993 From: gnu (John Gilmore) Date: Sun, 6 Jun 93 00:35:23 PDT Subject: decompiling DISKREET In-Reply-To: <9306050121.AA13122@triton.unm.edu> Message-ID: <9306060734.AA00306@toad.com> > > This is the reason that I disregard DISKREET from Norton. There's no > > source, and largish companies are notorious for pushing compromised > > software. Norton's unlikely to ship source, so unless someone > > decompiles it, I'm not biting. > > HMMmmm..... Well, how big is it? Is it a .exe or .com? It might be very > instructive to see how they do it... By the way, I have a relatively usable free 68k disassembler, and have recently retrofitted the simple GNU portable disassembler (supporting many processors) with an interface that should allow it to be glued into the usable disassembler (which traces branches, creates labels, lets you label things yourself, etc). Anyone who would like to work on these tools, please let me know. The GNU `objdump' program will disassemble the entire program from any object file format it recognizes (currently most a.out variants, most COFF variants, ELF, ecoff, xcoff, s-records, some IEEE object files). We have specs on the Windows object file formats, if anyone wants to add support for reading them. DOS EXE and COM files would be a useful addition, as well. You can get a taste of the current simple disassembler by getting the latest GNU Binutils (binary utilities) release from prep.ai.mit.edu or ftp.uu.net. Configure and build it on any of about twelve kinds of Unix machines, and run "objdump -d" on itself. John Gilmore From zimm at alumni.cco.caltech.edu Sun Jun 6 04:51:32 1993 From: zimm at alumni.cco.caltech.edu (Mark Edward Zimmerman) Date: Sun, 6 Jun 93 04:51:32 PDT Subject: random access into an encrypted file? Message-ID: <9306061150.AA07264@alumni.cco.caltech.edu> I'm enjoying the discussion of encrypting file systems, but have a perhaps-naive question: can the methods recently proposed here work for fast "random" access of bytes from the middle of a possibly-large file? Specifically, over the years I have written some free-text information-retrieval programs which build complete inverted indices to every word in a chosen text file (which may be many megabytes long, limited by disk space, not by RAM) --- and in order to fetch and display text quickly from an arbitrary point in the file, my programs do a lot of fseek() operations. If a file is encrypted under various schemes, I wonder how long it would take to fetch byte 100,000,000? Could it cause me some performance problems? :-) Just thought I'd raise the issue.... BTW, if anybody wants to work with large text files, the stuff I've done is all free under GNU GPL; for nicest user interface, see Mac version which hides behind HyperCard (in INFO-MAC archive at sumex-aim.stanford.edu, under directory info-mac/card with a name beginning "freetext", I think). Generic command-line C code to build indices is "qndxr.c" in various archives, and the generic command-line browser is "brwsr.c". See description in THE DIGITAL WORD, eds. Landow & Delany, MIT Press, 1993, pps. 53-68, for more details. Briefly, the programs let you scroll around in alphabetized word lists, generate key-word-in-context displays and do simple proximity filtering, and retrieve chunks of text on demand, very fast. Index-building is 15-20 MB/hour on an older Mac II-class machine, 60-80 MB/hour on a Sparcstation, etc. Best, ^z (no relation!) From mulivor at crc.monroecc.edu Sun Jun 6 09:45:59 1993 From: mulivor at crc.monroecc.edu (mulivor at crc.monroecc.edu) Date: Sun, 6 Jun 93 09:45:59 PDT Subject: SPA Press Release Message-ID: <9306061624.AA09694@relay2.UU.NET> I recently received this press release from the Software Publishers Association. It gets better as it goes on. --Phil Mulivor mulivor at orion.crc.monroecc.edu -------------------------------------------------------------------- 06/04 1018 SPA RENEWS CALL FOR LIBERALIZING EXPORT CONTROLS WASHINGTON (JUNE 4) IDG PR SERVICE - At a National Institute of Standards and Technology (NIST) hearing Thursday on national cryptographic policies, the Software Publishers Association (SPA) explained how continued "munitions" export controls of mass market software with encryption capabilities were seriously harming the American software industry and renewed its call for significant export liberalization of mass market software using DES or other encryption algorithms such as RC2/RC4 at comparable strengths. SPA also warned that the Administration's recent announcement of its "Clipper Chip" initiative did not address the software industry's concerns and should not be an excuse to delay export liberalization. The SPA announced the preliminary results of its recent research which reveal a robust and rapidly expanding foreign market in encryption programs and products. "Unilateral US export controls do not make any sense given the widespread legal availability of foreign encryption programs," testified Ilene Rosenthal, SPA's general counsel. "Foreign companies will buy foreign encryption products if they cannot buy from American companies and in turn become ex-US customers. As a result, the U.S. Government will only succeed in crippling an American industry's exporting ability." The SPA research team preliminary concluded that: - The US no longer dominates the encryption field. In fact, the SPA has identified to date more foreign than domestic encryption programs and products (143 vs. 133). - There clearly are many foreign options for strong encryption, contrary to assertions by the U.S. government. SPA has preliminarily identified to date 80 foreign software, hardware, and combination hardware/software products for text, data, and file encryption from companies in 13 foreign countries. Forty-eight of these employ DES, which is nearly impossible to export from the U.S. in other than very rare circumstances. Sixty-three additional foreign encryption programs and products have been identified (including those from an additional five countries) but have yet to be investigated. However, SPA believes many of these also will be found to employ DES or other comparable strength encryption algorithms. - Fifteen foreign mass market encryption software programs and kits are available that employ the DES algorithm. These are published by companies in Germany, Israel, the United Kingdom, Denmark, Canada, Belgium, and Australia. These software programs are installed by the user inserting a diskette; the kits enable encryption capabilities to be easily programmed into a variety of applications. - Foreign companies increasingly recognize and are responding to the need to provide software only encryption solutions. Although the foreign encryption market is still heavily weighted towards encryption hardware and hardware/software combinations, the market trend is going to software. The SPA noted that in addition to these commercially available programs and products, any analysis of the availability of foreign encryption alternatives must consider programs available on the Internet, which is the largest global network connecting millions of users throughout the world. - DES is widely available on the Internet, including implementations that can be simply down-loaded and used. - A recently popularized encryption program entitled Pretty Good Privacy (PGP) also is widely available throughout the world. PGP implements the International Data Encryption Algorithm (IDEA), which provides protection comparable to DES. The program is intended for electronic mail, but also is ideal for encrypting files. It is available for free, may be used legally throughout Europe, whether in a business or at home, comes with easy-to-read instructions, is trivial to install, and simple to use. "Some government officials routinely assert that even if the Government prohibits America's software publishers from offering encryption features demanded by their customers abroad, we should not be concerned because there are foreign programs and products available," said Ken Wasch, SPA's executive director. "Our reseach shows that such an assertion is erroneous. In fact, there are a very large number of such programs and products available on the market today. The result is lost sales for American business without any improvement in national security." The Software Publishers Association is the principal trade association of the PC software industry. Its more than 1000 members represent the leading publishers in the business, consumer, and education markets. The SPA has offices in Washington and Paris, France. CONTACT: Software Publishers Association, Washington Terri Childs, 202/452-1600 From mark at coombs.anu.edu.au Sun Jun 6 09:50:31 1993 From: mark at coombs.anu.edu.au (Mark) Date: Sun, 6 Jun 93 09:50:31 PDT Subject: CryptoStacker Message-ID: <9306061529.AA02177@relay2.UU.NET> >In the C programming library: > > CPHANT.ZIP C source for MSDOS network redirector > DRIVER.ZIP C/Asm source for generic driver skeleton > RDCF2.ZIP C source for complete MSDOS file system > >In the General library: > > CRAMDI.ZIP C source to RAM disk driver > FDCBIOS.ZIP Asm source to floppy disk driver How does someone no on compu$erve get access to these? archie didnt report anything. (Want to peek at the cphant.zip file) Mark mark at cheops.anu.edu.au From i6t4 at jupiter.sun.csd.unb.ca Sun Jun 6 10:31:26 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Sun, 6 Jun 93 10:31:26 PDT Subject: random access into an encrypted file? In-Reply-To: <9306061150.AA07264@alumni.cco.caltech.edu> Message-ID: Mark: There are two possible ways to encrypt the file as they go to the disk, and I think which you choose would determine what problems an fseek would encounter... As I understand the conversation so far, the talk is to make the encrypted disk software a device driver. Imagine what a typical device driver must do. The operating system wishes to see all files as long strings (streams) of bytes and the disk drive wishes to see all "files" as a collection of sectors (of a fixed size). The device driver converts a request for file position 'x' to a request to locate sector 'y'. Even if you only want one byte from the file, a whole sector gets read in. So heres where you have to decide which way you are going to encrypt the file. If you are going to encrypt each sector in isolation, then when the operating system requests a certain file location, that maps to a certain sector which is read in, decrypted (in isolation from the rest of the sectors) and then a particular byte is readily available. If however you use a different scheme whereby the whole file is encrypted as a single entity (which would be difficult to impossible to do using the device driver metaphor, but there are other ways to wedge encryption into the system) then presumably you need to decrypt from the very beginning any time you need to seek into the file, which is what I think you were worried about. If you are familiar with data compression products, then here is a comparison of the two techniques: If you use something like stacker, which is implemented as a device driver, then you have access to any byte of any file at any time. If you use something like pklite (the .exe compressor) then you can never seek into the file (to load an overlay for example). You have to read the whole file and decompress it in order access the bytes individually as uncompressed data. (That is not a perfect metaphor, as pklite files are self decompressing when they execute, not when the operating system accesses them, but it does serve to show the limitations imposed my higher level file management.) --- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger On Sun, 6 Jun 1993, Mark Edward Zimmerman wrote: > I'm enjoying the discussion of encrypting file systems, but have a > perhaps-naive question: can the methods recently proposed here work > for fast "random" access of bytes from the middle of a possibly-large > file? > Specifically, over the years I have written some free-text > information-retrieval programs which build complete inverted indices > to every word in a chosen text file (which may be many megabytes long, > limited by disk space, not by RAM) --- and in order to fetch and > display text quickly from an arbitrary point in the file, my programs > do a lot of fseek() operations. If a file is encrypted under various > schemes, I wonder how long it would take to fetch byte 100,000,000? > Could it cause me some performance problems? :-) From mdiehl at triton.unm.edu Sun Jun 6 11:41:24 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sun, 6 Jun 93 11:41:24 PDT Subject: My Poll. Message-ID: <9306061841.AA18948@triton.unm.edu> This is just a note to let you know that the deadline for my poll has been extended to Monday evening. My kitchen flooded yesterday and I will not have time to prepare the results of my poll till monday night. You may expect the results tuesday. Bummer. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From hughes at soda.berkeley.edu Sun Jun 6 11:58:21 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sun, 6 Jun 93 11:58:21 PDT Subject: random access into an encrypted file? In-Reply-To: <9306061150.AA07264@alumni.cco.caltech.edu> Message-ID: <9306061854.AA08835@soda.berkeley.edu> >can the methods recently proposed here work >for fast "random" access of bytes from the middle of a possibly-large >file? The model that has been most discussed recently has been that of encrypting sectors on the hard disk. In order to have random access to files, you have to have random access to sectors. Therefore, the encryption mechanism chosen must support random sector access. This is not difficult, but many of the techniques used for telecommunication encryption do not work. In particular, encryption modes that depend upon some previous state of the encryption machine do not work well. Cipher block chaining is a mode of operation for block ciphers that where the plaintext is xor'd with the previous block of ciphertext before encryption. The first block of plaintext, where there is no previous block, is xor'd with an initial vector, which may be considered part of the keying material. Now consider what would happen if you encrypted your whole disk in CBC mode. You'd have to start at the beginning of the disk and decrypt up to the point that you want to read. For a bit stream, this is fine, since one is decrypting the whole thing. CBC, however, is useful for doing sector encryption. A DES block is 8 bytes, a sector is typically 512. I assume here that one has to read the whole sector out of memory, although with some very clever and not obviously worthwhile optimizations one could decrypt on demand. Now CBC is a reasonable choice ifor in-sector encryption, because you have to read the whole thing anyway. Yet CBC requiress an initial vector. This is where counter mode come in. A good block cipher has what is called the avalanche property, which says that altering any bit of the input alters on average half of the bits of the output. (Note: if it altered more than half, the 1's-complement would change by less than half.) Thus the initial vectors do not need to change particularly much from one initial vector to the next. Hence an integer-valued counter works fine. For hard disks the sector number, already present, makes just such a unique initial vector. Summary: CBC within sectors, initial vectors provided by the sector number. This characterization of keying material works for block ciphers generally and yields a clean abstraction for the rest of the system. algorithm identifier (index or function pointer or link spec) plaintext/ciphertext block length key length The rest of the encryption code need only know these values. Here are some examples. Lengths are byte lengths. single DES, 8, 8 (64 bits, of which only 56 are used) double DES, 8, 16 triple DES, 8, 24 IDEA, 8, 16 Nice and clean. Eric From rarachel at ishara.poly.edu Sun Jun 6 16:33:14 1993 From: rarachel at ishara.poly.edu (A1 ray arachelian (library)) Date: Sun, 6 Jun 93 16:33:14 PDT Subject: ROT-13 hoopla on EchoMac Message-ID: <9306070028.AA17913@ishara.poly.edu> I seriously hope that this won't be way too off topic for this group, but I seem to have painted myself into a bit of a corner recently on FidoNet. Basically, it all started when someone requested a copy of a ROT-13 extension to a popular Macintosh programmer's editor called BBEdit. Soon after, the discussion was joined by the fatheaded sysops who would bible thump on the FidoNet rules that ROT-13 was encryption and as such it is outlawed on FidoNet. To make a long story shorter, in my plight to enlighten these folks (and the moderator of EchoMac who saw fit to banish me for posting a message encrypted with ROT-13,) I got a bit out of hand and started the usual on the soap-box preeching which included a message inviting everyone to join in the conversation by getting the ROT-13 extension. The rest of that message was "encrypted" by ROT-13. Now since ROT-13 is merely nothing more than A=N, B=M, C=O, D=P... and is fairly standard, I've got it on my head to convince the moderator that ROT-13 is not actually an encryption method. The FidoNet policies state that Fidonet cannot provide any sort of privacy as a measure to protect sysops from taking the heat for the possible illegal activities of users. Clearly, ROT-13 does not provide the least bit of privacy, save from a total computer neophyte. So, the reason I'm writing this here was basically "to go to the experts of encryption," and try to get them to agree with me that ROT-13 has never been a form of encryption because its purpose does not provide privacy. So I'm just asking you to agree with me, and I'll send the results to the moderator in question. If you'd like, mail me the responses directly so we won't clutter cypherpunks further, and I'll forward them myself. If you'd like, the moderator's address on FidoNet is Steve Ebener at 1:152/42,FidoNet (this should be reachable via Steve.Ebner at f42.n152.z1.ieee.org) Please don't flame him, I'm trying to unbanish myself off the echo, not get him upset, however the thought of writing a program that sends a cookie to him every twenty minutes did occur, at least until I thought better of it. From anton at hydra.unm.edu Sun Jun 6 18:07:53 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Sun, 6 Jun 93 18:07:53 PDT Subject: ROT-13 hoopla on EchoMac In-Reply-To: <9306070028.AA17913@ishara.poly.edu> Message-ID: <9306070107.AA02107@hydra.unm.edu> You might also wish to enlist the aid of Dave Munhollon, who is one of the main hub providers in SecureMail, the Fido crypto message backbone (yes there is such a thing, most of Fido just doesn't want you to know about it.) Forget the address right off hand, but he's in the nodelist. -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From karn at qualcomm.com Sun Jun 6 20:19:52 1993 From: karn at qualcomm.com (Phil Karn) Date: Sun, 6 Jun 93 20:19:52 PDT Subject: Tempest@home? Message-ID: <9306070319.AA07532@servo> A good source of general info on RFI (radio frequency interference) suppression can be found in amateur radio publications. THe same techniques hams use to keep their computers from interfering with their radios can be used to keep your computers from getting into the NSA's receivers... Phil From dporter at well.sf.ca.us Mon Jun 7 00:52:41 1993 From: dporter at well.sf.ca.us (Doug Porter) Date: Mon, 7 Jun 93 00:52:41 PDT Subject: CryptoStacker Message-ID: <93Jun7.005219pdt.13914@well.sf.ca.us> Some folks have asked that the network redirector, driver, and file system source files from CompuServe be made available via ftp. Two of them, cramdi.zip and rdcf2.zip may not be public domain. I've ftp'd the others to soda.berkeley.edu, as well as rdcf.zip, a public domain earlier version of rdcf2.zip. I'm sure Eric will have them visible soon. I'll contact the authors of cramdi and rdcf2. Doug From JZA3001 at HUSZEG11 Mon Jun 7 07:51:02 1993 From: JZA3001 at HUSZEG11 (b2men of EastEdge) Date: Mon, 7 Jun 93 07:51:02 PDT Subject: eastedge aDDRESS CHAnge Message-ID: <9306071450.AA07575@toad.com> Attention| E-mail address of EastEdge has changed to jza3001 at huszeg11.bitnet Old address will not exist in 5 days Please spread this information Thanx -b2men signing off From ebrandt at jarthur.Claremont.EDU Mon Jun 7 09:18:32 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Mon, 7 Jun 93 09:18:32 PDT Subject: remailer lossage: blank lines Message-ID: <9306071618.AA09949@toad.com> Well, nobody told me whether a message did or did not get through, but I'm now sure they didn't. All of the failed messages have blank lines before the :: token, which is consequently not recognized by recurse.pl. I dunno how they got in there, but I guess I should learn some perl and robustify against this -- unless somebody can think of a reason why :: needs to be able to start a message without being stripped. Damned in-band signalling... Eli ebrandt at jarthur.claremont.edu From norm at netcom.com Mon Jun 7 10:48:16 1993 From: norm at netcom.com (Norman Hardy) Date: Mon, 7 Jun 93 10:48:16 PDT Subject: CryptoStacker, long term vision Message-ID: <9306071748.AA22182@netcom3.netcom.com> When the Iranians took over the American Embassy in Teheran they, acquired access to the machines there. Subsequently there was talk of computer systems that were guaranteed to be volatile except for ciphered disks. There would be an unciphered boot block on disk that did not have the key to the rest of the disk but did have code to read and decipher the rest of the operating system. That key, however, would be in a safe place such as Washington DC. The system could not be booted until the key was available, presumably thru secure communications. If you trusted the operating system to only use the key for reading and writing the disk but not otherwise then pulling the plug made the all data in the computer inaccessible baring action from Washington. From hughes at soda.berkeley.edu Mon Jun 7 12:04:02 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 7 Jun 93 12:04:02 PDT Subject: ALERT: PGP removed from soda archive site Message-ID: <9306071900.AA08993@soda.berkeley.edu> The ftp site at soda will no longer be able to distribute PGP, I'm afraid. It appears that CERT informed someone on campus that "pirated" software was available on soda. The word came down, and the directory has been chown'd root and has had permissions removed. There will be more later on this. In the meantime, spread the word. Eric From mallen at redvax1.dgsca.unam.mx Mon Jun 7 16:01:44 1993 From: mallen at redvax1.dgsca.unam.mx (Mallen Fullerton Guillermo Manuel-UIA) Date: Mon, 7 Jun 93 16:01:44 PDT Subject: Dbase encryption Message-ID: <9306071535.AA15216@redvax1.dgsca.unam.mx> There is an encryption option in Dbase (SET ENCRYPTION ON). How secure is this encryption? How it works? I suspect it is not secure at all as the US Government allows its exportation :-( Guillermo From mimir at u.washington.edu Mon Jun 7 17:58:00 1993 From: mimir at u.washington.edu (Al Billings) Date: Mon, 7 Jun 93 17:58:00 PDT Subject: ALERT: PGP removed from soda archive site In-Reply-To: <9306071900.AA08993@soda.berkeley.edu> Message-ID: On Mon, 7 Jun 1993, Eric Hughes wrote: > The ftp site at soda will no longer be able to distribute PGP, I'm > afraid. It appears that CERT informed someone on campus that > "pirated" software was available on soda. The word came down, and the > directory has been chown'd root and has had permissions removed. What does CERT stand for again? From fergp at sytex.com Mon Jun 7 18:38:37 1993 From: fergp at sytex.com (Paul Ferguson) Date: Mon, 7 Jun 93 18:38:37 PDT Subject: ComputerWorld article on Clipper/Capstone Message-ID: <6PXs5B2w165w@sytex.com> ComputerWorld June 7, 1993 Vol. 27, No. 23 page 21 Fed officials pan ban of old encryption specs by Gary H. Anthes Gaithersburg, MD Federal officials responsible for shaping information security policy said last week that legislation mandating use of the government's recently proposed encryption technology -- and banning the use of older but popular techniques -- is neither wise nor legal. In April, the White House said it intended to establish as a federal standard an approach to encryption called "key-escrow." This method would require that the keys needed to unlock a coded conversation be kept by government-approved agencies and retrieved only for court-ordered wiretaps. Dubbed "Clipper" for voice communications and "Capstone" for data, the approach is intended to balance the conflicting objectives of users -- who demand absolute security and privacy -- and law enforcement agencies, which are looking for a legal "backdoor" into coded criminal communications. Protecting rights to privacy But the idea has been challenged by civil libertarians who fear abuses by a technologically empowered Big Brother, and by some users, especially those such as banks that have made large investments in cryptography based on the older Data Encryption Standard (DES), which some fear could be banned by the government. Protesters so far include the Computer and Business Equipment Manufacturers Association, Information Technology Association of America, Computer Professionals for Social Responsibility, Electronic Frontier Foundation, Business Software Alliance, Software Publishers Association and Information Systems Security Association. Raymond Kammer, acting director of the National Institute of Standards and Technology (NIST), acknowledged that a ban on existing techniques would be considered. "But my personal opinion is, I can't see doing anything that would take away any freedoms we now enjoy," Kammer said. "We tried to come up with a technique that would not require legislation," said Clint Brooks, advisor to the director of the National Security Agency, which developed and now strongly supports the key-escrow approach. Brooks predicted it would be years before criminal use of DES would be wide-spread enough to present obstacles to law enforcement agencies, which cannot crack DES codes. "Let's wait and see if legislation is needed," he said. While the majority of those attending a public hearing at the NIST last week spoke out against the government's proposal, a few strongly defended it saying criticisms are either misdirected or deal with fixable flaws. Donald Alvarez, national defense science and engineering graduate fellow at Princeton University, outlined six ways that Clipper could be breached but finished by saying, "I definitely believe it is possible to address the needs of both [users and law enforcers], even with the Clipper and Capstone chip sets." 8<---------- End of Article ------------- In a small, corner-page, footnote box on the same page -- "Keyed up In a statement filed with the Computer System and Privacy Advisory Board, Citicorp raised the following concerns about Clipper: o The private sector was not adequately consulted. o The algorithm used in Clipper/Capstone is not compatible with other commonly used encryption methods and will only cause costly disruptions for businesses. o The algorithm -- which is to be secret but will be examined by a handful of government-chosen experts -- "will undergo inadequate scrutiny and hurried review." o The databases and access systems associated with Clipper may be flawed and insecure." Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From tcmay at netcom.com Mon Jun 7 18:51:55 1993 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 7 Jun 93 18:51:55 PDT Subject: ALERT: PGP removed from soda archive site In-Reply-To: Message-ID: <9306080152.AA06391@netcom3.netcom.com> Al Billings wrote: > On Mon, 7 Jun 1993, Eric Hughes wrote: > > > The ftp site at soda will no longer be able to distribute PGP, I'm > > afraid. It appears that CERT informed someone on campus that > > "pirated" software was available on soda. The word came down, and the > > directory has been chown'd root and has had permissions removed. > > What does CERT stand for again? Computer Emergency Response Team, set up in the wake of the Morris worm in 1988. They meet to discuss security threats. BTW, I just downloaded MacPGP from soda and saw no problems. I didn't try ordinary PGP, as I assumed the circumstance Eric mentioned had changed and PGP was once again available. -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 hughes at soda.berkeley.edu Mon Jun 7 19:00:03 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 7 Jun 93 19:00:03 PDT Subject: ALERT: PGP now back on soda Message-ID: <9306080156.AA03431@soda.berkeley.edu> You can stop spreading the word now. PGP is back on soda. Remember, it is my analysis that soda is still able to distribute PGP because we keep a low profile. Please keep it that way. You can find pgp with archie, so I don't feel the need to advertise. Lots of stuff happened today after I posted my initial announcement that PGP had gone offline. Because of the intervention of Eric Hollander with the folks who are in charge of the machine, reasonableness has prevailed. What happened in a nutshell was the following. Person A, a fascist asshole by all accounts, simply turned off the PGP directory without telling me. I started getting questions by email from folks trying to get PGP. Person A's argument was that PGP was illegal, therefore soda should not distribute it. Eric Hollander, after some initial rounds, played trump and observed that the machine had been recompiled without the user limit that had been part of the OS license agreement, and recommended that soda be shut down immediately because the kernel that soda was running was contrary to the license agreement. Very quickly the president of the organization which runs soda intervened and everything was OK. What is still troubling to me is the nastygram that came down from CERT. We don't know how they were informed, nor what their policy is on this. I'll have another message on that angle later. Eric From ld231782 at longs.lance.colostate.edu Mon Jun 7 19:22:27 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Mon, 7 Jun 93 19:22:27 PDT Subject: more ominous shudders from the bowels of NSA In-Reply-To: <6PXs5B2w165w@sytex.com> Message-ID: <9306080222.AA03981@longs.lance.colostate.edu> [ComputerWorld] >"We tried to come up with a technique that would not require >legislation," said Clint Brooks, advisor to the director of the >National Security Agency, which developed and now strongly >supports the key-escrow approach. Another ominous, foreboding quote. >Federal officials responsible for shaping information security >policy said last week that legislation mandating use of the >government's recently proposed encryption technology -- and >banning the use of older but popular techniques -- is neither >wise nor legal. This article, nor any other alluding to `bans on cryptographic methods', is not sufficiently disturbing or alarmist. An such law would be blatantly, egregiously, grotesquely unconstitutional under protections of free speech. All hell would break lose if any such attempt reared its hideously monstrous face--imagine the Clipper `flap' multiplied by a gigabyte. Please, regarding cryptography, don't say that `the genie is out of the bottle' or `the laws would be unenforceable' -- these are tantamount to saying, `go ahead, we DARE you to try!' I fear more and more the reply will soon be, `try THIS!' From fnerd at smds.com Mon Jun 7 19:43:29 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Mon, 7 Jun 93 19:43:29 PDT Subject: ALERT / My email address is... Message-ID: <9306080240.AA23825@smds.com> Hi, folks. Just in case at any point in the near or far future, cypherpunks has any extended mail problems, and anyone wants to get in touch with me as a person who was on the cypherpunks list, feel free to send to fnerd at smds.com or ...uunet!smds.com!fnerd I know there are hacks to find out who the subscribers are, (or are they plugged?) but I'd just like to publicly say that it's okay to take down my address, whoever you are. What's yours? I think publishing the raw list might be construed as impolite and disrespectful of privacy, but a compilation of willing addressees might be nice. It would be interesting to see how close we could reconstruct the list by skimming private archives and communicating with acquaintances. It would be interesting to have list software that worked the way those exponential-spreading, redundant, church-closing- because-of-snow phone call networks work (i.e., Usenet with even more emphasis on decentralization and redundancy). Also, a virtual archive server on the same model would be cool. -fnerd quote me From honey at citi.umich.edu Mon Jun 7 21:16:19 1993 From: honey at citi.umich.edu (peter honeyman) Date: Mon, 7 Jun 93 21:16:19 PDT Subject: ALERT / My email address is... In-Reply-To: <9306080240.AA23825@smds.com> Message-ID: <9306080416.AA29026@toad.com> > I know there are hacks to find out who the subscribers are, > (or are they plugged?) i just checked. they are not. peter From mdiehl at triton.unm.edu Mon Jun 7 21:18:29 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Mon, 7 Jun 93 21:18:29 PDT Subject: ALERT / My email address is... In-Reply-To: <9306080240.AA23825@smds.com> Message-ID: <9306080418.AA07574@triton.unm.edu> According to FutureNerd Steve Witham: > > Hi, folks. > > Just in case at any point in the near or far future, > cypherpunks has any extended mail problems, > and anyone wants to get in touch with me > as a person who was on the cypherpunks list, > feel free to send to > fnerd at smds.com > or ...uunet!smds.com!fnerd And I'm mdiehl at triton.unm.edu. I might suggest that we try to create an encrypted cypherpunks list? Comments? > I know there are hacks to find out who the subscribers are, > (or are they plugged?) > but I'd just like to publicly say that it's okay to > take down my address, whoever you are. What's yours? > > I think publishing the raw list might be construed as > impolite and disrespectful of privacy, but a compilation > of willing addressees might be nice. Agreed. > It would be interesting to have list software that worked > the way those exponential-spreading, redundant, church-closing- > because-of-snow phone call networks work (i.e., Usenet with > even more emphasis on decentralization and redundancy). Also, > a virtual archive server on the same model would be cool. We could set up aliases and distribute a common secret key for the list.... > > -fnerd > quote me > "Your quoted." +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From rarachel at ishara.poly.edu Mon Jun 7 21:31:59 1993 From: rarachel at ishara.poly.edu (A1 ray arachelian (library)) Date: Mon, 7 Jun 93 21:31:59 PDT Subject: rot-13 on echomac Message-ID: <9306080527.AA23908@ishara.poly.edu> Forwarded message: From pozar at kumr.lns.com Mon Jun 7 21:49:11 1993 From: pozar at kumr.lns.com (Tim Pozar) Date: Mon, 7 Jun 93 21:49:11 PDT Subject: rot-13 on echomac In-Reply-To: <9306080527.AA23908@ishara.poly.edu> Message-ID: > Thank you for your letter of support, I'm now keeping a folder > of all the ROT-13 related messagess off this echo and when it > dies down, I'll send the whole thing to the moderator of EchoMac. > [...] > His address again: (you needn't mail him unless you want to, > as I'll forward all messages about this to him anyway) > > Steve.Ebener at f42.n152.z1.ieee.org ^^^^^^^^ Uh, try... Steve.Ebener at f42.n152.z1.fidonet.org > My mail adress: rarachel at ishara.poly.edu Tim -- Internet: pozar at kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA POTS: +1 415 788 2022 Radio: KC6GNJ / KAE6247 From Cypherpunk.Echo at f28.n125.z1.FIDONET.ORG Mon Jun 7 21:56:41 1993 From: Cypherpunk.Echo at f28.n125.z1.FIDONET.ORG (Cypherpunk Echo) Date: Mon, 7 Jun 93 21:56:41 PDT Subject: Mailing list request Message-ID: <219.2C126002@shelter.FIDONET.ORG> SUBSCRIBE CYPHERPUNKS CYPHERPUNK ECHO ----- Hi! I don't know if this is automated at your end, or if I should just be emailing a request, so I'm doing both - I'd like to subscribe to the cypherpunk mailing list under the name cypherpunk echo. I'll be porting the list to an area on my BBS. Thanks for any help, if any is required. Peter Wadsworth - Sysop, Coconino County BBS, 415-861-8290 -- Cypherpunk Echo - via FidoNet node 1:125/1 UUCP: ...!uunet!kumr!shelter!28!Cypherpunk.Echo INTERNET: Cypherpunk.Echo at f28.n125.z1.FIDONET.ORG From locklin at titan.ucs.umass.edu Mon Jun 7 23:01:59 1993 From: locklin at titan.ucs.umass.edu (Lupo the Butcher) Date: Mon, 7 Jun 93 23:01:59 PDT Subject: subscribe Message-ID: <9306080601.AA20790@titan.ucs.umass.edu> let me check it out for now... From binski at u.washington.edu Mon Jun 7 23:27:45 1993 From: binski at u.washington.edu (binski at u.washington.edu) Date: Mon, 7 Jun 93 23:27:45 PDT Subject: AT&T Encrypting Phone Ad in WS Journal Message-ID: FYI The Wall Street Journal, 7 June 93, page B7, has an AT&T ad for an encrypting communications box called "Surity Telephone Device". It plugs between a regular phone and the phone jack. Anybody know what's inside? Is this new? Also, page B6 has a so-so article on digital signatures. bf From MAILER-DAEMON Mon Jun 7 22:13:11 1993 From: MAILER-DAEMON (Mail Delivery Subsystem) Date: Tue, 8 Jun 93 01:13:11 EDT Subject: Returned mail: Host unknown Message-ID: <9306080513.AA23807@ishara.poly.edu> ----- Transcript of session follows ----- 550 jsday at THUNDER... Host unknown: Can't assign requested address ----- Unsent message follows ----- Received: by ishara.poly.edu (5.59a/25-eef) id AA23805; Tue, 8 Jun 93 01:13:11 EDT From: A1 ray arachelian (library) Full-Name: A1 ray arachelian (library) Message-Id: <9306080513.AA23805 at ishara.poly.edu> Subject: Re: ROT-13 on fido To: jsday at THUNDER Date: Tue, 8 Jun 93 1:13:10 EDT In-Reply-To: <9306070029.AA09898 at thunder.LakeheadU.Ca>; from "Jer!" at Jun 6, 93 8:29 pm Thank you for your letter of support, I'm now keeping a folder of all the ROT-13 related messagess off this echo and when it dies down, I'll send the whole thing to the moderator of EchoMac. Don't worry about the reformatting of your letter, I'll take care of it before sending the message. (And yes, I will forward >ALL< letters about the rot-13 issue to him, even those who disagree with me. :-) I do believe in freedom of speech, even when it doesn't match my point of view.) His address again: (you needn't mail him unless you want to, as I'll forward all messages about this to him anyway) Steve.Ebener at f42.n152.z1.ieee.org My mail adress: rarachel at ishara.poly.edu From clark at metal.psu.edu Tue Jun 8 02:46:26 1993 From: clark at metal.psu.edu (Clark Reynard) Date: Tue, 8 Jun 93 02:46:26 PDT Subject: CERT Message-ID: <9306081023.AA04054@metal.psu.edu> I was disgusted and horrified to read that PGP had been removed from soda, and gratified to find that it had been returned. However, your experiences with CERT are not unique. As could be expected of any agency directly funded by Air Force Intelligence, CERT is a genuinely ugly organization which needs to be stamped out. Frankly, it's a menace to society. Examine their acronym. Computer Emergency Response Team. What a fucking joke! Excepting the Morris Worm, can you name a SINGLE Computer Emergency which CERT has halted? It is simply an organization to keep the crypto-fascists wired into the net. I will assume, as you did not say otherwise, that you do not know the name of the CERT person who reported you, for whatever ridiculous reason. This is standard practice for CERT; it's customary for them to hide behind a shield of anonymity for the purpose of attacking people. My life was severely disturbed three years ago due to similar anonymous tips from CERT, and I have yet to discover the identity of the CERT person who tipped off the authorities to me. CERT is yet another agency which is freed of Constitutional restraints for a vague and undefined 'public good.' If distributing PGP, legal in the entire Free World except for the US, is a "Computer Emergency," then I'm a fucking Republican. Combat this so-called Computer Emergency Response Team wherever you see the tendrils of its evil influence. ---- Robert W. F. Clark "Be sand, not oil, in the machinery rclark at nyx.cs.du.edu of the world." Gunter Eich clark at metal.psu.edu From whitaker at eternity.demon.co.uk Tue Jun 8 03:25:04 1993 From: whitaker at eternity.demon.co.uk (Russell Earl Whitaker) Date: Tue, 8 Jun 93 03:25:04 PDT Subject: Forwarded article. Message-ID: <6471@eternity.demon.co.uk> This article was forwarded to you by whitaker at eternity.demon.co.uk (Russell Earl Whitaker): --------------------------------- cut here ----------------------------- Newsgroups: uk.events Path: eternity.demon.co.uk!demon!zaphod.axion.bt.co.uk!uknet!nessie! comms.ee.man!colin From: colin at comms.ee.man.ac.uk (Colin Boyd) Subject: Cryptography Course 7th-8th July Message-ID: <1993Jun7.103708.6901 at nessie.mcc.ac.uk> Sender: news at nessie.mcc.ac.uk (Usenet News System) Organization: Comms Research Group, EE Dept, Manchester University, UK. Distribution: uk Date: Mon, 7 Jun 1993 10:37:08 GMT Lines: 45 *Cryptography : Theory and Practice* A Two Day Course at the University of Manchester 7th-8th July 1993 Electronic communications are being used more and more in all areas of business practice. The convenience and efficiency of using new technology brings with it new security risks to the confidentiality and integrity of important commercial data. Many of these threats can only be practically countered by the use of cryptography. This short course will give a basic grounding in the capabilities, and also the limitations, of modern cryptography. The course is intended for engineers and managers who require familiarity with modern cryptographic theory and practice. Lectures cover background theory, current algorithms, and their application in the provision of security services. Supporting practical sessions provide "hands-on" experience using software implementations of modern cryptographic algorithms. Syllabus Topics: Cryptographic Basics Cryptographic Theory Symmetric Ciphers Authentication Public Key Cryptography Digital Signatures Cryptographic Protocols The cost of the course is 225 pounds per person. This fee includes full course documentation and tea/coffee and lunch each day. Overnight accommodation, at extra cost, can be arranged on request. Please reply by email for further details and a booking form or write to: Dr Colin Boyd Communications Research Group, Electrical Engineering Labs., University of Manchester, Manchester M13 9PL -- Colin Boyd (colin at comms.ee.man.ac.uk) Tel: +44 61 275 4562 (Direct line) Fax: +44 61 275 4512 --------------------------------- cut here ----------------------------- From tcmay at netcom.com Tue Jun 8 03:34:30 1993 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 8 Jun 93 03:34:30 PDT Subject: Getting on CERT's "Most Dangerous" List In-Reply-To: <9306081023.AA04054@metal.psu.edu> Message-ID: <9306081033.AA14809@netcom3.netcom.com> Clark Reynard writes about CERT: > I will assume, as you did not say otherwise, that you do not know > the name of the CERT person who reported you, for whatever > ridiculous reason. This is standard practice for CERT; it's > customary for them to hide behind a shield of anonymity > for the purpose of attacking people. > > My life was severely disturbed three years ago due to similar > anonymous tips from CERT, and I have yet to discover the identity > of the CERT person who tipped off the authorities to me. CERT > is yet another agency which is freed of Constitutional restraints > for a vague and undefined 'public good.' My life wasn't affected in a serious way by CERT, so far as I know, but I do have a funny story to tell. At a Bay Area party for hacker types in December, 1988, I was talking to a guy with longstanding computer security connections. He looked at me strangely and said something like "Well, Tim, your name just came up in Washington on a list of the most dangerous hackers in the country." I laughed it off and asked him why--after all, I'm not considered to much of a programmer by anyone _I_ know. He wouldn't elaborate, just looked at me strangely. (It was a funny story because I could other people at parties that I was on a "Most Wanted" kind of list, and yet I knew they couldn't actually pin anything on me as I literally hadn't done anything except draw some obvious conclusions about the implications of modern crypto techniques, such as Chaum's anonymous systems, and had written and talked about it.) This fellow had been in at the founding of CERT, and was at the first D.C. meeting in early December (shortly after the Morris worm). As he'd also been at hackers gatherings where I had talked about digital cash and "crypto anarchy" (my "Manifesto" was written earlier in 1988 and passed out to a few people), I had some suspicions that it was *he* who had volunteered my name for this list they were compiling. An obvious overstatement of my danger, and I never heard anything more about it. But I've always thought about this, and the other lists of subversives they must be generating. No, I won't give his name, as I can't prove anything and to speculate would be "narcish" McCarthyism. Just keep in mind that even hackers may have their own agendas and their own consulting arrangements with crypto and security groups, both private and government-run. -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 pfarrell at cs.gmu.edu Tue Jun 8 05:55:16 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Tue, 8 Jun 93 05:55:16 PDT Subject: Tuesday's Washington Post Message-ID: <32150.pfarrell@cs.gmu.edu> In Tuesday June 8 Final edition of the Washington Post, Page A12 US Data Decoding Plan Delayed Business and Legal Objections Reviewed by John Schwartz The Federal initiative to establish a new standard for scrambling electronic communications will be slowed until its ramifications can be more fully studied, the official in charge of implementing the program said yesterday. The government's proposed "Clipper Chip" plan, announced on April 16, would create a new national standard for data encryption that would make possible the deccoding and wiretaps by law enforcement and national security agencies. The plan has met with criticism from high-technology industries that argue that the new requirements ould be expensive and hurt the competiveness of their products. Civil liberties advocates see it as a threat to privacy. Raymond Kammer, acting director of the National Institite of Standards and Technology (NIST) - which developed the Clipper proposal with the National Security Agency and is charged with implementing it within the government- delivered the news to a Washington conference attended largly by critics of the Clipper plan. In an interview afterward, Kammer said that the entiore Clipper plan was still being discussed, and if the review revialed unresolvable problems, "maybe we won't continue in the direction we started out." Criticism was sharp at the cryptography and privacy conference sponsored by the Washington office of the Computer Professionals for Social Responsibility, a public interest group concerned with high-tech issues. One panelist compared Kammer's appearance at the conference to "having a target painted on your chest." Kammer said: "We're not going to close off the process while there's still productive conversation. And its' obvious from the meeting today that ther's still plenty of productive conversation." Pressure has been building on NIST since the WShite House announcement in April. Critics of the plan have flooded the administration with lengthly lists of questions about the new plan, voicing concerns that the proposal might make American products more expensicve, less secure, and less competitive overseas while not hindering criminals. Last Friday, NIST's advirosy panel on privacy issues concluded two days of heated hearings concerning the Clipper proposal with a resolution expressing "serious concerns" sparked by the administrations's proposal. "Things are going too fast." said William Ware, chairman of the Computer System Security and Privacy Advisory Board, a body created under the Computer Security Act of 1987. The NIST panel reported that the government had not conviningly explained the nature of law enforcement problems that would be solved by the Clipper plan, and cited damage the proposal was likely to do to the American software industry. Later that day, White House officials overseeing the Clipper plan met with representatives of industry and civil liberties groups, including the high-tech policy group Electronic Frontier Foundation as well as the American Civil Liberties Union. Administration officials said that the Clipper review would be extended into the fall and that the government would not move beyond its initial plans to buy about 10,000 Clipper-equiped telephones until the review was completed. John Podesta, assistance to the President, said that meeting was part of a continuing dialog with the private sector. "It's time to start ot get answers insteead of the endless quest for questions, Podesta said." ================== Any typos were added in transcription. Pat Farrell Grad Student pfarrell at cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From honey at citi.umich.edu Tue Jun 8 06:13:17 1993 From: honey at citi.umich.edu (peter honeyman) Date: Tue, 8 Jun 93 06:13:17 PDT Subject: CERT In-Reply-To: <9306081023.AA04054@metal.psu.edu> Message-ID: <9306081313.AA12942@toad.com> > Excepting > the Morris Worm, can you name a SINGLE Computer Emergency which > CERT has halted? cert was organized in reaction to the morris worm, and was not involved in its prophylaxis. i am disappointed to hear these stories about cert, but encourage others with tales to tell to step forward. this is a real eye-opener. peter From hughes at soda.berkeley.edu Tue Jun 8 08:18:49 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 8 Jun 93 08:18:49 PDT Subject: a great revelation from the bowels of NSA In-Reply-To: <9306080222.AA03981@longs.lance.colostate.edu> Message-ID: <9306081515.AA05070@soda.berkeley.edu> >>"We tried to come up with a technique that would not require >>legislation," said Clint Brooks, advisor to the director of the >>National Security Agency, >Another ominous, foreboding quote. I think this neither ominous nor foreboding. This statement was apparent within a week or so of the original announcement. The only thing new about it is that it confirms what I've thought for over a month: that the executive branch is trying to do an end run around the legislature. I was quite happy to see this, since now we can argue from this position not on the basis of surmise, but of quotation. This single quotation will be enormously useful in getting the legislature to take specific and bill-oriented action about the wiretap chips. In the checks and balance system, the legislature makes laws; the executive makes them happen. The executive is not supposed to go charging off and making de facto legislation. I would recommend that this quotation be spread far and wide. Put it in .signature blocks. Call for a return of the checks and balances system of government. Eric From hughes at soda.berkeley.edu Tue Jun 8 08:27:34 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 8 Jun 93 08:27:34 PDT Subject: CryptoStacker In-Reply-To: <93Jun7.005219pdt.13914@well.sf.ca.us> Message-ID: <9306081523.AA05311@soda.berkeley.edu> I've made available the following files on the archive site: cphant.zip driver.zip fdcbio.zip rdcf.zip in the directory pub/cypherpunks/applications/crypto.msdos.disk. Eric From hughes at soda.berkeley.edu Tue Jun 8 08:36:25 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 8 Jun 93 08:36:25 PDT Subject: ADMIN: upload ettiquette to the cypherpunks ftp site Message-ID: <9306081532.AA05641@soda.berkeley.edu> There are a few matters of upload ettiquette for the ftp site. 1. Upload stuff for cypherpunks to pub/cypherpunks/incoming/ and not to the general pub/incoming/ directory. I'll be able to more adequately handle files there. (I can't erase in the other directory.) 2. Whenever you upload something, also upload a short description of what it is you are uploading. I've got a few mystery files there that are on the low priority end of things, since I don't know what they are and I've got plenty of other stuff to do with the archive. 3. Send me mail telling me what you've put up. I don't have any automated software to look at the incoming directory, and so I may not notice. My address is below. 4. Don't bother uploading programs that don't have source code. The mission of the archive site is education. Software distribution is not a purpose, and software without source does not satisfy the educational criterion. Thanks. Eric Hughes cypherpunks ftp site maintainer hughes at soda.berkeley.edu From julf at penet.FI Tue Jun 8 08:38:39 1993 From: julf at penet.FI (Johan Helsingius) Date: Tue, 8 Jun 93 08:38:39 PDT Subject: CERT In-Reply-To: <9306081313.AA12942@toad.com> Message-ID: <9306081800.aa08835@penet.penet.FI> > i am disappointed to hear these stories about cert, but encourage others > with tales to tell to step forward. this is a real eye-opener. I just had to deal with a minor crisis caused by CERT. They contacted the domain-admin for the *.fi domain, saying they had been informed that the anonymous ftp archive at anon.penet.fi was being used to distribute illegal copies of software. They did *not* contact me directly, nor my service provider. The last time anon.penet.fi was shut down was exactly because of somebody contacting the domain-admin, who happens to be a person working for a competitor to my service provider. Fortunately I could tell them that anon.penet.fi didn't even run ftp at all, easily verifiable by trying to ftp from anon.penet.fi. They did apologize profusely, but somehow that doesn't quite... julf From smb at research.att.com Tue Jun 8 08:45:21 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 8 Jun 93 08:45:21 PDT Subject: a great revelation from the bowels of NSA Message-ID: <9306081545.AA18250@toad.com> >>"We tried to come up with a technique that would not require >>legislation," said Clint Brooks, advisor to the director of the >>National Security Agency, >Another ominous, foreboding quote. I think this neither ominous nor foreboding. This statement was apparent within a week or so of the original announcement. The only thing new about it is that it confirms what I've thought for over a month: that the executive branch is trying to do an end run around the legislature. Well, it could be innocent; it just takes longer to get legislation passed. Yeah, that's it... Of course, NSA does have another option -- they can disclose how cheaply they can crack DES. (That they can crack it I don't doubt; my only question is what it costs them per solution, including amortization of capital costs.) From eichin at cygnus.com Tue Jun 8 08:47:19 1993 From: eichin at cygnus.com (Mark Eichin) Date: Tue, 8 Jun 93 08:47:19 PDT Subject: Getting on CERT's "Most Dangerous" List In-Reply-To: <9306081033.AA14809@netcom3.netcom.com> Message-ID: <9306081547.AA16611@cygnus.com> Umm, I thought CERT was a purely commercial organization, rather than a government one... did I miss something? _Mark_ From composer at Beyond.Dreams.ORG Tue Jun 8 09:03:35 1993 From: composer at Beyond.Dreams.ORG (Jeff Kellem) Date: Tue, 8 Jun 93 09:03:35 PDT Subject: rot-13 on echomac In-Reply-To: Message-ID: <9306081603.AA05678@Beyond.Dreams.ORG> On the cypherpunks mailing list, Tim Pozar wrote.... > Ray Arachelian wrote... > > Steve.Ebener at f42.n152.z1.ieee.org > ^^^^^^^^ > Uh, try... > > Steve.Ebener at f42.n152.z1.fidonet.org Not knowing this person, I could be wrong. But, the first address should work. There are a bunch of fidonet addresses behind ieee.org. Actually, both of those addresses also go through the same mail forwarding site. [ I assume you were correcting it because it looked like similar to a fidonet style address? ] FYI... -jeff Jeff Kellem Internet: composer at Beyond.Dreams.ORG From honey at citi.umich.edu Tue Jun 8 09:06:25 1993 From: honey at citi.umich.edu (Peter Honeyman) Date: Tue, 8 Jun 93 09:06:25 PDT Subject: Getting on CERT's "Most Dangerous" List Message-ID: <9306081606.AA18740@toad.com> i thought cert was part of sei (software engineering institute), a pentagon entity run by carnegie-mellon. peter From hughes at soda.berkeley.edu Tue Jun 8 09:24:11 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 8 Jun 93 09:24:11 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306081620.AA07331@soda.berkeley.edu> Here, in its almost full glory, is the letter that CERT sent to the admin at berkeley. I've removed the addressee, since there's no need to involve that person. I have not, however, removed the name of the sender. Don't you just love that phrase "illegal trading of commercial software"? Eric ----------------------------------------------------------------------------- To: @ucbvax.Berkeley.EDU Subject: Possible abuse of anonymous FTP area on berkeley.edu host(s) Organization: CERT Coordination Center From: cert at cert.org Date: Wed, 02 Jun 93 16:56:55 -0400 Hello , I am a member of the CERT Coordination Center. CERT provides technical assistance in response to computer security incidents. Would you please forward this report to the appropriate system administrator(s)? We have been passed information that indicates that the anonymous FTP archive on the following host(s) may be in use by intruders for illegal trading of commercial software: >>>>>>> soda.berkeley.edu /pub/cypherpunks We have not confirmed this information, nor have we identified that the anonymous FTP configuration on the above-listed host(s) is open for abuse. While anonymous FTP areas can be put to good use, the intruder community makes use of them to illegally trade commercial software and other information. Intruders often create "hidden" files or directories in order to conceal their activity. On UNIX hosts, directory and file names of a form such as "..." (dot dot dot), ".. " (dot dot space space), or "..^G" (dot dot control-G) may be used. In some cases, intruders have abused anonymous FTP areas to such an extent that file storage has been exhausted and a system crash or denial of service has resulted. We would encourage you to check your anonymous FTP archive for any such "hidden" files or directories by using the "ls -laR" command. We would appreciate feedback on the name of any software packages found at your site and the number of accesses to that software, if that information is available from your logs. Please e-mail a summary of this information to "cert at cert.org" before deleting any such files and directories from your archive. For your information, I have appended some suggestions for anonymous FTP configuration. Thanks for checking into this incident, and please don't hesitate to contact us if we can be of any assistance. Katherine T. Fithen Technical Coordinator CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Internet e-mail: cert at cert.org (monitored during business hours) Telephone: 412-268-7090 (answers 24 hours a day) From hughes at soda.berkeley.edu Tue Jun 8 09:33:10 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 8 Jun 93 09:33:10 PDT Subject: Getting on CERT's "Most Dangerous" List In-Reply-To: <9306081606.AA18740@toad.com> Message-ID: <9306081629.AA07616@soda.berkeley.edu> >i thought cert was part of sei (software engineering institute), >a pentagon entity run by carnegie-mellon. I would propose that we get the FBI to fund CERT's law enforcement mission, rather that the DoD. Eric From pozar at kumr.lns.com Tue Jun 8 09:36:16 1993 From: pozar at kumr.lns.com (Tim Pozar) Date: Tue, 8 Jun 93 09:36:16 PDT Subject: rot-13 on echomac In-Reply-To: <9306081603.AA05678@Beyond.Dreams.ORG> Message-ID: Jeff Kellem wrote: > On the cypherpunks mailing list, Tim Pozar wrote.... > > Ray Arachelian wrote... > > > Steve.Ebener at f42.n152.z1.ieee.org > > ^^^^^^^^ > > Uh, try... > > > > Steve.Ebener at f42.n152.z1.fidonet.org > > Not knowing this person, I could be wrong. But, the first address should > work. There are a bunch of fidonet addresses behind ieee.org. Actually, > both of those addresses also go through the same mail forwarding site. > [ I assume you were correcting it because it looked like similar to a > fidonet style address? ] I mention this 'cause I am the Technical Contact for fidonet.org. The fidonet.org domain is served out of ieee.org, and with some of the gating that Burt is doing, the fidonet.org domain is not being appended to the fidonet address and ieeee.org is. The ieee.org domain is not something I would guarentee as working all the time or permenate. You would have less potenial problems if you used fidonet.org. Tim Pozar -- Internet: pozar at kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA POTS: +1 415 788 2022 Radio: KC6GNJ / KAE6247 From avalon at coombs.anu.edu.au Tue Jun 8 09:47:28 1993 From: avalon at coombs.anu.edu.au (Darren Reed) Date: Tue, 8 Jun 93 09:47:28 PDT Subject: CERT In-Reply-To: <9306081800.aa08835@penet.penet.FI> Message-ID: <9306081647.AA19872@toad.com> > > > > i am disappointed to hear these stories about cert, but encourage others > > with tales to tell to step forward. this is a real eye-opener. > > I just had to deal with a minor crisis caused by CERT. They contacted the > domain-admin for the *.fi domain, saying they had been informed that the > anonymous ftp archive at anon.penet.fi was being used to distribute > illegal copies of software. They did *not* contact me directly, nor my > service provider. [...] > Fortunately I could tell them that anon.penet.fi didn't even run ftp at > all, easily verifiable by trying to ftp from anon.penet.fi. They did > apologize profusely, but somehow that doesn't quite... Disturbing pattern that CERT contact people about hosts which perform actions contrary to the wishes of some MIBS. Or is that just paranoia ? I doubt the NSA/FBI/any_other_government_agencies would be crying if either anon.penet.fi or soda were taken off the net... From marc at GZA.COM Tue Jun 8 10:05:32 1993 From: marc at GZA.COM (Marc Horowitz) Date: Tue, 8 Jun 93 10:05:32 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306081620.AA07331@soda.berkeley.edu> Message-ID: <9306081705.AA13681@dun-dun-noodles.aktis.com> This thread is the first set of negative comments I've ever heard about CERT. >>> From: Clark Reynard >> Excepting the Morris Worm, can you name a SINGLE Computer Emergency >> which CERT has halted? It is simply an organization to keep the >> crypto-fascists wired into the net. My experience with them in the past has been as a clearinghouse for users to report security-related bugs to vendors, and for vendors to provide fixed back to users. They've done an admirable job at this; the major complaint is that they are too slow. They also help distribute tools like COPS to validate unix workstation security. They are a proactive organization, not a reactive organization, so it's meaningless to ask what "Computer Emergencies" CERT has "halted". I think that calling them "crypto-fascists" is at best an unsupported smear, and at worst slanderous. >>> From: peter honeyman >> i am disappointed to hear these stories about cert, but encourage others >> with tales to tell to step forward. this is a real eye-opener. I agree with Peter. If CERT is beginning to overstep its bounds perhaps someone should make a calm, rational complaint. >> > From: eichin at cygnus.com (Mark Eichin) >> Umm, I thought CERT was a purely commercial organization, rather than >> a government one... did I miss something? from the cert_faq, available as cert.org:/pub/cert_faq: CERT is sponsored by the Advanced Research Projects Agency (ARPA). The Software Engineering Institute is sponsored by the U.S. Department of Defense. Well, it's not a Government agency, but it's money certainly seems to come from there. Anyway, what I see here is an organization, founded for good reasons, which is getting a little out of hand. Rather than going ballistic, slandering CERT, and claiming they've never done anything of value, I think we should approach this as an internal problem at CERT. Currently, there is a big problem on the Internet with randoms using anonymous dropoff points to trade commercial software illegally. CERT accepts reports of these problems. In many cases, I imagine, they are accurate, and the host admins are glad to have the CERT tell them about it. What we have here, I think, is a few malicious individuals or groups, who are using the CERT as a weapon against hapless ftp and mail sites. This problem could be easily alleviated by CERT checking up on such reports before passing them on to host or domain admins. I think Julf's example is a good one. A site not running ftp is not trading in illegal software via ftp. Period. Idea for Eric: Send a letter to the RISKS Digest and , documenting the RISKS of a "computer security" organization becoming overzealous, and not researching problems which have been reported before sending reports to host and/or domain administrators. Include the letter you forwarded to us, and mention Julf's problem. Perhaps others will even mention similar problems. I think this will have the desired effect. Marc From hughes at soda.berkeley.edu Tue Jun 8 10:09:17 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 8 Jun 93 10:09:17 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306081650.AA08632@soda.berkeley.edu> Message-ID: <9306081704.AA09252@soda.berkeley.edu> >Any public spooling directory is fair game for their antics. [...] >My guess is that your CERT problems have NOTHING to do with >PGP distribution. There is only one directory on the cypherpunks site that is writable, and that is the incoming directory and it's not readable. I still don't know what the real accusation is. CERT is straight out of a Kafka novel in this regard. Maybe it's PGP, maybe it isn't, but they don't seem to be offering that information. Eric From karn at qualcomm.com Tue Jun 8 10:38:37 1993 From: karn at qualcomm.com (Phil Karn) Date: Tue, 8 Jun 93 10:38:37 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306081738.AA02682@servo> This seems to imply pretty strongly that the issue is not PGP, it's the possible abuse of the cypherpunks upload area if it is world writeable. Having CERT go specifically after the distribution of PGP would be pretty amusing considering the several PGP keys I have on my keyring from CERT people. Phil From mimir at u.washington.edu Tue Jun 8 10:57:08 1993 From: mimir at u.washington.edu (Al Billings) Date: Tue, 8 Jun 93 10:57:08 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306081620.AA07331@soda.berkeley.edu> Message-ID: "Intruder Community?" Interesting jargon these CERT people have? What kind of power do they possess or do they expect admins to go to the trouble of sending them logs of their FTP sites out of the goodness of their hearts? Wassail, Al From kent_hastings at qmail2.aero.org Tue Jun 8 11:00:48 1993 From: kent_hastings at qmail2.aero.org (Kent Hastings) Date: Tue, 8 Jun 93 11:00:48 PDT Subject: Mail Gateway Message-ID: <199306081759.AA06261@aerospace.aero.org> Mail Gateway Is there a secure (and/or cheap) STMP or UUCP e-mail gateway program to rival Microsoft Mail 3.0 with Gateways. I hear MM3 with a gateway runs $4,000. Be nice if it notified recipients when new mail arrives. Kent - kent_hastings at qmail2.aero.org From julf at penet.FI Tue Jun 8 11:10:39 1993 From: julf at penet.FI (Johan Helsingius) Date: Tue, 8 Jun 93 11:10:39 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306081620.AA07331@soda.berkeley.edu> Message-ID: <9306082011.aa12598@penet.penet.FI> > Here, in its almost full glory, is the letter that CERT sent to the > admin at berkeley. It's exactly the same message that was sent to the .fi domain-admin with regards to anon.penet.fi Julf From smb at research.att.com Tue Jun 8 11:14:44 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 8 Jun 93 11:14:44 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306081814.AA22615@toad.com> Here, in its almost full glory, is the letter that CERT sent to the admin at berkeley. I've removed the addressee, since there's no need to involve that person. I have not, however, removed the name of the sender. Don't you just love that phrase "illegal trading of commercial software"? Based on what you sent out, I confess that I see nothing wrong with CERT's note. They're right -- anonymous ftp is abused that way. I've seen it happen on a fair number of sites -- folks upload packages for others to snarf. The pattern of some of the transactions I've seen suggests that folks are chatting anonymously via IRC or some such, and are using third-party machines as anonymous relay points. Other transaction patterns suggest the creation of sub rosa archives by folks who have no legitimate right to use the machine. Files distributed that way (and I'm speaking here of what I've seen personally, not just rumors from CERT or the net) include copyrighted PC software packages. Now -- there's a lot of room for disagreement about whether or not it's proper to charge for software, or whether or not algorithm patents are or should be valid. But I suspect that most people on the list would agree that if someone has written something that they don't want distributed that way -- as evidenced, for example, by a copyright notice -- their wishes should be respected. That's common courtesy, if nothing else. Similarly, if you want to distribute files, use your own machine. Don't abuse someone else's, when you know perfectly well that that's not a proper use of anonymous ftp. Again -- neither CERT nor I am talking about things like RSA software. That's a can of worms I'm not going to open in this forum. And they're probably not even talking about files that legitimate users are making available. They're talking about abuse of other folks' machines, almost always with neither the knowledge nor the consent of the system owner. And the outcome is predictable; I've seen a number of cases where anonymous ftp has been shut down, to the detriment of the entire community. --Steve Bellovin From space2 at stein.u.washington.edu Tue Jun 8 11:30:42 1993 From: space2 at stein.u.washington.edu (TJO) Date: Tue, 8 Jun 93 11:30:42 PDT Subject: CERT In-Reply-To: <9306081800.aa08835@penet.penet.FI> Message-ID: <9306081830.AA26885@stein.u.washington.edu> > > i am disappointed to hear these stories about cert, but encourage others > > with tales to tell to step forward. this is a real eye-opener. > > I just had to deal with a minor crisis caused by CERT. They contacted the > domain-admin for the *.fi domain, saying they had been informed that the > anonymous ftp archive at anon.penet.fi was being used to distribute > illegal copies of software. They did *not* contact me directly, nor my > service provider. How is it that Cert (which to my knowledge is an organization run by Carnegie-Mellon in Pittsburg,PA (USA)) should come to have any influence on a domain in finland? They are not to my knowledge a gov't organization although they may be funded by some.. hmm. Doesn't their name stand for computer EMERGENCY response taskforce or something like that? They should have no business bothering you unless you requested some kind of assistance from them, IMHO. The same goes for the berkeley site... I'd definitely be interested in hearing who they think they are working for and under whose authority they are becoming netpolice. From hughes at soda.berkeley.edu Tue Jun 8 12:30:12 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 8 Jun 93 12:30:12 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306081814.AA22615@toad.com> Message-ID: <9306081926.AA17119@soda.berkeley.edu> >Based on what you sent out, I confess that I see nothing wrong with >CERT's note. The issues that Steve raises are 1. use of ftp sites counter to the knowledge or desires of their owners a. for one time transmission b. for illicit archive 2. distribution of software contrary to the author's desires 3. abuse leading to shutdown of archives I do not wish to quarrel with these issues. The question is not one of the ethicality of these actions, but of the relationship that CERT should have to such actions. CERT's mission is computer security, not copyright enforcement. What the letter offers is hearsay that illegal activity is taking place on a particular machine in a particular place. Such a letter might properly be construed as slander, since there was no effort made to verify the accuracy of this information and the letter even says this itself! What CERT might properly do is first, verify that an ftp site is running. Julf's case where the ftp daemon was not even enabled is a particularly egregious case in point. Next they should verify that the permissions on the directories in question are set so that world read/write access is available. They could also do a tree search of the directories and look for suspiciously named directories. All these actions can be automated; there is little excuse for making not even the most cursory check. In any case, CERT's response should be limited to issues of computer security and not law enforcement. They might properly notify an archive owner that illegal activity has been known to take place on archives configured in such a way, but to spread hearsay is irresponsible. Unfounded allegations of illegal activiy are socially dangerous, especially when promulgated by a respected institution. In the fifties in the US in a similar context this was called "red-baiting". Now if CERT receives reports about the improper distribution of software and the archive site is properly set up, one might reasonably assume collusion on behalf of the maintainers of the archive. In this case direct investigation should take place by properly authorized law enforcement authorities. CERT is not so authorized to my knowledge, and as it is funded with military money it would be a bad policy to give it a law enforcement function. The FBI is responsible for copyright enforcement in this country, and they are the proper ones to do an investigation. Eric From kent_hastings at qmail2.aero.org Tue Jun 8 12:44:57 1993 From: kent_hastings at qmail2.aero.org (Kent Hastings) Date: Tue, 8 Jun 93 12:44:57 PDT Subject: Eudora Mail Gateway Message-ID: <199306081943.AA09446@aerospace.aero.org> Eudora Mail Gateway#000# Thanks to FutureNerd for the Mail Gateway suggestion (via private e-mail). It is just the thing for which my associate was looking. (Never use a preposition to end a sentence with.) More questions will be asked of FutureNerd re Eudora privately as we try to get it running, but until then, here is a public thanks for your help. Kent - kent_hastings at qmail2.aero.org. #000# From honey at citi.umich.edu Tue Jun 8 12:52:01 1993 From: honey at citi.umich.edu (peter honeyman) Date: Tue, 8 Jun 93 12:52:01 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306081814.AA22615@toad.com> Message-ID: <9306081951.AA25120@toad.com> steve, like eric, i feel that cert is overstepping their charter by engaging in law enforcement activities. what's your feeling on the matter? don't you agree that this could jeopardize their ability to do the work they are chartered to do? peter From smb at research.att.com Tue Jun 8 13:22:05 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 8 Jun 93 13:22:05 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306082022.AA25894@toad.com> steve, like eric, i feel that cert is overstepping their charter by engaging in law enforcement activities. what's your feeling on the matter? don't you agree that this could jeopardize their ability to do the work they are chartered to do? Law enforcement? It's law enforcement if they do more than notify the owner of the site. Most such sites welcome the notifications *if* (and it's a big ``if'') their machines are being abused by outsiders. If CERT is going out and looking for pirated software, or if they try to take any action to enforce their notes -- then, I do agree with both of you; such actions are beyond their charter. (Though one can argue that clandestine distribution of malware would fall be an exception. I specify ``clandestine'' because one could entertain a reasonable suspicion that the motives of such distributors was not purely educational...) If you asked CERT to justify such notes, they'd probably quote the following text from their press release on ftp.cert.org: It will also serve as a focal point for the research community for identification and repair of security vulnerabilities, informal assessment of existing systems in the research community, improvement to emergency response capability, and user security awareness. ``User security awareness'' sounds about right. Look -- CERT did not demand that the ftp area be shut down, they did not threaten to cut the machine off from the Internet, they didn't (as far as I know) turn the note over to the FBI or the Secret Service, and they didn't mention PGP or ``dirty GIFs''. They simply *informed* the administrator, in a polite way, of information that that administrator probably wants to hear. (I've had occasion to notify various system administrators of the same sort of thing. They were all grateful for the report.) The overly-hasty response came from Eric's end. What the administrator's response should be if RSADSI sent a note about PGP is another matter. This is CERT, and they're talking about pirated software. --Steve Bellovin Disclaimer: I'm on friendly terms with CERT, and with a lot of the folks who work there. And -- as anyone who has read my papers knows -- I've sent in my share of incident and vulnerability reports. From jet at nas.nasa.gov Tue Jun 8 13:31:33 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Tue, 8 Jun 93 13:31:33 PDT Subject: CERT In-Reply-To: <9306081830.AA26885@stein.u.washington.edu> Message-ID: <9306082031.AA12159@boxer.nas.nasa.gov> >computer EMERGENCY response taskforce or something like that? They should have >no business bothering you unless you requested some kind of assistance from >them, IMHO. I personally like being contacted by an organization trying to tell me that someone might be misusing my computing resources. [in no way speaking for NASA] -- J. Eric Townsend jet at nas.nasa.gov 415.604.4311 CM-5 Administrator, Parallel Systems Support | personal email goes to: NASA Ames Numerical Aerodynamic Simulation | jet at well.sf.ca.us PGP2.1 public key available upon request or finger jet at simeon.nas.nasa.gov From honey at citi.umich.edu Tue Jun 8 13:34:23 1993 From: honey at citi.umich.edu (peter honeyman) Date: Tue, 8 Jun 93 13:34:23 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306082034.AA26060@toad.com> and what do you make of their report on julf's non-existent ftp area? steve, you know me well; you know i'm not a raving lunatic or or a conspiracy-freak nut-case. but i believe it is more than a coincidence that soda and penet were suddenly tarred by the same brush. perhaps cert is being used as a weapon, as marc suggested. that is the most benign interpretation i can think of. so i ask you again: don't you think cert might be jeopardizing its effectiveness through these actions? peter From smb at research.att.com Tue Jun 8 13:53:48 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 8 Jun 93 13:53:48 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306082053.AA26363@toad.com> and what do you make of their report on julf's non-existent ftp area? I don't know. The most charitable interpretation is that CERT is being extremely careful about their own behavior, and they're not going around probing for anonymous ftp on various sites without more than an informant's tip that such a service is offered. Again, though, I'm guessing. I do know that they're short on staff. They certainly can't scan the archives, and a report of a non-existent anonymous ftp area may be sufficiently rare they they never thought to check it. steve, you know me well; you know i'm not a raving lunatic or or a conspiracy-freak nut-case. but i believe it is more than a coincidence that soda and penet were suddenly tarred by the same brush. Of course you're not a raving lunatic. Certainly, you rave at times, but I don't think I've ever called you a lunatic... perhaps cert is being used as a weapon, as marc suggested. that is the most benign interpretation i can think of. so i ask you again: don't you think cert might be jeopardizing its effectiveness through these actions? You're right -- the coincidence, if coincidence it is, is quite odd. I'm more disturbed by the question of how CERT got the information; a more common report would be from an administrator who found such unwanted deposits, and who reported to CERT what sites sent them or retrieved them. CERT will certainly hurt itself if it allows itself to be used. But if most such reports are accurate, welcomed by the administrators, and obtained from legitimate sources, they won't have a problem. I'm going to stop speculating, though. I'll send a note to various folks at CERT (though without mentioning either cypherpunks, soda, or anon.penet by name), and ask them what their policy is on such reports, and in general where they come from. --Steve Bellovin From marc at GZA.COM Tue Jun 8 13:54:48 1993 From: marc at GZA.COM (Marc Horowitz) Date: Tue, 8 Jun 93 13:54:48 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306082034.AA26060@toad.com> Message-ID: <9306082054.AA14005@dun-dun-noodles.aktis.com> >> perhaps cert is being used as a weapon, as marc suggested. that >> is the most benign interpretation i can think of. so i ask you >> again: don't you think cert might be jeopardizing its effectiveness >> through these actions? "Do not attribute to malice that which can be adequately explained by stupidity." Without support, I think CERT is merely being stupid. Someone else (maybe even a government employee) is being malicious. I do think cert is harming their effectiveness by doing this. My guess is that they never stopped to think that someone might use them in this way to shut down an "unpopular" ftp site. Marc From smb at research.att.com Tue Jun 8 13:59:09 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 8 Jun 93 13:59:09 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306082059.AA26522@toad.com> >Any public spooling directory is fair game for their antics. [...] >My guess is that your CERT problems have NOTHING to do with >PGP distribution. There is only one directory on the cypherpunks site that is writable, and that is the incoming directory and it's not readable. It doesn't have to be. Anyone could create ``incoming/.. '', stick some files in it, and tell his/her friends. The new directory would be readable. Again, I'm not speaking hypothetically here. In our case, it was ..^T, and contained pirated PC software. (We decided not to infect those files with viruses... We didn't even replace them with programs that just printed nasty messages.) From shipley at tfs.COM Tue Jun 8 14:11:19 1993 From: shipley at tfs.COM (Peter Shipley) Date: Tue, 8 Jun 93 14:11:19 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306082034.AA26060@toad.com> Message-ID: <9306082110.AA07415@edev0.TFS> Eric why dont you move the cypherpunk anonymous ftp site to your own system on the internet and be free of UCB's influence. -Pete From 72114.1712 at CompuServe.COM Tue Jun 8 14:32:37 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Tue, 8 Jun 93 14:32:37 PDT Subject: CERT Message-ID: <930608212913_72114.1712_FHF45-2@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Punksters, I would guess that the intent of the letter Eric Hughes got from CERT was to intimidate rather than to raise some arguable issue. I hope Eric plans to ask Ms. Katherine T. Fithen, directly, who the tipster was ("I'm sorry, we do not divulge the names of our confidential informants"), why someone at CERT didn't contact Eric first, what specific allegations were made, etc. I would like to see a copy of such an e-mail message and its response, if any. What say, friend, Eric? Intrudingly yours, S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ral at telerama.pgh.pa.us Tue Jun 8 14:33:21 1993 From: ral at telerama.pgh.pa.us (Robert Luscombe) Date: Tue, 8 Jun 93 14:33:21 PDT Subject: CERT Message-ID: Not having heard of CERT before, and living ten minutes away from their offices at SEI, i checked out their anonymous ftp site (cert.org) and found the CERT faq in the pub directory. From the info THEY provide, it seems like a worthwhile organization. BUT, in their info, they deal with security issues, not copyright infringement. I realise that hidden directories in an incoming dir is a security issue, but it seems to be a thinly veiled attack on the distribution of software of illegal or questionable origins. They do publish security advisories; i would be interested in seeing a list of sites served with notices similar to those julf and soda received. Does anyone have more info on CERT? BTW- SEI at CMU is a scary place. The photo lab i worked for as a messenger had clients there, so i was in the building a couple times a day for more than i year. Because of their DOD affiliation, there are regular protests outside the building. On a normal delivery during one of these protests i was surrounded by guards, searched, and asked some WAY paranoid questions even though the regular guards knew who i was. If you ever happen to be walking the halls of SEI and see the nice big prints of guided missiles and other scary stuff, I probably delivered them. --Robert Luscombe ral at telerama.pgh.pa.us | 2201 Sarah Street Apt. 3 robert at well.sf.ca.us | Pittsburgh, PA 15203 rluscomb at nyx.cs.du.edu | 412/488-0941 (Finger for PGP Public Key) From honey at citi.umich.edu Tue Jun 8 14:34:14 1993 From: honey at citi.umich.edu (peter honeyman) Date: Tue, 8 Jun 93 14:34:14 PDT Subject: CERT In-Reply-To: <9306082031.AA12159@boxer.nas.nasa.gov> Message-ID: <9306082134.AA27495@toad.com> > I personally like being contacted by an organization trying to tell me > that someone might be misusing my computing resources. how would you feel about an organization telling your boss that your actions were contributing to the abuse? that is certainly how the message was received at soda, and in earlier, similar circumstances, at penet, as well. peter From mab at crypto.com Tue Jun 8 14:42:10 1993 From: mab at crypto.com (Matt Blaze) Date: Tue, 8 Jun 93 14:42:10 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306082022.AA25894@toad.com> Message-ID: <9306082126.AA29129@crypto.com> .... > >If you asked CERT to justify such notes, they'd probably quote the >following text from their press release on ftp.cert.org: > > It will also serve as a focal point for the research community > for identification and repair of security vulnerabilities, > informal assessment of existing systems in the research > community, improvement to emergency response capability, and > user security awareness. > >``User security awareness'' sounds about right. > .... Steve, I think CERT is off base with these notes. The problem, to my eyes, is not that they're notifying administrators of potential problems before they occur; that's all well and good, and probably easily within their charter. What I take issue with is the underhanded manner in which they seem to be doing it. According to the reports from soda and penet, the notes were not sent in response to any specific request from the sites in question, but rather on the inititate of someone at CERT itself or in response to some vague complaint from a third party. Furthermore, the notes were sent "above the heads" of the individual site adminstrators (perhaps to whoever is listed in the domain contact at the NIC), apparently causing bad feelings and misunderstanding in at least the two cases reported here. If they had sent mail to the postmasters at the individual sites saying "hey, did you know your machine has a writeable anonymous ftp directory?" that's one thing. I'd interpret that as a friendly and helpful gesture. Instead, the impression is one of, at best, unwelcome meddling, or, at worst, some kind of bizarre network-vigilantism. If they find something they don't like about one of my computers, who else are they going to send mail to? My boss? My mother? I should point out that I've delt with CERT myself a couple of years ago regarding an intruder on a machine I administered, and found them to be nothing but helpful and professional. Their assistance was, however, limited to reacting to specific problems that I asked them to help with. They never initiated any kind of audit of my site or did anything that would make me feel as if they were some kind of "net cop wannabes" who were "checking up" on my computers. I'd hate to see that image changing, because they have the potential to provide an increasingly valuable service as the internet grows. -matt From nobody at cicada.berkeley.edu Tue Jun 8 14:47:32 1993 From: nobody at cicada.berkeley.edu (nobody at cicada.berkeley.edu) Date: Tue, 8 Jun 93 14:47:32 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306082147.AA11091@cicada.berkeley.edu> -----BEGIN PGP SIGNED MESSAGE----- This "coincidence" brings a name to mind. Rhymes with "turn right." Starts with S. What could I be thinking? DEADBEAT -----BEGIN PGP SIGNATURE----- Version: 2.2 iQBFAgUBLBUF/fFZTpBW/B35AQEFfQGArv/awBslh2T7ybcjtiiiT9Ew3wxPz3Vv od0hAFCl5L0VFOA1MczZozJWf4xH0nFM =LNm6 -----END PGP SIGNATURE----- From TO1SITTLER at APSICC.APS.EDU Tue Jun 8 15:59:21 1993 From: TO1SITTLER at APSICC.APS.EDU (Kragen Sittler) Date: Tue, 8 Jun 93 15:59:21 PDT Subject: ALERT / My email address is... Message-ID: <930608165150.1a6@APSICC.APS.EDU> Well, actually, it's not even a hack to find out who the subscribers are... You simply use the EXPN command in the SMTP protocol to find out who the recipients of a list are. This is documented in RFC-821. However, the cypherpunks list requires a little bit of ingenuity, or familiarity with sendmail. I periodically get a copy of this list, just in case. Last I checked, there were 409 names on the list. Two were files, about ten or fifteen were either other lists, fidonet echos, or local USENET newsgroups. The rest appeared to be real people. Most of the apparent lists listed on the cypherpunks list were not traceable thru SMTP EXPN. If you desire real privacy, I suggest that you get the cypherpunks list, figure out which ones are hidden lists, and ask to subscribe to those. If it is desired, I can send a list of these lists to the cypherpunks list. Kragen From space2 at stein.u.washington.edu Tue Jun 8 16:00:28 1993 From: space2 at stein.u.washington.edu (TJO) Date: Tue, 8 Jun 93 16:00:28 PDT Subject: CERT In-Reply-To: <9306082031.AA12159@boxer.nas.nasa.gov> Message-ID: <9306082300.AA18418@stein.u.washington.edu> J.E.T. writes: i > >computer EMERGENCY response taskforce or something like that? They should have > >no business bothering you unless you requested some kind of assistance from > >them, IMHO. > > I personally like being contacted by an organization trying to tell me > that someone might be misusing my computing resources. Certainly that may be so.. but in this case they didn't merely tell 'you' with a simple note, instead they did atleast 2 things which really are bothersome and overstepping common 'courtesy' of merely informing 'you': 1) Instead of going directly to the owner of the directory in question or the administator of the host they jumped over 'your' head and went to the domain administrator. I can see going to a site administrator if they had reason to believe the owner of the directory was doing something illegal.. but then again they have no authority to make/enforce/etc any kind of laws. They were just plain out of line. Consider this example (and I'll give them the benefit of doubt here that someone really did complain to them and they aren't on some witchhunt of their own): I am Cert and Mr Von Karman has emailed me to say that a /jet/Enigma-cypher-code directory appears to have illegal software of some kind.. so I send up my email.. not to you.. but to Goldin, the new NASA head that I believe this directory owned by you has illegal software on it. Well that is a good way to put some bad marks on your record even if you do prove it untrue to your boss.. maybe you had just removed the evidence before he checks out your acct.. either way he shuts down your net access for a while..'just to be sure', and look out next time you want a promotion.. can't be to safe.. you might be a security risk! 2) They didn't check the system out before hand and blatantly said as much.. what kind of service to you is that? my friend met a guy who knows bigfoot..but certainly you don't see me bothering the people who own the land where bigfoot is supposed to live. 3) They want to confiscate logs from the system.. That sure as heck isn't any of their business.. 3) other complaints which I'll file for now. --- ------------------------.------------------.-----------------.- Tim Oerting | |insert disclaimer| Computer Consultant | U. of Washington |I speak 4 myself | School of Law | |..blah..blah.. | From kent_hastings at qmail2.aero.org Tue Jun 8 16:00:37 1993 From: kent_hastings at qmail2.aero.org (Kent Hastings) Date: Tue, 8 Jun 93 16:00:37 PDT Subject: New PGP Version? Message-ID: <199306082259.AA14066@aerospace.aero.org> New PGP Version? Here goes with ANOTHER stupid newbie question: What's the latest PGP version? I have DOS and Mac copies of version 2.2. Is there an e-mail accessible group like this for PGP or crypto in general? I see references to sci.crypt on occasion. Is that easy to get, or do I have to do fancy-smancy things with archie, ftp, usenet, and other Greek words? (I have docs for archie, and will soon have UUCP decode software, but I haven't figured out all this complicated, user-hostile stuff quite yet). I DO know IBM MVS/JES2 JCL, and because there is nothing more difficult to use, I am confident that this Internet jive will seem trivial someday. Kent - kent_hastings at qmail2.aero.org#000# From fnerd at smds.com Tue Jun 8 16:07:40 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Tue, 8 Jun 93 16:07:40 PDT Subject: CERT and us Message-ID: <9306082235.AA28928@smds.com> hey folks a poem by fnerd It looks like CERT may have a habit of sending accusatory-looking form letters without doing much checking of their own based on who knows what tips. Looks like they need to polish their policies and their prose a little bit. BUT We, too, are a group formed to look into problems of computer security. We, too, respond to security emergencies. We, too, distribute patches to help people improve their security. We, too, send messages--even rumors--back and forth about threatening situations and people we suspect. Sure, our style and emphasis are different, but our charter is very similar to theirs. Let's not let our name or style distract us from our mission or blind us to potential allies. Instead of thinking of them as the heavies and us as the rebels, WHY NOT us as the net-wise older brothers, and them as the enthusiastic amateurs who need some advice and calming down? Eric can write one of his authoritative letters, and we become the voice of reason, the watchers of the watchers, Liberty's eyes. Gentlemen and ladies (I reproach you), remember who we are. -fnerd quote me From honey at citi.umich.edu Tue Jun 8 16:16:35 1993 From: honey at citi.umich.edu (peter honeyman) Date: Tue, 8 Jun 93 16:16:35 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306082147.AA11091@cicada.berkeley.edu> Message-ID: <9306082316.AA00751@toad.com> > What could I be thinking? oho, that is rich! maybe we should forward db's note to cert, who would turn around and muscle netcom.com for allowing users to ... peter From jet at nas.nasa.gov Tue Jun 8 16:38:39 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Tue, 8 Jun 93 16:38:39 PDT Subject: CERT In-Reply-To: <9306082134.AA26126@data.nas.nasa.gov> Message-ID: <9306082338.AA00441@boxer.nas.nasa.gov> peter honeyman writes: > jet wrote: > > I personally like being contacted by an organization trying to tell me > > that someone might be misusing my computing resources. > how would you feel about an organization telling your boss that > your actions were contributing to the abuse? I wouldn't care given my current boss(es). If my boss were the sort to believe a vague form letter and take action w/o consulting me, I'd want a different boss anyway. From fergp at sytex.com Tue Jun 8 16:45:22 1993 From: fergp at sytex.com (Paul Ferguson) Date: Tue, 8 Jun 93 16:45:22 PDT Subject: McCarthy lives! Message-ID: -----BEGIN PGP SIGNED MESSAGE----- On Tue, 8 Jun 93 3:33:26 PDT, Timothy C. May wrote - > At a Bay Area party for hacker types in December, 1988, I was > talking to a guy with longstanding computer security > connections. He looked at me strangely and said something like > "Well, Tim, your name just came up in Washington on a list of > the most dangerous hackers in the country." I laughed it off > and asked him why--after all, I'm not considered to much of a > programmer by anyone _I_ know. He wouldn't elaborate, just > looked at me strangely. Funny you should mention that scenario. I've been hearing (through the proverbial grapevine, of course) that such a McCarthy-ist list does indeed exist. Of course, it _is_ rumour and should be discounted as such. Right? ;-) -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLBSeY5RLcZSdHMBNAQFTSAQAkULlzwMom5kgQxjNGK0atpYXV6FNT7w5 whuvrHkzHU/5dE1v+JAa0ESkmw6RibaMRv7fvMbDeR5nTU0tb3e6Q1jT+TNTcG/D rqf3dCDvbQNGfHLTV/oNKpRob/ivnp6kkvOEXvHFEX+NgrqpAu9N3dGgKcv/9TvH nsE3RTkOhvE= =s44R -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From poier at sfu.ca Tue Jun 8 16:56:17 1993 From: poier at sfu.ca (Skye Merlin Poier) Date: Tue, 8 Jun 93 16:56:17 PDT Subject: ALERT / My email address is... In-Reply-To: <9306080418.AA07574@triton.unm.edu> Message-ID: <9306082356.AA21325@malibu.sfu.ca> -----BEGIN PGP SIGNED MESSAGE----- :) I suggest that we try to create an encrypted cypherpunks list? Comments? Sounds good to me. Skye - -- - -----====> Skye Merlin Poier <====----- Undergrad in CMPT/MATH (Virtual Reality) |||| |||| email: poier at sfu.ca p-OO <--> OO-q THINK PGP Public Key available on finger \== ==/ -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLBUm9y0bkpXW3omvAQGitAQAoWoXxYAVyqnw+m8tjGTWmRQbtGbYJsPV zT1wKcx3PI/w9RzPXJUzNYjMg2sKKHTT/vxQuGM3TjuyVoPK+5fx33Z+A5QArAdB Y4An8VClFC2l8rieLGsYjIl+Za/d5D6a28hLL5SEkNyM7kzzMtbvInAXCKClEDs4 GcSSAnn8ea4= =GYsy -----END PGP SIGNATURE----- From gnu Tue Jun 8 17:36:31 1993 From: gnu (John Gilmore) Date: Tue, 8 Jun 93 17:36:31 PDT Subject: TIS/PEM FAQ as of 8 June 1993 Message-ID: <9306090036.AA02947@toad.com> ------- Forwarded Message From: James M Galvin To: ietf-announce at cnri.reston.va.us, psrg-interest at isi.edu, pem-dev at TIS.COM, rsaref-users at rsa.com, saag at TIS.COM, tispem-users at TIS.COM Subject: TIS/PEM FAQ as of 8 June 1993 Date: Tue, 08 Jun 93 16:21:10 -0400 - -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh HbGVud29vZA==,02 MIC-Info: RSA-MD5,RSA,BpCu5i/vNJFNX64bj4KuRr8Jm05gdfjIIO5WQaSTXAG kx09ivq97GtmdksgshOkdqynlLxTSph0s6DtNN5girn2Q/u08q44XLYbk6vYxA9g 37w/L1leqw7CldPLPOtQT Many of you will recall the announcement of the availability of TIS/PEM, the Internet reference implementation of PEM, distributed last week. Included below is the first TIS/PEM FAQ. We are posting it this one time to the same mailing lists that received the announcement last week. In the future, it will be posted to the mailing list and several appropriate newsgroups. We hope you find this useful. Thanks. TIS/PEM FAQ Last updated 8 June 1993 Send questions and comments to tispem-support at tis.com Questions answered: 1) What is Privacy Enhanced Mail (PEM)? 2) Where are the PEM standards defined? 3) Is there a forum for PEM developers and others interested in the PEM standards? 4) Are there implementations of PEM available? 5) How do I get TIS/PEM? 6) Why is TIS/PEM only available in the US and Canada? 7) Are special privileges (e.g., root access) required to install TIS/PEM? 8) What about integrating TIS/PEM into mail user agents? 9) What about DOS and other non-UNIX platforms? 10) What about certificates? 11) What is a distinguished name? 12) What is a Certification Authority (CA)? 13) What does a PCA do and how are they differentiated? 14) What PCAs are available? 15) How much does it cost to sign up under a PCA? 16) What if I have questions about TIS PCA? 17) Is there a mailing list for TIS/PEM users? 18) What if I have questions about or problems with TIS/PEM? 1 Q: What is Privacy Enhanced Mail (PEM)? A: PEM is an Internet standard for providing security services to electronic mail. It uses cryptographic techniques to provide message integrity checking, originator authentication, and confidentiality. It lets you know that a message hasn't been changed, who it's from, and, optionally, allows you to keep it secret from all but the intended recipients. 2 Q: Where are the PEM standards defined? A: There is a set of Proposed Standard RFCs (Internet standards documents) that specify PEM. The four new documents are RFCs 1421 (obsoletes 1113), 1422 (obsoletes 1114), 1423 (obsoletes 1115), and 1424 (new). These documents may be found in your favorite RFC repository. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info at ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs 3 Q: Is there a forum for PEM developers and others interested in the PEM standards? A: Yes, there is an electronic mailing list that is used to discuss the PEM specifications, implementation issues, and it is used to conduct some of the business of the Internet Engineering Task Force (IETF) PEM working group. Send a message to "pem-dev-request at tis.com" if you would like to be added to the list. 4 Q: Are there implementations of PEM available? A: Yes, implementations are being made available as you read this. Trusted Information Systems (TIS), under ARPA sponsorship and in cooperation with RSA Data Security Incorporated (RSADSI), has released a reference implementation of Privacy Enhanced Mail (TIS/PEM) to the Internet community. TIS/PEM is a UNIX-based implementation that has been integrated with Rand MH 6.7.2 and is easily integrated into other mail user agents. TIS/PEM is distributed in source form. It is openly available within the United States and Canada for non-commercial use (not for resale). 5 Q: How do I get TIS/PEM? A: TIS/PEM is available via anonymous ftp in the United States and Canada to US and Canadian citizens and people with a US "green card." To retrieve TIS/PEM please FTP to host: ftp.tis.com login: anonymous and retrieve the files pub/PEM/README pub/PEM/LICENSE pub/PEM/BUGS The README file contains further instructions. 6 Q: Why is TIS/PEM only available in the US and Canada? A: The export from the United States of the cryptography used in TIS/PEM is controlled by the United States government. 7 Q: Are special privileges (e.g., root access) required to install TIS/PEM? A: TIS/PEM can be installed in multi-user mode, which is identified by the use of a single, system-wide, shared database of cryptographic and administrative information maintained by one or more privileged users called certificate administrators, and single-user mode, which allows individuals to maintain their own databases of cryptographic and administrative information. Multi-user mode installation requires privileges, while single-user mode installation does not. 8 Q: What about integrating TIS/PEM into mail user agents? A: TIS/PEM has been integrated with MH 6.7.2 and is easily integrated with other mail user agents. If you integrate TIS/PEM with a popular mail user agent, we would be happy to make it available to others. Additionally, a set of filters, similar to the UNIX cat command, that allow you to apply and remove PEM enhancements (enhance and de-enhance) text files are provided. These filters make it possible to use PEM with mail user agents that are not PEM aware. 9 Q: What about DOS and other non-UNIX platforms? A: TIS/PEM is currently limited to UNIX, but we are pursuing porting it to other operating systems. 10 Q: What about certificates? A: While PEM uses X.509 certificates to bind distinguished names to RSA public keys, it is not necessary to join the Internet certification hierarchy or otherwise pay to use TIS/PEM. TIS/PEM is capable of generating the certificates that you need. Joining the Internet certification hierarchy has the benefit of making it easier to verify others' mail and for them to verify yours. To join the Internet certification hierarchy, you must sign up your Certification Authority (CA) under a Policy-level Certification Authority (PCA). 11 Q: What is a distinguished name? A: A distinguished name is a hierarchical, globally unique name used to identify something or someone. RFC 1255 and several North American Directory Forum (NADF) documents describe how to select appropriate distinguished names. The distinguished name for Earl Sinclair (a fictional character, geographically displaced) might be Country=US State or Province=CA Organization=Wesayso Corporation Organizational Unit=Tree Pushing Division Common Name=Earl Sinclair 12 Q: What is a Certification Authority (CA)? A: A Certification Authority (CA) vouches for the binding between users' distinguished names and RSA public keys within an organization or organizational unit. The CA's distinguished name is that of the organization or organizational unit and users' distinguished names are created by starting with the CA distinguished name and adding something to uniquely and unambiguously identify the user, like a common name. 13 Q: What does a PCA do and how are they differentiated? A: PCAs vouch for the binding between a CA's distinguished name and RSA public key. By joining a PCA, others can verify your PEM messages by following the certification path to the Internet Policy-level Certification Authority certificate without having to have retrieved your RSA public key using secure, out of band means. PCAs may also make CA Certificate Revocation Lists (CRLs) and certificates available and provide other services for its members. PCAs can be differentiated by the policy that they advertise. The policy includes the level of effort -- and associated assurance -- that a PCA uses to insure the correctness of the binding and the requirements they place on CAs which issue certificates under them. They can also be differentiated by the other services they offer and their price. 14 Q: What PCAs are available? A: Several PCAs exist as part of the Internet certification hierarchy, including PCAs at RSADSI and TIS, and more may come online in the near future. 15 Q: How much does it cost to sign up under a PCA? A: Individual PCAs will have their own price schedules. Signing up under the TIS PCA is free during 1993. 16 Q: What if I have questions about TIS PCA? A: Sent them to tispca-info at tis.com. 17 Q: Is there a mailing list for TIS/PEM users? A: Yes, it's tispem-users at tis.com. Send mail to tispem-users-request at tis.com to be added to or deleted from the list. 18 Q: What if I have questions about or problems with TIS/PEM? A: Send them to tispem-support at tis.com. - -----END PRIVACY-ENHANCED MESSAGE----- ------- End of Forwarded Message From smb at research.att.com Tue Jun 8 17:49:11 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 8 Jun 93 17:49:11 PDT Subject: CERT Message-ID: <9306090049.AA03320@toad.com> The paranoia is getting out of hand. Let's take this one point by point. I've deleted the poster's name, because this note is just an example; it's not the only such posting. Certainly that may be so.. but in this case they didn't merely tell 'you' with a simple note, instead they did atleast 2 things which really are bothersome and overstepping common 'courtesy' of merely informing 'you': ``You''? Who is ``you''? The CERT note didn't mention any individual. They might not have the information. If they did, it might be because the account was compromised. (That was the case the last time I helped a friend investigate ftp droppings. In that case, though, it was only the ftp account, not the login account, so notifying the owner would not have been damaging. Btw -- remember the recent CERT advisory on bugs in the WUSTL ftpd?) 1) Instead of going directly to the owner of the directory in question or the administator of the host they jumped over 'your' head and went to the domain administrator. I can see going to a site administrator if they had reason to believe the owner of the directory was doing something illegal.. but then again they have no authority to make/enforce/etc any kind of laws. They were just plain out of line. Consider this example (and I'll give them the benefit of doubt here that someone really did complain to them and they aren't on some witchhunt of their own): I am Cert and Mr Von Karman has emailed me to say that a /jet/Enigma-cypher-code directory appears to have illegal software of some kind.. so I send up my email.. not to you.. but to Goldin, the new NASA head that I believe this directory owned by you has illegal software on it. Well that is a good way to put some bad marks on your record even if you do prove it untrue to your boss.. maybe you had just removed the evidence before he checks out your acct.. either way he shuts down your net access for a while..'just to be sure', and look out next time you want a promotion.. can't be to safe.. you might be a security risk! As I said before, they might not know who was involved. Even if they did, and even if the account wasn't compromised, it's the SA's responsibility to investigate. What if a local user is doing un- authorized things? Take this particular case -- they could easily end up being sued for contributing to copyright infringement. They might win -- but defending against a lawsuit is expensive. 2) They didn't check the system out before hand and blatantly said as much.. what kind of service to you is that? my friend met a guy who knows bigfoot..but certainly you don't see me bothering the people who own the land where bigfoot is supposed to live. Check it out? How? Apart from the question of whether or not you want CERT looking through your directories (and I can just hear the complaints now -- ``On no evidence but an anonymous tip, CERT logged in, listed everything, looked for *my* hidden areas that I used to distribute restricted software, and tied up my link to the Internet for hours while the downloaded everything in sight'') -- it isn't feasible. I just ftp'd to soda for a quick look-see. A ls-lRa generated 160K bytes. Simply screening that takes time. Many of the files showed only numeric uid's; the ftpd passwd file was obviously not up to date. Even if I knew the suspect files, I might not know who the responsible user was. Many of the files had informative names like ``packet123.Z''. They mirrored the full X11R5 distribution. How much time and effort should CERT put in?!?!! A competent SA will at least know the putative ownership and reliability of the owner of most of that stuff; CERT sure doesn't (except, of course, for the list of hackers they may or may not have, and which has been (rightly) objected to). 3) They want to confiscate logs from the system.. That sure as heck isn't any of their business.. Confiscate? Confiscate? They asked for a copy, if available. ``Confiscate'' generally means ``take away''. They're not taking anything from you. If the logs do show anything, it's precisely their business -- evidence of someone abusing your system (I'm assuming here that there really was 3rd-party deposits and retrieval of files). Quick -- how many of those file transfers are coming from stolen accounts? In my experience, a goodly number. Look, I have my own concerns about CERT in this matter, notably the questions of what evidence they're acting on, and whether or not they're being used (consciously or not) to silence unpopular sites. I've sent them a note asking those questions. But let's try to keep things in perspective. Oh yeah -- as an added bonus, I've enclosed a transcript of the kinds of things I do when trying to find an administrative contact for some machine. I don't see any avenues of contact more likely than ``root'' or ``postmaster''. And it's clearly a large-scale timesharing machine, where there's no one individual clearly responsible for it. --Steve Bellovin ----- $ whois -h rs.internic.net soda.berkeley.edu No match for "SODA.BERKELEY.EDU". The InterNIC Registration Services Host ONLY contains Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. $ finger root at soda.berkeley.edu [soda.berkeley.edu] Login: root Name: The Allmighty Directory: / Shell: /bin/csh Office: E238, x2-7453 Last login Mon May 31 22:17 (PST) on console No Plan. $ finger postmaster at soda.berkeley.edu [soda.berkeley.edu] finger: postmaster: no such user. $ dig mx soda.berkeley.edu ; <<>> DiG 2.0 <<>> mx soda.berkeley.edu ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6 ;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 3, Addit: 8 ;; QUESTIONS: ;; soda.berkeley.edu, type = MX, class = IN ;; ANSWERS: soda.berkeley.edu. 55780 MX 4 soda.Berkeley.EDU. soda.berkeley.edu. 55780 MX 6 scotch.Berkeley.EDU. ;; AUTHORITY RECORDS: Berkeley.EDU. 161050 NS VANGOGH.CS.BERKELEY.EDU. Berkeley.EDU. 161050 NS VIOLET.Berkeley.EDU. Berkeley.EDU. 161050 NS UCBVAX.BERKELEY.EDU. ;; ADDITIONAL RECORDS: soda.Berkeley.EDU. 55780 A 128.32.149.19 scotch.Berkeley.EDU. 55780 A 128.32.131.179 VANGOGH.CS.BERKELEY.EDU. 161050 A 128.32.130.2 VIOLET.Berkeley.EDU. 161050 A 128.32.136.22 UCBVAX.BERKELEY.EDU. 39151 A 128.32.137.3 UCBVAX.BERKELEY.EDU. 161050 A 128.32.130.12 UCBVAX.BERKELEY.EDU. 161050 A 128.32.149.36 UCBVAX.BERKELEY.EDU. 51896 A 128.32.133.1 ;; Sent 1 pkts, answer found in time: 0 msec ;; FROM: inet to SERVER: default -- 0.0.0.0 ;; WHEN: Tue Jun 8 20:16:07 1993 ;; MSG SIZE sent: 35 rcvd: 295 $ telnet soda.berkeley.edu 25 Trying... Connected to soda.berkeley.edu. Escape character is '^]'. 220 soda.berkeley.edu Sendmail 5.65/KAOS-1 ready at Tue, 8 Jun 93 17:10:50 -0700 helo research.att.com 250 soda.berkeley.edu Hello research.att.com, pleased to meet you vrfy root 250-Eric Hollander <"|/accounts/hh/remail/slocal.pl"> 250-Keir Morgan 250-ERic MeHlHaFf 250-ERic MeHlHaFf <\mehlhaff> 250-Tom Holub 250-John S. Jacob 250-Matthew L. Seidl 250-Shannon D. Appel <"| /usr/local/lib/mh/slocal -user appel -verbose"> 250-Sean N. Welch 250-Dan Wallach 250-Donald J. Kubasak 250-David G. Paschich 250-Adam Glass <\glass> 250 Adam Glass vrfy postmaster 250-Eric Hollander <"|/accounts/hh/remail/slocal.pl"> 250-Keir Morgan 250-ERic MeHlHaFf 250-ERic MeHlHaFf <\mehlhaff> 250-Tom Holub 250-John S. Jacob 250-Matthew L. Seidl 250-Shannon D. Appel <"| /usr/local/lib/mh/slocal -user appel -verbose"> 250-Sean N. Welch 250-Dan Wallach 250-Donald J. Kubasak 250-David G. Paschich 250-Adam Glass <\glass> 250 Adam Glass quit 221 soda.berkeley.edu closing connection Connection closed by foreign host. $ finger @soda.berkeley.edu [soda.berkeley.edu] Login Name Tty Idle Login Time Office Office Phone aaron Aaron C. Smith qR Jun 8 08:58 Limbo 643-7217 aaron Aaron C. Smith *qT Jun 8 08:58 Limbo 643-7217 achoi Andrew Choi pB 3 Jun 7 18:19 appel Shannon D. Appel pK Jun 8 09:57 CEA 643-5657 aswan Andrew Swan pW Jun 8 17:06 calvin Wa Pak qe 22:11 Jun 7 18:57 cgd Chris G. Demetriou qf Jun 7 22:15 278 Cory 510-642-7520 cliffwd Cliff Draper pe 36 Jun 8 16:30 9-204a 643-3426 cynthia cynthia leigh haynes *pr 3 Jun 8 16:43 cynthia cynthia leigh haynes ps Jun 8 16:43 deb Debra Waldorf *p7 Jun 8 16:20 deb Debra Waldorf *qg 51 Jun 8 15:27 eganloo Egan Loo pJ Jun 8 16:57 eric Eric van Bezooijen qz 1:01 Jun 8 15:50 238E gwh George William Herbe pc 1 Jun 8 14:13 238E gwh George William Herbe pm Jun 8 14:26 238E henchiu Henry Chiu pR Jun 8 17:02 ho Kinson Ho *q3 1:13 Jun 8 15:08 608-1 Evan 642-8290 hughes Eric Hughes *qm 36 Jun 8 10:34 238E isaac Isaac Cheng *pE 12 Jun 8 09:51 isaac Isaac Cheng *qw 12 Jun 8 10:59 jenn Jennifer Hom *pF Jun 8 16:52 238E 415-688-8034 jlb Jordana Brown pQ Jun 8 14:45 karlht Karl Thiessen *pb 13 Jun 8 16:28 238 Evans 642-7453 kenji Kenji Hubbard *pX Jun 8 17:08 238E kube Donald J. Kubasak pU 2 Jun 8 17:05 CEA ESOC 643-7367 marco Marco Nicosia qI Jun 8 15:58 238E 510-283-9587 maroo Maroo Lieuw *qx Jun 8 13:33 849-9872 michelle Michelle Tisi *qZ 5:30 Jun 8 11:34 ming Tje Ming *qj 9 Jun 8 15:28 ming Tje Ming *qO 2:17 Jun 8 13:50 mlee Michael Lee *pD Jun 8 16:49 mlee Michael Lee *qC Jun 8 15:52 nancy Nancy Cheng *pf 1:18 Jun 8 14:17 nancy Nancy Cheng *qV 1:53 Jun 8 13:52 payam Payam Mirrashidi po 19:13 Jun 7 20:54 199MD Cory 642-1297 psb partha s. banerjee *py 2:25 Jun 8 14:32 IBM Almade 510-649-7505 psb partha s. banerjee *pz 2:38 Jun 8 14:32 IBM Almade 510-649-7505 ralbers Rick Albers *pV Jun 8 17:06 rmgee Randall Gee *pn Jun 8 14:28 robert Roberto Boyd *pA Jun 8 16:47 rsr Roy S Rapoport *pY Jun 8 17:09 510-540-5535 seidl Matthew L. Seidl qk 1 Jun 8 10:31 238E x2-7453 seidl Matthew L. Seidl *qB Jun 8 08:32 238E x2-7453 sfd Scott Drellishak pl Jun 8 16:40 Kerr 3-202 tom Tom Holub *pH Jun 8 16:53 tom Tom Holub pI Jun 8 16:53 welch Sean N. Welch *p0 Jun 8 09:04 MTV21-122 415-336-4289 From gnu Tue Jun 8 17:51:08 1993 From: gnu (John Gilmore) Date: Tue, 8 Jun 93 17:51:08 PDT Subject: McCarthy lives! In-Reply-To: Message-ID: <9306090050.AA03345@toad.com> > talking to a guy with longstanding computer security > connections. He looked at me strangely and said something like > "Well, Tim, your name just came up in Washington on a list of > the most dangerous hackers in the country." I laughed it off Tim, I'll be glad to teach you how to file a Privacy Act request. It's pretty simple, and it works on all Federal agencies. You get all records they are keeping on you, with some limited exceptions -- and for almost all of those, you get notified of the withholding. If you can identify one or a small number of agencies that might be keeping this "list", we can see if you are on it. And if we find the list, we can probably get the whole thing under the Freedom of Information Act. John From mark at coombs.anu.edu.au Tue Jun 8 18:02:02 1993 From: mark at coombs.anu.edu.au (Mark) Date: Tue, 8 Jun 93 18:02:02 PDT Subject: Statement of dissatisfaction with your recent efforts (fwd) Message-ID: <9306090101.AA03818@toad.com> Probably shouldnt have, but they get on my goat. Forwarded message: >From mark Wed Jun 9 10:59:04 1993 >Subject: Statement of dissatisfaction with your recent efforts >To: cert at cert.org >Date: Wed, 9 Jun 1993 10:59:04 +1000 (EST) > >Dear cert et al, > >It has come to my notice recently that your organisation has been >involved in a number of accusations against individuals and organisations >with very little to back such accusations. > >I am referring to, and these are the ones I will mention here, the >soda.berkeley.edu and the anon.penet.fi sites., both of which ARE >legitamate in all respects and are SEEN as such by the net.community. >Your organisations actions, in my personal opinion, consititute a form >of harrassment of the worse kind, and it basically smells. > >Whilst any one with any knowledge of your workings already knows the >low quality of feedback, lack of helpfulness and general arrogance of >your methods, it doesnt do you any good at all to set about on a >crusade of self-serving actions against those sites or entities or >groups of individuals you dont like or you see as furthering ideas >and software that might one day make your life difficult. You will >alienate a larger proportion of the net.community than you otherwise >have. > >I would suggest in future you take the time to VERIFY, through whatever >legal means are at your disposal, the authenticity of your information, >to view yourselves the problems/files and then take whatever action your >charter states as appropriate. Going off gun-ho and sending ominous form >letters to people you see as gullible enough to carry out your desires >really is less than professional. > >I fail to see where you get authority for a large proportion of your >actions, but that is a matter between you and your financiers. Just dont >expect people to take you seriously if the above scenarios are repeated. > >The above is my own personal observations and not those of any other >individual or organisation, although they are free to explicitly echo >them if they so desire. As of yet, none have. > >Mark. >mark at cheops.anu.edu.au From dsinclai at acs.ucalgary.ca Tue Jun 8 18:10:44 1993 From: dsinclai at acs.ucalgary.ca (Douglas Sinclair) Date: Tue, 8 Jun 93 18:10:44 PDT Subject: ALERT / My email address is... In-Reply-To: <9306082356.AA21325@malibu.sfu.ca> Message-ID: <9306090106.AA24109@acs1.acs.ucalgary.ca> An encrypted cypherpunks list? Why? To try and hide the forum's messages from the TLAs? I'm sure they already have people readin this list who'd be incorporated into the encrypted list too. Or do you plan to verify each reader before giving them the password or whatever? I fail to see the point. -- PGP 2.2 Key by finger From tcmay at netcom.com Tue Jun 8 18:21:28 1993 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 8 Jun 93 18:21:28 PDT Subject: McCarthy lives! In-Reply-To: <9306090050.AA03345@toad.com> Message-ID: <9306090121.AA10501@netcom3.netcom.com> John Gilmore writes: > > talking to a guy with longstanding computer security > > connections. He looked at me strangely and said something like > > "Well, Tim, your name just came up in Washington on a list of > > the most dangerous hackers in the country." I laughed it off > > Tim, I'll be glad to teach you how to file a Privacy Act request. > It's pretty simple, and it works on all Federal agencies. You get all > records they are keeping on you, with some limited exceptions -- and > for almost all of those, you get notified of the withholding. If you > can identify one or a small number of agencies that might be keeping > this "list", we can see if you are on it. And if we find the list, we > can probably get the whole thing under the Freedom of Information Act. I'll take John up on his kind offer! Though I expressed that to me this experience was kind of funny (in a devil-may-care way, I hope you all understand), it *does* raise larger issues of whether CERT is developing list of what might be called "subversives" based on hearsay evidence and innuendo. So, I'll try to pursue this and keep you folks posted. -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 gnu Tue Jun 8 18:37:36 1993 From: gnu (John Gilmore) Date: Tue, 8 Jun 93 18:37:36 PDT Subject: AT&T Encrypting Phone Ad in WS Journal In-Reply-To: Message-ID: <9306090137.AA05168@toad.com> > The Wall Street Journal, 7 June 93, page B7, has an AT&T ad for an > encrypting communications box called "Surity Telephone Device". > It plugs between a regular phone and the phone jack. > Anybody know what's inside? Is this new? The box pictured is the Clipper-based successor to the AT&T 3600 secure phone. They have a "bump in the cord" architecture; in the case of the 3600, it plugged between the handset and the phone. This is a pain in the ass (there are six or seven "handset modules" that plug into the unit, and you have to use one to match your phone -- or get several and pray that one will match each phone you ever want to use.) We played with one of the 3600's at a Bay Area cypherpunks meeting a few months ago. I'd refer to the "Surity" as the "surly telephone device". John From honey at citi.umich.edu Tue Jun 8 18:43:14 1993 From: honey at citi.umich.edu (peter honeyman) Date: Tue, 8 Jun 93 18:43:14 PDT Subject: News Bytes June 8, 1933 Message-ID: <9306090143.AA05481@toad.com> some interesting stuff here -- a little whistle-blowing here, a little clipper punching there ... peter ------- Forwarded Message Date: Tue, 8 Jun 93 13:02:07 -0400 From: rweingar at cs.UMD.EDU (Rick Weingarten) Message-Id: <9306081702.AA18515 at tove.cs.UMD.EDU> To: adrion at cs.umass.edu, basili at cs.umd.edu, corbato at xx.lcs.mit.edu, patterson at ginger.berkeley.edu, pfreeman at gatech.edu, mrg at research.att.com, cwg at research.nj.nec.com, ashok at almaden.ibm.com, weiser.parc at xerox.com, wulf at virginia.edu, wise at seafox.cs.indiana.edu, tony at ide.com, forsythe at cs.UMD.EDU, jh at cs.cornell.edu, greg at cs.arizona.edu, johnsson at think.com, klawe at cs.ubc.ca, kung at harvard.edu, mji at guardian.cs.psu.edu, lazowska at cs.washington.edu, leveson at ics.uci.edu, steve.muchnick at eng.sun.com, jrr at cs.purdue.edu, ritchie at hplabs.hp.com, jes at cs.brown.edu, denning at cs.georgetown.edu, jwerth at cs.utexas.edu, phayes at herodotus.cs.uiuc.edu, policy at cs.UMD.EDU Subject: News Bytes June 8, 1933 Computing Research News Bytes by Juan Antonio Osuna with Rick Weingarten 6/8/93 GAO Criticizes ARPA on Architecture Research The General Accounting Office released a report in May (GAO/IMTEC- 93-24), criticizing the DoD's Advanced Research Projects Agency for its handling of the High Performance Computers and Communications program. Some researchers have criticized ARPA for procuring only Intel and Thinking Machines supercomputers for use by ARPA projects, while ignoring machines manufactured by other companies.. GAO cleared ARPA of the harsher accusations of serious misconduct, but upheld this general criticism, saying that such a narrow focus has inhibited R&D by other supercomputer manufacturers. The report suggested that ARPA should seek advice from a broader range of researchers who do not directly participate in ARPA projects. Finally, GAO said ARPA needs to give more emphasis to software development, which in the past has been given lower priority than hardware. ARPA claims it has already fixed many of these problems.. GAO is now planning a follow-on study looking more broadly at program management and support for high performance architecture research in all agencies.. House Appropriations Subcom Gives NSF an 11% Increase [elided] "Clipper Chip" Proposal Draws Public Criticism The Clinton Administration's recent proposal to implement the Clipper chip as a government encryption standard is receiving a cold welcome from some in the computer community. During a three-day meeting before the Computer System Security and Privacy Advisory Board of the National Institute of Standards and Technology, dozens of people from academia, industry, and civil liberties groups expressed disapproval for the way the White House is trying to implement its cryptographic policies. Complaints were directed in three directions---to the technology, to the process of selecting the standard, and to the civil liberties implications for Federal wiretapping. The Administration initiated a public review after, rather than before, declaring Clipper as a government standard and ordering thousands of Clipper devices for government use. In light of the negative reaction, the advisory board passed a resolution to extend public review and voted to hold another board meeting in late July. The board also decided to send a letter to the White House to relay public concerns and to suggest tactfully that the president reconsider the Clipper scheme. Amendments to HPCC Act Move Forward [elided] ------- End of Forwarded Message From norm at netcom.com Tue Jun 8 19:12:57 1993 From: norm at netcom.com (Norman Hardy) Date: Tue, 8 Jun 93 19:12:57 PDT Subject: CERT netnews Message-ID: <9306090213.AA15326@netcom3.netcom.com> Netnews group "comp.security.announce" seems to be the product of CERT. About once a week, on the average, they post something relating to the security of some specific operating system. The few postings that I have seen seem directed to the sys-op (typically Unix) regarding some common practice with security implications or often holes in the defaults that some system comes with. What I have seen there is technical and not political. From shipley at tfs.COM Tue Jun 8 19:40:49 1993 From: shipley at tfs.COM (Peter Shipley) Date: Tue, 8 Jun 93 19:40:49 PDT Subject: ALERT / My email address is... In-Reply-To: <9306082356.AA21325@malibu.sfu.ca> Message-ID: <9306090240.AA08014@edev0.TFS> >-----BEGIN PGP SIGNED MESSAGE----- > >:) I suggest that we try to create an encrypted cypherpunks list? Comments? > >Sounds good to me. > the only use that whould bring is to get us to get more serious about key extange and to develop easier software for reading/scaning encrypted messages. On the other hand it would no benefit us in the way of that it would not us to get our messages and views to the world. (Last I checked this was not a exclusive email list). -Pete From julf at penet.FI Tue Jun 8 19:50:37 1993 From: julf at penet.FI (Johan Helsingius) Date: Tue, 8 Jun 93 19:50:37 PDT Subject: CERT In-Reply-To: <9306090049.AA03320@toad.com> Message-ID: <9306090458.aa20630@penet.penet.FI> > As I said before, they might not know who was involved. Even if they > did, and even if the account wasn't compromised, it's the SA's > responsibility to investigate. What if a local user is doing un- > authorized things? Take this particular case -- they could easily end > up being sued for contributing to copyright infringement. They might > win -- but defending against a lawsuit is expensive. Yes. Agree. And I would have had no problem had they contacted the SA at my site (me) or even my connectivity service provider (EUnet), but they didn't. They contacted the domain admin for Finland. A high-level "political" authority on a national level! Without consulting anyone involved... Julf From remail at tamsun.tamu.edu Tue Jun 8 20:31:04 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Tue, 8 Jun 93 20:31:04 PDT Subject: anonymous mail Message-ID: <9306090330.AA15612@tamsun.tamu.edu> -----BEGIN PGP SIGNED MESSAGE----- Deadbeat wrote: > This "coincidence" brings a name to mind. > Rhymes with "turn right." > Starts with S. > What could I be thinking? This is by far the best explanation for the whole soda/penet/CERT problems! Undoubtedly the work of good old Mr. "Rear of the boat; illumination" Dr. Manhattan -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLBVYzN1uahe7Mr5vAQHLlgQArcKYK9yvgXOhRdtt03z1tz3wpaUi/RAE oL1fjvLWJ7PHyK1BObnEhFjfv/JO4DwPqd1EevVDzyV3G/AydKf6GtuNVofDmu4T JlDLx5DFTZQ24xgljaubJ4yOOXgbsNMvziHq5dmwx2boqyXjufq8lXhKgnDQQBEl xH7ooyA7Aaw= =/16r -----END PGP SIGNATURE----- From ld231782 at longs.lance.colostate.edu Tue Jun 8 20:37:37 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Tue, 8 Jun 93 20:37:37 PDT Subject: TIS/PEM FAQ as of 8 June 1993 In-Reply-To: <9306090036.AA02947@toad.com> Message-ID: <9306090337.AA02019@longs.lance.colostate.edu> > TIS/PEM FAQ do you have any plans to get this on news.answers? It would be great there. Also, You should consider sci.crypt. I can help you with either if you need it. tx. From fergp at sytex.com Tue Jun 8 20:40:13 1993 From: fergp at sytex.com (Paul Ferguson) Date: Tue, 8 Jun 93 20:40:13 PDT Subject: InfoWorld Message-ID: INFOWorld June 7, 1993 Volume 15, Issue 23 pages 1, 103 IS managers assail data encryption rule 'Clipper chip would allow snooping by Scott Mace And Shawn Willett GAITHERSBURG, Md. -- IS managers and computer vendors last week blasted the Clinton administration's plans to mandate use of the "Clipper" data encryption chip. During hearings hosted by the U.S. Commerce Department here last week and in interviews, many IS managers and vendors said they fear the encryption standard could make their operations vulnerable not only to snooping by the government, but by criminals as well. IS managers and consultants from Bankers Trust Co. of New York and Deloitte &Touche voiced these concerns at the hearing and chided the government for shrouding the process in secrecy. "The secret process up until now has been destructive to public trust," said William Murray, IS consultant at Deloitte & Touche, in Wilton, Conn. "It is only a matter of time before hackers figure out a back door to de-crypt it," said Sheldon Laube, national director of information and technology at Price Waterhouse, in Menlo Park, Calif. Laube echoed the concerns of other corporate data managers. "If the government can de-encrypt it, we have to assume competitors can as well," said Bob Holmes, computer technology research analyst at Southern California Gas, in Los Angeles. The chip, which would be installed in data communications devices, including computers, modems, fax machines, and phones, encrypts data so outsiders cannot listen in or steal sensitive data. But government agencies, such as the FBI, could ask for a court order to obtain the "keys" to decode the data. No one would be forced to implement the chip, but the administration proposal could mandate government agencies to buy it, effectively forcing its widespread adoption. The Clipper chip, jointly developed by the National Security Agency and the national Institute of Standards and Technology (NIST) was also assailed by computer vendors. Oliver Smoot, vice president of the Computer and Business Equipment Manufacturers Association (CBEMA), testified that its members would have to develop separate product lines for the United States and overseas because a few foreign governments would want to give the U.S. government the capability to decode their data transmissions. This, along with the inclusion of the chip in every computer, would mean higher prices, Smoot said. CBEMA members include Apple Computer Inc., Compaq Computer Corp., IBM, and Hewlett-Packard Co. The plan has also been hotly contested by computer industry civil libertarians, such as the Electronic Frontier Foundation, which urged that the Constitution's prohibition of illegal search and seizure be applied. NIST and other government agencies countered that the chip is very resistant to tampering. It uses a key escrow system, where two or more government agencies will hold parts of a decryption key, for use by law enforcement with a valid court order. The FBI expects organized crime and terrorists to begin encoding information. Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From ryan at rtfm.mlb.fl.us Tue Jun 8 21:18:45 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Tue, 8 Jun 93 21:18:45 PDT Subject: CryptoStacker Update Message-ID: This is an update on the CryptoStacker undertaking for those interested. I am still at the research/initial_design stage, so any further suggestions would be welcome. I am working on several other projects right now so actual coding will likely not begin in earnest for at least a week or two, I also do not wish to rush things any more than I need to... The CryptoStacker engine will probably consist of a block driver style device driver running under MSDOS which will intercept blocks of data going to the disk and encrypt them, and intercept blocks of data coming from the dish and decrypt them. The system should be completely seamless and hopefully will remain at one abstraction level. The intercepted functions will be the read/write functions of interrupt 13h. The initial version will be a simple driver with no sector remapping and will have to be installed on an already existing partition seperate from the boot partition. Hopefully in the future it will be possible to create a false disk by remapping sectors and extracting all drive data from a single file stored on the physical drive, a la Stacker's one huge file. This would allow for installation without the backup and reformatting of the hard drive. The keys will initially be stored on floppy disks and password protected. For simplicity, I will use one single key for the whole disk during development, but I hope to be able to provide at least one key per track in the initial version. I intend to make the key hooks as modular as possible and as open as possible in order that the possibility of PCMIA cards holding keys, barcode keys, datacard keys, etc, will be possible in the future. The encryption engine will be completely in software for the widest possible spread. This is the single only design consideration that I am absolutely set upon, and even then I will be glad to implement any advice on how to make the code as open as possible for future hardware assistance. I would like to see it expand into hardware in the future as encryption hardware hopefully becomes easier to find. The actual encryption algorithm is a more difficult case to comment on. I have done a lot of research on DES, since most of the advice that I have recieved has pointed in that direction, but I can see that it will be extremely slow and unwieldy in software. I would like to use an algorithm which would be a little more optimized for software but alas, I am more than a little afraid of the wrath of the cypherexperts who will shun any non-DES product. I am looking into the IDEA engine now, and I like the fact that it also has the capability to take in 8bytes and put out 8bytes, but that is about all that I know about it. Things that make DES attractive to me: 1) Takes 8 bytes, puts out 8 bytes. 2) Nonlinear. 3) It is its own inverse. 4) I understand it (a factor not to be underestimated) Things that make it unnattractive: 1) It is slow as hell, especially with triple iterations. If anyone knows of some algorithms that have been widely examined which meet at least a few of the 'pro' arguments and doesn't meet the 'con' argument, please let me know... There has been some consideration on the possibility of having the key time out after a preset interval. I like the idea as an option to the user who really wants it, but I have a lot of reservations about how to make a system time out gracefully when this happens. I have some ideas for how to do this with a multitasking OS, but they just seem like hacks to me, I am looking for elegant solutions. There has also been some contemplation as to how to shield a key from being read from a PC's memory. It has been suggested that I just inform the user of the security hole and not worry about it. This seems lazy and counterproductive to me, and I would like to at least make some effort to hide the key. Any good virus writers out there? Most of my techniques involve hiding code on mass storage, but I'm sure there are some tricks to memory someone might suggest. Well, that seems about it. I hope that this has been more coherent than the flurry of replies that marked the beginning of this, and less offensive... -Ryan the Bit Wallah From ld231782 at longs.lance.colostate.edu Tue Jun 8 21:24:17 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Tue, 8 Jun 93 21:24:17 PDT Subject: a "great" NSA revelation In-Reply-To: <9306081515.AA05070@soda.berkeley.edu> Message-ID: <9306090424.AA02488@longs.lance.colostate.edu> [E.H. & L.D.] >>>"We tried to come up with a technique that would not require >>legislation," said Clint Brooks, advisor to the director of the >>National Security Agency, > >>Another ominous, foreboding quote. > >I think this neither ominous nor foreboding. This statement was >apparent within a week or so of the original announcement. I've analyzed this elsewhere. You are taking this at face value. First of all, the person (apparently a very high-ranking advisor, probably the highest and closest to the project to appear in the media) is already talking in the past tense. If they were confident and not rattled it would be `we've come up with a technique that doesn't require legislation'. So far so good. But at this late date, and the quote is presumably fresh, it has that vague hint that they are now *considering* the legislative approach given the `nice guy' approach failed. Cypherpunks, beware! I think it could really happen. *No one* in the government has ruled out domestic cryptographic regulation. We have nothing but the spineless whimperings of Kammer saying `I can't see what it would accomplish'. Everybody has this strange mindset that such a thing is conceivable. WHAT? As I was telling someone on the list, that would be like waking up *into* a nightmare. Here's the likely scenario: they come up with a way of `certifying' or `licensing' cryptographic equipment with penalties that have some teeth (like ability to confiscate on `suspicion'!) and intimidate cryptographic developers. Why? Well, to protect the public from inferior cryptography, of course. We have to make sure there's no problems with the hardware, isn't that obvious? I hope CPSR and EFF have their lawyers revved up, because this is Supreme Court material. Legislation of cryptography is the most obnoxious, foul-smelling decomposition I've ever considered. Doesn't anyone get it? Clipper represents a startling shift from NSA policy to tinkering with *domestic* cryptography on the *large-scale* by intent, despite, as CPSR points out, no legal foundation whatsoever (and in fact, I'd buy a jackhammer or bulldozer before I see anybody erecting one). A startling shift from a passive to an *active* role in ensuring wiretapping. The seriousness of this kind of infraction only comes around once every few decades. Don't be fooled by the recent suggestions that Clipper will be put on hold! The root of the conflict is still untouched! >This single >quotation will be enormously useful in getting the legislature to take >specific and bill-oriented action about the wiretap chips. In the >checks and balance system, the legislature makes laws; the executive >makes them happen. You seem to favor a legislative approach to protecting cryptography. Well, all I can say is that there are a lot of pitfalls. In my opinion a 200 year old scrap of paper is all the verbiage we need. There is nothing extremely unusual about cryptography from a legal standpoint. Its just another medium of data transmission. >The executive is not supposed to go charging off >and making de facto legislation. >The only >thing new about it is that it confirms what I've thought for over a >month: that the executive branch is trying to do an end run around the >legislature. I'm glad you came to this epiphany on the original, true treachery of the `initiative', but I'm sorry to say I don't share it. If by `executive' you are alluding to Clinton, clearly he had very little to do with it, and as I've said elsewhere on sci.crypt, his support is convenient but not necessary. Even Bush's involvement was surely extremely marginal at best. The *true* problem is that there is a massive entrenchment of inbred bureacrats at a site that has the initials F.M. that is completely insulated from the periodic cleansings of elections, devoid of overhead accountability and the venerable mechanisms for `checks and balances' and `division of power' in our government you cite, and paid tens of billions of dollars a year by *us* to find ways of *evading* protections on privacy and spying on the neighbors (friend and foe alike). They will not go away quietly. Ah, but as everyone knows, neither will I. BTW, could anyone give a reference on the FEAL politics history? It's just like deja vu all over again. From mdiehl at triton.unm.edu Tue Jun 8 21:46:47 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 8 Jun 93 21:46:47 PDT Subject: ALERT / My email address is... (fwd) Message-ID: <9306090446.AA22053@triton.unm.edu> > On Mon, 7 Jun 1993 22:18:16 -0600 (MDT), "J. Michael Diehl" wrote: > > > > We could set up aliases and distribute a common secret key for the list.... > > How are you going to do this securely? > Just a thought, We're not. I was very tired and was using my other, much smaller, brain to think with. ;^) I was (thinking?) of distributing a common secret key to people who we know are not spooks, and who would be interested in the cypherpunk's cause. This and anonymous remailers would ensure that anyone could say anything with total anonymity, since we would all share secret keys. The problem is, of course, that many people who would otherwise be interested, could not participate in our new clique. ;^( SO, DISREGUARD MY COMMENTS! Plz! +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Tue Jun 8 22:17:57 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 8 Jun 93 22:17:57 PDT Subject: McCarthy lives! In-Reply-To: <9306090050.AA03345@toad.com> Message-ID: <9306090517.AA22707@triton.unm.edu> According to John Gilmore: > Tim, I'll be glad to teach you how to file a Privacy Act request. > It's pretty simple, and it works on all Federal agencies. You get all > records they are keeping on you, with some limited exceptions -- and > for almost all of those, you get notified of the withholding. If you > can identify one or a small number of agencies that might be keeping > this "list", we can see if you are on it. And if we find the list, we > can probably get the whole thing under the Freedom of Information Act. I would think a quick tutorial on this would be of general interest. Could you find some time....? Thanx in advance. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Tue Jun 8 22:24:04 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 8 Jun 93 22:24:04 PDT Subject: ALERT / My email address is... In-Reply-To: <9306090240.AA08014@edev0.TFS> Message-ID: <9306090523.AA22828@triton.unm.edu> According to Peter Shipley: > >:) I suggest that we try to create an encrypted cypherpunks list? Comments? > >Sounds good to me. > the only use that whould bring is to get us to get more serious about > key extange and to develop easier software for reading/scaning encrypted > messages. On the other hand it would no benefit us in the way of that Yes, this is a much needed improvement in this group. > it would not us to get our messages and views to the world. (Last I > checked this was not a exclusive email list). I completely agree. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Tue Jun 8 23:53:47 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 8 Jun 93 23:53:47 PDT Subject: My Poll.... Message-ID: <9306090653.AA23961@triton.unm.edu> Well, I finally got to look at the responses to my poll. FYI, I got 33 replies. This is a small number considering there are (I think) 400+ people on this list. I didn't take the time to actually tally the results for each question. I'm inherently lazy... ;^) I can make some comments about what we use, tho. Note that the lists are in no particular order. Since this was certainly not a scientific poll, I opted to not include any statistics, sorry. I was kinda hoping to have a more homogeneous environment than what we have. Kinda naive, huh? Well, this is what I have to say after reading each of your replies. I would like to thank everyone who participated in my informal poll. I hope the results are usefull to any software-developer-cypherpunks out there. The systems that we use tended to be (IMHO) hi-end PC's, 386's and better. Macs were a close second, with various *nix's forming a large block. This isn't any suprise. The actuall list: PC, NCube, Sun, Mac, IBM RT, IBM RS/6000, DEC/MIPS, VAX, NeXT, HP 7xx, Cray, SGI Indigo, Amiga. As for OS's, MSDOS was, again, the clear winner. It would seem that many people are going from dos, to one of the various (free) unix's for the PC. I didn't know it was so widespread. The list: MSDOS, BSDI BSD/386, SunOS, A/UX, 4.3BSD, UNICOS, Ultrix, Linux, MacOS, HP/UX, NeXTStep, Solaris, AIX, System, IRIX, AmigaDos, vm, DESQview. There are more Cypherpunks who refuse to use online services than use them. Of those who do use online systems, and I counted bbs's and internet as an online system, these are the systems we use: The WELL, MCI, Prodigy, Compuserve, GEnie, AOL, BBSs, netcom, Internet, Fido. I didn't know there were so many mail readers..... SLMR, MH, pine, elm, emacs, Cyberdesk, Mush, NeXTMail, NUpop, GRn, QWK, Eudora, dxmail, LOCALLY DEVELOPED I was shocked to find that people still use pgp v2.1. Why? Also, unix pgp made a strong showing, considering it probably isn't very secure in that environment. The only versions mentioned are: 2.2, 2.1, MacPGP 2.1, unix. I know of other versions, tho. This poll was motivated by all of the talk about writing a secure comm program. Judging from how many different programs in use now, it will be hard to write a program which will please everybody. I also wonder if any of the telix users find telix to be very much like procomm; I did. Of the telix users, would you be interested in helping me test my mail scripts, and perhapse writing extensions for other mail readers, if needed? Hope to hear from you. Anyway, here is the list of the comm programs which we use: MacSamson, JComm, Term, QuickLink II, PPP/SLIP, Seyon, UUPC, Telix, Z-Term, procomm, Kermit, vlt, White Knight, Eudora, QModemPro, Procomm Plus, Telemate, tapcis. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From stig at netcom.com Wed Jun 9 01:43:09 1993 From: stig at netcom.com (Stig) Date: Wed, 9 Jun 93 01:43:09 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306082054.AA14005@dun-dun-noodles.aktis.com> Message-ID: <9306090843.AA10157@netcom.netcom.com> To quote: Marc Horowitz > "Do not attribute to malice that which can be adequately explained by > stupidity." Without support, I think CERT is merely being stupid. > Someone else (maybe even a government employee) is being malicious. I > do think cert is harming their effectiveness by doing this. My guess > is that they never stopped to think that someone might use them in > this way to shut down an "unpopular" ftp site. > Sounds like this thread is getting too soft on CERT: For soda, the mail went to someone at soda.... For Julf's machine, it went to his NETWORK PROVIDER. (This is not a courteous move, nor was it intended to be.) Stig /* Jonathan Stigelman, Stig at netcom.com, PGP public key by finger */ /* fingerprint = 32 DF B9 19 AE 28 D1 7A A3 9D 0B 1A 33 13 4D 7F */ From crunch at netcom.com Wed Jun 9 01:57:46 1993 From: crunch at netcom.com (John Draper) Date: Wed, 9 Jun 93 01:57:46 PDT Subject: Encrypting Cypherpunks mailing list postings Message-ID: <9306090858.AA08791@netcom4.netcom.com> Mikes response to the ideas of encrypting the Cypherpunks mailing list... >We're not. I was very tired and was using my other, much smaller, brain to >think with. ;^) I was (thinking?) of distributing a common secret key to people >who we know are not spooks, and who would be interested in the cypherpunk's >cause. I think it MAY be possible to write a perl program that would take the incoming mail encrypted with a single common public key for Cypherpunk mailing list mail, than would decrypt it internally, then for each person in the mailing list, using their public keys, encrypt each message for the individual recipients, and mail them out. Naturally this would be SLOWER THAN MOLASSIS!! But it would be worth a try to see how it works. Lets talk about it at the upcoming Cypherpunks meeting. The ravers can really use something like this to keep the Full Moon Raves location a secret and known ONLY to those dedicated ravers that want to attend. As far as the Cypherpunks mailing list goes, it may not be appropriate to encrypt to the group ALL the time, but SOME messages might be worthy of encryption. From clark at metal.psu.edu Wed Jun 9 05:42:19 1993 From: clark at metal.psu.edu (Clark Reynard) Date: Wed, 9 Jun 93 05:42:19 PDT Subject: CERT Message-ID: <9306091318.AA00472@metal.psu.edu> Marc Horowitz writes: >>> From: Clark Reynard >> Excepting the Morris Worm, can you name a SINGLE Computer Emergency >> which CERT has halted? It is simply an organization to keep the >> crypto-fascists wired into the net. >My experience with them in the past has been as a clearinghouse for >users to report security-related bugs to vendors, and for vendors to >provide fixed back to users. They've done an admirable job at this; >the major complaint is that they are too slow. They also help >distribute tools like COPS to validate unix workstation security. Granted. However, as you say, they are terribly slow and inefficient even at this. While I read CERT adisories and clippings, it is rare that I discover anything which could be called 'news.' >They are a proactive organization, not a reactive organization, so >it's meaningless to ask what "Computer Emergencies" CERT has "halted". Perhaps, then, their name is inappropriate. The term "Computer" seems to imply they are involved with computers. This is true. However, "Emergency," when modified by "Computer," seems to indicate that they are involved in some way with "Computer Emergencies," whatever this means. When combined with "Response," the previous terms seem to imply that they are intended to "Respond" to "Computer Emergencies," which, as you say, they don't do. They ought to change their name, or find some computer emergencies to which to respond. >I think that calling them "crypto-fascists" is at best an unsupported >smear, and at worst slanderous. A quibble: I believe you mean 'libellous.' They are crypto-fascists; that is to say, they are 'hidden' fascists. (However, I'll grant that calling them fascists is probably not productive, however amusing it may be.) [Peter Honeyman's comments deleted.] >I agree with Peter. If CERT is beginning to overstep its bounds. >perhaps someone should make a calm, rational complaint. I shall do so. Don't worry, I won't call them crypto-fascists. I shall forward it when I send it. ---- Robert W. F. Clark Stop the Clipper Chip rclark at nyx.cs.du.edu Proposal! clark at metal.psu.edu From AOLCHTNN at vax1.tcd.ie Wed Jun 9 06:20:05 1993 From: AOLCHTNN at vax1.tcd.ie (AOLCHTNN at vax1.tcd.ie) Date: Wed, 9 Jun 93 06:20:05 PDT Subject: Timothy C. May:superhacker Message-ID: <01GZ6EDS7DHK003YG5@vax1.tcd.ie> Why doesn't Tim and anyone else who suspects that they have reached the much-sought status of "superhacker on gov't files not just write to their local friendly federal government office and ask for a copy of their own records? As far as I know, the US freedom of information act allows anyone access to information about them that has been stored by the government. (I'm not a laywer and not even a US resident so don't quote me on any of this; but then I'm not charging legal fees either.) Of course any interesting information they've got is likely to be classified, but at least you'll find out whether any such information is stored on the files. Of course, requesting your own government file is likely to draw attention to yourself, so it's probably best not to do so unless you're sure that they already know that you know-that-they-know-something. Yours becoming increasingly paranoid by the minute, Antoin O Lachtnain, Trinity College, Dublin (Colaiste na Trinoide, Baile Atha Cliath) From hughes at soda.berkeley.edu Wed Jun 9 06:57:57 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 9 Jun 93 06:57:57 PDT Subject: a "great" NSA revelation In-Reply-To: <9306090424.AA02488@longs.lance.colostate.edu> Message-ID: <9306091354.AA00091@soda.berkeley.edu> >>This single >>quotation will be enormously useful in getting the legislature to take >>specific and bill-oriented action about the wiretap chips. >You seem to favor a legislative approach to protecting cryptography. >[...] In my opinion a 200 year old scrap of paper is all the >verbiage we need. Protecting cryptography must be fought on all fronts. If we disregard the legislature, we will lose. Period. The Constitution is the highest law of the land. As you may recall, it was ratified by state legislatures. Eric From rjones at salsa.abq.bdm.com Wed Jun 9 07:00:54 1993 From: rjones at salsa.abq.bdm.com (Ross E. Jones) Date: Wed, 9 Jun 93 07:00:54 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <28802.rjones@abq.bdm.com> In message Tue, 08 Jun 93 14:13:05 EDT, smb at research.att.com writes: > >Based on what you sent out, I confess that I see nothing wrong with >CERT's note. I agree that the rights of people who develop copyrighted software must be respected. This is fundamental to working in software development. My problem with the letter is that CERT did not verify the accusation before it was sent. Friend-to-friend this could be considered a "heads-up", but from a semi-official source such as CERT, this message takes on more of the characteristics of not-so-subtile arm twisting. It resulted in soda being closed down for a while to the detriment of all the users. Ross E Jones BDM, Federal rjones at abq.bdm.com Phone: (505) 848-5733 Fax: (505) 848-4047 From honey at citi.umich.edu Wed Jun 9 07:23:07 1993 From: honey at citi.umich.edu (Peter Honeyman) Date: Wed, 9 Jun 93 07:23:07 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306091423.AA01017@toad.com> > It resulted in soda being > closed down for a while to the detriment of all the users. very similar circumstances resulted in penet shutting down for a lengthy period; penet is still operating under severe restrictions. the cert letter could have produced the same result. interestingly, i believe the penet letter was sent to the same address as the earlier, infamous "famous net personality" letter. another coincidence? peter From dmandl at lehman.com Wed Jun 9 07:25:20 1993 From: dmandl at lehman.com (David Mandl) Date: Wed, 9 Jun 93 07:25:20 PDT Subject: Encrypting Cypherpunks mailing list postings Message-ID: <9306091424.AA17881@disvnm2.shearson.com> From: crunch at netcom.com (John Draper) > Mikes response to the ideas of encrypting the Cypherpunks mailing list... > > >I was (thinking?) of distributing a common secret key to > >people > >who we know are not spooks, and who would be interested in the cypherpunk's > >cause. > > I think it MAY be possible to write a perl program that would take the > incoming mail encrypted with a single common public key for Cypherpunk > mailing list mail, than would decrypt it internally, then for each > person in the mailing list, using their public keys, encrypt each > message for the individual recipients, and mail them out. But this is a PUBLIC LIST. Our readers from the NSA/FBI/CIA will get the messages along with everyone else--encrypted with their keys, of course, so no spies can read them! I just don't think any of this makes sense for a list this large and this open. Anyone can subscribe. For smaller circles of friends who know and trust one another, it would be more useful. BTW, wouldn't this all be easier using the "multiple recipients" feature of PGP anyway? This is exactly the kind of thing it was designed for: Server gets message, server multiply-encrypts to all subscribers, server distributes message the same way it does now. But again, I think this is pointless on a list like this. > The ravers can really use something like this to keep the Full Moon Raves > location a secret and known ONLY to those dedicated ravers that want to > attend. Yup. Agreed. This is exactly the kind of group that should be using PGP in this way. I do think that it would be a good idea to make an active effort to distribute and certify keys. This will also help to promote the use of encryption, which should be one of our main goals. Also: Making a sub-list of people who are "known not to be spooks," on a list like this, is dangerous. Would be nice if we could really do it, but there would almost certainly be agents getting included in the sub-list, as well as exclusions of folks who aren't agents. --Dave. From hughes at soda.berkeley.edu Wed Jun 9 07:31:36 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 9 Jun 93 07:31:36 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306090843.AA10157@netcom.netcom.com> Message-ID: <9306091428.AA00931@soda.berkeley.edu> >For soda, the mail went to someone at soda.... The first CERT letter was sent to a contact for the berkeley.edu domain, not to soda. This original recipient then forwarded the mail to root at soda, which is aliased to a number of people. The root who turned off the directory is not the same one who finally forwarded me the CERT letter. In short, they went over Julf's head, and they went over mine. Eric From hughes at soda.berkeley.edu Wed Jun 9 08:04:45 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 9 Jun 93 08:04:45 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <28802.rjones@abq.bdm.com> Message-ID: <9306091501.AA01867@soda.berkeley.edu> >It resulted in soda being >closed down for a while to the detriment of all the users. Before the rumor flies to far, soda was not closed down. One directory on the cypherpunks site was locked for less than a week. Had it not been for the intervention of a good friend who is also root on soda to do local politics, that directory might still be locked. The consequences could have been worse. Eric From poier at sfu.ca Wed Jun 9 09:24:49 1993 From: poier at sfu.ca (Skye Merlin Poier) Date: Wed, 9 Jun 93 09:24:49 PDT Subject: InfoWorld In-Reply-To: Message-ID: <9306091624.AA16331@malibu.sfu.ca> The FBI expects organized crime and terrorists to begin encoding information. Begin? Huh? Give me a break.... -- -----====> Skye Merlin Poier <====----- Undergrad in CMPT/MATH (Virtual Reality) |||| |||| email: poier at sfu.ca p-OO <--> OO-q THINK PGP Public Key available on finger \== ==/ From mmidboe at cs.uah.edu Wed Jun 9 10:31:53 1993 From: mmidboe at cs.uah.edu (Matt Midboe Computer Science Dept., Univ. of Alabama-Huntsville) Date: Wed, 9 Jun 93 10:31:53 PDT Subject: CryptoStacker and hiding the key In-Reply-To: Message-ID: <9306091731.AA28880@uahcs2.cs.uah.edu> -----BEGIN PGP SIGNED MESSAGE----- You could put the key in the unused sectors of the drive. Chkdsk will probably not like that at all, and I imagine some virus scanners. Virus scanners, there is another problem. Some of them would be useless wouldn't they, because I think they go around int 13h (since viruses can stealth around int 13h, right?) so you would need to tell people about that type of problem. But putting the key in the unused sectors still doesn't provide enough protection. What is the problem with just having a regular key file, and when the user boots up the computer it asks them a pass phrase to decrypt the key file? If they fail wipe the key and force the user to restore the key from a backup somewhere. d. saint -----BEGIN PGP SIGNATURE----- Version: 2.2 iQBVAgUBLBYeX1gV4u6tNx5/AQE66AIA1NVezgP2BkfZUpot6LMVEzciBDCfl1Kq d1QbgNpgK3OINAq/IhYimUMotE+oXng59fHJYeWf+/QINxBwPYfx0Q== =i8F7 -----END PGP SIGNATURE----- From karn at qualcomm.com Wed Jun 9 10:38:04 1993 From: karn at qualcomm.com (Phil Karn) Date: Wed, 9 Jun 93 10:38:04 PDT Subject: InfoWorld Message-ID: <9306091737.AA21998@servo> Well, to borrow Whit Diffie's great phrase, those of us who regularly conspire to participate in the political process are already encrypting... Phil From huntting at glarp.com Wed Jun 9 10:55:54 1993 From: huntting at glarp.com (Brad Huntting) Date: Wed, 9 Jun 93 10:55:54 PDT Subject: McCarthy lives! In-Reply-To: <9306090050.AA03345@toad.com> Message-ID: <199306091755.AA05395@misc.glarp.com> > Tim, I'll be glad to teach you how to file a Privacy Act request. > It's pretty simple, and it works on all Federal agencies. You get > all records they are keeping on you, with some limited exceptions -- > and for almost all of those, you get notified of the withholding. > If you can identify one or a small number of agencies that might > be keeping this "list", we can see if you are on it. And if we > find the list, we can probably get the whole thing under the Freedom > of Information Act. I'd be very interested in hearing more on this... brad From fnerd at smds.com Wed Jun 9 11:22:49 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Wed, 9 Jun 93 11:22:49 PDT Subject: Encrypting the list Message-ID: <9306091758.AA04012@smds.com> On encrypting the list, mostly I vote NO. The idea of "known non-spies" is, to say the least, a shakey one. Not the kind of concept you base security on. Also not the kind of psychological attitude and atmosphere that I want to be part of. "Are you one of US?" Stewart Brand says in the latest Whole Earth Review, that as soon as you become one of the people who knows the kinds of things that THEY want to know, then how do other people know that YOU aren't one of THEM? We're all prime suspects for being spies. I'd feel the most secure if everybody kept the content (not necessarily their true names) out in the open. Of course there's the fact that we want to be as inviting and easy-to-connect-to as possible to serious newcomers and potential friends. I count true spies and near-spies among the potential friends. I just don't want this to be, or seem like, a clique. It would be nice, however, to set up crypto I/O connection OPTIONS to the list, as an incentive for lazy people like me to figure out how to get PGP and mail filters set up. -fnerd quote me From jet at nas.nasa.gov Wed Jun 9 12:58:01 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Wed, 9 Jun 93 12:58:01 PDT Subject: Encrypting the list In-Reply-To: <9306091758.AA04012@smds.com> Message-ID: <9306091955.AA09779@boxer.nas.nasa.gov> FutureNerd Steve Witham writes: > We're all prime suspects for being spies. 'specially those of us with both .gov and .com email addresses, right? From geoffw at nexsys.net Wed Jun 9 13:15:33 1993 From: geoffw at nexsys.net (Geoff White) Date: Wed, 9 Jun 93 13:15:33 PDT Subject: Paranoid? PGP to the rescue!! Message-ID: <9306092002.AA25856@nexsys.nexsys.net> Rather then encrypting mailing list and stuff like that, the real solution for "sensitive info" is for EVERYBODY especially people who share a lot of sensitive info with each other, to get themselves PGP keys. Learn how to use PGP or some other form of encryption you will be better off for it, trust me, once this happens, then you can choose who YOU would like to send secure info to. So in other words, if I want to send the FMR instructions to Brian I can encrypt the info and send it. I actually wished he had a key while he was away because then I could send him a private message to any account, just in case he couldn't log into soda. PGP is abount sending secure information to friends and others, information that is private and that you don't want others to read. I would consider it rude to post an encrypted message to a public list unless it was an absolute emergency (i.e. the Thought Police are at my door, and they are going to take me away). The desimination of FMR info should be based on a personal system of trust, PGP is some software that helps you keep the integrity of the communications between TRUSTED members, it is NOT a substitute for that trust and if used as such, will quickly disapoint you, with potentially disasterous consequences for some people. (It's better to assume that "They" are listening and choose your words, then to believe that because you have encrypted your infomation it is safe for you to incriminate yourself and others.) With PGP, if the keys are not handled in a proper manner, it is no better than any normal private e-mail list. The only reason that I would advocate encryption of the FMR instructions is FOR PRACTICE i.e. (danger paranoid statements approaching :) in case the day comes when we will really need to send information that we don't want Them to know. The FMR info is not precious, we don't have much to loose except the party getting busted. But if we did encrypt the data and use that as a method of distribution to TRUSTED roots of the FMR phone tree (which could change from time to time, then If the FMRs are mysteriously busted it would mean one or more of the following: 1) One of the TRUSTED is an informant or cop. 2) One or more of the people on the phone tree (only people who meet visually) are informants or cops. 3) one of the above persons told the info to an informant or cop. 4) The cops "get lucky" 5) The promoters leak the info to someone who knows or who is an informant or cop. 6) The cops can "break" the PGP code (a SERIOUS problem for cypherpunks) It is my assumption that 1 -5 are the most likely, and of 1 - 5 3 - 5 are things that we have absolutely NO control over. So PGP will only help us to enforce 1 and 2, I don't know if all the trouble of going through the motions of PGP are worth it except for the FUN and mystique of it all, it might just draw more attention and make the authorities think that there is something more to it than it really is. I don't think this is a good idea. I think if individuals want to use PGP to send secure messages whether it is FMR info or resumes that should be between them. I think we should take this discussion offline (oh oh elitism strikes :) but everone knows what I mean by that, the people who have access to Future FMR info will I'm sure pledge to make sure that the info is distributed in a fair, secure and hopefully timely manner. Those of you who wish to find the Full Moon Rave, look to the skies, keep your ears peeled and make friends, it's not hard. - G ------------------------------------------------------------------------------- NEXUS SYSTEMS/CYBERTRIBE-5 : Voice:(415)965-2384 Fax: (415)327-6416 Editor/Instigator/Catalyst : Geoff White Production Crew : Universal Movement Trinity "They might stop the party, but they can't stop the future" --PGP Public key available upon request-- Paranoia - Your state of mind when you finally realize what's really going on. ------------------------------------------------------------------------------- From mark at cheops.anu.edu.au Wed Jun 9 15:20:21 1993 From: mark at cheops.anu.edu.au (Mark) Date: Wed, 9 Jun 93 15:20:21 PDT Subject: CERT reply regarding their emails Message-ID: <9306092220.AA15407@toad.com> Just got this: Forwarded message: >From mjw at cert.org Thu Jun 10 07:39:35 1993 >Message-Id: <9306092141.AA15453 at shuttle.cert.org> >To: mark at cheops.anu.edu.au >Cc: cert at cert.org >Subject: Re: Statement of dissatisfaction with your recent efforts >In-Reply-To: Your message of "Wed, 09 Jun 93 10:59:04 +1000." <9306090100.AA11648 at cert.org> >Date: Wed, 09 Jun 93 17:41:15 EDT >From: Moira J West > >Hello Mark, > We're sorry for any misunderstandings caused by our e-mail. >I have appended a copy of our follow-up to Berkeley on this issue. > >Regards >Moira > >Moira J. West >Technical Coordinator, Computer Emergency Response Team >Software Engineering Institute >Carnegie Mellon University >Pittsburgh, Pa. 15213-3890 > >Internet E-mail: cert at cert.org (monitored during business hours) >Telephone: (412) 268-7090 (answers 24 hour a day) > >---------------------------------------------------------------------- > >We've had a lot of feedback from various sites in response to our >e-mail to you last week referring to possible anonymous FTP abuse on >Berkeley hosts. > >We are concerned at the reaction that our e-mail caused. There's >obviously been a misunderstanding here and we wanted to follow-up with >you on this. There was certainly no intent on the part of CERT to >make accusations of any sort. We were simply trying to alert sites to >the possibility of activity that they might have concerns about. > >Our letter to you was one of many which we sent out to a number of >sites across the world in the form of an FYI of possible abuse of >their anonymous FTP areas. We had been receiving complaints from >sites about wide-scale trading of commercial software on their >writable anonymous FTP areas. During the process of helping sites to >secure their systems we were given copies of files left in abused >archives which indicated lists of hosts (and in some cases >directories) that intruders were using to trade of commercial >software. We chose to contact the sites so that they could check >their systems and take any steps that they thought appropriate. > >There were several reasons why we didn't attempt to verify the >information. There were a large number of hosts involved and with the >resources that we have available to us, it was not possible for us to >attempt to confirm the information on each host. In any case, we felt >it wouldn't be sufficient to check for specific directories or >filenames on an archive, the whole archive would need to be checked >for writable directories and then some verification of the contents of >those directories would need to take place. > >Previously, we have found that sites we contacted with this type of >information, did find writable areas which are being abused. In this >case some sites found such activity on their hosts, others stated that >the information was dated or incorrect. In hindsight, we see that it >would have been better for everyone concerned in this case if we had >undertaken some initial verification of the information or issued an >CERT advisory instead of the individual letters. > >As so many sites are potentially vulnerable to this activity and may >be unaware that it exists, we've decided to put together a CERT >advisory on the topic and hope to issue it in the near future. > >We're sorry if our original e-mail didn't clearly state our intentions >and was the cause of any misunderstandings. > >We'll follow-up with the various sites who have contacted us in regard >to our original e-mail to you, by passing them a copy of this letter. > >Regards >Moira > >Moira J. West >Technical Coordinator, Computer Emergency Response Team >Software Engineering Institute >Carnegie Mellon University >Pittsburgh, Pa. 15213-3890 > >Internet E-mail: cert at cert.org (monitored during business hours) >Telephone: (412) 268-7090 (answers 24 hour a day) -----------End of forwarded message Mark mark at cheops.anu.edu.au From nobody at soda.berkeley.edu Wed Jun 9 15:35:01 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Wed, 9 Jun 93 15:35:01 PDT Subject: Maclean's Article on privacy issues in Canada Message-ID: <9306092231.AA21926@soda.berkeley.edu> Without permission from Maclean's magazine (April 26, 1993) [Any errors are from my poor typing. Some emphasis added to replace italics in the original article.] Business (page 20) Preserving individual privacy New technology has made trafficking in personal data a huge industry Until Jan. 18, 1993, checking out licence plates was a $5-million-a-year business for the Ontario ministry of transportation. For a $5 fee, anyone could walk into their regional vehichle licensing bureau, fill in an application form and learn a wide range of details about a vehicle--including the owner's name and home address. According to ministry spokesman Anne McLaughlin, most people conducted searches for legitimate reasons: they wanted to know the history of a used car they were thinking about buying or they needed to track down a witness to an accident. But some searches clearly resulted in gross violations of privacy. In November, an Ottawa woman, who declined to be named, complained that a man found out where she lived by tracking her licence plates and asked to take here out. McLaughlin said that the ministry "was aware of a few of these situations" and, as a result, stopped providing names and addresses to the general public. Now, she said, the ministry will only provide that personal information for specific purposes, including court proceedings and police investigations. The collection, compilation and trafficking in personal data has become a huge industry: some privacy experts say that it is worth as much as $300 million a year in Canada. It has grown, in part, because rapidly evolving technologies, including telecommunications and computers, have simpily made it easy to do. Said Evan Hendricks, editor of "Privacy Times", a Washington-based newsletter that tracks privacy issues worldwide: "The paper trail has become the electronic trail." But as technology has become more pervasive, so has the sense that it is increasingly difficult to ensure that private matters remain private--as Premier Robert Bourassa's aides discovered during the referendum intercept of cellulas calls and the chatty Prince Charles and his lover Camilla Parker-Bowles now know. As a result, organizations ranging from the federal Office of the Privacy Commissioner to the Canadian Standards Association (CSA) and the Quebec government are taking a new look at the issue. At the heart of the matter is a delicate balancing act: the right of the individual to privacy versus the legitimate needs of government or business to gather information. Privacy advocates express concern, however, that it has become much too easy for organizations to gather, store, use and manipulate data about an individual. "The average Canadian's name is being crunched through various computers five to 10 times a day," said Bruce Phillips, the privacy commissioner of Canada and strong advocate of restraint on snooping. A joint study between several federal government departments and four private-sector organizations indicates that many Canadians share Phillips concern. In Privacy Revealed, a survey of 3,000 Canadians released late last month, 60 per cent daid that they have less personal privacy than they did a decade ago. Nevertheless, the trend towards collecting even greater amounts of data is bound to continue. The advertising and marketing industries are increasingly using consumer-profile data. Part of the reason is that companies need better information on targeting the fickle markets for consumer goods. At the same time, there is an increasing fragmentation in television. In the age of the TV zapper and the proliferation of cable TV channels, advertisers can no longer be certain that they are reaching their target audience. As a result, they are turning more often to other alternatives, including data-based direct-mail campaigns. To reduce the cost of mailings, direct marketers attempt to reach customers who have indicated an interest in a given area. S.I.R. Mail Order, for one, a Winnepeg-based firm specializing in hunting, fishing and camping equipment, rents its customer lists to others who want to attract rural subscribers. In December, Quebec became the first jurisdiction in North America to attemp to regulate personal information in the hands of the private sector when Communications Minister Lawrence Cannon introduced Bill 68. Although the federal government and most provinces have privacy acts, they apply only to information in government records. Still, many consumer advocates say that Quebec's proposed legislation, which should be in force by the end of June, does not go nearly far enough in protecting individual rights. On the other hand, some executives say that the bill places so many restrictions on how companies may share information with third parties that the bill will add greatly to the cost of gathering data. Said Jean-Claude Chartrand, chairman and chief executive officer of Montreal-based Equifax Canada Inc., the nation's largest credit bureau: "That will add to the cost of credit, which in the final analysis will cost the consumer." Several industry organizations in Canada have attempted on their own to deal with privacy concerns. The Canadian Bankers Association adopted a voluntary privacy code in 1990 that spells out how banks should collect, store and use customer information. Since 1990, Canada's six major chartered banks have inmplemented the code or devised their own. Still, the Royal Bank of Canada sparked controversy last month when it revealed that it sometimes included client-card numbers along with names, ages and addresses among the information sent to market-research firms that were testing demand for new products. Although a Royal Bank spokesman insisted that the practice was not an invasion of privacy, the bank has since stopped releasing client-card numbers for research purposes. Another industry group that has passed its own privacy code is the Toronto-based Canadian Direct Marketing Association. Effective next January, members must obtain a customer's permission before they sell or trade any information about that customer to a third party. Association members must provide customers with an easy mechanism, such as a box to check off on an order form, that allows them to remove their names from marketing lists before those lists are transferred to other marketers. Said association president John Gustavson: "This way, our customers can receive information on the things they want and avoid the stuff they don't want." On another front, the CSA, a Toronto-based nonprofit organization that has traditionally restricted itself to the safety testing and certifing of electrical appliances and other consumer products, is also turning its attention to privacy issues. In December, 1992, the CSA established a committe that will try to establish a standard to recommend to companies across Canada. David McKendry, head of the consumer affairs consulting practice with Price Waterhouse in Ottawa, is chairman of the committe, which also includes members from government, the private sector and consumer groups. He said that privacy is a logical issue for the CSA to tackle. "Safety is changing in the marketplace", McKendry said. "Privacy *is* a safety issue in the information age." Many privacy advocates say that they welcome attempts by various sectors to come to terms with privacy issues. At the same time, however, they note that Canadians still need more legal protection. "I'm all in favor of self-regulation," said David Flaherty, a Canadian professor of law and history, currently on sabbatical, at the Woodrow Wilson International Centre for Scholars in Washington. "But it doesn't have the force of law." Flaherty said that many Canadians are surprised to learn that they do not have a constitutional right to privacy. "The word 'privacy' is not in the Charter of Rights and Freedoms," he said. For his part, Privacy Commissioner Phillips, a former newspaper and television reporter, said that he agrees with Flaherty that privacy should be included in the Charter. "It would be a benchmark for the entire country," he said. Many experts, however, maintain that Canadians have adequate protection. Simon Chester, a lawyer with the Toronto firm McMillan Binch, said that there are better ways to protect individual's privacy than spelling it out in the Charter. The charter, which applies only to government and not the private sector, is too blunt an instrument, Chester said. "It is much more important to have specific specific legislation," he added. Equifax's Chartrand said that, as a result, his credit bureau operates its systems to meet the toughest standards in the country, which, he says, are usually Ontario's laws. That means, Chartrand said, that consumers across Canada enjoy the same level of protection, even if they are in the two provinces that have no consumer credit laws. Clearly, however, Canadians will continue to be concerned about whether technology has moved ahead faster than the law's ability to protect their privacy. Barbara Wickens From mdiehl at triton.unm.edu Wed Jun 9 16:57:33 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 9 Jun 93 16:57:33 PDT Subject: Encrypting the list In-Reply-To: <9306091758.AA04012@smds.com> Message-ID: <9306092357.AA00323@triton.unm.edu> According to FutureNerd Steve Witham: > On encrypting the list, mostly I vote NO. Well, I suggested it, so I guess I'll unsuggest it. This is a bad idea. I was tired when I perposed it. Lets leave this alone now, ok? ...other stuff deleted. > It would be nice, however, to set up crypto I/O connection > OPTIONS to the list, as an incentive for lazy people like me to > figure out how to get PGP and mail filters set up. Yes! +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From shipley at tfs.COM Wed Jun 9 17:21:42 1993 From: shipley at tfs.COM (Peter Shipley) Date: Wed, 9 Jun 93 17:21:42 PDT Subject: Encrypting the list In-Reply-To: <9306092357.AA00323@triton.unm.edu> Message-ID: <9306100018.AA10070@edev0.TFS> >> It would be nice, however, to set up crypto I/O connection >> OPTIONS to the list, as an incentive for lazy people like me to >> figure out how to get PGP and mail filters set up. > I also think it would be a good idea (and exercise) to have a cypto option to the list (where all my incoming email is PGP'ed ether with my key or a cypherpunk key. Again I state that this is more of an exercise for us then anything else. -Pete From hkhenson at cup.portal.com Wed Jun 9 22:49:26 1993 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Wed, 9 Jun 93 22:49:26 PDT Subject: CERT reply regarding their emails Message-ID: <9306092138.1.26702@cup.portal.com> Interesting response from CERT! I suspect that they will be more careful in sending out form letters to places where there could be edgy people. Keith From nobody at alumni.cco.caltech.edu Wed Jun 9 22:58:25 1993 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Wed, 9 Jun 93 22:58:25 PDT Subject: My poll.... Message-ID: <9306100557.AA01443@alumni.cco.caltech.edu> Uu> I was shocked to find that people still use pgp v2.1. I don't know where you've been, but version 2.2 has a notorious bug that locks up the box under numerous situations. In my experience, version 2.2 locks up 8088-based computers. Version 2.1 does not. There is an unauthorized bug fix version, 2.21. I use 2.2 as it runs well on my system. ********************************************************************* * - 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 <* ********************************************************************* ... Protect your right to privacy --- Say no to Clipper/Capstone! ___ 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 nobody at alumni.cco.caltech.edu Thu Jun 10 00:05:02 1993 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Thu, 10 Jun 93 00:05:02 PDT Subject: My poll.... Message-ID: <9306100703.AA02027@alumni.cco.caltech.edu> Uu> I was shocked to find that people still use pgp v2.1. I don't know where you've been, but version 2.2 has a notorious bug that locks up the box under numerous situations. In my experience, version 2.2 locks up 8088-based computers. Version 2.1 does not. There is an unauthorized bug fix version, 2.21. I use 2.2 as it runs well on my system. ********************************************************************* * - 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 mdiehl at triton.unm.edu Thu Jun 10 01:01:11 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Thu, 10 Jun 93 01:01:11 PDT Subject: My poll.... In-Reply-To: <9306100557.AA01443@alumni.cco.caltech.edu> Message-ID: <9306100801.AA11287@triton.unm.edu> According to nobody at alumni.cco.caltech.edu: > > Uu> I was shocked to find that people still use pgp v2.1. > > I don't know where you've been, but version 2.2 has a notorious bug > that locks up the box under numerous situations. In my experience, Been reading this list for some time now; never heard of this bug. Thanx. > version 2.2 locks up 8088-based computers. Version 2.1 does not. > There is an unauthorized bug fix version, 2.21. I use 2.2 as it runs > well on my system. Well, now I know. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From rclark at nyx.cs.du.edu Thu Jun 10 04:46:52 1993 From: rclark at nyx.cs.du.edu (Robert W. F. Clark) Date: Thu, 10 Jun 93 04:46:52 PDT Subject: Forward of my message to CERT Message-ID: <9306101147.AA20953@nyx.cs.du.edu> Dear Moira, I was somewhat disturbed to note the recent actions of CERT with regard to Johan Helsingius' site anon.penet.fi; and with regard to the cypherpunks' archive at soda.berkeley.edu. I read a clarification of your position which appeared to regret any inconvenience these actions and others may have caused, it still seemed that you do not intend to exercise any more caution in the phrasing of your message. While the message disclaims that you have verified the information included in it, it still bears the phrasing of an accusation, not an advisory. While it is certainly laudable to bring potential security problems to the attention of system administrators and users, the method in which this was done, and those to whom you mentioned it, cause me serious doubts as to the effectiveness of your actions. In the first case, that of Johann Helsingius, you did not notify the system administrator but the domain manager for all Finland. Not only is the domain manager in no position to patch potential security holes in a local system, but additionally he probably has more important tasks than checking out false reports. Allegations were made by an unnamed officer of CERT that the site was illegally distributing software by anonymous ftp; whereas, even the most rudimentary efforts at verification would have revealed that the site in question does not operate anonymous ftp. It is neither sensible nor equitable to contact a domain administrator without even contacting the administrator of the questionable system; especially the domain administrator of an entire sovereign nation. Certainly, if CERT can not even bother to take the time of even a preliminary verification of their reports before announcing them, certainly it seems to be an imposition to demand that the domain administrator of an entire country spend time investigating spurious reports. If there is suspicion that a particular machine has been compromised, and is thus an insecure method of contacting the administrator, perhaps contacting the administrator by postal mail or by telephone would be more sensible than contacting the administrator of all the machines in Finland. Certainly if the machine itself is compromised, it is quite possible that the entire domain is also compromised, and email may be insecure and easily available to hostile third parties. With the additional implication in the ominous form letter you mail that the person responsible for the machine may be involved in illegal activities, the potential for abuse of CERT by people filing false reports is, though perhaps not in itself a "computer emergency," is certainly something which you ought to consider in your standard procedures. As sites which use TCP/IP without providing for authentication are considered security holes, so is a Computer Emergency Response Team which does the same thing, that is, simply relays accusations without any authentication of their veracity. Considering the possible damage to the reputations of persons not involved in illegal activity, and the disruption of services which results when such accusations are made, actions of this sort are retrogressive and represent as significant a threat to the systems as would a 'denial of service' attack. Please be more careful in the future when relaying such messages. ---- Robert W. F. Clark rclark at nyx.cs.du.edu From rclark at nyx.cs.du.edu Thu Jun 10 04:47:44 1993 From: rclark at nyx.cs.du.edu (Robert W. F. Clark) Date: Thu, 10 Jun 93 04:47:44 PDT Subject: CryptoStacker (Key storage) Message-ID: <9306101147.AA20987@nyx.cs.du.edu> mmidboe at uahcs2.cs.uah.edu (Matt Midboe) writes: >What is the problem with just having a regular key file, and when >the user boots up the computer it asks them a pass phrase to decrypt the key >file? If they fail wipe the key and force the user to restore the key from a >backup somewhere. The problem with this is that a hostile third party who has captured a machine will first make a backup of all files on the system, including the key. It is very likely that the party will bypass the initial bootup procedure in which the key is requested, since the hostile party expects some sort of 'data bomb,' having been involved with systems confiscation for quite some time. While there are some options available, such as disallowing bootups from floppy, these are in the main cheap hacks not to be trusted for security. In this case, when the system is booted and the key is requested, even if the key is wiped, they simply restore it from backup and try again. They are likely to keep the system for several months, so they will have time to conquer any 'toy-grade' security. While it is not yet standard procedure to make a snapshot of the system memory when confiscating systems, the increasing cleverness of law enforcement and other bodies makes this seem likely in the future. So you can't have the key on the disk, nor can you have it hanging around in cleartext in memory except when encrypted data is accessed; preferably, the key should be encrypted, and on some fragile (i. e., easily destroyable) media. Any backups should be encrypted, and not easily accessible; preferably with a trusted party and not in the same building as the computer with encrypted information. ---- Robert W. F. Clark "Be sand, not oil, in the rclark at nyx.cs.du.edu machinery of the world." Gunter Eich From banisar at washofc.cpsr.org Thu Jun 10 05:09:23 1993 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Thu, 10 Jun 93 05:09:23 PDT Subject: Markey Clipper Hearing 6/9 and CPSR Testimony Message-ID: <9306100817.AA34158@hacker2.eff.org> On June 9, 1993, Congressman Edward Markey, Chairman of the House Subcommittee on Telecommunications and Finance held an oversight hearing on "encryption and telecommunications network security." Panelists were Whitfield Diffie of Sun Microsystems, Dr. Dorothy Denning, Steven Bryen of Secure Communications, Marc Rotenberg of the CPSR Washington Office and E.R. Kerkeslager of AT&T. Congressman Markey, after hearing the testimony presented, noted that the Clipper proposal had raised an "arched eyebrow among the whole committee" and that the committee viewed the proposal skeptically. This statement was the latest indication that the Clipper proposal has not been well recieved by policy makers. Last Friday, the Computer Systems Security and Privacy Advisory Board of NIST issued two resolutions critical of the encryption plan, suggesting that further study was required and that implementation of the plan should be delayed until the review is completed. At the Third CPSR Cryptography and Privacy Conference on Monday, June 7, the Acting Director of NIST, Raymond Kammer, announced that the implementation of the proposal will be delayed and that a more comprehensive review will be undertaken. The review is due in the fall. Kammer told the Washington Post that "maybe we won't continue in the direction we started out." ------------------------------------------------------------------------------ Prepared Testimony and Statement for the Record of Marc Rotenberg, director CPSR Washington Office on Encryption Technology and Policy Before The Subcommittee on Telecommunications and Finance. Committee on Energy and Commerce U.S. House of Representatives June 9, 1993 SUMMARY The cryptography issue is of particular concern to CPSR. During the past several years CPSR has pursued an extensive study of cryptography policy in the United States. CPSR has organized public conferences, conducted litigation under the Freedom of Information Act, and has emphasized the importance of cryptography for privacy protection and the need to scrutinize carefully government proposals designed to limit the use of this technology. To evaluate the Clipper proposal it is necessary to look at a 1987 law, the Computer Security Act, which made clear that in the area of unclassified computing systems, the National Institute of Standards and Technology (NIST) and not the National Security Agency (NSA), would be responsible for the development of technical standards. The Act emphasized public accountability and stressed open decision-making. In the spirit of the Act, in 1989 NIST set out to develop a public key cryptography standard. According to documents obtained by CPSR through the Freedom of Information Act, NIST recommended that the algorithm be "public, unclassified, implementable in both hardware or software, usable by federal Agencies and U.S. based multi-national corporation." However, the Clipper proposal and the full-blown Capstone configuration that resulted is very different: the Clipper algorithm, Skipjack, is classified; public access to the reasons underlying the proposal is restricted; Skipjack can be implemented only in tamper-proof hardware; it is unlikely to be used by multi- national corporations, and the security of Clipper remains unproven. The Clipper proposal undermines the central purpose of the Computer Security Act. Although intended for broad use in commercial networks, it was not developed at the request of either U.S. business or the general public. It does not reflect public goals. The premise of the Clipper key escrow arrangement is that the government must have the ability to intercept electronic communications. However, there is no legal basis to support this premise. In law there is nothing inherently illegal or suspect about the use of a telephone. The federal wiretap statute says only that communication service providers must assist law enforcement execute a lawful warrant. CPSR supports the review of cryptography policy currently underway at the Department of Commerce. CPSR also supports the efforts undertaken by the Subcommittee on Telecommunications and Finance to study the full ramifications of the Clipper proposal. However, we are not pleased about the review now being undertaken at the White House. That effort has led to a series of secret meetings, has asked that scientists sign non-disclosure agreements and accept restrictions on publication, and has attempted to resolve public concerns through private channels. This is not a good process for the evaluation of a technology that is proposed for the public switched network. Even if the issues regarding Clipper are resolved favorably, privacy concerns will not go away. Rules still need to be developed about the collection and use of transactional data generated by computer communications. Several specific steps should be taken. First, the FCC should be given a broad mandate to pursue privacy concerns. Second, current gaps in the communications law should be filled. The protection of transactional records is particularly important. Third, telecommunications companies should be encouraged to explore innovative ways to protect privacy. "Telephone cards", widely available in other countries, are an ideal way to protect privacy. ---------------------------------- TESTIMONY Mr. Chairman, members of the Subcommittee, thank you for the opportunity to testify today on encryption policy and the Clipper proposal. I especially wish to thank you Congressman Markey, on behalf of CPSR, for your ongoing efforts on the privacy front as well as your work to promote public access to electronic information. The cryptography issue is of particular concern to CPSR. During the past several years we have pursued an extensive study of cryptography policy in the United States. We have organized several public conferences, conducted litigation under the Freedom of Information Act, and appeared on a number of panels to discuss the importance of cryptography for privacy protection and the need to scrutinize carefully government proposals designed to limit the use of this technology. While we do not represent any particular computer company or trade association we do speak for a great many people in the computer profession who value privacy and are concerned about the government's Clipper initiative. Today I will briefly summarize our assessment of the Clipper proposal. Then I would like to say a few words about the current status of privacy protection. CLIPPER To put the Clipper proposal in a policy context, I will need to briefly to describe a law passed in 1987 intended to address the roles of the Department of Commerce and the Department of Defense in the development of technical standards. The Computer Security Act of 1987 was enacted to improve computer security in the federal government, to clarify the responsibilities of the National Institute of Standards and Technology (NIST) and the National Security Agency, and to ensure that technical standards would serve civilian and commercial needs. The law made clear that in the area of unclassified computing systems, NIST and not NSA, would be responsible for the development of technical standards. It emphasized public accountability and stressed open decision-making. The Computer Security Act also established the Computer System Security and Privacy Advisory Board (CSSPAB), charged with reviewing the activities of NIST and ensuring that the mandate of the law was enforced. The Computer Security Act grew out of a concern that classified standards and secret meetings would not serve the interests of the general public. As the practical applications for cryptography have moved from the military and intelligence arenas to the commercial sphere, this point has become clear. There is also clearly a conflict of interest when an agency tasked with signal interception is also given authority to develop standards for network security. In the spirit of the Computer Security Act, NIST set out in 1989 to develop a public key standard FIPS (Federal Information Processing Standard). In a memo dated May 5, 1989, obtained by CPSR through the Freedom of Information Act, NIST said that it planned: to develop the necessary public-key based security standards. We require a public-key algorithm for calculating digital signatures and we also require a public-key algorithm for distributing secret keys. NIST then went on to define the requirements of the standard: The algorithms that we use must be public, unclassified, implementable in both hardware or software, usable by federal Agencies and U.S. based multi- national corporation, and must provide a level of security sufficient for the protection of unclassified, sensitive information and commercial propriety and/or valuable information. The Clipper proposal and the full-blown Capstone configuration, which incorporates the key management function NIST set out to develop in 1989, is very different from the one originally conceived by NIST. % The Clipper algorithm, Skipjack, is classified, % Public access to the reasons underlying the proposal is restricted, % Skipjack can be implemented only in tamper-proof hardware, % It is unlikely to be used by multi-national corporations, and % The security of Clipper remains unproven. The Clipper proposal undermines the central purpose of the Computer Security Act. Although intended for broad use in commercial networks, it was not developed at the request of either U.S. business or the general public. It does not reflect public goals. Rather it reflects the interests of one secret agency with the authority to conduct foreign signal intelligence and another government agency responsible for law enforcement investigations. Documents obtained by CPSR through the Freedom of Information Act indicate that the National Security Agency dominated the meetings of the joint NIST/NSA Technical Working group which made recommendations to NIST regarding public key cryptography, and that a related technical standard for message authentication, the Digital Signature Standard, clearly reflected the interests of the NSA. We are still trying to determine the precise role of the NSA in the development of the Clipper proposal. We would be pleased to provide to the Subcommittee whatever materials we obtain. LEGAL AND POLICY ISSUES There are also several legal and constitutional issues raised by the government's key escrow proposal. The premise of the Clipper key escrow arrangement is that the government must have the ability to intercept electronic communications, regardless of the economic or societal costs. The FBI's Digital Telephony proposal, and the earlier Senate bill 266, were based on the same assumption. There are a number of arguments made in defense of this position: that privacy rights and law enforcement needs must be balanced, or that the government will be unable to conduct criminal investigations without this capability. Regardless of how one views these various claims, there is one point about the law that should be made very clear: currently there is no legal basis -- in statute, the Constitution or anywhere else -- that supports the premise which underlies the Clipper proposal. As the law currently stands, surveillance is not a design goal. General Motors would have a stronger legal basis for building cars that could go no faster than 65 miles per hour than AT&T does in marketing a commercial telephone that has a built-in wiretap capability. In law there is simply nothing about the use of a telephone that is inherently illegal or suspect. The federal wiretap statute says only that communication service providers must assist law enforcement in the execution of a lawful warrant. It does not say that anyone is obligated to design systems to facilitate future wire surveillance. That distinction is the difference between countries that restrict wire surveillance to narrow circumstances defined in law and those that treat all users of the telephone network as potential criminals. U.S. law takes the first approach. Countries such as the former East Germany took the second approach. The use of the phone system by citizens was considered inherently suspect and for that reason more than 10,000 people were employed by the East German government to listen in on telephone calls. It is precisely because the wiretap statute does not contain the obligation to incorporate surveillance capability -- the design premise of the Clipper proposal -- that the Federal Bureau of Investigation introduced the Digital Telephony legislation. But that legislation has not moved forward and the law has remained unchanged. The Clipper proposal attempts to accomplish through the standard-setting and procurement process what the Congress has been unwilling to do through the legislative process. On legal grounds, adopting the Clipper would be a mistake. There is an important policy goal underlying the wiretap law. The Fourth Amendment and the federal wiretap statute do not so much balance competing interests as they erect barriers against government excess and define the proper scope of criminal investigation. The purpose of the federal wiretap law is to restrict the government, it is not to coerce the public. Therefore, if the government endorses the Clipper proposal, it will undermine the basic philosophy of the federal wiretap law and the fundamental values embodied in the Constitution. It will establish a technical mechanism for signal interception based on a premise that has no legal foundation. The assumption underlying the Clipper proposal is more compatible with the practice of telephone surveillance in the former East Germany than it is with the narrowly limited circumstances that wire surveillance has been allowed in the United States. UNANSWERED QUESTIONS There are a number of other legal issues that have not been adequately considered by the proponents of the key escrow arrangement that the Subcommittee should examine. First, not all lawful wiretaps follow a normal warrant process. The proponents of Clipper should make clear how emergency wiretaps will be conducted before the proposal goes forward. Second, there may be civil liability issues for the escrow agents, if they are private parties, if there is abuse or compromise of the keys. Third, there is a Fifth Amendment dimension to the proposed escrow key arrangement if a network user is compelled to disclose his or her key to the government in order to access a communications network. Each one of these issues should be examined carefully. CPSR CONFERENCE At a conference organized by CPSR this week at the Carnegie Endowment for International Peace we heard presentations from staff members at NIST, FBI, NSA and the White House about the Clipper proposal. The participants at the meeting had the opportunity to ask questions and to exchange views. Certain points now seem clear: % The Clipper proposal was not developed in response to any perceived public or business need. It was developed solely to address a law enforcement concern. % Wire surveillance remains a small part of law enforcement investigations. The number of arrests resulting from wiretaps has remained essentially unchanged since the federal wiretap law was enacted in 1968. % The potential risks of the Clipper proposal have not been assessed and many questions about the implementation remain unanswered. % Clipper does not appear to have the support of the business or research community. Many comments on the Clipper proposal, both positive and negative as well the materials obtained by CPSR through the Freedom of Information Act, are contained in the Source book compiled by CPSR for the recent conference. I am please to make a copy of this available to the Subcommittee. NETWORK PRIVACY PROTECTION Communications privacy remains a critical test for network development. Networks that do not provide a high degree of privacy are clearly less useful to network users. Given the choice between a cryptography product without a key escrow and one with a key escrow, it would be difficult to find a user who would prefer the key escrow requirement. If this proposal does go forward, it will not be because network users or commercial service providers favored it. Even if the issues regarding the Clipper are resolved favorably, privacy concerns will not go away. Cryptography is a part of communications privacy, but it is only a small part. Rules still need to be developed about the collection and use of transactional data generated by computer communications. While the federal wiretap law generally does a very good job of protecting the content of communications against interception by government agencies, large holes still remain. The extensive use of subpoenas by the government to obtain toll records and the sale of telephone records by private companies are just two examples of gaps in current law. The enforcement of privacy laws is also a particularly serious concern in the United States. Good laws without clear mechanisms for enforcement raise over-arching questions about the adequacy of legal protections in this country. This problem is known to those who have followed developments with the Privacy Act since passage in 1974 and the more recent Video Privacy and Protection Act of 1988. I make this point because it has been the experience in other countries that agencies charged with the responsibility for privacy protection can be effective advocates for the public in the protection of personal privacy. RECOMMENDATIONS Regarding the Clipper proposal, we believe that the national review currently underway by the Computer Security and Privacy Advisory Board at the Department of Commerce will be extremely useful and we look forward to the results of that effort. The Panel has already conducted a series of important open hearings and compiled useful materials on Clipper and cryptography policy for public review. We are also pleased that the Subcommittee on Telecommunications and Finance has undertaken this hearing. This Subcommittee can play a particularly important role in the resolution of these issues. We also appreciate the Chairman's efforts to ensure that the proper studies are undertaken, that the General Accounting Office fully explores these issues, and that the Secretary of Commerce carefully assesses the potential impact of the Clipper proposal on export policy. We are, however, less pleased about the White House study currently underway. That effort, organized in large part by the National Security Council, has led to a series of secret meetings, has asked that scientists sign non-disclosure agreements and accept restrictions on publication, and has attempted to resolve public concerns through private channels. This is not a good process for the evaluation of a technology that is proposed for the public switched network. While we acknowledge that the White House has been reasonably forthcoming in explaining the current state of affairs, we do not think that this process is a good one. For these reasons, we believe that the White House should properly defer to the recommendations of the Computer System Security and Privacy Advisory Board and the Subcommittee on Telecommunications and Finance. We hope that no further steps in support of the Clipper initiative will be taken. We specifically recommend that no further purchase of Clipper chips be approved. Speaking more generally, we believe that a number of steps could be taken to ensure that future communications initiatives could properly be viewed as a boost to privacy and not a set-back. % The FCC must be given a strong mandate to pursue privacy concerns. There should be an office specifically established to examine privacy issues and to prepare reports. Similar efforts in other countries have been enormously successful. The Japanese Ministry of Post and Telecommunications developed a set of privacy principles to ensure continued trade with Europe. The Canada Ministry of Communications developed a set of communications principles to address public concerns about the privacy of cellular communications. In Europe, the EC put forward an important directive on privacy protection for the development of new network services. % Current gaps in the communications law should be filled. The protection of transactional records is particularly important. Legislation is needed to limit law enforcement access to toll record information and to restrict the sale of data generated by the use of telecommunication services. As the network becomes digital, the transaction records associated with a particular communication may become more valuable than the content of the communication itself. % Telecommunications companies should be encouraged to explore innovative ways to protect privacy. Cryptography is a particular method to seal electronic communications, but far more important for routine communications could be anonymous telephone cards, similar to the metro cards here in the District of Columbia, that allow consumers to purchase services without establishing accounts, transferring personal data, or recording personal activities. Such cards are widely available in Europe, Japan, and Australia. I thank you very much for the opportunity to appear before the Subcommittee and would be pleased to answer your questions Computer Professionals for Social Responsibility CPSR is a national membership organization, established in 1982, to address the social impact of computer technology. There are 2,500 members in 20 chapters across the United States, and offices in Palo Alto, California, Cambridge, Massachusetts, and Washington DC. The organization is governed by a board of elected officers and meetings are open to the public. CPSR sponsors an annual meeting and the biennial conference on Directions and Implications of Advanced Computing. CPSR sponsored the first conference on Computers, Freedom, and Privacy in 1991. CPSR also operates the Internet Library at cpsr.org. The library contains documents from the White House on technology policy and a wide range of public laws covering privacy, access to information, and communications law and is available free of charge to all users of the Internet. Marc Rotenberg is the director of the CPSR Washington office and an adjunct professor at Georgetown University Law Center. He is chairman of the ACM Committee on Scientific Freedom and Human Rights, an editor for the Computer Law and Security Report (London), and the secretary of Privacy International, an organization of human rights advocates and privacy scholars in forty countries. He received an A.B. from Harvard College and a J.D. from Stanford Law School, and is a member of the bar of the United States Supreme Court. His forthcoming article "Communications Privacy: Implications for Network Design" will appear in the August 1993 issue of Communications of the ACM. From 74076.1041 at CompuServe.COM Thu Jun 10 07:38:15 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Thu, 10 Jun 93 07:38:15 PDT Subject: Encrypting the list Message-ID: <930610142951_74076.1041_FHD65-1@CompuServe.COM> To: cypherpunks at toad.com If we could encrypt the list, and if we could subscribe via Julf's remailer or get our remailers to accept address aliases of some sort, then list subscribers could have "local" privacy. Local sysops and roots would not be able to see our incoming mail, and would not see that we were subscribing to a group like "cypherpunks". My long-term goal would be to have all mail be encrypted, and all mail be sent via anonymous remailers (or equivalent technology), so that the content and routing of our messages is truly private. Hal 74076.1041 at compuserve.com From rwhelan at mason1.gmu.edu Thu Jun 10 08:53:32 1993 From: rwhelan at mason1.gmu.edu (Robert J. Oot) Date: Thu, 10 Jun 93 08:53:32 PDT Subject: My poll.... In-Reply-To: <9306100801.AA11287@triton.unm.edu> Message-ID: <9306101553.AA29767@mason1.gmu.edu> > > Uu> I was shocked to find that people still use pgp v2.1. > > I don't know where you've been, but version 2.2 has a notorious bug > > that locks up the box under numerous situations. In my experience, > Been reading this list for some time now; never heard of this bug. Thanx. > > version 2.2 locks up 8088-based computers. Version 2.1 does not. ^^^^^^^^^^^^^^^^^^^^ > > There is an unauthorized bug fix version, 2.21. I use 2.2 as it runs > > well on my system. > > Well, now I know. I was not aware that people still used that version of a computer. An 8088???? -- Ryan A. Whelan "Only two good things came out of Berkeley, LSD and BSD, rwhelan at mason1.gmu.edu rwhelan at cosmos.gmu.edu coincidence???" rwhelan at gmuvax.gmu.edu PGP Public Key available via finger "If its not UNIX, its crap" From julf at penet.FI Thu Jun 10 10:09:16 1993 From: julf at penet.FI (Johan Helsingius) Date: Thu, 10 Jun 93 10:09:16 PDT Subject: CERT: the letter from CERT to berkeley.edu admin In-Reply-To: <9306091423.AA01017@toad.com> Message-ID: <9306101732.aa19627@penet.penet.FI> > interestingly, i believe the penet letter was sent to the same address > as the earlier, infamous "famous net personality" letter. Yes, it was. Julf From cir at access.digex.net Thu Jun 10 10:13:30 1993 From: cir at access.digex.net (Jeff Ubois) Date: Thu, 10 Jun 93 10:13:30 PDT Subject: crypto print drivers for email Message-ID: <199306101713.AA00144@access.digex.net> Forgive me if I've missed it on alt.security.pgp, but what would people think of implementing PGP or other crypto schemes using a print driver ? A model could be some of the fax software that lets you fax directly from other applications by issuing a print command. These packages have print drivers that let you enter the name and phone number of the person you are faxing, or select a name from an address book after you give the print command. You can also select high or low resolution, what kinds of headers you want added to the message, and make file attachments. This is a very easy way to send faxes, and seems like it would be an easy way to create and send encrypted messages too. For persons who aren't technically adept, this would be a lot simpler than say pem -e -r recipient at bighost.edu -p bigpubkeyfile -s mysecret or even PGP equivalents. --Jeff From hughes at soda.berkeley.edu Thu Jun 10 10:13:52 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 10 Jun 93 10:13:52 PDT Subject: Encrypting the list In-Reply-To: <9306092357.AA00323@triton.unm.edu> Message-ID: <9306101710.AA13192@soda.berkeley.edu> Summary: Encrypting the cypherpunks list make no difference in the security of information dispersal, but may make a large difference in local security and as a spur to software development. >> It would be nice, however, to set up crypto I/O connection >> OPTIONS to the list, as an incentive for lazy people like me to >> figure out how to get PGP and mail filters set up. >Yes! Michael, here is a word from your friendly neighborhood list maintainer. I don't have time to work on this, and neither to the people who run toad.com. So it's not going to happen on toad for a while. The good news is that it doesn't have to. You yourself can write the code! The code for the existing cypherpunks remailer is all you need to get started. Here's how. You subscribe to cypherpunks and then forward the list mail, encrypted, to all the people who have subscribed with you for an encrypted version of the cypherpunks mail. With the cypherpunks remailer, you can do all this with your own account. It is a pretty good skeleton for the creation of email servers out of user accounts. You don't need your sysadmin's cooperation to get it running, although you may need their blessing to keep it running. You can implement a listserv type operation if you want, with automatic subscribe/unsubscribe and add all the options you want to it. You'll have to deal with the bounce messages, of course, but you can rwrite software to deal with that. Someone who wants to provide digest service can to a similar thing for digestification. There have been lots of people over the course of the list history who have wanted encryption and digests. I would suggest that those who want them convince someone to run a secondary service to provide them with these services. Eric From ee92jks at brunel.ac.uk Thu Jun 10 11:07:37 1993 From: ee92jks at brunel.ac.uk (Jonathan K Saville) Date: Thu, 10 Jun 93 11:07:37 PDT Subject: CryptoStacker Update Message-ID: <18312.9306101807@monge.brunel.ac.uk> Re: possible problems with INT13 I may be mistaken, but I have this feeling that DPMI servers (including MS Windows) react unkindly to people using INT13. This is certainly what the Borland Open Architecture handbook says. If your program is resident when such a server is running, it could throw up a General Protection fault. I will check into this myself... -- # Jon Saville | Who alive can say, 'Thou art no John Keats # ee92jks at brunel.ac.uk | Poet, may'st not tell thy dreams?' 1819 PGP 2.2 public key available upon request From tispem-support at TIS.COM Thu Jun 10 13:24:42 1993 From: tispem-support at TIS.COM (Mark S Feldman) Date: Thu, 10 Jun 93 13:24:42 PDT Subject: TIS/PEM FAQ as of 8 June 1993 In-Reply-To: <9306090337.AA02019@longs.lance.colostate.edu> Message-ID: <9306102025.AA00847@TIS.COM> -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh HbGVud29vZA==,06 MIC-Info: RSA-MD5,RSA,EMzvB0taB3V9fReB4tnloOKIfTeWTa6vIoJ7nM5WuSM UfXytoaJleK/JNTLRxKKhR+rhSL7zORq3d/TnaDV0c2YzvF8UJ1YLl+PheYhQg3D +ylKoRuzlGHJeNj5Mor/G > do you have any plans to get this on news.answers? It would be great > there. Also, You should consider sci.crypt. I can help you with either > if you need it. Thanks. Hadn't thought about news.answers. I thought that we did post it to sci.crypt, though. Regardless, we'll re-evaluate the news groups that we use the next time we post the FAQ. Mark -----END PRIVACY-ENHANCED MESSAGE----- From eichin at cygnus.com Thu Jun 10 13:31:10 1993 From: eichin at cygnus.com (Mark Eichin) Date: Thu, 10 Jun 93 13:31:10 PDT Subject: query... In-Reply-To: <9306102009.AA27673@snark.shearson.com> Message-ID: <9306102030.AA07054@cygnus.com> A query -- I understand that the MIT Athena people implemented a DES encrypted telnet/telnetd for use with Kerberos. Anyone out there know where its sources live and how I could hack it to take a user specified DES key? Perry The first one was done by Paul Borman at Cray. A snapshot was up for FTP on uunet (named telnet.91.03.25.tar.Z) though I don't know what was done with it; the authentication and encryption options draft standard that it conformed to has been modified since then, although all of the implementations (such as the utexas version for the Mac) I've seen so far conform to Borman's version. It shouldn't be too hard to specify a key (of course you have the problem of securely getting the key to the other end of the connection -- that is, after all, one of the major side-benefits of Kerberos...) The last release of Kerberos from MIT included a "kstream" library, written by Ken Raeburn, which could be dropped in to an existing telnet or kermit or other application to provide this kind of feature. There is also Derek Atkins' S.B. Thesis project, which included modifications to telnet for accessing Kerberos via the remote host, without having IP access on the client to the KDC (such as on a dialup or with a firewall or something.) I'm sure he'll announce something here about how to get the sources, if they're in a releasable yet. _Mark_ MIT Student Information Processing Board Cygnus Support Cygnus Network Security From ryan at rtfm.mlb.fl.us Thu Jun 10 13:56:27 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Thu, 10 Jun 93 13:56:27 PDT Subject: CryptoStacker Update In-Reply-To: <18312.9306101807@monge.brunel.ac.uk> Message-ID: On Thu, 10 Jun 1993, Jonathan K Saville wrote: > > Re: possible problems with INT13 > > I may be mistaken, but I have this feeling that DPMI servers (including > MS Windows) react unkindly to people using INT13. This is certainly what > the Borland Open Architecture handbook says. If your program is resident > when such a server is running, it could throw up a General Protection > fault. I will check into this myself... The programs running on the system will not be using INT13. They will use the higher level interrupts that they normally use. The block driver exists below all of that and merely controls what happens once the higher level interrupts already call INT13. I don't think that it will be any problem, certainly less of a problem than if I tried to screw with higher level interrupts. -=Ryan=- the Bit Wallah From Brian.Hawthorne at East.Sun.COM Thu Jun 10 14:46:49 1993 From: Brian.Hawthorne at East.Sun.COM (Brian Holt Hawthorne - SunSelect Engineering) Date: Thu, 10 Jun 93 14:46:49 PDT Subject: McCarthy lives! Message-ID: <9306102141.AA09055@sea.East.Sun.COM> ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 50 > > Tim, I'll be glad to teach you how to file a Privacy Act request. > > It's pretty simple, and it works on all Federal agencies. You get > > all records they are keeping on you, with some limited exceptions -- > > and for almost all of those, you get notified of the withholding. > > If you can identify one or a small number of agencies that might > > be keeping this "list", we can see if you are on it. And if we > > find the list, we can probably get the whole thing under the Freedom > > of Information Act. > > I'd be very interested in hearing more on this... Freedom of Information Act and Privacy Act apply only to federal agencies. Privacy Act Requests for personal data must be notarized. If the agency ignores the request, you must appeal under FOIA, since there are no appeal provisions under the Privacy Act. You must specify the "Systems of Records" you want searched. These are listed in the Federal Register and in "Protecting Your Right to Privacy--A Digest of Systems of Records, which you can get from the GPO). I've included the ones you probably would want with the FBI or CIA. You must pre-authorize a dollar amount for search and copying costs. Attached are some sample letters for the FBI, the CIA and general Privacy Act/FOIA. FOIA requests can be more general, I've got info on that as well. I am not a lawyer, and this is not intended as legal advice. The info is out of a wonderful book: Biggs, Don. How to avoid laywers. Includes index. 1. Forms (Law)--United States. I. Title. KF170.B47 1984 347.73'55 84-18636 ISBN 0-8240-7285-5 347.30755 ISBN 0-8240-7284-7 (pbk.) Garland Publishing, Inc. 136 Madison Ave. New York, NY 10016 It is a bit out of date (1985), but I believe the Privacy Act and FOIA is still pretty much the same. It has extensive instructions for what to actually do and what the pitfalls are. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: privacy-act X-Sun-Charset: us-ascii X-Sun-Content-Lines: 80 DATE ADDRESS This is a request under provisions of Title 5 USC, Sec. 552, the Freedom of Information Act, and Title 5 USC, Sec. 552a, the Privacy Act. Please furnish me with copies of all records on me retrievable by the use of an individual identifier and by the use of any combination of identifiers (e.g., name + date of birth + social security number, etc.) that are contained in the following systems of records: In order to identify myself and to facilitate your search of records systems, I provide the following information: _________________________________________________________ Last Name First Middle _________________________________________________________ Street City State Zip Code _________________________________________________________ Date of Birth Place of Birth Sex Social Security _________________________________________________________ Other information In the event that any part or all of my records are withheld, I request a complete list of all records being withheld and the specific exemption being claimed for the withholding of each. In the event that search and copyinng fees are estimated to exceed $ _________, I request an opportunity to review such records, or to have a duly authorized representative review such records, in order to select those to be copied. If you have an questions regarding this request, please telephone me at ________________ weekdays between _________ and ____________ or write to me at the above address. As provided for by Sec. 552(a)(6)(i) of the Freedom of Information Act, I shall expect to receive a reply within ten (10) business days. Sincerely, __________________ CERTIFICATE OF NOTARY STATE OF ) ) ss: COUNTY OF ) On this _______ day of _________, 19___, before me personally came and appeared _____________________________, known, and known to me, to be the individual described in and who executed the foregoing instrument, and who duly acknowledged to me that he/she executed same for the purpose therein contained. IN WITNESS WHEREOF, I hereunto set my hand and official seal. ________________________________ Notary Public My commission expires: _____________________ ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: privacy-act-cia X-Sun-Charset: us-ascii X-Sun-Content-Lines: 83 DATE Director Federal Bureau of Investigation J. Edgar Hoover Building 10th Street and Pennsylvania Avenue, N.W. Washington, D.C. 20535 Attn: FOIA/Privacy Act Branch This is a request under provisions of Title 5 USC, Sec. 552, the Freedom of Information Act, and Title 5 USC, Sec. 552a, the Privacy Act. Please furnish me with copies of all records on me retrievable by the use of an individual identifier and by the use of any combination of identifiers (e.g., name + date of birth + social security number, etc.) that are contained in the following systems of records: National Crime Information Center (NCIC) Central Records System Electronic Surveillance (Eisur) Indices In order to identify myself and to facilitate your search of records systems, I provide the following information: _________________________________________________________ Last Name First Middle _________________________________________________________ Street City State Zip Code _________________________________________________________ Date of Birth Place of Birth Sex Social Security _________________________________________________________ Other information In the event that any part or all of my records are withheld, I request a complete list of all records being withheld and the specific exemption being claimed for the withholding of each. In the event that search and copyinng fees are estimated to exceed $ _________, I request an opportunity to review such records, or to have a duly authorized representative review such records, in order to select those to be copied. If you have an questions regarding this request, please telephone me at ________________ weekdays between _________ and ____________ or write to me at the above address. As provided for by Sec. 552(a)(6)(i) of the Freedom of Information Act, I shall expect to receive a reply within ten (10) business days. Sincerely, __________________ CERTIFICATE OF NOTARY STATE OF ) ) ss: COUNTY OF ) On this _______ day of _________, 19___, before me personally came and appeared _____________________________, known, and known to me, to be the individual described in and who executed the foregoing instrument, and who duly acknowledged to me that he/she executed same for the purpose therein contained. IN WITNESS WHEREOF, I hereunto set my hand and official seal. ________________________________ Notary Public My commission expires: _____________________ ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: privacy-act-fbi X-Sun-Charset: us-ascii X-Sun-Content-Lines: 83 DATE Director Federal Bureau of Investigation J. Edgar Hoover Building 10th Street and Pennsylvania Avenue, N.W. Washington, D.C. 20535 Attn: FOIA/Privacy Act Branch This is a request under provisions of Title 5 USC, Sec. 552, the Freedom of Information Act, and Title 5 USC, Sec. 552a, the Privacy Act. Please furnish me with copies of all records on me retrievable by the use of an individual identifier and by the use of any combination of identifiers (e.g., name + date of birth + social security number, etc.) that are contained in the following systems of records: National Crime Information Center (NCIC) Central Records System Electronic Surveillance (Eisur) Indices In order to identify myself and to facilitate your search of records systems, I provide the following information: _________________________________________________________ Last Name First Middle _________________________________________________________ Street City State Zip Code _________________________________________________________ Date of Birth Place of Birth Sex Social Security _________________________________________________________ Other information In the event that any part or all of my records are withheld, I request a complete list of all records being withheld and the specific exemption being claimed for the withholding of each. In the event that search and copyinng fees are estimated to exceed $ _________, I request an opportunity to review such records, or to have a duly authorized representative review such records, in order to select those to be copied. If you have an questions regarding this request, please telephone me at ________________ weekdays between _________ and ____________ or write to me at the above address. As provided for by Sec. 552(a)(6)(i) of the Freedom of Information Act, I shall expect to receive a reply within ten (10) business days. Sincerely, __________________ CERTIFICATE OF NOTARY STATE OF ) ) ss: COUNTY OF ) On this _______ day of _________, 19___, before me personally came and appeared _____________________________, known, and known to me, to be the individual described in and who executed the foregoing instrument, and who duly acknowledged to me that he/she executed same for the purpose therein contained. IN WITNESS WHEREOF, I hereunto set my hand and official seal. ________________________________ Notary Public My commission expires: _____________________ From murphy at s1.elec.uq.oz.au Thu Jun 10 16:42:53 1993 From: murphy at s1.elec.uq.oz.au (Peter Murphy) Date: Thu, 10 Jun 93 16:42:53 PDT Subject: My Poll.... In-Reply-To: <9306090653.AA23961@triton.unm.edu> Message-ID: <9306102341.AA22865@s2.elec.uq.oz.au> Responding to J. Michael Diehl's post ... > > Well, I finally got to look at the responses to my poll. FYI, I got 33 replies. > This is a small number considering there are (I think) 400+ people on this list. > I didn't take the time to actually tally the results for each question. I'm > inherently lazy... ;^) I can make some comments about what we use, tho. Note > that the lists are in no particular order. Since this was certainly not a > scientific poll, I opted to not include any statistics, sorry. I was kinda > hoping to have a more homogeneous environment than what we have. Kinda naive, > huh? Well, this is what I have to say after reading each of your replies. I > would like to thank everyone who participated in my informal poll. I hope the > results are usefull to any software-developer-cypherpunks out there. > { The rest of the post (documenting results) deleted. } I'm sorry that I didn't answer your poll. However, if I had a little bit more time I would have answered it. Unfortunately, this mailing list is so expansive (and my time is so limited) that I only read my mail about once a week. So I became aware of the poll's closing date (last Thursday, 3/6) the next day (i.e., 4/6). Please give a little more time in future. It was a GREAT idea. Thanks for doing it. Cheers, Peter. P.S. In case you're still interested in accumulating results, I respond to email on Sony News-OS V. 4.3 (analogous to Berkeley 4.1). I also use a lot of MS-DOS PCs (mostly on the Elec. Eng. Novell network, although I might be acquiring a 486 pretty soon). As for PGP, ... well I OFFICIALLY don't have a copy, being not a resident of North America :-) ... > +-----------------------+-----------------------------+---------+ > | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | > | mdiehl at triton.unm.edu | But, I was mistaken. |available| > | mike.diehl at fido.org | | Ask Me! | > | (505) 299-2282 +-----------------------------+---------+ > | | > +------"I'm just looking for the opportunity to be -------------+ > | Politically Incorrect!" | > +-----If codes are outlawed, only criminals wil have codes.-----+ > +----Is Big Brother in your phone? If you don't know, ask me---+ > -- ==================================================== Peter Murphy - Department of Electrical Engineering, University of Queensland: murphy at s2.elec.uq.oz.au . "Contrary to popular belief, the wings of demons are the same as the wings of angels, although they're often better groomed." - Terry Pratchett. ==================================================== From fergp at sytex.com Thu Jun 10 17:40:17 1993 From: fergp at sytex.com (Paul Ferguson) Date: Thu, 10 Jun 93 17:40:17 PDT Subject: A definite trend Message-ID: -----BEGIN PGP SIGNED MESSAGE----- I've been very busy this week busting my chops on a networking project for a client, but I have to take a moment to add my own few comments. I realize that this is old news to some of you, but it appears that many of you seem to forget that a rather unpleasant trend seems to be developing within the law enforcement community. While we are voicing our opposition to the "Key-Escrow" proposal (known to most of us as Clipper/Capstone/Skipjack), there are other historical instances which are directly proportionate to where the LEAs are in relationship to their efforts at legislating technology. The point that I am attempting to make is that the "Key-Escrow" initiative is but another extension of the earlier Digital Telephony proposal introduced early last year (also known as "Son of S. 266"). As far as I'm concerned, the "Key-Escrow" initiative is an attempted continuance of a failed effort. Excerpted from "Digital Media: A Seybold Report," April 20 1992 volume 1, number 11, page 7, is one of the first reports of this failed attempt to legislate LEA access to communications on a broad scale - "Though not specifically listed as a target in the proposal, many people are calling Digital Telephony 'Son of S. 266,' a failed Senate bill that required the same 'dumbing-down' for encryption as the F.B.I. proposal does for phone systems. In other words, makers of encryption devices or software were to be required to leave a 'back door' open for law-enforcement and security agencies that wanted to decode encrypted communication. "The bill, of course, completely defeats the purpose of encryption - leaving the 'back door' open for the very same sophisticated techno-criminals that the agencies were trying to thwart. S. 266 was shouted down last year by outraged computer experts and civil libertarians. "At the CFP [CFP II - PF] conference, encryption expert Whitfield Diffie said, 'I understand why the police don't like [encryption]. But a very large part of the essence of a free versus totalitarian society consists of the difference between being answerable for your actions and being subject to prior restraint against actions the society doesn't approve of.'" [End of excerpt] Additionally, later in the article, a summary list is provided which outlined the proposal, which is excerpted below - "The F.B.I. proposal The following is taken directly from a Federal Bureau of Investigation document distributed to legislators and other concerned parties in Washington, DC. Digital Telephony: Summary of Issues * The F.B.I. utilizes electronic surveillance (wire taps) in virtually every area of its investigative responsibilities. * The telecommunications industry, which remained virtually unchanged for approximately 50 years, is now rapidly changing to address the need for more advanced telecommunications systems, such as personal communications networks, advanced cellular and integrated services digital networks (ISDN) which have the capacity for high-speed transmissions of video, voice and data. * One of the telephone telecommunications industry's major developmental efforts is to provide total digital connectivity (end to end) for its subscribers, including residential and business communities, in the near future. * At present, no capability exists to intercept ISDN (digital) transmissions; therefore, the emergence of digital telecommunications technology will preclude the F.B.I. and all of law enforcement from being able to intercept electronic communications, thus all but eliminating a statutorily-sanctioned, court-authorized and extraordinarily successful investigate technique. * The Department of Justice and the F.B.I. have been working with the White House, various Administration agencies, the telecommunications industry and Congress to find a workable solution to this very serious problem that endangers the safety of the American public. A legislative solution has been developed to ensure that the legitimate need for law enforcement to lawfully intercept communications is met by the telecommunications industry. Legislative Remedy The proposal would amend the Communications Act of 1934 to require providers of electronic communications services and private branch exchanges to ensure that the Government's ability to lawfully intercept communications is unimpeded by the introduction of advanced digital telecommunications technology or any other emerging telecommunications technology. Specifically, the amendment provides the following: 1. The FCC, in consultation with the Attorney General, shall determine the technological interception needs of the Government and issue regulations that will preserve the Government's ability to conduct lawful electronic surveillance. 2. The FCC shall issue regulations within 120 days after enactment requiring the modification of existing telecommunication systems if those systems impede the Government's ability to conduct lawful electronic surveillance. 3. Compliance by service providers and private branch exchanges will be required within 180 days of the issuance of the regulations and the use of non-conforming equipment is prohibited thereafter. 4. The FCC has the authority to compensate (through rate structure) telecommunication system operators under FCC jurisdiction for reasonable costs associated with required modifications of existing telecommunications equipment or technology. 5. The Attorney General has specific authority, in addition to that already vested in the FCC, to seek civil penalties and injunctive relief for non-compliance." [End of excerpt] Of course, this bill died on "The Hill" because of lack of support. It does suggest, however, that this is the tell-tale sign of a continuing effort by the law enforcement community (which is grasping at straws) to find ways to exploit domestic communications due to the increasing complexity of technological advances in that area. LEAs are also using highly volatile topics as drug enforcement and terrorism as justification. While being politically correct, this does not justify the scrutiny of private communications without reasonable justification. Hey -- you don't have to get whacked across the head with a 2x4 to see the writing on the wall. Clipper is an offering by a kinder, gentler government. Clipper/Capstone offers a method to secure your communications for you, with a "Key-Escrow" system, a GW (Gee Whiz) chip set whose internals are classified and a premise of good faith. I'm certainly no sage with a crystal ball, but I can't help but wonder which trump card will be played next. Whatever it is, I get the feeling that it is not good. Cheers. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLBfG+5RLcZSdHMBNAQGO/gQApCXzaIxktfKTpK7nBJUrw1tRzXmw6twR zYPjKYKdiJ9lQ6qPrUwbCGccPjN2Gnv7MP29H782ixzA7wMbMo47SkMbVA2fpxzp 2SpXRYmhkwMNdbD03nooF8QN2qwN6X7FtZ7yCelCf4X+TDXVEN+EAKu+g2AH5rKm 7q0aTzJgKPg= =D3Pp -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp at sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip. From peb at PROCASE.COM Thu Jun 10 18:04:17 1993 From: peb at PROCASE.COM (peb at PROCASE.COM) Date: Thu, 10 Jun 93 18:04:17 PDT Subject: ATT ad in WSJ Message-ID: <9306102001.AA21195@banff.procase.com> ATT has an ad in today's (June 10, 1993) Wall Street Journal for their secure phone for $1200; they do not say how it works (neither cryptography nor Clipper are mentioned). Strangely, they suggest that it could be used in places where one could easily be overheard (like an airport--I don't know how they would connect to a public phone). Paul E. Baclace peb at procase.com From hughes at soda.berkeley.edu Thu Jun 10 18:52:12 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 10 Jun 93 18:52:12 PDT Subject: cypherpunks physical meeting Message-ID: <9306110134.AA09618@soda.berkeley.edu> Cypherpunks Meeting Saturday, June 12, 1993 12:00 noon - 6:00 p.m. Cygnus Support offices, Mt. View, CA I've really got to get some automated software running for posting these announcements. I apologize, again, for the untimeliness of this message. This time there will be a reporter from the BBC attending, not to film, but to talk to people about electronic culture in the Bay Area. We will also have some other visitors, I believe. Topics: 1. Clipper, of course. The CPSR Crypto Policy meeting was earlier this week, as well as the Markey hearings. We will have reports on these. 2. Software development. Mail, links, disks. It is time to make an overall plan for the architecture of encrypted life. I want to brainstorm to make sure we come up with a complete list. 3. Crypto '93 attendance 4. Other, as usual. Eric ----------------------------------------------------------------------------- [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 TO1SITTLER at APSICC.APS.EDU Thu Jun 10 21:38:37 1993 From: TO1SITTLER at APSICC.APS.EDU (Kragen Sittler) Date: Thu, 10 Jun 93 21:38:37 PDT Subject: 8088 Message-ID: <930610223100.da8@APSICC.APS.EDU> Begin Quoted Message------------------------------------------------------ From: rwhelan at mason1.gmu.edu (Robert J. Oot) Message-Id: <9306101553.AA29767 at mason1.gmu.edu> [discussion of pgp versions and locking removed, you all read it three times already] > > version 2.2 locks up 8088-based computers. Version 2.1 does not. ^^^^^^^^^^^^^^^^^^^^ > > There is an unauthorized bug fix version, 2.21. I use 2.2 as it runs > > well on my system. > > Well, now I know. I was not aware that people still used that version of a computer. An 8088???? PGP Public Key available via finger "If its not UNIX, its crap" End Quoted Message----------------------------------------------------------- Not everyone can afford to buy a new computer. I myself am using a 286, because though I want to buy a faster computer, I have no spare money. I am using VMS to connect to the net for a similar reason. I can't afford my own net connection, so I borrow someone else's. VMS with multinet is considerably better for net.connections than turds in a toilet. And an 8088 is considerably better for encryption and word processing than a pencil and paper. Don't be so arrogant. Kragen From mdiehl at triton.unm.edu Thu Jun 10 22:28:52 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Thu, 10 Jun 93 22:28:52 PDT Subject: Encrypting the list In-Reply-To: <9306101710.AA13192@soda.berkeley.edu> Message-ID: <9306110528.AA22688@triton.unm.edu> According to Eric Hughes: > Summary: Encrypting the cypherpunks list make no difference in the > > >> It would be nice, however, to set up crypto I/O connection > >> OPTIONS to the list, as an incentive for lazy people like me to > >> figure out how to get PGP and mail filters set up. > > Michael, here is a word from your friendly neighborhood list > maintainer. I don't have time to work on this, and neither to the > people who run toad.com. So it's not going to happen on toad for a > while. > > The good news is that it doesn't have to. You yourself can write the > code! The code for the existing cypherpunks remailer is all you need > to get started. Here's how. You subscribe to cypherpunks and then > forward the list mail, encrypted, to all the people who have > subscribed with you for an encrypted version of the cypherpunks mail. Between a full-time job, my mail system, pgp menu, a software review, a girlfriend, and wedding plans, I sure won't be able to write this code. I'd love to if I had the time.... Will someone else volunteer? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From i6t4 at jupiter.sun.csd.unb.ca Fri Jun 11 00:44:25 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Fri, 11 Jun 93 00:44:25 PDT Subject: Encrypting the list In-Reply-To: <9306110528.AA22688@triton.unm.edu> Message-ID: On Thu, 10 Jun 1993, J. Michael Diehl wrote: > love to if I had the time.... Will someone else volunteer? Well.. I am starting a project (as soon as my mail alias is set up by the sysadmin) to do something like this... Mostly I just want to play with writing software that intercepts email... and try my hand at calling PGP from other software... which leads to a suggestion... It would be nice if PGP had a publicly available API, similar to that provided by RSAREF. -- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger i6t4 at unb.ca | (506) 457-1931 ^{1024/746EBB 1993/02/23} From newsham at wiliki.eng.hawaii.edu Fri Jun 11 02:21:30 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Fri, 11 Jun 93 02:21:30 PDT Subject: Circ Message-ID: <9306110921.AA18240@toad.com> I uploaded the package Circ.tar.Z which is the latest version of my encryption protocol for use on top of IrcII clients, to soda.berkeley.edu in ~ftp/pub/cypherpunks/incoming. I have also sent Eric the description of the package. It has so far not moved to a normal directory (why?). Oh well I was going to wait before announcing it, but you can get it from this directory now. (I am having technical difficulties posting it to comp.sources.misc so far. Still working on it ) Tim From newsham at wiliki.eng.hawaii.edu Fri Jun 11 03:23:51 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Fri, 11 Jun 93 03:23:51 PDT Subject: someones bouncing In-Reply-To: <930611093124_515664.456256_BHC50-22@CompuServe.COM> Message-ID: <9306111023.AA20380@toad.com> got this after my last post. someone is bouncing again. > --- Returned message --- > > Sender: newsham at wiliki.eng.hawaii.edu > Received: from orion.crc.monroecc.edu by ihd.compuserve.com (5.67/5.930129sam) > id AA21224; Fri, 11 Jun 93 05:31:53 -0400 > Message-Id: <9306110931.AA21224 at ihd.compuserve.com> > Date: Fri, 11 Jun 1993 05:23:53 -0400 > From: newsham at wiliki.eng.hawaii.edu > To: 71762.2440 at compuserve.com > Subject: Circ > X-Vms-To: cypherpunks at toad.com > > ================== RFC 822 Headers ================== > > Return-Path: cypherpunks-request at toad.com > Received: by orion.crc.monroecc.edu (UCX V2.0-05) > Fri, 11 Jun 1993 05:23:47 -0400 > Received: from toad.com by relay2.UU.NET with SMTP > (5.61/UUNET-internet-primary) id AA29927; Fri, 11 Jun 93 05:30:31 -0400 > Received: by toad.com id AA18245; Fri, 11 Jun 93 02:21:30 PDT > Return-Path: > Received: from wiliki.eng.hawaii.edu ([128.171.60.1]) by toad.com id AA18240; Fri, 11 Jun 93 02:21:24 PDT > Message-Id: <9306110921.AA18240 at toad.com> > Received: by wiliki.eng.hawaii.edu > (1.37.109.4/15.6) id AA16878; Thu, 10 Jun 93 23:20:53 -1000 > From: Timothy Newsham > Subject: Circ > To: cypherpunks at toad.com > Date: Thu, 10 Jun 1993 23:20:52 -1000 (HST) > X-Mailer: ELM [version 2.4 PL21] > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 509 > > From 76630.3577 at CompuServe.COM Fri Jun 11 07:02:21 1993 From: 76630.3577 at CompuServe.COM (Duncan Frissell) Date: Fri, 11 Jun 93 07:02:21 PDT Subject: 8088 Message-ID: <930611135802_76630.3577_EHK30-1@CompuServe.COM> >>>I was not aware that people still used that version of a computer. >>>An 8088???? >>> >>> >>>End Quoted Message----------------------------------------------------- >>> >>>Not everyone can afford to buy a new computer. I myself am using a 286, >>>because though I want to buy a faster computer, I have no spare money. >>> >>>(Kragen Sittler) Additionally, when one is running PGP under Windows the "virtual DOS machine" on which it is running *is* an 8088 (of sorts) and PGP 2.2 will lock it up 2/3 of the time. Duncan Frissell From hughes at soda.berkeley.edu Fri Jun 11 08:16:30 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 11 Jun 93 08:16:30 PDT Subject: Circ In-Reply-To: <9306110921.AA18240@toad.com> Message-ID: <9306111512.AA11268@soda.berkeley.edu> >I uploaded the package Circ.tar.Z It's in pub/cypherpunks/applications/misc. >It has so far not moved to a normal directory (why?). Time. Eric From hughes at soda.berkeley.edu Fri Jun 11 08:26:58 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 11 Jun 93 08:26:58 PDT Subject: MAIL: logging that happens on soda Message-ID: <9306111523.AA11809@soda.berkeley.edu> I was rooting around soda for some other reason and stumbled upon the mail logs (!) for soda. I just sent myself some mail to generate a sample entry. It's got complete traffic analysis data, complete with to/from pairs, time of day, and message size. Jun 11 08:13:35 soda sendmail[11298]: AA11298: message-id=<9306111513.AA11298 at soda.berkeley.edu> Jun 11 08:13:35 soda sendmail[11298]: AA11298: from=hughes, size=66, class=0, received from local Jun 11 08:13:36 soda sendmail[11300]: AA11298: to=hughes, delay=00:00:01, stat=Sent I would recommend that all remailer operators find out what kind of mail logging, if any, takes place on their machines. If you need a place to start looking, the mail log on soda was in the same directory as the syslog messages. I would also recommend that this information on mail logging by the system be put in Karl's remailer list. Eric From pauld at umbc.edu Fri Jun 11 09:11:49 1993 From: pauld at umbc.edu (Mr. Paul Danckaert (ACS)) Date: Fri, 11 Jun 93 09:11:49 PDT Subject: List.. Message-ID: <199306111611.AA00781@rpco25.acslab.umbc.edu> Please remove me from the list for now.. I'm skipping out for a bit and don't want 10000 messages when I get back.. ;) Thanks.. Paul --- Paul Danckaert - pauld at umbc.edu --------------------------------------- ------------------------------------------------- Beware of the Leopard ------- From shipley at tfs.COM Fri Jun 11 09:51:47 1993 From: shipley at tfs.COM (Peter Shipley) Date: Fri, 11 Jun 93 09:51:47 PDT Subject: MAIL: logging that happens on soda In-Reply-To: <9306111523.AA11809@soda.berkeley.edu> Message-ID: <9306111651.AA14556@edev0.TFS> >I was rooting around soda for some other reason and stumbled upon the >mail logs (!) for soda. I just sent myself some mail to generate a >sample entry. It's got complete traffic analysis data, complete with >to/from pairs, time of day, and message size. Eric, most of us know this stuff you are making yourself look very unix illiterate. I know one person at berkeley who wrote a sh script 5 years ago that would track remote mail aliases by analising who (on campus) who recived with close time stamps. with this info he was able to reverse engineer the containce of a lesbian emailing list. I have a scipt I use the just reads the syslog file and prints out a list of who is emailing who and what their total volume of mail is. >If you need a >place to start looking, the mail log on soda was in the same directory >as the syslog messages. or of you look at the file /etc/syslog.conf is tell you where log the data. From hughes at soda.berkeley.edu Fri Jun 11 11:05:40 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 11 Jun 93 11:05:40 PDT Subject: MAIL: logging that happens on soda In-Reply-To: <9306111651.AA14556@edev0.TFS> Message-ID: <9306111802.AA17868@soda.berkeley.edu> Re: sendmail logs >Eric, most of us know this stuff you are making yourself look very >unix illiterate. I have opened my mouth and removed all doubt. I _am_ mostly illiterate in the details of Unix; this is one system administration detail I did not know. I have known for a long time that these logs were in principle easy for administration to keep, but I did not know that they were an entirely standard feature. I raise this because it affects perceived remailer security and I have not once heard these specific logs brought up, on the list or in person. Eric From XXCLARK at indst.indstate.edu Fri Jun 11 13:20:50 1993 From: XXCLARK at indst.indstate.edu (XXCLARK at indst.indstate.edu) Date: Fri, 11 Jun 93 13:20:50 PDT Subject: No Subject Message-ID: <9306112020.AA05923@toad.com> According to nobody at alumni.cco.caltech.edu: > version 2.2 locks up 8088-based computers. Version 2.1 does not. > There is an unauthorized bug fix version, 2.21. I use 2.2 as it PGP 2.2 runs without a hitch on at least one 10 MHz+ XT box in which the 8088 was replaced with an NEC V-20 and an 8087 co-processor added when new... about six years ago. Probably far more XT boxes running, worldwide, than some are capable of imagining. Key generation on the XT is as exciting... and as fast... as a baseball game, but who generates new keys daily? Encryption speed is more than adequate. Not so high a brag-ability index as its companion box, a 486/66 EISA... but to use that machine for encryption seems an utter waste of processor power. `Course, if one can only afford a 486, I suppose one must make do as best one can... From kellyg at sco.COM Fri Jun 11 15:34:51 1993 From: kellyg at sco.COM (Kelly Goen) Date: Fri, 11 Jun 93 15:34:51 PDT Subject: MAIL: logging that happens on soda Message-ID: <9306111524.aa22415@vishnu.sco.com> Hi Eric, I as well as many others on this list have either worked as security administrators/ and/or designers in the aspect of systems that you have brought up here. Are you aware of the firewalls mailing list, it could be a HUGE resource in terms of these questions. As to the Logs... well the logfile name could be linked to /dev/null :) that would eliminate the logging problem... Another annoying tracking log is the syslog daemon. Mail connects are logged in their syslog using Sun sendmail and the standard syslog.conf. syslog.conf changes are needed to eliminate this misfeature... cheers kelly p.s. ignore that rather uninformed person who complained you were making yourself look illiterate... most of the folks on this list unless they actually do it for a living(such as moi) ARE quite illiterate about matters such as DNS/Mail logging and TCP/UDP/ICMP/IP logging and/or trusted systems etc. Thats part of what this forum is about for each of us to educate the rest of the list so that privacy issues get FULL spectrum coverage. Please do keep bringing these issues to the forefront... some of do appreciate it. I and others will be happy to discuss the technical details of various tracking and auditing. In-Reply-To: Peter Shipley's message of Fri, 11 Jun 1993 09:51:13 -0700 <9306111651.AA14556 at edev0.TFS> Subject: MAIL: logging that happens on soda Re: sendmail logs >Eric, most of us know this stuff you are making yourself look very >unix illiterate. I have opened my mouth and removed all doubt. I _am_ mostly illiterate in the details of Unix; this is one system administration detail I did not know. I have known for a long time that these logs were in principle easy for administration to keep, but I did not know that they were an entirely standard feature. I raise this because it affects perceived remailer security and I have not once heard these specific logs brought up, on the list or in person. Eric From jet at nas.nasa.gov Fri Jun 11 16:16:56 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Fri, 11 Jun 93 16:16:56 PDT Subject: A note from one of the jackbooted facists... In-Reply-To: <9306111524.aa22415@vishnu.sco.com> Message-ID: <9306112316.AA20618@boxer.nas.nasa.gov> This is not an official NASA document. Hi. If you saw what I do for a living sometime, you'd probably consider me a jackbooted facist of the highest order. I implement logging systems, help build firewalls, implement security software and teach people how to build secure systems. Luckily, this isn't my job at NASA -- I'm not a *government* facist brown-shirt. > Another annoying tracking log is the syslog daemon. Annoying if you want to be secure. If you're going to send messages through one of 'my' systems, I'm going to track and log them. Period. Don't like it? Route through something else. This list is being run from a UC-system owned computer. It's not in somebody's closet hooked to a phone line. If UC wants to log email, that's just fine. > syslog.conf changes are needed to eliminate this misfeature... A misfeature that helps me keep people from using 'my' machines unless I let them. > forum is about for each of us to educate the rest of the list > so that privacy issues get FULL spectrum coverage. I thought this list was here to discuss cryptography, not system security or firewalls. :-) If you don't control the system, consider it insecure and all of your informational transfer monitored, logged, and analyzed. -- J. Eric Townsend jet at nas.nasa.gov 415.604.4311| personal email goes to: CM-5 Administrator, Parallel Systems Support | jet at well.sf.ca.us NASA Ames Numerical Aerodynamic Simulation |--------------------------- PGP2.2 public key available upon request or finger jet at simeon.nas.nasa.gov From shipley at tfs.COM Fri Jun 11 16:34:38 1993 From: shipley at tfs.COM (Peter Shipley) Date: Fri, 11 Jun 93 16:34:38 PDT Subject: MAIL: logging that happens on soda In-Reply-To: <9306112141.AA17441@smds.com> Message-ID: <9306112334.AA15175@edev0.TFS> >> Eric, most of us know this stuff >> you are making yourself look very unix illiterate. > >You're looking a little like a nerdsnob to me. > Gee can't a guy rib a friend in public? From mdiehl at triton.unm.edu Fri Jun 11 16:53:19 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 11 Jun 93 16:53:19 PDT Subject: MAIL: logging that happens on soda In-Reply-To: <9306111524.aa22415@vishnu.sco.com> Message-ID: <9306112353.AA28100@triton.unm.edu> According to Kelly Goen: > Hi Eric, > I as well as many others on this list have either > worked as security administrators/ and/or designers in the > aspect of systems that you have brought up here. > > > Are you aware of the firewalls mailing list, it could be a HUGE > resource in terms of these questions. As to the Logs... I, for one, am not aware of this mailing list. Could you post info? Thanx. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From newsham at wiliki.eng.hawaii.edu Fri Jun 11 17:01:31 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Fri, 11 Jun 93 17:01:31 PDT Subject: Mail logging Message-ID: <9306120001.AA09108@toad.com> > > >I was rooting around soda for some other reason and stumbled upon the > >mail logs (!) for soda. I just sent myself some mail to generate a > >sample entry. It's got complete traffic analysis data, complete with > >to/from pairs, time of day, and message size. The goal of this list is not to turn off such "features" but to provide security in the face of these features, in hostile environments, environments not totally under our own control. From bbyer at BIX.com Fri Jun 11 17:15:26 1993 From: bbyer at BIX.com (bbyer at BIX.com) Date: Fri, 11 Jun 93 17:15:26 PDT Subject: CryptoStacker Message-ID: <9306112008.memo.59593@BIX.com> If the project is called CryptoStacker, why not use Stacker? Have the program go beneath Stacker (or another disk doubling system) and encrypt/decrypt the actual stacker file as Stacker reads it? It would be a much simpler solution once you found out how te interface with Stacker. Ben Byer From peb at PROCASE.COM Fri Jun 11 17:21:43 1993 From: peb at PROCASE.COM (peb at PROCASE.COM) Date: Fri, 11 Jun 93 17:21:43 PDT Subject: test, delete me Message-ID: <9306120020.AA21501@banff.procase.com> This is a test; please delete. From smb at research.att.com Fri Jun 11 17:28:06 1993 From: smb at research.att.com (smb at research.att.com) Date: Fri, 11 Jun 93 17:28:06 PDT Subject: MAIL: logging that happens on soda Message-ID: <9306120028.AA09550@toad.com> According to Kelly Goen: > > Are you aware of the firewalls mailing list, it could be a HUGE > resource in terms of these questions. As to the Logs... I, for one, am not aware of this mailing list. Could you post info? To subscribe, send mail to majordomo at greatcircle.com, with the body of the message saying subscribe firewalls From ld231782 at longs.lance.colostate.edu Fri Jun 11 17:45:52 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Fri, 11 Jun 93 17:45:52 PDT Subject: heavy Clipper ammunition Message-ID: <9306120045.AA05435@longs.lance.colostate.edu> This will be a short note. The apologists for Clipper on sci.crypt including Sternlight, Denning, Tighe, Goble, and others tend to ultimately fall back on the argument `What's the big deal? Its voluntary!' In some ways, this is their last and most desperate argument. Here are the critical reasons why that is not an acceptable excuse or redeeming feature. 1) Whether Clipper is *currently* voluntary is meaningless given the possibility that it could later become a legislated standard. The argument that it is `voluntary' is worthless unless there is an explicit *guarantee* of such. But, as the original Clipper announcement makes obvious, no such promise is made, apparently because it could not be adhered to. 2) As the CPSR statements point out, NSA has no legal authority to propose a domestic cryptographic standard. (That it pretends that President Clinton and the NIST are the actual purveyors is ugly deceit.) Nor, likely, would any such domestic authority ever be granted to the agency. In some ways, that's the whole point of NIST's cryptographic standards role: that it would be unchained and unmanipulated by NSA. Kammer's meek whimperings in the media prove this is clearly not the case. 3) I don't know who first suggested this, but there is every possibility that the entire plan with Clipper was to make it voluntary *initially* followed by a later legislative enforcement with its proliferation. After all, Clipper would give the NSA the critical `foot in the door' into domestic U.S. cryptography, at which point it would have a toehold to make further encroachments. Hence, the current arguments that `it's only voluntary' are perhaps the ultimate hypocritical lie. From hughes at soda.berkeley.edu Fri Jun 11 18:00:51 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 11 Jun 93 18:00:51 PDT Subject: Mail logging In-Reply-To: <9306120001.AA09108@toad.com> Message-ID: <9306120057.AA09590@soda.berkeley.edu> >> >It's got complete traffic analysis data, complete with >> >to/from pairs, time of day, and message size. >The goal of this list is not to turn off such "features" but to >provide security in the face of these features, in hostile environments, >environments not totally under our own control. Well said. If you externally observe a remailer, there are three basic items to correlate incoming to outgoing with: body content, body length, and redelivery latency. Notice that items two and three are provided by the mail logs on my machine. A remailer which is a mix needs to confuse all three. The first, content, requires an encryption or decryption operation. The second, length, requires length quantization and therefore padding and packeting. The last, latency, is only solved by random delays if the traffic through the node stays above a certain threshold. The real important characteristic with latency is reordering the incoming and outgoing messages. The simplest way to do this is to accumulate N messages, create a random permutation on N elements, and mail the messages out in the permuted order. The single most basic problem with mail development that we have is that we don't have enough mail volume through the remailers we have in order to be able to experiment with better systems. In particular, we need to examine other reordering algorithms for the case where volume is low and delivery latencies would be too high with the simple gather-and-permute algorithm. Eric From eric at Synopsys.COM Fri Jun 11 18:36:01 1993 From: eric at Synopsys.COM (eric at Synopsys.COM) Date: Fri, 11 Jun 93 18:36:01 PDT Subject: A note from one of the jackbooted facists... In-Reply-To: <9306112316.AA20618@boxer.nas.nasa.gov> Message-ID: <199306120135.AA17720@gaea.synopsys.com> >>>>> On Fri, 11 Jun 93 16:16:49 -0700, jet at nas.nasa.gov (J. Eric Townsend) said: jet> This list is being run from a UC-system owned computer. It's not in jet> somebody's closet hooked to a phone line. If UC wants to log email, jet> that's just fine. If you're referring to the cypherpunks list, it should be pointed out that toad.com is not a UC system. It is in fact a system in sombody's closet, hooked to a phone line. That is, unless John Gilmore has taken hoptoad out of his bedroom closet since I saw it last... -eric messick (eric at toad.com) From nobody at rosebud.ee.uh.edu Fri Jun 11 18:38:57 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Fri, 11 Jun 93 18:38:57 PDT Subject: DH for email Message-ID: <9306120138.AA10588@toad.com> Suppose you are communicating with someone using email about something which the government wouldn't like. Being careful, you use PGP or something similar. Later, the government gets wind of your activities. They seize your computer, recovering your encrypted secret key. You do not have copies of your old mail, but to your dismay, you discover that your email service provider keeps backups of old mail. Using a court order, the government is able to recover copies of all of your old email. The court orders you to reveal your pass phrase for your secret key. Any refusal will result in your being jailed for contempt. You are forced to comply. The result is that your old messages are decrypted and used against you as evidence. It would be good to have an alternative which would not be subject to this kind of attack. Diffie-Hellman key exchange is generally suitable for an interactive environment like an encrypted telnet session or a secure serial line. But it could be adapted to email by having each side create one or more "key halves" in advance, and exchanging these in an initial message. Future email could use a session key created by taking the next pair of key halves (one from each person). When the supply of key halves got low, more could be generated and piggybacked with the next email message. Such a system would be more secure against the kind of attack described here. There would be no possibility of reconstructing the session key used if the key halves were destroyed after use. You may choose to keep your own personal copies of email, but you can delete them and be secure in the knowledge that no attacker will be able to reconstruct them. A program like PGP could be created which would automatically take care of the bookkeeping involved with creating and exchanging key halves for the DH algorithm. Then users could have electronic conversations which were freer from the threat of being coerced into revealing their secret keys and having the contents of their mail exposed. From ld231782 at longs.lance.colostate.edu Fri Jun 11 19:21:29 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Fri, 11 Jun 93 19:21:29 PDT Subject: it's official: PKP sells out for Clipper Message-ID: <9306120221.AA06841@longs.lance.colostate.edu> >From the following document: >PKP will also grant a license to practice key management, at no >additional fee, for the integrated circuits which will implement >both the DSA and the anticipated Federal Information Processing >Standard for the "key escrow" system announced by President Clinton >on April 16, 1993. more weasel words: >Notice of availability of this invention for licensing >was waived because it was determined that expeditious granting of >such license will best serve the interest of the Federal Government >and the public. what else? ===cut=here=== From: jim at rand.org (Jim Gillogly) Newsgroups: sci.crypt Subject: DSA: NIST and PKP come to terms Message-ID: <16860 at rand.org> Date: 11 Jun 93 20:56:44 GMT Sender: news at rand.org Organization: Banzai Institute This text was transcribed from a fax and may have transcription errors. We believe the text to be correct but some of the numbers may be incorrect or incomplete. --------------------------------------------------------------------- ** The following notice was published in the Federal Register, Vol. 58, No. 108, dated June 8, 1993 under Notices ** National Institute of Standards and Technology Notice of Proposal for Grant of Exclusive Patent License This is to notify the public that the National Institute of Standards and Technology (NIST) intends to grant an exclusive world-wide license to Public Key Partners of Sunnyvale, California to practice the Invention embodied in U.S. Patent Application No. 07/738.431 and entitled "Digital Signature Algorithm." A PCT application has been filed. The rights in the invention have been assigned to the United States of America. The prospective license is a cross-license which would resolve a patent dispute with Public Key Partners and includes the right to sublicense. Notice of availability of this invention for licensing was waived because it was determined that expeditious granting of such license will best serve the interest of the Federal Government and the public. Public Key Partners has provided NIST with the materials contained in Appendix A as part of their proposal to NIST. Inquiries, comments, and other materials relating to the prospec- tive license shall be submitted to Michael R. Rubin, Active Chief Counsel for Technology, Room A-1111, Administration Building, National Institute of Standards and Technology, Gaithersburg, Maryland 20899. His telephone number is (301) 975-2803. Applica- tions for a license filed in response to this notice will be treated as objections to the grant of the prospective license. Only written comments and/or applications for a license which are received by NIST within sixty (60) days for the publication of this notice will be considered. The prospective license will be granted unless, within sixty (60) days of this notice, NIST receives written evidence and argument which established that the grant of the license would not be consistent with the requirements of 35 U.S.C. 209 and 37 CFR 404.7. Dated: June 2, 1993. Raymond G. Kammer Acting Director, National Institute Standards and Technology. Appendix "A" The National Institute for Standards and Technology ("NIST") has announced its intention to grant Public Key Partners ("PKP") sublicensing rights to NIST's pending patent application on the Digital Signature Algorithm ("DSA"). Subject to NIST's grant of this license, PKP is pleased to declare its support for the proposed Federal Information Processing Standard for Digital Signatures (the "DSS") and the pending availability of licenses to practice the DSA. In addition to the DSA, licenses to practice digital signatures will be offered by PKP under the following patents: Cryptographic Apparatus and Method ("Diffie-Hellman") No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle") No. 4,315,552 Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig") No. 4,434,414 Method For Identifying Subscribers And For Generating And Verifying Electronic Signatures In A Data Exchange System ("Schnorr") No. 4,995,082 It is PKP's intent to make practice of the DSA royalty free for personal, noncommercial and U.S. Federal, state and local government use. As explained below, only those parties who enjoy commercial benefit from making or selling products, or certifying digital signatures, will be required to pay royalties to practice the DSA. PKP will also grant a license to practice key management, at no additional fee, for the integrated circuits which will implement both the DSA and the anticipated Federal Information Processing Standard for the "key escrow" system announced by President Clinton on April 16, 1993. Having stated these intentions, PKP now takes this opportunity to publish its guidelines for granting uniform licenses to all parties having a commercial interest in practicing this technology: First, no party will be denied a license for any reason other that the following: (i) Failure to meet its payment obligations, (ii) Outstanding claims of infringement, or (iii) Previous termination due to material breach. Second, licenses will be granted for any embodiment sold by the licensee or made for its use, whether for final products software, or components such as integrated circuits and boards, and regard- less of the licensee's channel of distribution. Provided the requisite royalties have been paid by the seller on the enabling component(s), no further royalties will be owned by the buyer for making or selling the final product which incorporates such components. Third, the practice of digital signatures in accordance with the DSS may be licensed separately from any other technical art covered by PKP's patents. Fourth, PKP's royalty rates for the right to make or sell products, subject to uniform minimum fees, will be no more than 2 1/2% for hardware products and 5% for software, with the royalty rate further declining to 1% on any portion of the product price exceeding $1,000. These royalty rates apply only to noninfringing parties and will be uniform without regard to whether the licensed product creates digital signatures, verifies digital signatures or performs both. Fifth, for the next three (3) years, all commercial services which certify a signature's authenticity for a fee may be operated royalty free. Thereafter, all providers of such commercial certification services shall pay a royalty to PKP of $1.00 per certificate for each year the certificate is valid. Sixth, provided the foregoing royalties are paid on such products or services, all other practice of the DSA shall be royalty free. Seventh, PKP invites all of its existing licensees, at their option, to exchange their current licenses for the standard license offered for DSA. Finally, PKP will mediate the concerns of any party regarding the availability of PKP's licenses for the DSA with designated representatives of NIST and PKP. For copies of PKP's license terms, contact Michael R. Rubin, Acting Chief Counsel for Technolo- gy, NIST, or Public Key Partners. Dated: June 2, 1993. Robert B. Fougner, Esq., Director of Licensing, Public Key Partners, 310 North Mary Avenue, Sunnyvale, CA 94033 [FR Doc. 93-13473 Filed 8-7-93; 8:45 am] --------------------------------------------------------------------- Forwarded by: -- Jim Gillogly Trewesday, 21 Forelithe S.R. 1993, 20:56 From mab at crypto.com Fri Jun 11 19:28:11 1993 From: mab at crypto.com (Matt Blaze) Date: Fri, 11 Jun 93 19:28:11 PDT Subject: Privacy panel at USENIX Conference Message-ID: <9306120218.AA07373@crypto.com> Anyone who's going to be attending USENIX the week after next will want to make sure not to miss the privacy panel, to be held Friday afternoon (First session after lunch, I think). The topic to be discussed is anonymity on the net... Here's the official announcement: USENIX SUMMER 1993 TECHNICAL CONFERENCE June 21 -25, 1993 Cincinnati, Ohio Privacy Panel: Anonymity Servers - Finding The Bounds of Rights This USENIX Panel session will address anonymity servers, systems serving to sanitize e-mail and NetNews postings in order to conceal the source. We will explore the legal and ethical issues involved, and try to shed some light on the subtle complexities involving "the bounds of rights" such systems pose. Some of the issues are considerably more complex than they might first appear. Our panel will consist of Dan Appelman, John Gilmore, Johan ("Julf") Helsingius, and will be convened by Mike O'Dell. Biographies of the participants follow. Dan Appelman, Panelist Dan Appelman is a lawyer who practices computer and telecommunications law from his office in Palo Alto, California. He also teaches a course in telecommunications policy, law and regulation and has written and lectured about the legal issues in both the telecommunications and data processing industries. Dan is the lawyer the USENIX Association and several other amusing high-tech enterprises. He is a partner in the law firm of Heller, Ehrman, White & McAuliffe. John Gilmore, Panelist Among his other interests and accomplishments, John Gilmore is a dedicated champion of civil liberties in cyberspace. John was a cofounder of the Electronic Frontier Foundation and has campaigned aggressively for public availability of high-quality encryption systems. He was employee number five at Sun Microsystems, may well have written more APL interpreters than any other single human, and his most recent business venture is the founding of Cygnus Support, a software support company dedicated to the commercial viability of free software. He notes that he has never had time to attend college or buy a suit. Johan Helsingius, Panelist The last time anyone really referred to Johan Helsingius using his family name was while he was doing his military service long ago. As the memories are not too fond, he prefers to be called "Julf", a name based on a play on words involving 3 languages. He has been heavily involved in all manner of European Unix-related activities for longer than he cares to remember. He founded and still runs two successful consultancy and training companies, Penetron and Penetic, which manage to fund his well-developed tastes for global travel and exploring the native arcania. Most recently Julf established an anonymity server, anon.penet.fi, that quickly became the most popular anonymous posting service on the Internet with more than 20,000 users. Although he is based in downtown Helsinki, Julf tends to spend most of his time in airport departure lounges. Mike O'Dell, Provocateur Mike O'Dell is Vice-president of the USENIX Association and he is also Editor-in-Chief of the USENIX journal, Computing Systems. When he is not busy doing either of those two things, he is Vice-president of Engineering at UUNET Technologies, Inc., a commercial IP and UUCP connectivity provider. Mike's role in this panel, however, is to reprise his occasional role as Resident Crank and thereby provoke a lively analysis of the issues. From ld231782 at longs.lance.colostate.edu Fri Jun 11 19:54:25 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Fri, 11 Jun 93 19:54:25 PDT Subject: more Clipper proponents on sci.crypt Message-ID: <9306120254.AA07220@longs.lance.colostate.edu> Call me paranoid, but I think the NSA has decided that sci.crypt is now a good spot to level propaganda. From: pugh at cs.umd.edu (Bill Pugh) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 >I don't like the Clipper, and don't think it will succeed. However, on the >chance that we get stuck with it, we should figure out ways to solve many >of the concerns people have raised. > >A lot of people have concerns about the key escrow system. There are >good reasons to be worried about a system in which the government can >get a court order to decode your communications. But an even greater >concern to many people is how to make sure that key disclosure is limited >to lawfully authorized cases. The more I see statements like these, the more I suspect that the Clipper has a backdoor besides the key escrow systems. I think the whole escrow issue is a decoy to getting a widespread NSA standard in place. Also, keep in mind it could be the case that NSA builds different versions of the chips over time. How would we ever know? From: rja14 at cl.cam.ac.uk (Ross Anderson) Organization: U of Cambridge Computer Lab, UK >At Eurocrypt 93 a few weeks ago, the NSA's technical director said that the >key escrow system was still `vaporware' and that they had no objection to >interested parties getting involved in the design, to make sure that it was >`whiter than white'. > >Here's my twopenceworth: you can in fact make an escrow system which will be >goood enough to silence all or most of the reasonable objections, and here is >how to do it. > >1. The International Problem. > >... if clipper is restricted to the US, it will lose a lot of its value. >The bad guys such as the Mafia and the various terrorist groups will just >buy their communications systems in Europe or the Far East. Indeed, >respectable US corporations may end up buying their kit there as this is the >only way in which they can get the same kind of scrambler phone in each of >their offices. This guy then goes on to propose a lot of bizarre international configurations of key escrow. Holy cow-- this guy is advocating *international* key escrow? Good lord, cypherpunks, I wouldn't be surprised if Britain soon official endorses the Clipper. All our worst paranoia would be reality. Consider it: the NSA and GCHQ have been in active collaboration ever since WWII and especially in recent years. This is all documented by Bamford. What if Clipper is not just amenable to the NSA, but was also developed with British input? >The big question of course is whether the Agency would be happy with an >escrow system which really worked, on top of algorithms which were really >hard to break and were implemented well. Perhaps the object of the current >exercise is simply to sow fear, uncertainty and doubt, and thus postpone the >uptake of crypto in the commercial sector, I don't care if `the Agency' is happy or not. I think they would most definitely *not* be happy under such an arrangement and would use any significant Clipper entrenchment as torque to later ban alternative cryptographic schemes. I'm growing desperately weary. I think the tidal wave is approaching. From mark at coombs.anu.edu.au Fri Jun 11 20:56:41 1993 From: mark at coombs.anu.edu.au (Mark) Date: Fri, 11 Jun 93 20:56:41 PDT Subject: Mail logging Message-ID: <9306120356.AA11546@toad.com> >The single most basic problem with mail development that we have is >that we don't have enough mail volume through the remailers we have in >order to be able to experiment with better systems. In particular, we >need to examine other reordering algorithms for the case where volume >is low and delivery latencies would be too high with the simple >gather-and-permute algorithm. Well, I hate to point out the obvious but can we organise with the list maintainer to have our mail routed through random machines until it gets to us? I'd only recommend this for the more email aware members as it might prove confusing. Also, to save my own sanity and others certain header munglings might be desirable to ensure that the mail is still filterable. I'd suggest either an addition to the remailer scripts to allow a predefined header line through, or the Subject: line of each message is prefixed with CRYPTO: so the end users can still filter the messages as they now do. Currently I use 'procmail' to filter out various things and it works on the contents of the mail header as so: --------.procmailrc-------------------------- IFS="" PATH=/home/coombs/mark/bin:/usr/local/bin:/usr/bin:/bin MAILDIR=$HOME/mail DEFAULT=/usr/mail/$USER # Filtering for cypherpunks :2 # Two 'if' clauses (^To:.*cypherpunks at toad.com.*|^Cc: .*cypherpunks at toad.com.*) (^Subject: .*(UNSUBSCRIBE|nsubscribe).*) /dev/null # If a match send mail here. --------.procmailrc-------------------------- If we were to route all the mail through remailers I would lose the functionality of filtering as I wouldnt know where the email was coming from, nor would I be able to know it was cypherpunks mail until I read the message body. thats why a Subject: line change or a modification to the remailer scripts (if needed) should be made. Assuming the above was made, all the maintainer would have to do is change my mark at coombs.anu.edu.au line in the alias file to a: |/bin/random-remail -dest mark at coombs.anu.edu.au or |/bin/random-pgp-remail -dest mark at coombs.anu.edu.au -key mark at coombs.anu.edu.au where 'random-remail' is a short program that scans a list of remailers and randomly selects some, puts the addresses and remail triggers into a file, appends the message and changes the "Subject: blah" line to "Subject: CRYPTO: blah". 'random-pgp-remail' does the same and encrypts the whole message before sending, possibly encrypting again a few times with remailer keys. This approach would (dramatically :) increase the remailer traffic to levels where mail re-ordering is possible. Padding would be the next step, add the lines on the end to bring the message to 512 bytes, 1024 bytes, 2048 bytes or greater. Maybe pad all messages to the nearest 1024 bytes? (see below for a method :) The only problem I can see after the programs are debugged etc is the extra overhead on toad.com, wther it's a non encrypted mail out or not. But if that is acceptable to the maintainer in the intrests of giving remailer operators some fodder then we can implement it I dont see any of the random-[pgp-]remailer programs being longer than 30 or 40 (perl script) lines. I'd write them myself if I could get some mail aliases installed on this host. Admittedly they aren't essential but I'd like them for testing purposes. Mark mark at coombs.anu.edu.au PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PA <---- end of padding to make this 2048 bytes long From phantom at u.washington.edu Fri Jun 11 21:38:02 1993 From: phantom at u.washington.edu (The Phantom) Date: Fri, 11 Jun 93 21:38:02 PDT Subject: Remailer mail logging: Message-ID: just for your info: the mead remailer has no logging enabled! :) Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom at u.washington.edu phone: (206) 528-5732 PGP 2.2 key available via email or finger phantom at hardy.u.washington.edu From M..Stirner at f28.n125.z1.FIDONET.ORG Fri Jun 11 21:57:58 1993 From: M..Stirner at f28.n125.z1.FIDONET.ORG (M. Stirner) Date: Fri, 11 Jun 93 21:57:58 PDT Subject: Pgp v 2.2/8088 Message-ID: <341.2C1956A8@shelter.FIDONET.ORG> * Reply to msg originally in CYPHERPUNKS > version 2.2 locks up 8088-based computers. Version 2.1 does not. > There is an unauthorized bug fix version, 2.21. I use 2.2 as it Uu> PGP 2.2 runs without a hitch on at least one 10 MHz+ XT Uu> box in which the 8088 was replaced with an NEC V-20 and an 8087 Uu> co-processor added when new... about six years ago. I don't doubt it for a second, but I know it definitely will lock up a real 8088. Also there is a problem with DesqView in some cases. Uu> Probably far more XT boxes running, worldwide, than some Uu> are capable of imagining. I'm sure of that, too. PGP is a worldwide phenomenon, & there are a whole lot of XT-class computers in the outside world. Uu> Key generation on the XT is as exciting... and as fast... Uu> as a baseball game... Well, more like _cricket_, actually. 8-) Uu> Encryption speed is more than adequate. Considering the math involved, yes. Still even a 20MHz 286 fairly flies doing PGP tasks in comparison, though. ********************************************************************* * - 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 zanadu at well.sf.ca.us Fri Jun 11 22:11:51 1993 From: zanadu at well.sf.ca.us (Leo Reilly) Date: Fri, 11 Jun 93 22:11:51 PDT Subject: Unsubscribe Message-ID: <93Jun11.221119pdt.13922-2@well.sf.ca.us> could you please remove me from the mail list. I am on the road for two weeks, without a laptop, and I cannot affored the disk space to be taken up while I am gone. Cheers! Leo Reilly From hal at alumni.cco.caltech.edu Fri Jun 11 22:28:15 1993 From: hal at alumni.cco.caltech.edu (Hal Finney) Date: Fri, 11 Jun 93 22:28:15 PDT Subject: PKP sellout? Message-ID: <9306120527.AA03229@alumni.cco.caltech.edu> This was my response on sci.crypt to this announcement that PKP will be supporting DSS, and licensing its technology for use by Clipper phones. Thanks to Lance for alerting us to this announcement. ----- jim at rand.org (Jim Gillogly) forwards: >This is to notify the public that the National Institute of >Standards and Technology (NIST) intends to grant an exclusive >world-wide license to Public Key Partners of Sunnyvale, California >to practice the Invention embodied in U.S. Patent Application No. >07/738.431 and entitled "Digital Signature Algorithm." And so it appears that another patent jewel will be added to the crown worn by PKP, the de facto owner of cryptographic technology in the United States. They will have an exclusive license to the DSA, as they already do to RSA and most other worthwhile encryption technologies. This also appears to put to rest the much-publicized feud between RSA and NIST/NSA. Conspiracy theorists can now comfortably return to the position that PKP/RSADSI is actually an arm of the NSA, dedicated to restricting and delaying access to strong cryptography as much as possible. >Notice of availability of this invention for licensing >was waived because it was determined that expeditious granting of >such license will best serve the interest of the Federal Government >and the public. Once again we are presented with a fait accompli; no other organizations were given an opportunity to bid for the licensing of this patent. The government prefers to see PKP holding the keys to all cryptography in the U.S. Remember how Clipper's technology was similarly assigned to particular corporations on a non-competitive basis? >Subject to NIST's grant of this license, PKP is pleased to declare >its support for the proposed Federal Information Processing >Standard for Digital Signatures (the "DSS") and the pending >availability of licenses to practice the DSA. And what of the technical objections to DSA/DSS raised in earlier documents by officials of RSADSI, such as in the recent CACM? No doubt those objections are now moot. >PKP will also grant a license to practice key management, at no >additional fee, for the integrated circuits which will implement >both the DSA and the anticipated Federal Information Processing >Standard for the "key escrow" system announced by President Clinton >on April 16, 1993. So PKP is now supporting key escrow and Clipper. Can anyone seriously argue that this company is a friend to supporters of strong cryptography? These are dark times indeed. PKP has thrown in with the government, getting behind DSS and Clipper in exchange for exclusive licensing rights. Their ownership of DH and RSA will make it that much harder for any competition to Clipper to arise. If the 60-day comment period really means anything, perhaps public criticism can be effective here. There is much to be concerned about in this announcement. Hal Finney hal at alumni.caltech.edu From M..Stirner at f28.n125.z1.FIDONET.ORG Fri Jun 11 22:57:57 1993 From: M..Stirner at f28.n125.z1.FIDONET.ORG (M. Stirner) Date: Fri, 11 Jun 93 22:57:57 PDT Subject: Nsa/gshq Message-ID: <343.2C196B79@shelter.FIDONET.ORG> * Reply to msg originally in CYPHERPUNKS Uu> Good lord, cypherpunks, I wouldn't be surprised if Britain soon Uu> official endorses the Clipper. All our worst paranoia would be Uu> reality. Consider it: the NSA and GCHQ have been in active Uu> collaboration ever since WWII and especially in recent years. Uu> This is all documented by Bamford. To say nothing of Peter Wright's [MI5] revelations, the publication of which I understand was banned in the UK. Very interesting stuff - I hope Britons eventually got the chance to read his book, _Spycatcher_. ********************************************************************* * - 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 tcmay at netcom.com Fri Jun 11 23:09:14 1993 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 11 Jun 93 23:09:14 PDT Subject: PKP sellout? In-Reply-To: <9306120527.AA03229@alumni.cco.caltech.edu> Message-ID: <9306120609.AA05252@netcom3.netcom.com> Yep, dark times indeed. As Hal and Lance note, these decisions are all made in complete secrecy. Bidzos and RSA appear to have sold out. If true, we'll have lots to talk about at Saturday's meeting. -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 ryan at rtfm.mlb.fl.us Fri Jun 11 23:35:50 1993 From: ryan at rtfm.mlb.fl.us (RYAN Alan Porter) Date: Fri, 11 Jun 93 23:35:50 PDT Subject: CryptoStacker In-Reply-To: <9306112008.memo.59593@BIX.com> Message-ID: On Fri, 11 Jun 1993 bbyer at BIX.com wrote: > If the project is called CryptoStacker, why not use Stacker? > Have the program go beneath Stacker (or another disk doubling system) > and encrypt/decrypt the actual stacker file as Stacker reads it? It > would be a much simpler solution once you found out how te interface > with Stacker. Problems: 1) Defeats the purpose of free/cheap-ware. 2) Mixes abstraction levels and causes drivers to run redundantly (and thus, more slowly) 3) Would not be modular with further expandability Solution: Take the meat of the suggestion (building upon an already working system of sector remapping and data mangling) and build upon it. Indeed, what I am doing is finding working sources for drivers and network redirectors and examining them to find one which will serve as a good model to work from. This will provide the benefits of working under Stacker, as you suggested, and will also have the advantages of freeing us from the list of disadvantages. > Ben Byer -=Ryan=- the Bit Wallah cat cypherpunk.flames > /dev/null From XXCLARK at indst.indstate.edu Sat Jun 12 00:16:38 1993 From: XXCLARK at indst.indstate.edu (XXCLARK at indst.indstate.edu) Date: Sat, 12 Jun 93 00:16:38 PDT Subject: Pgp v 2.2/8088/V-20 Message-ID: <9306120716.AA13031@toad.com> ms>I don't doubt it for a second, but I know it definitely will ms>lock up a real 8088. Grew so accustomed to the NEC V-series I suspect I'd come to think of them as the *real* 8088... and 8080. Uu> Key generation on the XT is as exciting... and as fast... Uu> as a baseball game... ms> Well, more like _cricket_, actually. 8-) There is *nothing* like cricket. Uu> Encryption speed is more than adequate. ms> Considering the math involved, yes. Still even a 20MHz 286 ms> fairly flies doing PGP tasks in comparison, though. Agreed. Just didn't want the potential PGP user with an XT to feel he'd have to settle for a Clipper chip... and had my button pushed by the naif overly impressed with the originovelnew. One wonders what reaction one would elicit were he confronted with an Altair kit and its quarter mile of white wire or MS Basic on paper tape or cassette. --------------------------------------------------------------------- internet : xxclark at indst.indstate.edu RelayNet (488) Vanilla BITNET: XXCLARK at INDST FidoNet (1:2230/114) Phone: 911 TechNet 11:800/0 One need not be a weatherman to know which way the wind is blowing. --------------------------------------------------------------------- From shipley at merde.dis.org Sat Jun 12 01:11:59 1993 From: shipley at merde.dis.org (Peter shipley) Date: Sat, 12 Jun 93 01:11:59 PDT Subject: MAIL: logging that happens on soda In-Reply-To: <9306111802.AA17868@soda.berkeley.edu> Message-ID: <9306112112.AA21861@merde.dis.org> A non-text attachment was scrubbed... Name: not available Type: text/x-pgp Size: 765 bytes Desc: not available URL: From Rain.Face at f418.n161.z1.FIDONET.ORG Sat Jun 12 03:57:23 1993 From: Rain.Face at f418.n161.z1.FIDONET.ORG (Rain Face) Date: Sat, 12 Jun 93 03:57:23 PDT Subject: REMAILER UPDATE Message-ID: <356.2C19A34A@shelter.FIDONET.ORG> In that I have been off this list for a while, I was wondering if someone could give me a quick update on which anon remailers are still in service and what the current syntax is. Thanks. --------------------------------------------------------------- ||"No apologies, no excuses,| |PGP Key ID # EFAA97 via all servers | no jive and no regrets." | --------------------------------------------------------------- --- Blue Wave/TG v2.12 [NR] * Origin: realitycheckBBS (510)527-1662 (1:161/418.0) -- Rain Face - via FidoNet node 1:125/1 UUCP: ...!uunet!kumr!shelter!161!418!Rain.Face INTERNET: Rain.Face at f418.n161.z1.FIDONET.ORG From smb at research.att.com Sat Jun 12 05:02:23 1993 From: smb at research.att.com (smb at research.att.com) Date: Sat, 12 Jun 93 05:02:23 PDT Subject: PKP sellout? Message-ID: <9306121202.AA16880@toad.com> It's worth remembering that for the most part, corporations don't have ethics, they have bottom lines. Most of PKP's objections to the DSA were not really solid; rather, they were in defense of RSA as a profit center. There only two really big ones -- that DSA as originally proposed had too small a key size, and that it doesn't provide secrecy, only authentication. The former has been fixed by NIST, and the latter was a design goal. In this case, NIST really had no choice but to deal with PKP. Apart from the question of the Diffie-Hellman patent -- and in my opinion, DSA definitely did infringe on it -- the proposed algorithm was very close to Schnorr's algorithm, which was patented, and to which PKP had purchased the rights. If NIST had gone ahead without making a deal with PKP, the standard would have been tied up in lawsuits for years, with the outcome quite uncertain. And while that may or may not have suited this community, it would not meet NIST's objectives. I don't see the hand of conspiracy here; rather, I see an encouraging trend, that the private sector is able to compete in cryptographic competence with NSA. I am encouraged by the pledges to allow non-commercial use -- note the lack of any RSAREF-like interface -- and to engage in non-discriminatory licensing. --Steve Bellovin From morpheus at entropy.linet.org Sat Jun 12 06:59:48 1993 From: morpheus at entropy.linet.org (morpheus) Date: Sat, 12 Jun 93 06:59:48 PDT Subject: No Subject Message-ID: From: morpheus at entropy.linet.org (morpheus) Subject: Re: Encrypting the list References: <9306091955.AA09779 at boxer.nas.nasa.gov> Organization: Ranch Apocalypse Date: Fri, 11 Jun 1993 22:31:42 GMT Message-ID: <1993Jun11.223142.28987 at entropy.linet.org> In article <9306091955.AA09779 at boxer.nas.nasa.gov> src4src!imageek!nas.nasa.gov!jet (J. Eric Townsend) writes: >FutureNerd Steve Witham writes: > > We're all prime suspects for being spies. > >'specially those of us with both .gov and .com email addresses, right? And worry all the more about ORGanized spies.. Worrying about spies is pointless. Publicity is good. There isn't any point in cutting people "out of the loop" in effort to stop "spies", what is being discussed needs to be known to as many people as possible. We're talking cryptography, not revolution. -- morpheus at entropy.linet.org Vote anarchist. Support your local police, for a more efficient police state. From jet at nas.nasa.gov Sat Jun 12 12:51:59 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Sat, 12 Jun 93 12:51:59 PDT Subject: A note from one of the jackbooted facists... In-Reply-To: <199306120135.AA17720@gaea.synopsys.com> Message-ID: <9306121951.AA23408@boxer.nas.nasa.gov> eric at Synopsys.COM writes: > If you're referring to the cypherpunks list, it should be pointed out > that toad.com is not a UC system. It is in fact a system in sombody's I'm a big idiot. I just have a 'cypher' alias, and I forgot what it pointed to. Still, the person with the machine 'in their closet' has the right to keep records. :-) From pozar at kumr.lns.com Sat Jun 12 12:59:03 1993 From: pozar at kumr.lns.com (Tim Pozar) Date: Sat, 12 Jun 93 12:59:03 PDT Subject: A note from one of the jackbooted facists... In-Reply-To: <199306120135.AA17720@gaea.synopsys.com> Message-ID: eric at Synopsys.COM wrote: > If you're referring to the cypherpunks list, it should be pointed out > that toad.com is not a UC system. It is in fact a system in sombody's > closet, hooked to a phone line. That is, unless John Gilmore has > taken hoptoad out of his bedroom closet since I saw it last... Wrong room of the house and wiring, but right concept. Tim -- Internet: pozar at kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA POTS: +1 415 788 2022 Radio: KC6GNJ / KAE6247 From jet at nas.nasa.gov Sat Jun 12 13:10:49 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Sat, 12 Jun 93 13:10:49 PDT Subject: evil government and corporate plot Message-ID: <9306122010.AA23499@boxer.nas.nasa.gov> It appears that both NASA and Thinking Machines are involved in a plot to keep me from attending today's meeting. Said plot involves agents of both parties deliberately crashing the CM-5 and requiring me to fix it before I'm allowed to do anything else. [sigh] -eric From 76114.2307 at CompuServe.COM Sat Jun 12 18:49:16 1993 From: 76114.2307 at CompuServe.COM (William H. Oldacre) Date: Sat, 12 Jun 93 18:49:16 PDT Subject: 8088/PGP failures. Message-ID: <930613014638_76114.2307_BHA60-1@CompuServe.COM> >I don't know where you've been, but version 2.2 has a notorious bug >that locks up the box under numerous situations. In my experience, >version 2.2 locks up 8088-based computers. Version 2.1 does not. >I was not aware that people still used that version of a computer. >An 8088???? >Don't be so arrogant. >Additionally, when one is running PGP under Windows the "virtual DOS >machine" on which it is running *is* an 8088 (of sorts) and PGP 2.2 will >lock it up 2/3 of the time. >PGP 2.2 runs without a hitch on at least one 10 MHz+ XT box in which >the 8088 was replaced with an NEC V-20 and an 8087 co-processor added >when new... about six years ago. >I don't doubt it for a second, but I know it definitely will lock up a >real 8088. Also there is a problem with DesqView in some cases. I live in Central Florida which experiences more lightning discharges than almost anywhere else in the country (excepting certain mountain tops). We are now entering our most violent season. Yesterday, a semi-trailer was struck on I-75 at a Gainesville exit and had both front tires blown out and his front window shattered. In Florida, you are roughly thirteen times more likely to be killed by lightning than win any single entry in the Florida lottery (lottery odds: 13.9 million to one). My home has been directly struck by lightning and suffered heavy damage. This may help to explain to those who authored the sentences above why I still employ an 8 MHz, 8088 based, Sanyo MBC-775 computer as my primary communications computer (no hard drive). Not counting the disfunctional Honeywell mainframe in the garage, I have over a dozen computers. Why risk a more expensive (and failure prone) system when it's sophistication is not necessary? PGP 2.2 works perfectly on my unit. I suggest that the lockup problem may be more related to the many different approaches to writing an IBM compatible ROM BIOS, rather than to the processor used. From phred at well.sf.ca.us Sat Jun 12 20:08:39 1993 From: phred at well.sf.ca.us (Fred Heutte) Date: Sat, 12 Jun 93 20:08:39 PDT Subject: PKP sellout? Message-ID: <93Jun12.200814pdt.13879-2@well.sf.ca.us> This PKP announcement is the last straw. This is clearly a case of the federal policy/procurement bureaucracy going completely out of control. The way things ran under Bush, except if they tried to pull this blatant a deal their bluff would have been called immediately. I think it's time to demand the White House put a total moratorium on all policies related to digital and telecommunications data and privacy until they can extract themselves from this quicksand. And if they won't do that, it's time to kick some *serious* political butt. Don't you let that deal go down! Fred Heutte Sunlight Data Systems "Why make it simple and easy when you can make it complex and wonderful!" From nobody at cicada.berkeley.edu Sat Jun 12 20:36:00 1993 From: nobody at cicada.berkeley.edu (nobody at cicada.berkeley.edu) Date: Sat, 12 Jun 93 20:36:00 PDT Subject: what happens when you reply to nobody@cicada.berkeley.edu ? Message-ID: <9306130335.AA16404@cicada.berkeley.edu> Ya, I wanted to know what happens when you responded to mail from nobody at cicada.berkeley.edu ? Thanks From ld231782 at longs.lance.colostate.edu Sat Jun 12 23:02:29 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Sat, 12 Jun 93 23:02:29 PDT Subject: PKP sellout = betrayal In-Reply-To: <9306121202.AA16880@toad.com> Message-ID: <9306130602.AA19359@longs.lance.colostate.edu> S. Bellovin >I don't see the hand of conspiracy here; rather, I see an encouraging >trend, that the private sector is able to compete in cryptographic >competence with NSA. > >I am encouraged by the pledges to allow non-commercial use -- note the >lack of any RSAREF-like interface -- and to engage in non-discriminatory >licensing. By cooperating with NIST on DSA and Clipper, they are implicitly sending the message that the poorly-to-outrageously directed standards making processes for both are wholly acceptable assuming PKP directly profits. That is, that is the weak `nonconspirational' interpretation. The conspirational interpretation is that this announcement is just a blatant indication that PKP, in addition to NIST, is controlled by the NSA. Let me remind everyone that Capstone has a yet-unspecified exchange protocol. Denning suggested on RISKS that Diffie-Hellman (covered by PKP patents) `could be used'. There is some serious evasion going on here. If Capstone is already built, with a public-key algorithm installed, it suggests that PKP has been cooperating on the Clipper/Capstone proposals all along. It will be most interesting to hear announcements on Capstone that announce its key exchange mechanism. PKP `had' the ability to murder Clipper/Capstone in its crib if it so desired, more so than any other single nexus, by denying the right to use public key algorithms (on which it now has a strangling, monopolistic lock). Gad, I can't believe it didn't occur to me to lobby them to do so. In retrospect, it wouldn't have done anything more than heighten the inevitable betrayal. Maybe Mr. Bellovin can clarify how this agreement represents an `encouraging trend in the private sector to compete with the NSA' -- Good lord man, not unless you think that PKP represents the entire private sector in cryptographic applications. Uh, touche' -- you do and it does. Does anybody feel like raiding PKP dumpsters? :( P.S. doubt P.R.Z. will be in a docile mood after hearing this one... From mdiehl at triton.unm.edu Sun Jun 13 01:17:55 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sun, 13 Jun 93 01:17:55 PDT Subject: alt.whistleblowing Message-ID: <9306130817.AA01161@triton.unm.edu> I just started reading the alt.whistleblowing newsgroup. It would seem that it has already digressed into a flamefest. Could the person who created it please post a set of guidelines for the group! Also, people are using their REAL names! Appearantly, they don't know anything about the anon remailers....Could someone post a notice about that, too? Same thing goes WRT pgp. We helped create this group, we ought to help keep it worth reading. ;^) +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From smb at research.att.com Sun Jun 13 01:34:11 1993 From: smb at research.att.com (smb at research.att.com) Date: Sun, 13 Jun 93 01:34:11 PDT Subject: PKP sellout = betrayal Message-ID: <9306130834.AA01183@toad.com> Let me remind everyone that Capstone has a yet-unspecified exchange protocol. Denning suggested on RISKS that Diffie-Hellman (covered by PKP patents) `could be used'. There is some serious evasion going on here. If Capstone is already built, with a public-key algorithm installed, it suggests that PKP has been cooperating on the Clipper/Capstone proposals all along. It will be most interesting to hear announcements on Capstone that announce its key exchange mechanism. I'm not sure what your point is here. It requires no conspiracy to opt for Diffie-Hellman as a key exchange mechanism; it's simply the obvious way to do things. (I'm speaking professionally here; cryptographic protocols are one of my research areas.) The STU-III's already use Diffie-Hellman; it's possible that the government's license for that patent grants it broad rights for such things. (The government does have free use of RSA; is there any such clause with respect to Diffie- Hellman?) PKP `had' the ability to murder Clipper/Capstone in its crib if it so desired, more so than any other single nexus, by denying the right to use public key algorithms (on which it now has a strangling, monopolistic lock). Gad, I can't believe it didn't occur to me to lobby them to do so. In retrospect, it wouldn't have done anything more than heighten the inevitable betrayal. No, PKP had no such ability. Clipper was always a potential source of profit to them, precisely because either RSA or Diffie-Hellman was needed for it. Given that they were going to make money from Clipper, the only question was how much. As Deep Throat said ~20 years ago, ``Follow the money''. (Those a bit older still should recall Dow Chemical's position on co-operating with the government.) ``Betrayal'' is a moral term. As I said before, corporations don't care about such things, only about bottom lines. That some settlement about DSA would be reached was inevitable. NIST needed PKP's assent to go ahead with DSA. PKP wanted to make money from the DSA, because it extends their profitable lifetime -- the RSA patent expires in 2001, whereas the Schnorr patent doesn't expire till 2008. PKP only opposed DSA while they didn't own the Schnorr patent; their other handle on DSA, the Diffie-Hellman patent, expires even earlier (1997). The interesting thing is the incentive to use Clipper. That's not something PKP cares about one way or another, compared with any sort of widespread use of cryptography (though perhaps RSADSI does; if private cryptography is restricted, RC2 and RC4 have much less of a market). Obviously, NIST wanted some clause like that. In exchange, they had to give PKP something more. My guess is that the hook was to grant them exclusive world-wide licensing rights to DSA, rather than simply a cut of the royalties. Maybe Mr. Bellovin can clarify how this agreement represents an `encouraging trend in the private sector to compete with the NSA' -- Good lord man, not unless you think that PKP represents the entire private sector in cryptographic applications. Uh, touche' -- you do and it does. I was unclear; I wasn't referring to the agreement at all. Rather, I meant that Schnorr had invented the algorithm that NIST had to have -- a signature scheme that is very efficient for smart cards, but could not be used for secrecy. NSA apparently didn't have anything better; I can't believe they and NIST were unaware of Schnorr's work (though perhaps they were unaware of the patent). (I suppose, of course, that NSA might have had something totally different, which they couldn't discuss because it would open up new areas for civilian research...) P.S. doubt P.R.Z. will be in a docile mood after hearing this one... Especially given the part about reserving the right not to license to infringers.... From hughes at soda.berkeley.edu Sun Jun 13 07:40:57 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sun, 13 Jun 93 07:40:57 PDT Subject: what happens when you reply to nobody@cicada.berkeley.edu ? In-Reply-To: <9306130335.AA16404@cicada.berkeley.edu> Message-ID: <9306131437.AA22430@soda.berkeley.edu> The name 'nobody' is frequently aliased to /dev/null, i.e. the bit bucket. I cannot speak for cicada in particular. When I wrote the first of these remailers, I remailed from nobody because it was the /dev/null alias; responding to anonymity should get you nothing. Eric From hughes at soda.berkeley.edu Sun Jun 13 08:14:53 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sun, 13 Jun 93 08:14:53 PDT Subject: Mail logging In-Reply-To: <9306120356.AA11546@toad.com> Message-ID: <9306131511.AA22941@soda.berkeley.edu> >>The single most basic problem with mail development that we have is >>that we don't have enough mail volume through the remailers we have >Well, I hate to point out the obvious but can we organise with the >list maintainer to have our mail routed through random machines until >it gets to us? No. toad.com is overloaded as it is. It's slow as molasses already, and adding any encryption at all to cypherpunks would make it even worse. Even forking a process per user would be way to much. As I said before, any experimentation that people want to do with list distribution can be done by hacking the current remailer code. You don't have to have any sysadmin privileges to do this. You don't even have to have my permission to do this. Eric From dporter at well.sf.ca.us Sun Jun 13 09:46:04 1993 From: dporter at well.sf.ca.us (Doug Porter) Date: Sun, 13 Jun 93 09:46:04 PDT Subject: PKP Message-ID: <93Jun13.094534pdt.13887-3@well.sf.ca.us> Ok, PKP now effectively has a monopoly. Is an antitrust action appropriate? The timing of this announcement, just after Clipper got set back hard, may be significant. It would have raised far fewer suspicions to put the license out to bid and then make sure PKP got it. My partner, who rejects conspiracy theories out of hand, described the action as "stupid". The folks at Meade may be running scared. The announcement is viewed by some as unnecessarily verifying PKP as a previously hidden asset. If someone is overreacting, perhaps those fighting for freedom are getting to them. Doug From honey at citi.umich.edu Sun Jun 13 10:06:12 1993 From: honey at citi.umich.edu (peter honeyman) Date: Sun, 13 Jun 93 10:06:12 PDT Subject: PKP In-Reply-To: <93Jun13.094534pdt.13887-3@well.sf.ca.us> Message-ID: <9306131706.AA09634@toad.com> > Ok, PKP now effectively has a monopoly. Is an antitrust action > appropriate? no. establishing and securing a monopoly is the whole point of patent law. personally, i plan to continue to infringe on the pkp patents -- protected by the research use exclusion and the rsaref noncommerical-use license -- while the onslaught of time makes pkp assets ever less viable. fuck 'em. join me. peter From dporter at well.sf.ca.us Sun Jun 13 12:36:28 1993 From: dporter at well.sf.ca.us (Doug Porter) Date: Sun, 13 Jun 93 12:36:28 PDT Subject: PKP Message-ID: <93Jun13.123601pdt.13888-1@well.sf.ca.us> > establishing and securing a monopoly is the whole point of patent law. Sure is; but patents are intended to convey a sharply limited monopoly. I seem to remember Judge Green expressing intense dissatisfaction with interlocking patents used to control an entire industry. We need info from someone who knows. Mike, are you listening, and are you familiar with antitrust law? Doug From miron at extropia.wimsey.com Sun Jun 13 15:49:12 1993 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Sun, 13 Jun 93 15:49:12 PDT Subject: alt.whistleblowing In-Reply-To: <9306130817.AA01161@triton.unm.edu> Message-ID: <1993Jun13.213716.16151@extropia.wimsey.com> mdiehl at triton.unm.edu (J. Michael Diehl) writes: >I just started reading the alt.whistleblowing newsgroup. It would seem that That is strange, I'm not getting anything here. Maybe there is a propagation problem. What is the recommended action in this case? Posting to alt.config, or resending the newgroup message? -- 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. From smb at research.att.com Sun Jun 13 17:08:10 1993 From: smb at research.att.com (smb at research.att.com) Date: Sun, 13 Jun 93 17:08:10 PDT Subject: corporations and morality Message-ID: <9306140008.AA22117@toad.com> I stumbled on a quote that succinctly expresses what I was saying about the lack of corporate morality. This is the head quote from Chapter XIX of Niven and Pournelle's ``Oath of Fealty'': They [corporations] cannot commit treason, nor be outlawed nor excommunicated, for they have no souls. --Sir Edward Coke, Lord Chief Justice of England Sutton's Hospital Case, 10 Report 32, 1628 From hkhenson at cup.portal.com Sun Jun 13 18:05:22 1993 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Sun, 13 Jun 93 18:05:22 PDT Subject: alt.whistleblowing Message-ID: <9306131218.1.10271@cup.portal.com> Can an alt.group be moderated? If so, the moderator could be through an anon remailer. Of course, bozos can still add their sig line. :) Keith From mdiehl at triton.unm.edu Sun Jun 13 18:12:17 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sun, 13 Jun 93 18:12:17 PDT Subject: alt.whistleblowing In-Reply-To: <1993Jun13.213716.16151@extropia.wimsey.com> Message-ID: <9306140111.AA16461@triton.unm.edu> According to Miron Cuperman: > mdiehl at triton.unm.edu (J. Michael Diehl) writes: > >I just started reading the alt.whistleblowing newsgroup. It would seem that > > That is strange, I'm not getting anything here. Maybe there is a > propagation problem. Well, it took a week to make it here..... > What is the recommended action in this case? Posting to alt.config, > or resending the newgroup message? Couldn't tell you, except, perhapse to be patient? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Sun Jun 13 18:15:25 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sun, 13 Jun 93 18:15:25 PDT Subject: Digital Cash$$$$ Message-ID: <9306140115.AA16633@triton.unm.edu> Hay all! I'm becomming very intrigued about digital cash. But, I have a few qestions. 1. How does one start a digital cash economy? How is the initial distribution of currency done? This is, of course, assuming the technical stuff is taken care of. 2. Is digital cash supposed to be backed by actuall cash on deposit at the bank? 3. How would one "get out" of such an economy if he wanted to? 4. If DC is to be backed by actual cash, is this really such a good idea? Looking forward to hearing any and all comments. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From surfpunk at osc.versant.com Sun Jun 13 18:37:47 1993 From: surfpunk at osc.versant.com (erfhetraf) Date: Sun, 13 Jun 93 18:37:47 PDT Subject: [surfpunk-0086] CRYPT: PKP and NIST cross-license Message-ID: #ifdef __CYPHERPUNKS fellow cypherpunks -- I'm forwarding you this copy of SURFPUNK that I just produced. It tries to deal with the cypherpunk events of the last few days. If someone has a good summary of all this, a cypherpunk press release, so to speak, I'd love to publish it, too. Also corrections and clarifications and even flames are welcome. Brief info on SURFPUNK -- we cover cypherpunk, cyberpunk, conscious hacking, public policy, what's new on the net, etc. We republish a lot of hard information from other lists. We have some overlap with cypherpunks, but pretty much SURFPUNK is reaching 300 more people. keep practicing, strick strick at versant.com #endif /*__CYPHERPUNKS*/ # Subject: I want my SURFPUNK # # I don't know what happened to my subscription to # SURFPUNK, but I haven't received an issue since # May 5. I'd like to have it back. Thanks. # # -- a concerned surfpunker Whew. It's been a long time. Apologies. I've had a different sort of mailer problems each week. But I hope we're back now to stay. If you haven't received an issue since #0085 on Wed, 5 May 93, you're not missing any. We've been out for a good month. Our address has simplified. We are now simply "surfpunk at versant.com". It used to be "surfpunk at osc.versant.com". You can now drop the "osc". If you are missing surfpunks, or want old backissues, use the "www" (or "xmosaic") server with the Universal Record Locator http://www.acns.nwu.edu/surfpunk/ (and check out the first issue of BLINK while you're there). [ Write for more info on BLINK. ] This is a theme issue -- see the first article. --strick ________________________________________________________________________ ________________________________________________________________________ 0000000 a55a e970 d8f6 7ea7 3838 6988 5c4e 337c 0000020 ba89 c087 915b 4652 fa21 e20e c5db 3e03 0000040 a856 e161 fa23 50d3 efa9 0641 96c8 50a5 0000060 ee84 beb0 b865 d2d8 8299 f98c 2e97 a2d3 0000100 4df7 db2a 8845 6ea3 1068 a3f8 331f 0c6d 0000120 efe8 4ac7 d0c7 5eb7 f4ce 9434 22f8 c2c6 0000140 d2bd 2db2 40d9 8672 f4f4 f0ed da9f 7393 0000160 b9d2 15d4 e653 d649 a15c 2161 f7bc 62ed ________________________________________________________________________ Subject: _f y__ c_n wr_t_ th_s, g_ t_ j__l From: strick This issue will contain a number of documents relating to cryptography. The last couple of months have seen a lot of action in this realm, and I wish I had a good summary of what the big moves were and what the current status is. It would be difficult, however, to separate the plain fact of what documents say from what they imply and what is really going on behind the scenes. Here's a very brief, highlevel summary, from my own point of view. It's probably not too far off from the consensus at the Mountain View Cypherpunks physical meeting last weekend. It discussses US policy, but it will certainly influence the rest of the world's policies. We seem to be moving from an era when the US policy on cryptography was something like this: Any encryption is legal within the US [ and perhaps Canada ] boundaries, but only very weak encryption can be exported. The restrictions on export may not have made much sense on the surface, but they have sucessfully prevented the really popular products from using encryption. In effect, the available encryption is weak enough that a determined agent, perhaps the U S Government, can easily crack it. The new era might be this: Strong encryption is available within the US, and even mandated in some cases, but only encryption that leaves "escrowed" keys is allowed. The escrowed keys are available to the U S Government. Any other strong encryption is made illegal. How to make encryption illegal is a good question. Any strings of seemingly random numbers could potentially be an encrypted message. Could you imagine going to jail if you cannot decode stray bits? I'm not going to try to convince you that this is the ultimate goal, but I do hope you will try to understand what is happening. A paranoid view is that all of these decisions are already made, and the technology is in place, and now, with only token public debate, the system will be put in place. If this is correct, then President Clinton will be of little help; he is already a strong proponent of the Clipper chip. I don't know if the paranoid view is correct, but it is plausible. Sorry if this isn't a fun issue. I hope the documents I pick are helpful. What's in this issue of SURFPUNK: -- NIST and PKP cross-lisence, to lock public key encryption and the NIST-proposed digitial signature algorithm. About two months ago PKP acquired the Schorr patent, which supposedly covers the DSA algorithm that NIST proposes for digital signatures. -- Opinion by Hal Finney -- Opinion by L. Detweiler -- NIST Crypto Resolutions, Computer System Security and Privacy Advisory Board, June 4, 1993 -- CPSR Crypto Statement to NIST Computer System Security and Privacy Advisory Board, June 1993 -- CPSR Crypto Statement to The Subcommittee on Telecommunications and Finance, Committee on Energy and Commerce, U.S. House of Representatives, June 9, 1993 [ from CuD #5.43 ] For more info, try these resources: ** Usenet groups sci.crypt ** Usenet groups comp.risks (RISKS Forum) ** Usenet groups comp.org.eff.news ** Usenet groups comp.org.eff.talk ** EFF ftp site: ftp.eff.org ** Cypherpunks mailing list: cypherpunk-request at toad.com ** Cypherpunks ftp site soda.berkeley.edu : /pub/cypherpunks ** Computer Underground Digest Usenet group comp.society.cu-digest subscriptions: tk0jut2 at mvs.cso.niu.edu ANONYMOUS FTP SITES: UNITED STATES: ftp.eff.org (192.88.144.4) in /pub/cud uglymouse.css.itd.umich.edu (141.211.182.53) halcyon.com( 202.135.191.2) in /pub/mirror/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) ________________________________________________________________________ 0000200 ff5d 91ce 4fff ad85 57b4 a2a8 b354 9cd0 0000220 ab61 c3f6 ad38 d6dd 7f74 01ad e27e ca2e 0000240 e348 3346 1c03 c629 dfa0 09b7 43f6 f992 0000260 25a1 e863 6f16 49a1 cf88 2fdb 4562 00ec 0000300 b330 9bff 2493 5b5c 59cc 7dbc c0cf 46f2 0000320 888d b538 d02a ae5a 0153 ad8f fd19 8ebb 0000340 f25a 0712 8e87 be58 6e27 b639 21ab ddb7 0000360 4026 b065 f228 bad9 bc7e f407 3713 1246 ________________________________________________________________________ To: cypherpunks at toad.com Subject: it's official: PKP sells out for Clipper Date: Fri, 11 Jun 93 20:19:45 -0600 From: ""L. Detweiler"" >From the following document: >PKP will also grant a license to practice key management, at no >additional fee, for the integrated circuits which will implement >both the DSA and the anticipated Federal Information Processing >Standard for the "key escrow" system announced by President Clinton >on April 16, 1993. more weasel words: >Notice of availability of this invention for licensing >was waived because it was determined that expeditious granting of >such license will best serve the interest of the Federal Government >and the public. what else? ===cut=here=== From: jim at rand.org (Jim Gillogly) Newsgroups: sci.crypt Subject: DSA: NIST and PKP come to terms Message-ID: <16860 at rand.org> Date: 11 Jun 93 20:56:44 GMT Sender: news at rand.org Organization: Banzai Institute This text was transcribed from a fax and may have transcription errors. We believe the text to be correct but some of the numbers may be incorrect or incomplete. --------------------------------------------------------------------- ** The following notice was published in the Federal Register, Vol. 58, No. 108, dated June 8, 1993 under Notices ** National Institute of Standards and Technology Notice of Proposal for Grant of Exclusive Patent License This is to notify the public that the National Institute of Standards and Technology (NIST) intends to grant an exclusive world-wide license to Public Key Partners of Sunnyvale, California to practice the Invention embodied in U.S. Patent Application No. 07/738.431 and entitled "Digital Signature Algorithm." A PCT application has been filed. The rights in the invention have been assigned to the United States of America. The prospective license is a cross-license which would resolve a patent dispute with Public Key Partners and includes the right to sublicense. Notice of availability of this invention for licensing was waived because it was determined that expeditious granting of such license will best serve the interest of the Federal Government and the public. Public Key Partners has provided NIST with the materials contained in Appendix A as part of their proposal to NIST. Inquiries, comments, and other materials relating to the prospec- tive license shall be submitted to Michael R. Rubin, Active Chief Counsel for Technology, Room A-1111, Administration Building, National Institute of Standards and Technology, Gaithersburg, Maryland 20899. His telephone number is (301) 975-2803. Applica- tions for a license filed in response to this notice will be treated as objections to the grant of the prospective license. Only written comments and/or applications for a license which are received by NIST within sixty (60) days for the publication of this notice will be considered. The prospective license will be granted unless, within sixty (60) days of this notice, NIST receives written evidence and argument which established that the grant of the license would not be consistent with the requirements of 35 U.S.C. 209 and 37 CFR 404.7. Dated: June 2, 1993. Raymond G. Kammer Acting Director, National Institute Standards and Technology. Appendix "A" The National Institute for Standards and Technology ("NIST") has announced its intention to grant Public Key Partners ("PKP") sublicensing rights to NIST's pending patent application on the Digital Signature Algorithm ("DSA"). Subject to NIST's grant of this license, PKP is pleased to declare its support for the proposed Federal Information Processing Standard for Digital Signatures (the "DSS") and the pending availability of licenses to practice the DSA. In addition to the DSA, licenses to practice digital signatures will be offered by PKP under the following patents: Cryptographic Apparatus and Method ("Diffie-Hellman") No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle") No. 4,315,552 Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig") No. 4,434,414 Method For Identifying Subscribers And For Generating And Verifying Electronic Signatures In A Data Exchange System ("Schnorr") No. 4,995,082 It is PKP's intent to make practice of the DSA royalty free for personal, noncommercial and U.S. Federal, state and local government use. As explained below, only those parties who enjoy commercial benefit from making or selling products, or certifying digital signatures, will be required to pay royalties to practice the DSA. PKP will also grant a license to practice key management, at no additional fee, for the integrated circuits which will implement both the DSA and the anticipated Federal Information Processing Standard for the "key escrow" system announced by President Clinton on April 16, 1993. Having stated these intentions, PKP now takes this opportunity to publish its guidelines for granting uniform licenses to all parties having a commercial interest in practicing this technology: First, no party will be denied a license for any reason other that the following: (i) Failure to meet its payment obligations, (ii) Outstanding claims of infringement, or (iii) Previous termination due to material breach. Second, licenses will be granted for any embodiment sold by the licensee or made for its use, whether for final products software, or components such as integrated circuits and boards, and regard- less of the licensee's channel of distribution. Provided the requisite royalties have been paid by the seller on the enabling component(s), no further royalties will be owned by the buyer for making or selling the final product which incorporates such components. Third, the practice of digital signatures in accordance with the DSS may be licensed separately from any other technical art covered by PKP's patents. Fourth, PKP's royalty rates for the right to make or sell products, subject to uniform minimum fees, will be no more than 2 1/2% for hardware products and 5% for software, with the royalty rate further declining to 1% on any portion of the product price exceeding $1,000. These royalty rates apply only to noninfringing parties and will be uniform without regard to whether the licensed product creates digital signatures, verifies digital signatures or performs both. Fifth, for the next three (3) years, all commercial services which certify a signature's authenticity for a fee may be operated royalty free. Thereafter, all providers of such commercial certification services shall pay a royalty to PKP of $1.00 per certificate for each year the certificate is valid. Sixth, provided the foregoing royalties are paid on such products or services, all other practice of the DSA shall be royalty free. Seventh, PKP invites all of its existing licensees, at their option, to exchange their current licenses for the standard license offered for DSA. Finally, PKP will mediate the concerns of any party regarding the availability of PKP's licenses for the DSA with designated representatives of NIST and PKP. For copies of PKP's license terms, contact Michael R. Rubin, Acting Chief Counsel for Technolo- gy, NIST, or Public Key Partners. Dated: June 2, 1993. Robert B. Fougner, Esq., Director of Licensing, Public Key Partners, 310 North Mary Avenue, Sunnyvale, CA 94033 [FR Doc. 93-13473 Filed 8-7-93; 8:45 am] --------------------------------------------------------------------- Forwarded by: -- Jim Gillogly Trewesday, 21 Forelithe S.R. 1993, 20:56 ________________________________________________________________________ 0000400 408c 5e2c 8c0b 8ad6 d941 4bae a2a9 0c4f 0000420 8aee 82fa 2e90 5515 e195 31a9 34d0 103c 0000440 aecc 33d5 7ab8 2f94 ce33 78e4 0419 d967 0000460 2808 d042 0e59 c194 d2d0 d0bc 3299 d18e 0000500 7266 8380 cd47 0372 40a2 9d1f ff6d d234 0000520 69ae 12d4 539c 70cc ac9a 5877 c689 ebeb 0000540 3074 5be2 68ec 3b91 961d 48f0 82c8 dc2d 0000560 bf18 1cd2 edb2 f1d0 1480 80f0 c634 f119 ________________________________________________________________________ From: hal at alumni.cco.caltech.edu (Hal Finney) Date: Fri, 11 Jun 93 22:27:09 PDT To: cypherpunks at toad.com Subject: PKP sellout? This was my response on sci.crypt to this announcement that PKP will be supporting DSS, and licensing its technology for use by Clipper phones. Thanks to Lance for alerting us to this announcement. ----- jim at rand.org (Jim Gillogly) forwards: >This is to notify the public that the National Institute of >Standards and Technology (NIST) intends to grant an exclusive >world-wide license to Public Key Partners of Sunnyvale, California >to practice the Invention embodied in U.S. Patent Application No. >07/738.431 and entitled "Digital Signature Algorithm." And so it appears that another patent jewel will be added to the crown worn by PKP, the de facto owner of cryptographic technology in the United States. They will have an exclusive license to the DSA, as they already do to RSA and most other worthwhile encryption technologies. This also appears to put to rest the much-publicized feud between RSA and NIST/NSA. Conspiracy theorists can now comfortably return to the position that PKP/RSADSI is actually an arm of the NSA, dedicated to restricting and delaying access to strong cryptography as much as possible. >Notice of availability of this invention for licensing >was waived because it was determined that expeditious granting of >such license will best serve the interest of the Federal Government >and the public. Once again we are presented with a fait accompli; no other organizations were given an opportunity to bid for the licensing of this patent. The government prefers to see PKP holding the keys to all cryptography in the U.S. Remember how Clipper's technology was similarly assigned to particular corporations on a non-competitive basis? >Subject to NIST's grant of this license, PKP is pleased to declare >its support for the proposed Federal Information Processing >Standard for Digital Signatures (the "DSS") and the pending >availability of licenses to practice the DSA. And what of the technical objections to DSA/DSS raised in earlier documents by officials of RSADSI, such as in the recent CACM? No doubt those objections are now moot. >PKP will also grant a license to practice key management, at no >additional fee, for the integrated circuits which will implement >both the DSA and the anticipated Federal Information Processing >Standard for the "key escrow" system announced by President Clinton >on April 16, 1993. So PKP is now supporting key escrow and Clipper. Can anyone seriously argue that this company is a friend to supporters of strong cryptography? These are dark times indeed. PKP has thrown in with the government, getting behind DSS and Clipper in exchange for exclusive licensing rights. Their ownership of DH and RSA will make it that much harder for any competition to Clipper to arise. If the 60-day comment period really means anything, perhaps public criticism can be effective here. There is much to be concerned about in this announcement. Hal Finney hal at alumni.caltech.edu ________________________________________________________________________ 0000600 c8aa 62f7 811f e878 3616 b536 f59e fe2d 0000620 90fe 7f30 88fd 3576 29bf 9a02 0929 f48b 0000640 51a5 089b 795e 5849 61eb 1a5e f78f 3c6b 0000660 46c2 dd52 ae1b 42bb 926c 6be1 7709 5de3 0000700 0be1 7ae3 d9d4 1421 ca27 c0c0 e202 3814 0000720 850c 5164 74a1 2586 c012 660e f38a 1ba9 0000740 7fd0 dd7a 3608 63de 20ee 94fd c55c ef3d 0000760 41b2 89f9 e373 f2b5 df3e eaf0 142e a17b ________________________________________________________________________ To: cypherpunks at toad.com Subject: PKP sellout = betrayal Date: Sun, 13 Jun 93 00:00:45 -0600 From: ""L. Detweiler"" S. Bellovin >I don't see the hand of conspiracy here; rather, I see an encouraging >trend, that the private sector is able to compete in cryptographic >competence with NSA. > >I am encouraged by the pledges to allow non-commercial use -- note the >lack of any RSAREF-like interface -- and to engage in non-discriminatory >licensing. By cooperating with NIST on DSA and Clipper, they are implicitly sending the message that the poorly-to-outrageously directed standards making processes for both are wholly acceptable assuming PKP directly profits. That is, that is the weak `nonconspirational' interpretation. The conspirational interpretation is that this announcement is just a blatant indication that PKP, in addition to NIST, is controlled by the NSA. Let me remind everyone that Capstone has a yet-unspecified exchange protocol. Denning suggested on RISKS that Diffie-Hellman (covered by PKP patents) `could be used'. There is some serious evasion going on here. If Capstone is already built, with a public-key algorithm installed, it suggests that PKP has been cooperating on the Clipper/Capstone proposals all along. It will be most interesting to hear announcements on Capstone that announce its key exchange mechanism. PKP `had' the ability to murder Clipper/Capstone in its crib if it so desired, more so than any other single nexus, by denying the right to use public key algorithms (on which it now has a strangling, monopolistic lock). Gad, I can't believe it didn't occur to me to lobby them to do so. In retrospect, it wouldn't have done anything more than heighten the inevitable betrayal. Maybe Mr. Bellovin can clarify how this agreement represents an `encouraging trend in the private sector to compete with the NSA' -- Good lord man, not unless you think that PKP represents the entire private sector in cryptographic applications. Uh, touche' -- you do and it does. Does anybody feel like raiding PKP dumpsters? :( P.S. doubt P.R.Z. will be in a docile mood after hearing this one... ________________________________________________________________________ 0001000 26b5 740f 361d c550 1053 5998 56dc 1e64 0001020 01e9 8f39 a3e2 e991 1e37 bd23 3c9d 07f2 0001040 9892 7e43 17ed bef3 10d0 c9ea 7b1a f2ed 0001060 5b94 23ef d25f ebe4 91d8 b9fc 638b 7704 0001100 adf7 ac9f 412f 7a67 a2a7 9c59 dcf4 135b 0001120 fdfa 3dd3 4656 4ce2 74bc 4fe7 17e4 ec78 0001140 52c3 93e5 4472 1336 7e88 b901 cc76 c18e 0001160 a949 456d 2c94 6c0e 90fc d109 e2ed 224b ________________________________________________________________________ From: Dave Banisar Newsgroups: alt.privacy,alt.security,comp.org.eff.talk,sci.crypt,alt.privacy.clipper Subject: NIST CSSPAB Resolutions 6/4/93 Date: 5 Jun 1993 00:48:11 GMT Organization: CPSR Washington Office NIST Crypto Resolutions Computer System Security and Privacy Advisory Board June 4, 1993 Resolution #1 At Mr. Kammer's request we have conducted two days of hearings. The clear message of the majority of input was that there are serious concerns regarding the Key Escrow Initiative and the Board concurs with these concerns. Many of these issues are still to be fully understood and more time is needed to achieving that understanding. Accordingly, this Board resolves to have an additional meeting in July 1993 in order to more completely respond to Mr. Kammer's request and to fulfill its statutory obligations under P.L. 100-235. The Board recommends that the inter-agency review take note of our input collected, our preliminary finding, and adjust the timetable to allow for resolution of the significant issues and problems raised. Attached to this resolution is a preliminary distillation of the serious concerns and problems. Resolution #2 Key escrowing encryption technology represents a dramatic change in the nation's information infrastructure. The full implications of this encryption technique are not fully understood at this time. Therefore, the Board recommends that key escrowing encryption technology not be deployed beyond current implementations planned within the Executive Branch, until the significant public policy and technical issues inherent with this encryption technique are fully understood. [Attachment to Resolution #1]] - A convincing statement of the problem that Clipper attempts to solve has not been provided. - Export and important controls over cryptographic products must be reviewed. Based upon data compiled from U.S. and international vendors, current controls are negatively impacting U.S. 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 a critical and significant component of the National Information Infrastructure and the U.S. 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. It does not appear to be clearly defined at this time and, since it is an integral part of the security of the system, it appears to require further development and consideration of alternatives to the key escrow scheme (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 systems 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. ======================================================= NIST Resolutions on Key Escow Issues and Clipper provided by CPSR Washington office 666 Pennsylvania Ave., SE Suite 303 Washington, DC 20003 rotenberg at washofc.cpsr.org ======================================================= ________________________________________________________________________ 0001200 87ce da42 62c0 89bf aae8 c933 f8c2 c29b 0001220 9e7b c03b 3c4f b60e 27b0 1114 2018 d5f7 0001240 2dd0 e567 12aa df8b ae74 86bc aed8 48e4 0001260 5b1e 9e14 5d51 6dca 158a 16ae 4590 87f4 0001300 2bbf d387 bcc6 9e23 aaa9 6af1 591d eb26 0001320 a780 9bbb 85fb 0cef fabe fe9f 2d63 f2ad 0001340 460d 2de6 4e0e 7058 85de bc5e 17f1 4ffb 0001360 006a 3347 8da1 192b 01d3 da57 98ed f6c3 ________________________________________________________________________ Organization: CPSR Civil Liberties and Computing Project From: Dave Banisar To: CYPHERPUNKS Date: Wed, 2 Jun 1993 21:20:10 EST Subject: CPSR NIST Crypto Statement CPSR NIST Crypto Statement Department of Commerce National Institute of Standards and Technology Computer System Security and Privacy Advisory Board Review of Cryptography Policy June 1993 Statement of CPSR Washington office Marc Rotenberg, director (rotenberg at washofc.cpsr.org) with David Sobel, legal counsel, Dave Banisar, policy analyst Mr. Chairman, members of the Advisory Panel, thank you for the opportunity to speak today about emerging issues on cryptography policy. My name is Marc Rotenberg and I am director of the CPSR Washington office. Although CPSR does not represent any computer firm or industry trade association, we speak for many in the computer profession who value privacy and are concerned about the government's Clipper proposal. During the last several years CPSR has organized several meetings to promote public discussion of cryptography issues. We have also obtained important government documents through the Freedom of Information Act. We believe that good policies will only result if the public, the profession, and the policy makers are fully informed about the significance of these recent proposals. We are pleased that the Advisory Board has organized hearings. This review of cryptography policy will help determine if the Clipper proposal is in the best interests of the country. We believe that a careful review of the relevant laws and policies shows that the key escrow arrangement is at odds with the public interest, and that therefore the Clipper proposal should not go forward. Today I will address issues 1 through 3 identified in the NIST announcement, specifically the policy requirements of the Computer Security Act, the legal issues surrounding the key escrow arrangement, and the importance of privacy for network development. 1. CRYPTOGRAPHY POLICY The first issue concerns the 1987 statute enacted to improve computer security in the federal government, to clarify the responsibilities of NIST and NSA, and to ensure that technical standards would serve civilian and commercial needs. The Computer Security Act, which also established this Advisory Panel, is the true cornerstone of cryptography policy in the United States. That law made clear that in the area of unclassified computing systems, the Department of Commerce and not the Department of Defense, would be responsible for the development of technical standards. It emphasized public accountability and stressed open decision-making. The Computer Security Act grew out of a concern that classified standards and secret meetings would not serve the interests of the general public. As the practical applications for cryptography have moved from the military and intelligence arenas to the commercial sphere, this point has become clear. There is also clearly a conflict of interest when an agency tasked with signal interception is also given authority to develop standards for network security. In the spirit of the Computer Security Act, NIST set out in 1989 to develop a public key standard FIPS. In a memo dated May 5, 1989 and obtained by CPSR through the Freedom of Information Act, NIST said that it planned: to develop the necessary public-key based security standards. We require a public-key algorithm for calculating digital signatures and we also require a public-key algorithm for distributing secret keys. NIST then went on to define the requirements of the standard: The algorithms that we use must be public, unclassified, implementable in both hardware or software, usable by federal Agencies and U.S. based multi-national corporation, and must provide a level of security sufficient for the protection of unclassified, sensitive information and commercial propriety and/or valuable information. The Clipper proposal and the full-blown Capstone configuration, which incorporates the key management function NIST set out to develop in 1989, is very different from the one originally conceived by NIST. % The Clipper algorithm, Skipjack, is classified, % Public access to the reasons underlying the proposal is restricted, % Skipjack can be implemented only in tamper-proof hardware, % It is unlikely to be used by multi-national corporations, and % Its security remains unproven. The Clipper proposal undermines the central purpose of the Computer Security Act. Although intended for broad use in commercial networks, it was not developed at the request of either U.S. business or the general public. It does not reflect public goals. Rather it reflects the interests of one secret agency with the authority to conduct foreign signal intelligence and another government agency responsible for law enforcement investigations. It is our belief that the Clipper proposal clearly violates the intent of the Computer Security Act of 1987. What is the significance of this? It is conceivable that an expert panel of cryptographers will review the Skipjack algorithm and find that it lives up its billing, that there is no "trap door" and no easy way to reverse-engineer. In fact, the White House has proposed just such a review process But is this process adequate? Is this the procedure the Advisory Board would endorse for the development of widespread technical standards? The expert participants will probably not be permitted to publish their assessments of the proposal in scientific journals, further review of the standard will be restricted, and those who are skeptical will remain in the dark about the actual design of the chip. This may be an appropriate process for certain military systems, but it is clearly inappropriate for a technical standard that the government believes should be widely incorporated into the communications infrastructure. Good government policy requires that certain process goals be satisfied. Decisions should be made in the open. The interests of the participating agencies should be clear. Agencies should be accountable for their actions and recommendations. Black boxes and government oversight are not compatible. There is an even greater obligation to promote open decisions where technical and scientific issues are at stake. Innovation depends on openness. The scientific method depends on the ability of researchers to "kick the tires" and "test drive" the product. And, then, even if it is a fairly good design, additional testing encourages the development of new features, improved performance and reduced cost. Government secrecy is incompatible which such a development process. Many of these principles are incorporated into the Computer Security Act and the Freedom of Information Act. The current government policy on the development of unclassified technical standards, as set out in the Computer Security Act, is a very good policy. It emphasizes public applications, stresses open review, and ensures public accountability. It is not the policy that is flawed. It is the Clipper proposal. To accept the Clipper proposal would be to endorse a process that ran contrary to the law, that discourages innovation, and that undermines openness. 2. LEGAL AND CONSTITUTIONAL ISSUES There are several legal and constitutional issues raised by the government's key escrow proposal. The premise of the Clipper key escrow arrangement is that the government must have the ability to intercept electronic communications, regardless of the economic or societal costs. The FBI's Digital Telephony proposal, and the earlier Senate bill 266, was based on the same assumption. There are a number of arguments made in defense of this position: that privacy rights and law enforcement needs must be balanced, or that the government will be unable to conduct criminal investigations without this capability. Regardless of how one views these various claims, there is one point about the law that should be made very clear: currently there is no legal basis -- in statute, the Constitution or anywhere else -- that supports the premise which underlies the Clipper proposal. As the law currently stands, surveillance is not a design goal. General Motors would have a stronger legal basis for building cars that could not go faster than 65 miles per hour than AT&T does in marketing a commercial telephone that has a built-in wiretap capability. In law there is simply nothing about the use of a telephone that is inherently illegal or suspect. The federal wiretap statute says only that communication service providers must assist law enforcement in the execution of a lawful warrant. It does not say that anyone is obligated to design systems to facilitate future wire surveillance. That distinction is the difference between countries that restrict wire surveillance to narrow circumstances defined in law and those that treat all users of the telephone network as potential criminals. U.S. law takes the first approach. Countries such as the former East Germany took the second approach. The use of the phone system by citizens was considered inherently suspect and for that reason more than 10,000 people were employed by the East German government to listen in on telephone calls. It is precisely because the wiretap statute does not contain the obligation to incorporate surveillance capability -- the design premise of the Clipper proposal -- that the Federal Bureau of Investigation introduced the Digital Telephony legislation. But that legislation has not moved forward on Capitol Hill and the law has remained unchanged. The Clipper proposal attempts to accomplish through the standard-setting and procurement process what the Congress has been unwilling to do through the legislative process. On legal grounds, adopting the Clipper would be a mistake. There is an important policy goal underlying the wiretap law. The Fourth Amendment and the federal wiretap statute do not so much balance competing interests as they erect barriers against government excess and define the proper scope of criminal investigation. The purpose of the federal wiretap law is to restrict the government, it is not to coerce the public. Therefore, if the government endorses the Clipper proposal, it will undermine the basic philosophy of the federal wiretap law and the fundamental values embodied in the Constitution. It will establish a technical mechanism for signal interception based on a premise that has no legal foundation. I am not speaking rhetorically about "Big Brother." My point is simply that the assumption underlying the Clipper proposal is more compatible with the practice of telephone surveillance in the former East Germany than it is with the narrowly limited circumstances that wire surveillance has been allowed in the United States. There are a number of other legal issues that have not been adequately considered by the proponents of the key escrow arrangement that the Advisory Board should examine. First, not all lawful wiretaps follow a normal warrant process. It is critical that the proponents of Clipper make very clear how emergency wiretaps will be conducted before the proposal goes forward. Second, there may be civil liability issues for the escrow agents if there is abuse or compromise of the keys. Escrow agents may be liable for any harm that results. Third, there is a Fifth Amendment dimension to the proposed escrow key arrangement if a network user is compelled to disclose his or her key to the government in order to access a communications network. Each one of these issues should be examined. There is also one legislative change that we would like the Advisory Board to consider. During our FOIA litigation, the NSA cited a 1951 law to withhold certain documents that were critical to understand the development of the Digital Signature Standard. The law, passed grants the government the right restrict the disclosure of any classified information pertaining to cryptography. While the government may properly withhold classified information in FOIA cases, the practical impact of this particular provision is to provide another means to insulate cryptographic policy from public review. Given the importance of public review of cryptography policy, the requirement of the Computer Security Act, and the Advisory Board's own commitment to an open, public process, we ask the Advisory Board to recommend to the President and to the Congress that section 798 be repealed or substantially revised to reflect current circumstances. This is the one area of national cryptography policy where we believe a change is necessary. 3. INDIVIDUAL PRIVACY Communications privacy remains a critical test for network development. Networks that do not provide a high degree of privacy are clearly less useful to network users. Given the choice between a cryptography product without a key escrow and one with a key escrow, it would be difficult to find a user who would prefer the key escrow requirement. If this proposal does go forward, it will not be because network users or commercial service providers favored it. Many governments are now facing questions about restrictions on cryptography similar to the question now being raised in this country. It is clear that governments may choose to favor the interests of consumers and businesses over law enforcement. Less than a month ago, the government of Australia over-rode the objections of law enforcement and intelligence agencies and allowed the Australian telephone companies to go forward with new digital mobile phone networks, GSM, using the A5 robust algorithm. Other countries will soon face similar decisions. We hope that they will follow a similar path To briefly summarize, the problem here is not the existing law on computer security or policies on cryptography and wire surveillance. The Computer Security Act stresses public standards, open review, and commercial applications. The federal wiretap statute is one of the best privacy laws in the world. With the exception of one provision in the criminal code left over from the Cold War, our current cryptography policy is very good. It reflects many of the values -- individual liberty, openness, government accountability -- that are crucial for democratic societies to function. The problem is the Clipper proposal. It is an end-run around policies intended to restrict government surveillance and to ensure agency accountability. It is an effort to put in place a technical configuration that is at odds with the federal wiretap law and the protection of individual privacy. It is for these reasons that we ask the Advisory Board to recommend to the Secretary of Commerce, the White House, and the Congress that the current Clipper proposal not go forward. I thank you for the opportunity to speak with you about these issues. I wish to invite the members of the Advisory Committee to the third annual CPSR Privacy and Cryptography conference that will be held Monday, June 7 in Washington, DC at the Carnegie Endowment for International Peace. That meeting will provide an opportunity for further discussion about cryptography policy. ATTACHMENTS "TWG Issue Number: NIST - May 5, 1989," document obtained by CPSR as a result of litigation under the Freedom of Information Act. "U.S. as Big Brother of Computer Age," The New York Times, May 6, 1993, at D1. "Keeping Fewer Secrets," Issues in Science and Technology, vol. IX, no. 1 (Fall 1992) "The Only Locksmith in Town," The Index on Censorship (January 1990) [The republication of these articles for the non-commercial purpose of informing the government about public policy is protected by section 107 of the Copyright Act of 1976] =============================================== ________________________________________________________________________ 0001400 f135 cf93 65f4 004a 2351 719b b2c9 cabe 0001420 c052 c788 2fff b5a3 616c 7fe0 6f45 6fe1 0001440 2005 3c8f 7ca8 29eb ee14 0785 5491 8039 0001460 2035 cc23 1a87 7a6c 4551 7869 7008 1d34 0001500 ac37 e2d2 6bb5 5139 d137 9d38 0727 50af 0001520 fd74 2e07 4bcd 2bc4 200b 4349 d2b0 9151 0001540 b5a2 e493 41d2 c559 9dbc 2a17 61aa cf59 0001560 9aa2 81b6 e41b 13ca 70b6 470c 5cd6 30a7 ________________________________________________________________________ Source: Computer underground Digest Sun June 13 1993 Volume 5 : Issue 43 ISSN: ISSN 1004-043X Date: Sat, 12 Jun 1993 12:30:38 EST From: Dave Banisar Subject: File 2--CPSR Clipper Testimony (6-9-93) in House Subcommittee CPSR Clipper Testimony 6/9 On June 9, 1993, Congressman Edward Markey, Chairman of the House Subcommittee on Telecommunications and Finance held an oversight hearing on Rencryption and telecommunications network security. Panelists were Whitfield Diffie of Sun Microsystems, Dr. Dorothy Denning, Steven Bryen of Secure Communications, Marc Rotenberg of the CPSR Washington Office and E.R. Kerkeslager of AT&T. Congressman Markey, after hearing the testimony presented, noted that the Clipper proposal had raised an arched eyebrow among the whole committeeS and that the committee viewed the proposal skeptically. This statement was the latest indication that the Clipper proposal has not been well received by policy makers. Last Friday, the Computer Systems Security and Privacy Advisory Board of NIST issued two resolutions critical of the encryption plan, suggesting that further study was required and that implementation of the plan should be delayed until the review is completed. At the Third CPSR Cryptography and Privacy Conference on Monday, June 7, the Acting Director of NIST, Raymond Kammer, announced that the implementation of the proposal will be delayed and that a more comprehensive review will be undertaken. The review is due in the fall. Kammer told the Washington Post that Rmaybe we wonUt continue in the direction we started ous. +------------------------------------------------- Prepared Testimony and Statement for the Record of Marc Rotenberg, director CPSR Washington Office on Encryption Technology and Policy Before The Subcommittee on Telecommunications and Finance. Committee on Energy and Commerce U.S. House of Representatives June 9, 1993 SUMMARY The cryptography issue is of particular concern to CPSR. During the past several years CPSR has pursued an extensive study of cryptography policy in the United States. CPSR has organized public conferences, conducted litigation under the Freedom of Information Act, and has emphasized the importance of cryptography for privacy protection and the need to scrutinize carefully government proposals designed to limit the use of this technology. To evaluate the Clipper proposal it is necessary to look at a 1987 law, the Computer Security Act, which made clear that in the area of unclassified computing systems, the National Institute of Standards and Technology (NIST) and not the National Security Agency (NSA), would be responsible for the development of technical standards. The Act emphasized public accountability and stressed open decision-making. In the spirit of the Act, in 1989 NIST set out to develop a public key cryptography standard. According to documents obtained by CPSR through the Freedom of Information Act, NIST recommended that the algorithm be "public, unclassified, implementable in both hardware or software, usable by federal Agencies and U.S. based multi-national corporation." However, the Clipper proposal and the full-blown Capstone configuration that resulted is very different: the Clipper algorithm, Skipjack, is classified; public access to the reasons underlying the proposal is restricted; Skipjack can be implemented only in tamper-proof hardware; it is unlikely to be used by multi-national corporations, and the security of Clipper remains unproven. The Clipper proposal undermines the central purpose of the Computer Security Act. Although intended for broad use in commercial networks, it was not developed at the request of either U.S. business or the general public. It does not reflect public goals. The premise of the Clipper key escrow arrangement is that the government must have the ability to intercept electronic communications. However, there is no legal basis to support this premise. In law there is nothing inherently illegal or suspect about the use of a telephone. The federal wiretap statute says only that communication service providers must assist law enforcement execute a lawful warrant. CPSR supports the review of cryptography policy currently underway at the Department of Commerce. CPSR also supports the efforts undertaken by the Subcommittee on Telecommunications and Finance to study the full ramifications of the Clipper proposal. However, we are not pleased about the review now being undertaken at the White House. That effort has led to a series of secret meetings, has asked that scientists sign non-disclosure agreements and accept restrictions on publication, and has attempted to resolve public concerns through private channels. This is not a good process for the evaluation of a technology that is proposed for the public switched network. Even if the issues regarding Clipper are resolved favorably, privacy concerns will not go away. Rules still need to be developed about the collection and use of transactional data generated by computer communications. Several specific steps should be taken. First, the FCC should be given a broad mandate to pursue privacy concerns. Second, current gaps in the communications law should be filled. The protection of transactional records is particularly important. Third, telecommunications companies should be encouraged to explore innovative ways to protect privacy. "Telephone cards", widely available in other countries, are an ideal way to protect privacy. TESTIMONY Mr. Chairman, members of the Subcommittee, thank you for the opportunity to testify today on encryption policy and the Clipper proposal. I especially wish to thank you Congressman Markey, on behalf of CPSR, for your ongoing efforts on the privacy front as well as your work to promote public access to electronic information. The cryptography issue is of particular concern to CPSR. During the past several years we have pursued an extensive study of cryptography policy in the United States. We have organized several public conferences, conducted litigation under the Freedom of Information Act, and appeared on a number of panels to discuss the importance of cryptography for privacy protection and the need to scrutinize carefully government proposals designed to limit the use of this technology. While we do not represent any particular computer company or trade association we do speak for a great many people in the computer profession who value privacy and are concerned about the government's Clipper initiative. Today I will briefly summarize our assessment of the Clipper proposal. Then I would like to say a few words about the current status of privacy protection. CLIPPER To put the Clipper proposal in a policy context, I will need to briefly to describe a law passed in 1987 intended to address the roles of the Department of Commerce and the Department of Defense in the development of technical standards. The Computer Security Act of 1987 was enacted to improve computer security in the federal government, to clarify the responsibilities of the National Institute of Standards and Technology (NIST) and the National Security Agency, and to ensure that technical standards would serve civilian and commercial needs. The law made clear that in the area of unclassified computing systems, NIST and not NSA, would be responsible for the development of technical standards. It emphasized public accountability and stressed open decision-making. The Computer Security Act also established the Computer System Security and Privacy Advisory Board (CSSPAB), charged with reviewing the activities of NIST and ensuring that the mandate of the law was enforced. The Computer Security Act grew out of a concern that classified standards and secret meetings would not serve the interests of the general public. As the practical applications for cryptography have moved from the military and intelligence arenas to the commercial sphere, this point has become clear. There is also clearly a conflict of interest when an agency tasked with signal interception is also given authority to develop standards for network security. In the spirit of the Computer Security Act, NIST set out in 1989 to develop a public key standard FIPS (Federal Information Processing Standard). In a memo dated May 5, 1989, obtained by CPSR through the Freedom of Information Act, NIST said that it planned: to develop the necessary public-key based security standards. We require a public-key algorithm for calculating digital signatures and we also require a public-key algorithm for distributing secret keys. NIST then went on to define the requirements of the standard: The algorithms that we use must be public, unclassified, implementable in both hardware or software, usable by federal Agencies and U.S. based multi-national corporation, and must provide a level of security sufficient for the protection of unclassified, sensitive information and commercial propriety and/or valuable information. The Clipper proposal and the full-blown Capstone configuration, which incorporates the key management function NIST set out to develop in 1989, is very different from the one originally conceived by NIST. % The Clipper algorithm, Skipjack, is classified, % Public access to the reasons underlying the proposal is restricted, % Skipjack can be implemented only in tamper-proof hardware, % It is Unlikely to be used by multi-national corporations, and % The security of Clipper remains unproven. The Clipper proposal undermines the central purpose of the Computer Security Act. Although intended for broad use in commercial networks, it was not developed at the request of either U.S. business or the general public. It does not reflect public goals. Rather it reflects the interests of one secret agency with the authority to conduct foreign signal intelligence and another government agency responsible for law enforcement investigations. Documents obtained by CPSR through the Freedom of Information Act indicate that the National Security Agency dominated the meetings of the joint NIST/NSA Technical Working group which made recommendations to NIST regarding public key cryptography, and that a related technical standard for message authentication, the Digital Signature Standard, clearly reflected the interests of the NSA. We are still trying to determine the precise role of the NSA in the development of the Clipper proposal. We would be pleased to provide to the Subcommittee whatever materials we obtain. LEGAL AND POLICY ISSUES There are also several legal and constitutional issues raised by the government's key escrow proposal. The premise of the Clipper key escrow arrangement is that the government must have the ability to intercept electronic communications, regardless of the economic or societal costs. The FBI's Digital Telephony proposal, and the earlier Senate bill 266, were based on the same assumption. There are a number of arguments made in defense of this position: that privacy rights and law enforcement needs must be balanced, or that the government will be unable to conduct criminal investigations without this capability. Regardless of how one views these various claims, there is one point about the law that should be made very clear: currently there is no legal basis -- in statute, the Constitution or anywhere else -- that supports the premise which underlies the Clipper proposal. As the law currently stands, surveillance is not a design goal. General Motors would have a stronger legal basis for building cars that could go no faster than 65 miles per hour than AT&T does in marketing a commercial telephone that has a built-in wiretap capability. In law there is simply nothing about the use of a telephone that is inherently illegal or suspect. The federal wiretap statute says only that communication service providers must assist law enforcement in the execution of a lawful warrant. It does not say that anyone is obligated to design systems to facilitate future wire surveillance. That distinction is the difference between countries that restrict wire surveillance to narrow circumstances defined in law and those that treat all users of the telephone network as potential criminals. U.S. law takes the first approach. Countries such as the former East Germany took the second approach. The use of the phone system by citizens was considered inherently suspect and for that reason more than 10,000 people were employed by the East German government to listen in on telephone calls. It is precisely because the wiretap statute does not contain the obligation to incorporate surveillance capability -- the design premise of the Clipper proposal -- that the Federal Bureau of Investigation introduced the Digital Telephony legislation. But that legislation has not moved forward and the law has remained unchanged. The Clipper proposal attempts to accomplish through the standard-setting and procurement process what the Congress has been unwilling to do through the legislative process. On legal grounds, adopting the Clipper would be a mistake. There is an important policy goal underlying the wiretap law. The Fourth Amendment and the federal wiretap statute do not so much balance competing interests as they erect barriers against government excess and define the proper scope of criminal investigation. The purpose of the federal wiretap law is to restrict the government, it is not to coerce the public. Therefore, if the government endorses the Clipper proposal, it will undermine the basic philosophy of the federal wiretap law and the fundamental values embodied in the Constitution. It will establish a technical mechanism for signal interception based on a premise that has no legal foundation. The assumption underlying the Clipper proposal is more compatible with the practice of telephone surveillance in the former East Germany than it is with the narrowly limited circumstances that wire surveillance has been allowed in the United States. UNANSWERED QUESTIONS There are a number of other legal issues that have not been adequately considered by the proponents of the key escrow arrangement that the Subcommittee should examine. First, not all lawful wiretaps follow a normal warrant process. The proponents of Clipper should make clear how emergency wiretaps will be conducted before the proposal goes forward. Second, there may be civil liability issues for the escrow agents, if they are private parties, if there is abuse or compromise of the keys. Third, there is a Fifth Amendment dimension to the proposed escrow key arrangement if a network user is compelled to disclose his or her key to the government in order to access a communications network. Each one of these issues should be examined carefully. CPSR CONFERENCE At a conference organized by CPSR this week at the Carnegie Endowment for International Peace we heard presentations from staff members at NIST, FBI, NSA and the White House about the Clipper proposal. The participants at the meeting had the opportunity to ask questions and to exchange views. Certain points now seem clear: % The Clipper proposal was not developed in response to any perceived public or business need. It was developed solely to address a law enforcement concern. % Wire surveillance remains a small part of law enforcement investigations. The number of arrests resulting from wiretaps has remained essentially unchanged since the federal wiretap law was enacted in 1968. % The potential risks of the Clipper proposal have not been assessed and many questions about the implementation remain unanswered. % Clipper does not appear to have the support of the business or research community. Many comments on the Clipper proposal, both positive and negative as well the materials obtained by CPSR through the Freedom of Information Act, are contained in the Source book compiled by CPSR for the recent conference. I am please to make a copy of this available to the Subcommittee. NETWORK PRIVACY PROTECTION Communications privacy remains a critical test for network development. Networks that do not provide a high degree of privacy are clearly less useful to network users. Given the choice between a cryptography product without a key escrow and one with a key escrow, it would be difficult to find a user who would prefer the key escrow requirement. If this proposal does go forward, it will not be because network users or commercial service providers favored it. Even if the issues regarding the Clipper are resolved favorably, privacy concerns will not go away. Cryptography is a part of communications privacy, but it is only a small part. Rules still need to be developed about the collection and use of transactional data generated by computer communications. While the federal wiretap law generally does a very good job of protecting the content of communications against interception by government agencies, large holes still remain. The extensive use of subpoenas by the government to obtain toll records and the sale of telephone records by private companies are just two examples of gaps in current law. The enforcement of privacy laws is also a particularly serious concern in the United States. Good laws without clear mechanisms for enforcement raise over-arching questions about the adequacy of legal protections in this country. This problem is known to those who have followed developments with the Privacy Act since passage in 1974 and the more recent Video Privacy and Protection Act of 1988. I make this point because it has been the experience in other countries that agencies charged with the responsibility for privacy protection can be effective advocates for the public in the protection of personal privacy. RECOMMENDATIONS Regarding the Clipper proposal, we believe that the national review currently underway by the Computer Security and Privacy Advisory Board at the Department of Commerce will be extremely useful and we look forward to the results of that effort. The Panel has already conducted a series of important open hearings and compiled useful materials on Clipper and cryptography policy for public review. We are also pleased that the Subcommittee on Telecommunications and Finance has undertaken this hearing. This Subcommittee can play a particularly important role in the resolution of these issues. We also appreciate the Chairman's efforts to ensure that the proper studies are undertaken, that the General Accounting Office fully explores these issues, and that the Secretary of Commerce carefully assesses the potential impact of the Clipper proposal on export policy. We are, however, less pleased about the White House study currently underway. That effort, organized in large part by the National Security Council, has led to a series of secret meetings, has asked that scientists sign non-disclosure agreements and accept restrictions on publication, and has attempted to resolve public concerns through private channels. This is not a good process for the evaluation of a technology that is proposed for the public switched network. While we acknowledge that the White House has been reasonably forthcoming in explaining the current state of affairs, we do not think that this process is a good one. For these reasons, we believe that the White House should properly defer to the recommendations of the Computer System Security and Privacy Advisory Board and the Subcommittee on Telecommunications and Finance. We hope that no further steps in support of the Clipper initiative will be taken. We specifically recommend that no further purchase of Clipper chips be approved. Speaking more generally, we believe that a number of steps could be taken to ensure that future communications initiatives could properly be viewed as a boost to privacy and not a set-back. % The FCC must be given a strong mandate to pursue privacy concerns. There should be an office specifically established to examine privacy issues and to prepare reports. Similar efforts in other countries have been enormously successful. The Japanese Ministry of Post and Telecommunications developed a set of privacy principles to ensure continued trade with Europe. The Canada Ministry of Communications developed a set of communications principles to address public concerns about the privacy of cellular communications. In Europe, the EC put forward an important directive on privacy protection for the development of new network services. % Current gaps in the communications law should be filled. The protection of transactional records is particularly important. Legislation is needed to limit law enforcement access to toll record information and to restrict the sale of data generated by the use of telecommunication services. As the network becomes digital, the transaction records associated with a particular communication may become more valuable than the content of the communication itself. % Telecommunications companies should be encouraged to explore innovative ways to protect privacy. Cryptography is a particular method to seal electronic communications, but far more important for routine communications could be anonymous telephone cards, similar to the metro cards here in the District of Columbia, that allow consumers to purchase services without establishing accounts, transferring personal data, or recording personal activities. Such cards are widely available in Europe, Japan, and Australia. I thank you very much for the opportunity to appear before the Subcommittee and would be pleased to answer your questions Computer Professionals for Social Responsibility CPSR is a national membership organization, established in 1982, to address the social impact of computer technology. There are 2,500 members in 20 chapters across the United States, and offices in Palo Alto, California, Cambridge, Massachusetts, and Washington DC. The organization is governed by a board of elected officers and meetings are open to the public. CPSR sponsors an annual meeting and the biennial conference on Directions and Implications of Advanced Computing. CPSR sponsored the first conference on Computers, Freedom, and Privacy in 1991. CPSR also operates the Internet Library at cpsr.org. The library contains documents from the White House on technology policy and a wide range of public laws covering privacy, access to information, and communications law and is available free of charge to all users of the Internet. Marc Rotenberg is the director of the CPSR Washington office and an adjunct professor at Georgetown University Law Center. He is chairman of the ACM Committee on Scientific Freedom and Human Rights, an editor for the Computer Law and Security Report (London), and the secretary of Privacy International, an organization of human rights advocates and privacy scholars in forty countries. He received an A.B. from Harvard College and a J.D. from Stanford Law School, and is a member of the bar of the United States Supreme Court. His forthcoming article "Communications Privacy: Implications for Network Design" will appear in the August 1993 issue of Communications o0f the ACM. ------------------------------ End of Computer Underground Digest #5.43 ************************************ ________________________________________________________________________ 0001600 177c fd13 f000 3011 ccc9 ba18 6823 3cf2 0001620 0811 2a14 eda0 ddbe 7745 d8e1 c6bf ee7e 0001640 fa73 d3ec 9a34 8eea 0598 ff85 2133 d0ec 0001660 e9b1 8cbe add6 a48a 1ae8 80bd efd2 1a9f 0001700 9ba0 d3d6 4e83 2a9f 8dee 2039 cb9c 5ebf 0001720 3d41 6e32 8251 bc3c 4231 4e6c 482f d31e 0001740 6e0e 72dd 164d a663 3d6a 1b44 1a26 9835 0001760 e4c7 2fd7 11d2 6b25 4335 64e8 b746 da0c ________________________________________________________________________ ________________________________________________________________________ The SURFPUNK Technical Journal is a dangerous multinational hacker zine originating near BARRNET in the fashionable western arm of the northern California matrix. Quantum Californians appear in one of two states, spin surf or spin punk. Undetected, we are both, or might be neither. ________________________________________________________________________ Send postings to , subscription requests to . MIME encouraged. Xanalogical archive access at "http://www.acns.nwu.edu/surfpunk/" ________________________________________________________________________ ________________________________________________________________________ /* xor files together, M bytes max */ #include #define M 9999 char buf[M]; char pad[M]; readin(s) char* s; { int cc; int i; FILE* f= fopen( s, "r" ); if (!f) { perror(s); return; } bzero(buf, sizeof buf); cc= fread( buf, 1, M, f ); for ( i=0; i Several people on this list seem interested in the idea of setting up a digital cash system. A while back someone was dumping legal info on the legitimacy of running your own bank. I have an idea that would allow for "fun" use of digital cash systems while allowing a platform to test out ideas and put the system into a somewhat "real" environment. All that is needed for a digital cash environment is a way to earn money and a way to spend money. The ideas proposed so far seemed to be "send me real money and we'll give you credits." How about putting the digital money in a game/bbs environment? Example: mud's could allow people to transfer their funds between different games, to give away some of their game money electronically to others, etc. BBS's might let you spend your digital cash earned from a MUD for more time or other services. Maybe they'll let you earn money from them in special ways. A bank could be set up, and fixed sized donations could be sent out to each service (BBS, MUD, etc) participating. Each service could then award its participants with earnings as they play. How could something like this actually come about? Banking routines for transfer of funds would have to be written in portable code, with an easy interface for software authors to use in their packages. Most people running BBS's, MUD's and other services on the net have the technical knowledge to patch something this simple into their programs. I am not a big fan of MUD's, and hardly BBS around, but I think this might be a good way to get a system up and running. This will enable flaws in the system to surface, and even under very bad circumstances, no one loses real money. Tim From i6t4 at jupiter.sun.csd.unb.ca Sun Jun 13 23:21:16 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Sun, 13 Jun 93 23:21:16 PDT Subject: request for patent info Message-ID: Seems to me that now might be a good time to get a list together of all encryption related patents and when they expire. Unless someone already has such a list, I will compile and repost any info sent to me. -- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger i6t4 at unb.ca | (506) 457-1931 ^{1024/746EBB 1993/02/23} From ld231782 at longs.lance.colostate.edu Sun Jun 13 23:21:39 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Sun, 13 Jun 93 23:21:39 PDT Subject: alt.whistleblowing-cypherpunk FAQ In-Reply-To: <9306130817.AA01161@triton.unm.edu> Message-ID: <9306140621.AA29371@longs.lance.colostate.edu> J. Michael Diehl >I just started reading the alt.whistleblowing newsgroup. It would seem that it >has already digressed into a flamefest. Could the person who created it please >post a set of guidelines for the group! Also, people are using their REAL >names! Appearantly, they don't know anything about the anon remailers....Could >someone post a notice about that, too? Same thing goes WRT pgp. We helped >create this group, we ought to help keep it worth reading. ;^) Mr. Diehl: If you had taken the time to read any significant portion of alt.whistleblowing traffic, I would imagine you would have stumbled on messages where I presented an outline/preliminary FAQ and an anonymous posting described precisely how to use Julf's remailer to send traffic (which were posted under a week ago). I take great offense at your hasty, flippant denigration of it so far as a `flamefest'. While of course I'm not really associated with alt.whistleblowers at all in the grand cyberspatial scheme of things, I feel a smidgeon of personal responsibility for the group. Are you paying attention? Have you seen my promises there and on the cypherpunk list to create the FAQ? So far, IMHO, the traffic has mostly been very high-caliber and even spectacular. A lady named Karen Lofstrom reported how her boss at a Hawaii university misused ~$100,000 in funds and work of public employees on his private company -- from NSA grant money -- starting a long thread of sympathetic responses (she alluded to this earlier on sci.crypt I believe but expanded it beautifully in alt.whistleblower). We have other interesting revelations so far too. There are messages pointing out a private `whistleblowing support organization' and how to contact them. Your message, upon rereading it, makes me extremely exasperated. It reconfirms my suspicion that a large part of traffic on this list and tactics in the Cypherpunk arsenal are to just give lip service to interesting ideas but leave the messy and laborious detail work to others. Despite plenty of great fireworks on this list, I have seen no tangible contributions from others on the whistleblowing project other than Miron Cuperman's gracious effort to create the group (despite grandiose reassurances to the contrary), and Julf's immediate support of it, two individuals who are already highly active and motivated outside of their cypherpunk involvement. Furthermore, I've encountered many extremely frustrating obstructions here. I've seen great accomplishments by individuals who call themselves `cypherpunks' but none by well-orchestrated collections of them. This is not to discourage positive effort in the future by anyone on this list on the whistleblower project or anything else. It is to suggest that the Cypherpunks are so intensely individualistic as to preclude group projects and large-scale cooperation, and that this is a serious obstacle to enacting meaningful, critical change on the agenda. (Go ahead, flame me and ask what I've done for everyone lately --- I won't respond. That is not the spirit of my words.) The statement that makes my blood boil violently is the following: >We helped >create this group, we ought to help keep it worth reading. ;^) How is it that `we' created this group? All I've seen here is voluminous verbiage (yes, mine included). I appreciate the call to arms and cooperation, but I've tried it here before with impoverished, negligible, and excruciatingly painful results. How long ago did you join the list? I've already posted ways for cypherpunks to help out on the whistleblowing newsgroup. The simplest way is to just go there and post something useful or assimilate existing traffic into something useful. Mr. Diehl, the following is not a personal request. On behalf of the hundreds of people who read the cypherpunks list, I humbly ask you (and remind all other cypherpunks) to put the tiniest greater effort into your postings to the mailing list that, like all others, take the time of everyone to sort in their mailbox, and make every effort to direct messages through personal email where appropriate. I've asked you before politely in private email to no response, or apparently, effect. It is only in the rarest of occasions I will ever put forth such a request, and an even more unusual case to go public with it. I appreciated your volunteering to do the email survey but turning around with the final summary and admitting yourself that you're `too lazy to tabulate results' I find highly annoying (what is the point?), and I think does a disservice to the people who took the time to respond (including myself). Following is some traffic from the group. Some favorite quotes: >From Greg Welch, who's been extremely helpful in contributing to the FAQ referring to that private whistleblower agency: >BTW, you just made me realize that I need to contact them to see if they >can read (or are already reading) this news group somehow. Boy, I wish this >group was around when I was in a similar situation. Also, from Karen Lofstrom, the NSA grant whistleblower: >If we can get a number of other whistleblowers posting here, or people >from organizations that support whistleblowers, perhaps we can create some >group wisdom about how to blow the whistle _effectively_. I certainly >could have used some informed advice when I started. ===cut=here=== From yuma!csn!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ames!news.H awaii.Edu!uhunix3.uhcc.Hawaii.Edu!lofstrom Tue, 8 Jun 1993 03:55:08 GMT Newsgroups: alt.whistleblowing Path: yuma!csn!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ames!news.H awaii.Edu!uhunix3.uhcc.Hawaii.Edu!lofstrom From: lofstrom at uhunix3.uhcc.Hawaii.Edu (Karen Lofstrom) Subject: NSA Grant Misused Message-ID: Summary: Grantee runs private business with government paid labor Keywords: NSA, whistleblowing Sender: news at news.Hawaii.Edu Organization: University of Hawaii X-Newsreader: TIN [version 1.2 PL0] Date: Tue, 8 Jun 1993 03:55:08 GMT Lines: 83 I noted with interest the creation of this newsgroup and looked forward to reading the contributions of other whistleblowers. However, no whistleblowers have come forward. I suppose I'll have to post, then. I'm a fired whistleblower. After working five months of a part-time job funded by a NSA grant, at Chaminade University (note that this case does not involve the University of Hawaii, under whose auspices I post), I had begun to realize that my boss was misusing the grant. He was using government paid clerical labor, including mine, to run several businesses. He was ordering equipment for the grant from his own company, and charging the government twice what he charged any other customers (and a 1000% markup over what he actually paid for the equipment). I started collecting documentation of the problems, sneaking xeroxes when no one was looking. I didn't know anything about how to blow a whistle, so I consulted a friend of mine who worked in the state prosecutor's office. He suggested I contact a LARGE, reputable law firm, which I did. The lawyer I consulted was friendly and helpful, even refusing to charge for his services. I had been planning to go talk to the university. The lawyer said that they had failed in their oversight, would probably be more inclined to cover things up than fix them. He suggested I phone the granting agency and talk to someone there (though not the person directly responsible for the grant, who was a friend of the grantee, and had taken an expensive present from him). Well, the lawyer didn't know that you can't phone the NSA. I had a phone number from the copy of the grant I had surreptitiously xeroxed, but the operator said they would accept calls from secure lines only. Write a letter, she said. I wrote a letter and chewed my nails for a week. They didn't respond at all. So I took the advice of another friend and went to the FBI and the DCIS (Defense Criminal Investigation Services). They started an investigation. I was fired. I didn't go to the press because I was trying to be nice, and reasonable, and hoping that the government would take some action. I didn't necessarily want my ex-boss prosecuted, I just wanted the waste stopped. Well, the DCIS decided not to prosecute. They said that my charges weren't unfounded, but that the case was so complex that they weren't sure they could win it in a jury trial. Well, the investigator told me that. The DCIS never put anything on paper. So I wrote the NSA, asking if they were taking any steps to prevent further waste and fraud. They advised me to contact the DCIS. I wrote the DCIS, they didn't answer. I went to my Congressman, who wrote to the NSA. The NSA told him to tell me to write to the DCIS. I wrote the DCIS and they didn't answer. I wrote the Congressman again and got no reply. So I went to the papers. The local alternative weekly wasn't interested; they said they didn't have enough writers to cover all the stories. I went to the mainstream newspaper, which was extremely interested at first. Then the reporter discovered that I had been fired over a year ago. This made the whole thing non-news. Apparently if I had contacted them while the investigation was still going on, it would have been news. Several people have advised me to sue. There is a law forbidding the firing of whistleblowers. However, the damages to be to be recovered might be slight, given that it was a low-paying clerical job, and I would have to pay for the suit out of my own pocket. The NSA didn't renew the grant. However, they didn't do anything to crack down on my ex-boss. He stole approximately $100,000 from the taxpayers, and he's going to get away with it. For the halls of infamy: the grant was NSA Grant PR #00-91-0016 MDA904-91-H-5002. The grantee was Dr. John Wollstein. I keep asking myself, what could I have done differently? I do wish that I had been on the net then, that this topic had existed, and that I could have gotten some advice from other whistleblowers. I wish that I'd contacted the press as soon as I was fired, rather than trying to be "nice". I'd like some discussion of this, but I would hope that it could be productive. It wouldn't make me feel any better to have peoplle flaming for being stupid about this or that, given that _I'm_ the one who paid the price for trying to do the right thing. ----- Karen Lofstrom lofstrom at uhunix.uhcc.Hawaii.edu K.Lofstrom on GEnie From yuma!csn!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.reston.an s.net!darwin.sura.net!news-feed-1.peachnet.edu!concert!borg.cs.unc.edu!c s.unc.edu!welchg 8 Jun 1993 12:59:43 GMT Path: yuma!csn!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.reston.an s.net!darwin.sura.net!news-feed-1.peachnet.edu!concert!borg.cs.unc.edu!c s.unc.edu!welchg From: welchg at cs.unc.edu (Gregory Welch) Newsgroups: alt.whistleblowing Subject: Re: NSA Grant Misused Date: 8 Jun 1993 12:59:43 GMT Organization: The University of North Carolina at Chapel Hill Lines: 109 Distribution: world Message-ID: <1v22fvINNc4f at borg.cs.unc.edu> References: NNTP-Posting-Host: sirius.cs.unc.edu Keywords: NSA, whistleblowing My God Karen, I would hope that nobody would "flame" you! Nobody should have to go through what you did, but unfortunately it happens. The world has enough problems without people like your old employer adding their garbage. Good for you for being strong & courageous enough to do something. My hat is off to you. I have a few suggestions/comments inserted below. But *most* importantly, I *strongly* suggest that you contact: Project on Government Oversight 2025 I Street, NW Suite 1117 Washington, DC 20006 202-466-5539 (this should be placed in a FAQ or such for this group...?) Ask to speak to someone about your situation, and ask them to send you some literature about their organization (they have a booklet, etc.) They may be able to help you obtain legal help (ACLU?) etc. Best of all it will do you good to know that there *are* people, even organizations, who are trying to stop the waste, abuse, fraud, etc. Some background: "The Project" (as they like to refer to it) is a non-profit organization that has been around for several years (previously called the Government Accountability Project or GAP.) I have worked with them in the past (a guy named Keith Rutter in particular -- don't know if he's still there) and feel that they are a *great* source for help in a situation like yours. In fact, that's all they do, full-time, is assist "whistleblowers" in correcting or exposing such problems. This organization has access to government officals (congressmen & women, etc.) as well as other legal & publicity entities. Their goal is to assist people like you (and me it so happens) in addressing such problems in the most *effective* manner. In other words, they are experienced in working quietly with people like us (reading this group) to accomplish as much as possible, without causing one to become a martyr for the cause. And when "quiet" is no longer appropriate, they will also help doing whatever is necessary. The organization also maintains an extensive network of past whistleblowers, and experts in various fields who are happy to assist (e.g. with problems that are of a particular technical nature.) BTW, you just made me realize that I need to contact them to see if they can read (or are already reading) this news group somehow. Boy, I wish this group was around when I was in a similar situation. Now, a few posting-specific comments... In article , lofstrom at uhunix3.uhcc.Hawaii.Edu (Karen Lofstrom) writes: [stuff deleted] |> |> Several people have advised me to sue. There is a law forbidding |> the firing of whistleblowers. However, the damages to be |> to be recovered might be slight, given that it was a low-paying clerical |> job, and I would have to pay for the suit out of my own pocket. |> Most certainly ask the people at "The Project" about this. It *sounds* like you have a pretty tight case (caveat: I'm *not* a lawyer :-) ). Anyway, it *is* against the law for anyone to seek retribution against someone in your situation. It is also possible that punitive damages could be awarded (not sure) in which case you might get enough to make the disruption to your life a little more tolerable. Besides, if you could get the ACLU (or such) to represent you, the greatest accomplishment might be to publicize your case, giving hope to those in similar situations, and cause to worry to other would-be thieves. |> The NSA didn't renew the grant. However, they didn't do anything to crack |> down on my ex-boss. He stole approximately $100,000 from the taxpayers, |> and he's going to get away with it. |> Boy, not if we can help it! I will call "the project" today to let them know about the net. Please send me mail if you want me to mention your name & situation, I could ask them to contact you if you want. [stuff deleted] |> I keep asking myself, what could I have done differently? I do wish that |> I had been on the net then, that this topic had existed, and that I could |> have gotten some advice from other whistleblowers. I wish that I'd |> contacted the press as soon as I was fired, rather than trying to be "nice". |> Don't look back too much, it may not be over yet. You may still be able to do something about this. |> I'd like some discussion of this, but I would hope that it could be |> productive. It wouldn't make me feel any better to have peoplle flaming |> for being stupid about this or that, given that _I'm_ the one who paid the |> price for trying to do the right thing. |> |> |> |> ----- Karen Lofstrom lofstrom at uhunix.uhcc.Hawaii.edu |> K.Lofstrom on GEnie Thanks for the most meaningful posting to this newsgroup yet, and thanks for doing what you did. -- _____________________________________________________________________________ GREG WELCH | Email: welchg at cs.unc.edu University of North Carolina at Chapel Hill | Department of Computer Science | Room 323, Sitterson Hall | Chapel Hill, NC 27599 | From yuma!csn!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.reston.an s.net!agate!ames!news.Hawaii.Edu!uhunix3.uhcc.Hawaii.Edu!lofstrom Wed, 9 Jun 1993 01:59:42 GMT Newsgroups: alt.whistleblowing Path: yuma!csn!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.reston.an s.net!agate!ames!news.Hawaii.Edu!uhunix3.uhcc.Hawaii.Edu!lofstrom From: lofstrom at uhunix3.uhcc.Hawaii.Edu (Karen Lofstrom) Subject: Re: NSA Grant Misused Message-ID: Sender: news at news.Hawaii.Edu Organization: University of Hawaii X-Newsreader: TIN [version 1.2 PL0] References: <1993Jun8.202526.26656 at oucsace.cs.ohiou.edu> Date: Wed, 9 Jun 1993 01:59:42 GMT Lines: 22 Thanks all, for the appreciative posts and the E-mails of support that I received. No flames. Why was I expecting them? Perhaps because I felt that I had been a bit naive in expecting the government to police itself, without the glare of outside publicity to force it to do the right thing. So the question I put up for discussion is: when should a whistleblower go the media? How? If we can get a number of other whistleblowers posting here, or people from organizations that support whistleblowers, perhaps we can create some group wisdom about how to blow the whistle _effectively_. I certainly could have used some informed advice when I started. Someone upstream asked what the grant was funding. Nothing classified. Something that was actually beneficial and socially benign. It was to help high-school age immigrants from Asian and especially SE Asian countries maintain their first languages. Eventually useful to the NSA, as providing a pool of possible translators, but also good for the kids involved. That's one reason I wanted to step lightly. -- --- Karen Lofstrom lofstrom at uhunix.uhcc.Hawaii.edu K.Lofstrom on GEnie From jdblair at nextsrv.cas.muohio.EDU Sun Jun 13 23:27:20 1993 From: jdblair at nextsrv.cas.muohio.EDU (jdblair at nextsrv.cas.muohio.EDU) Date: Sun, 13 Jun 93 23:27:20 PDT Subject: thanks Message-ID: <9306140637.AA02012@ nextsrv.cas.muohio.EDU > Thanks to everyone for a really interesting and informative discussion group. I started out knowing almost nothing about encryption systems, and now I feel like I am at least an informed novice. I have learned a lot, and I really appreciate it. I will be in the Sangre de Christo Mtns. in New Mexico for the rest of the summer (w/o net access, this time), so I'll have to catch up in the fall. thanks again, -john From gnu Mon Jun 14 00:09:53 1993 From: gnu (John Gilmore) Date: Mon, 14 Jun 93 00:09:53 PDT Subject: Digital cash software Message-ID: <9306140709.AA05436@toad.com> I spoke with David Chaum, the inventor of digital money, last week at the cryptography meetings in DC. He is willing to give us a noncommercial license to use his digital money patents, and copies of some of his software for digital cash, for us to deploy somehow, and start using. He'll be back in August for Crypto '93 in Santa Barbara, and will bring one of his assistants (Nils) up to the Bay Area to teach us about the software. I think we can get a copy from him in the meantime, and puzzle it out ourselves between now and then. We'll also need to work out the legalese on the patents; it should be simple, but then again, almost everything *should* be simple... If we have a small group of people (say 2 to 5) who are seriously interested in building a digital-cash-on-the-Internet application and getting it into use, then speak up and get organized, and I will cross-connect you to David and Nils so things will start moving. David's company Digicash has been working on toll collection systems; he showed pictures of their newest system that allows driving full speed through the tollbooths and still does the transaction, using infrared through the windshield, I think. If someone wanted to present his system and his company to the authoritarians who were last seen preparing to put unencrypted automated vehicle-ID numbers on cars in California for toll collection, that would be a good thing. Speak up... John From phred at well.sf.ca.us Mon Jun 14 01:51:32 1993 From: phred at well.sf.ca.us (Fred Heutte) Date: Mon, 14 Jun 93 01:51:32 PDT Subject: corporations and morality Message-ID: <93Jun14.015105pdt.13893-1@well.sf.ca.us> Feh on Pournelle and Niven especially, dreary drones of the Ayn Rand school of pseudo-insight. Read some of Peter Drucker's new work on corporate responsibility and tell me corporate America isn't thinking about ethics and morality. And just this weekend on a PBS forum on workplace harassment issues I heard a CEO quoting Milton Friedman approvingly on the issue of ethical behavior not only being the right thing to do but central to achieving the corporate mission. Wake up -- it's not 1880 any more!! From shipley at merde.dis.org Mon Jun 14 02:11:28 1993 From: shipley at merde.dis.org (Peter shipley) Date: Mon, 14 Jun 93 02:11:28 PDT Subject: Mail logging Message-ID: <9306140456.AA29696@merde.dis.org> A non-text attachment was scrubbed... Name: not available Type: text/x-pgp Size: 800 bytes Desc: not available URL: From mlshew at dixie.com Mon Jun 14 06:49:09 1993 From: mlshew at dixie.com (Mark Shewmaker) Date: Mon, 14 Jun 93 06:49:09 PDT Subject: Rude CryptoStacker Suggestion Message-ID: I have one possible suggestion that might speed up your goals of getting an ecrypting filesystem on PC Clones, although I'm not exactly sure how to put it politely: Seeing as you're looking for encrypting filesystems to work on PC clones, have you made sure such code doesn't exist already? Why not just scrounge through ftp sites (or archie) until you find an already written DOS program that does what you like, and use it instead? With DOS's huge installed user base, I have an extremely difficult time believing that this stuff doesn't already exist for it. Ryan, I don't intend to demean your efforts to bring privacy to the hard drives of the great unwashed masses, (especially if they really are without options at this point)--on the contrary, it's quite a noble goal, and would be a good programming project in its own right even if other solutions do exist, but I'd hate to see you waste your efforts if the same thing really exists elsewhere. -Mark Shewmaker From m5 at vail.tivoli.com Mon Jun 14 07:15:49 1993 From: m5 at vail.tivoli.com (Mike McNally) Date: Mon, 14 Jun 93 07:15:49 PDT Subject: DH for email (re: email protection and privacy) Message-ID: <9306141414.AA07349@vail.tivoli.com> In light of a conversation (not a private conversation; it was at an EFF-Austin gathering) with Mike Godwin in which he stated that the court has ample precedent to cite you for contempt upon refusal to produce encryption keys, I think it's clear that no decypherable encryption scheme is really adequate to protect private materials during a legal investigation. Similarly, I suspect that a scheme to protect information by automatic destruction or obfuscation (as a friend described it, "digital flash paper") would be considered illegal obstruction of justice. Therefore, were I to be in possession of information that for political or business reasons I strongly required absolute privacy, I would resort to physical security as the closest thing to a sure-fire solution. Back things up onto high-density tape, and keep the tapes (*and* the tape drive, lest its presence be taken as prima facie evidence of the existance of off-line "evidence") in some secure place. - -- Mike McNally From nowhere at bsu-cs.bsu.edu Mon Jun 14 07:29:43 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Mon, 14 Jun 93 07:29:43 PDT Subject: REMAIL/ANON/PGP: System becoming available Message-ID: <9306141432.AA08208@bsu-cs.bsu.edu> Cypherpunks, I realize that I have been completely quiet on the list for a few months... Sorry about that, but I have been away from the University. Right now I am working in Indianapolis and telnetting from IUPUI up to BSU. Anyway, to the heart of the matter... I have gotten permission from one of the "good guys" at BSU to put my 486dx/33 with 386BSD in his office (secure) and get it on the Ethernet. I will probably run my anonymous remailer on there (the current one will stay in business) where it is safer. In addition, I want to run a pseudonymous service like anon.penet.fi. I have written some software in C that does it, but does not quite support PGP yet (it's not as easy as I would like to have believed before starting the project). It will give you an ID and will restrict mail from and to certain addresses/sites. It also puts a standard header into the message and has features to add header lines and footers to the messages automatically. The system will sit idle (aside from mail) most of the time, so I have no problem using PGP and being an encryption drop-point. I am about to start a rewrite of my remailer pretty soon because it needs some help. Anyway, I will send you all the IP address and host name of my computer when it's online. This could get exciting... I have a guest account on there where you can request an account, but I can't afford to give out too many accounts. Of course, I would much rather cypherpunks have accounts than a bunch of sniveling netbrats. Anyway, gotta run. Incidentally, I have about 3 MB of backed up mail here. It's only since the second week of May! Chael Hall -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at BSUVC.BSU.EDU, chall at bsu.edu chall at phantom.bsu.edu, nowhere at chaos.bsu.edu [not online yet] (317) 776-4000 from 8 am - 5 pm CST From hughes at soda.berkeley.edu Mon Jun 14 07:36:03 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 14 Jun 93 07:36:03 PDT Subject: request for patent info In-Reply-To: Message-ID: <9306141432.AA05436@soda.berkeley.edu> >Seems to me that now might be a good time to get a list together of all >encryption related patents and when they expire. As much as we need this, we also need the actual text of the patents. What a patent actually covers is often much narrower than what is claimed. >Unless someone already >has such a list, I will compile and repost any info sent to me. The experience of others trying to gather such information as this is that you have to be proactive if you expect to get anything done. Waiting for people to send you stuff is an exercise in patience. Eric From mnemonic at eff.org Mon Jun 14 07:42:19 1993 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 14 Jun 93 07:42:19 PDT Subject: PKP In-Reply-To: <93Jun13.123601pdt.13888-1@well.sf.ca.us> Message-ID: <199306141442.AA00948@eff.org> > We need info from someone who knows. Mike, are you listening, and are you > familiar with antitrust law? Doug, I am listening, but antitrust is not my area. Many of the developers and businessfolk on this list have a clearer knowledge of antitrust law than I. You are right, of course, that "patents are intended to convey a sharply limited monopoly." --Mike From hughes at soda.berkeley.edu Mon Jun 14 07:47:25 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 14 Jun 93 07:47:25 PDT Subject: digital cash In-Reply-To: <9306140251.AA27197@toad.com> Message-ID: <9306141443.AA05997@soda.berkeley.edu> >How about putting the digital money in a game/bbs >environment? I had a talk with a fellow named Joichi Ito at CFP about this subject. He's a total MUD addict and told me, "I would pay real money for MUD money." The legal issues involved in setting up a real world money system are enormous. Doing a game environment implementation would allow the technical issues to be worked out without having to hire lawyers. And if some people transact for real money, we can't help that. For MUD's in particular, there's a problem with conservation of mass, er, gold. It's really easy to create more MUD money. However, if there were a currency exchange system available between MUD's, you would have a classical free banking environment. Everyone issues currency, and as gamemaster your money deflates to the extent that you allow more gold to exist in your game. I can't think of a better way to get people to learn about monetary effects in macroeconomics. I also spoke with Pavel Curtis at CFP, but only enough to interest him in talking further. Pavel runs the largest MUD on the planet. Eric From julf at penet.FI Mon Jun 14 07:56:16 1993 From: julf at penet.FI (Johan Helsingius) Date: Mon, 14 Jun 93 07:56:16 PDT Subject: Digital cash software In-Reply-To: <9306140709.AA05436@toad.com> Message-ID: <9306141710.aa20936@penet.penet.FI> > I spoke with David Chaum, the inventor of digital money, last week at > the cryptography meetings in DC. He is willing to give us a noncommercial > license to use his digital money patents, and copies of some of his > software for digital cash, for us to deploy somehow, and start using. Wow! Great! > If we have a small group of people (say 2 to 5) who are seriously > interested in building a digital-cash-on-the-Internet application > and getting it into use, then speak up and get organized, and I > will cross-connect you to David and Nils so things will start moving. Definitely interested! Julf From jet at nas.nasa.gov Mon Jun 14 09:00:18 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Mon, 14 Jun 93 09:00:18 PDT Subject: forward: Cu Digest, #5.43 -- 2600 & CPSR House Subcommittee Testimony Message-ID: <9306141559.AA01370@boxer.nas.nasa.gov> Emmanuel's comments are somewhat disturbing... > > > Computer underground Digest Sun June 13 1993 Volume 5 : Issue 43 > ISSN 1004-043X > > Editors: Jim Thomas and Gordon Meyer (TK0JUT2 at NIU.BITNET) > Archivist: Brendan Kehoe > Shadow-Archivists: Dan Carosone / Paul Southworth > Ralph Sims / Jyrki Kuoppala > Ian Dickinson > Copy Editor: Etaoin Shrdlu, Seniur > > CONTENTS, #5.43 (June 13 1993) > File 1--Hacker testimony to House subcommittee largely unheard > File 2--CPSR Clipper Testimony (6-9-93) in House Subcommittee > > Cu-Digest is a weekly electronic journal/newsletter. Subscriptions are > available at no cost electronically from tk0jut2 at mvs.cso.niu.edu. The > editors may be contacted by voice (815-753-6430), fax (815-753-6302) > or U.S. mail at: Jim Thomas, Department of Sociology, NIU, DeKalb, IL > 60115. > > Issues of CuD can also be found in the Usenet comp.society.cu-digest > news group; on CompuServe in DL0 and DL4 of the IBMBBS SIG, DL1 of > LAWSIG, and DL0 and DL12 of TELECOM; on GEnie in the PF*NPC RT > libraries and in the VIRUS/SECURITY library; from America Online in > the PC Telecom forum under "computing newsletters;" > On Delphi in the General Discussion database of the Internet SIG; > on the PC-EXEC BBS at (414) 789-4210; and on: Rune Stone BBS (IIRG > WHQ) 203-832-8441 NUP:Conspiracy > CuD is also available via Fidonet File Request from 1:11/70; unlisted > nodes and points welcome. > EUROPE: from the ComNet in LUXEMBOURG BBS (++352) 466893; > In ITALY: Bits against the Empire BBS: +39-461-980493 > > ANONYMOUS FTP SITES: > UNITED STATES: ftp.eff.org (192.88.144.4) in /pub/cud > uglymouse.css.itd.umich.edu (141.211.182.53) in /pub/CuD/cud > halcyon.com( 202.135.191.2) in /pub/mirror/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) > > COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing > information among computerists and to the presentation and debate of > diverse views. CuD material may be reprinted for non-profit as long > as the source is cited. Authors hold a presumptive copyright, and > they should be contacted for reprint permission. It is assumed that > non-personal mail to the moderators may be reprinted unless otherwise > specified. Readers are encouraged to submit reasoned articles > relating to computer culture and communication. Articles are > preferred to short responses. Please avoid quoting previous posts > unless absolutely necessary. > > DISCLAIMER: The views represented herein do not necessarily represent > the views of the moderators. Digest contributors assume all > responsibility for ensuring that articles submitted do not > violate copyright protections. > > ---------------------------------------------------------------------- > > Date: Thu, 10 Jun 1993 16:53:48 -0700 > From: Emmanuel Goldstein > Subject: File 1--Hacker testimony to House subcommittee largely unheard > > What follows is a copy of my written testimony before the House > Subcommittee on Telecommunications and Finance. The June 9th hearing > was supposed to have been on the topic of network security, toll > fraud, and the social implications of the rapidly emerging > technologies. I was asked to speak for those who had no voice, which > translates to hackers and consumers. Instead I found myself barraged > with accusations from the two representatives in attendance (Rep. Ed > Markey D-MA and Rep. Jack Fields R-TX) who considered 2600 Magazine > (of which I'm the editor) nothing more than a manual for computer > crime. One article in particular that Markey latched upon was one in > our Spring issue that explained how a cable descrambler worked. > According to Markey, there was no use for this information outside of > a criminal context. Fields claimed we were printing cellular "codes" > that allowed people to listen in on cellular calls. In actuality, we > printed frequencies. The difference didn't seem to matter - after > explaining it to him, he still said he was very disturbed by the fact > that I was allowed to keep publishing. It soon became apparent to me > that neither one had read my testimony as there seemed to be no > inclination to discuss any of the issues I had brought up. In a way, > it was very much like being on the Geraldo show. Somehow I thought > elected representatives would be less sensationalist and more > interested in learning but this was not the case here. We got > absolutely nowhere. Markey in particular was rude, patronizing, and > not at all interested in entertaining any thought outside his narrow > perception. It's too bad this opportunity was lost. There is a real > danger in elected officials who don't listen to all relevant opinions > and who persist in sticking to old-fashioned, outdated notions that > just don't apply to high technology. You can look forward to more > restrictive regulations and higher penalties for violating them if > this mentality continues to dominate. > > +++++++++++++++++++ > WRITTEN TESTIMONY FOLLOWS: > > Mr. Chairman, members of the Committee, thank you for the > opportunity to speak on the issue of the rapid growth and changes in > the telecommunications industry. > > My name is Emmanuel Goldstein and I am the publisher of 2600 > Magazine, which is a journal for computer hackers as well as anyone > else who happens to be interested in the direction that technology is > taking us. We tend to be brutally honest in our assessments and, as a > result, we do get some corporations quite angry at us. But we've also > managed to educate a large number of people as to how their telephone > system works, what kinds of computers may be watching them, and how > they can shape technology to meet their needs, rather than be forced > to tailor their existence to meet technology's needs. > > I am also the host of a weekly radio program called Off The Hook > which airs over WBAI in New York. Through that forum we have > discovered the eagerness and curiosity that many "ordinary people on > the street" possess for technology. At the same time we have seen > fears and suspicions expressed that would be unwise to ignore. > > HOW TO HANDLE RAPIDLY CHANGING TECHNOLOGY > > The next few years will almost certainly go down in history as > those in which the most change took place in the least amount of time. > The computer and telecommunications revolution that we are now in the > midst of is moving full speed ahead into unknown territory. The > potential for amazing advances in individual thought and creativity is > very real. But so is the potential for oppression and mistrust the > likes of which we have never before seen. One way or the other, we > will be making history. > > I think we can imagine it best if we think of ourselves speeding > down a potentially dangerous highway. Perhaps the road will become > slick with ice or fraught with sharp curves. It's a road that nobody > has gone down before. And the question we have to ask ourselves is > what kind of a vehicle would we prefer to be in if things should start > getting out of control: our own automobile where we would have at > least some chance of controlling the vehicle and bringing it down to a > safe speed or a bus where we, along with many others, must put all of > our trust behind a total stranger to prevent a disaster. The answer is > obviously different depending on the circumstances. There are those of > us who do not want the responsibility of driving and others who have > proven themselves unworthy of it. What's important is that we all have > the opportunity at some point to choose which way we want to go. > > Rapidly changing technology can also be very dangerous if we > don't look where we're going or if too many of us close our eyes and > let someone else do the driving. This is a ride we all must stay awake > for. > > I am not saying we should be overly suspicious of every form of > technology. I believe we are on the verge of something very positive. > But the members of this committee should be aware of the dangers of an > uninformed populace. These dangers will manifest themselves in the > form of suspicion towards authority, overall fear of technology, and > an unhealthy feeling of helplessness. > > HOW NEW TECHNOLOGY CAN HURT US > > The recent FBI proposal to have wiretap capabilities built into > digital telephone systems got most of its publicity because American > taxpayers were expected to foot the bill. But to many of the > non-technical people I talked to, it was just another example of Big > Brother edging one step closer. It is commonly believed that the > National Security Agency monitors all traffic on the Internet, not to > mention all international telephone calls. Between Caller ID, TRW > credit reports, video cameras, room monitors, and computer > categorizations of our personalities, the average American feels as if > life no longer has many private moments. Our Social Security numbers, > which once were for Social Security, are now used for everything from > video rentals to driver's licenses. These numbers can easily be used > to track a person's location, expenses, and habits - all without any > consent. If you know a person's name, you can get their telephone > number. If you have their phone number, you can get their address. > Getting their Social Security number is not even a challenge anymore. > With this information, you can not only get every bit of information > about this person that exists on any computer from Blockbuster Video > to the local library to the phone company to the FBI, but you can > begin to do things in this poor person's name. It's possible we may > want a society like this, where we will be accountable for our every > movement and where only criminals will pursue privacy. The American > public needs to be asked. But first, they need to understand. > > In Germany, there is a fairly new computerized system of identity > cards. Every citizen must carry one of these cards. The information > includes their name, address, date of birth, and nationality - in > other words, the country they were originally born in. Such a system > of national identity can be quite useful, but in the wrong hands it > can be extremely scary. For example, if a neo-Nazi group were to > somehow get their hands on the database, they could instantly find out > where everyone of Turkish nationality lived. A malevolent government > could do the same and, since not carrying the card would be a crime, > it would be very hard to avoid its wrath. > > Before introducing a new technology that is all-encompassing, all > of its potential side-effects and disadvantages should be discussed > and addressed. Opportunities must exist for everyone to ask questions. > In our own country, nobody was ever asked if they wanted a credit file > opened on them, if they wanted to have their phone numbers given to > the people and companies they called through the use of Caller ID and > ANI, or if they wanted to be categorized in any manner on numerous > lists and databases. Yet all of this has now become standard practice. > > This implementation of new rules has resulted in a degree of > cynicism in many of us, as well as a sense of foreboding and dread. We > all know that these new inventions will be abused and used to > somebody's advantage at some point. There are those who would have us > believe that the only people capable of such misdeeds are computer > hackers and their ilk. But it just isn't that simple. > > UNDERSTANDING COMPUTER HACKERS > > To understand computer hackers, it helps to think of an alien > culture. We have such cultures constantly around us - those with > teenage children ought to know what this means. There are alien > cultures of unlimited varieties throughout the globe, sometimes in the > most unexpected places. I'm convinced that this is a good thing. > Unfortunately, all too often our default setting on whatever it is we > don't understand is "bad". Suspicion and hostility follow and are soon > met with similar feelings from the other side. This has been going on > between and within our cultures for as long as we've existed. While we > can't stop it entirely, we can learn to recognize the danger signs. > The best way that I've found to deal with an alien culture, whether > it's in a foreign country or right here at home, is to try and > appreciate it while giving it a little leeway. There is not a single > alien culture I've encountered that has not been decidedly friendly. > That includes deadheads, skateboarders, Rastafarians, and hackers. > > When we talk about computer hackers, different images spring to > mind. Most of these images have come about because of perceptions > voiced by the media. Too often, as I'm sure the members of this > committee already suspect, the media just doesn't get it. This is not > necessarily due to malice on their part but rather a general lack of > understanding and an overwhelming pressure to produce a good story. > Hence we get an abundance of sensationalism and, when the dust clears, > hackers are being compared with bank robbers, mobsters, terrorists, > and the like. It's gotten to the point that the word hacker is almost > analogous to the word criminal. > > Fortunately, the media is learning. Reporters now approach > hackers with a degree of technological savvy. For the most part, they > have stopped asking us to commit crimes so they can write a story > about it. As the technology envelops us, journalists are developing > the same appreciation and curiosity for it that hackers have always > had. Any good reporter is at least part hacker because what a hacker > does primarily is relentlessly pursue an answer. Computers naturally > lend themselves to this sort of pursuit, since they tend to be very > patient when asked a lot of questions. > > WHAT CONSTITUTES A HI-TECH CRIME? > > So where is the boundary between the hacker world and the > criminal world? To me, it has always been in the same place. We know > that it's wrong to steal tangible objects. We know that it's wrong to > vandalize. We know that it's wrong to invade somebody's privacy. Not > one of these elements is part of the hacker world. > > A hacker can certainly turn into a criminal and take advantage of > the weaknesses in our telephone and computer systems. But this is > rare. What is more likely is that a hacker will share knowledge with > people, one of whom will decide to use that knowledge for criminal > purposes. This does not make the hacker a criminal for figuring it > out. And it certainly doesn't make the criminal into a hacker. > > It is easy to see this when we are talking about crimes that we > understand as crimes. But then there are the more nebulous crimes; the > ones where we have to ask ourselves: "Is this really a crime?" Copying > software is one example. We all know that copying a computer program > and then selling it is a crime. It's stealing, plain and simple. But > copying a program from a friend to try it out on your home computer -- > is this the same kind of crime? It seems obvious to me that it is not, > the reason being that you must make a leap of logic to turn such an > action into a crime. Imagine if we were to charge a licensing fee > every time somebody browsed through a magazine at the local bookshop, > every time material was borrowed from a library, or every time a phone > number was jotted down from the yellow pages. Yet, organizations like > the Software Publishers Association have gone on record as saying that > it is illegal to use the same computer program on more than one > computer in your house. They claim that you must purchase it again or > face the threat of federal marshalls kicking in your door. That is a > leap of logic. > > It is a leap of logic to assume that because a word processor > costs $500, a college student will not try to make a free copy in > order to write and become a little more computer literate. Do we > punish this student for breaking a rule? Do we charge him with > stealing $500? To the hacker culture on whose behalf I am speaking > today, the only sensible answer is to make it as easy as possible for > that college student to use the software he needs. And while we're at > it, we should be happy that he's interested in the first place. > > Of course, this represents a fundamental change in our society's > outlook. Technology as a way of life, not just another way to make > money. After all, we encourage people to read books even if they can't > pay for them because to our society literacy is a very important goal. > I believe technological literacy is becoming increasingly important. > But you cannot have literacy of any kind without having access. > > If we continue to make access to technology difficult, > bureaucratic, and illogical, then there will also be more computer > crime. The reason being that if you treat someone like a criminal, > they will begin to act like one. If we succeed in convincing people > that copying a file is the same as physically stealing something, we > can hardly be surprised when the broad-based definition results in > more overall crime. Blurring the distinction between a virtual > infraction and a real-life crime is a mistake. > > LEGISLATION FOR COMPUTER AGE CRIME > > New laws are not needed because there is not a single crime that > can be committed with a computer that is not already defined as a > crime without a computer. But let us not be loose with that > definition. Is mere unauthorized access to a computer worthy of > federal indictments, lengthy court battles, confiscation of equipment, > huge fines, and years of prison time? Or is it closer to a case of > trespassing, which in the real world is usually punished by a simple > warning? "Of course not," some will say, "since accessing a computer > is far more sensitive than walking into an unlocked office building." > If that is the case, why is it still so easy to do? If it's possible > for somebody to easily gain unauthorized access to a computer that has > information about me, I would like to know about it. But somehow I > don't think the company or agency running the system would tell me > that they have gaping security holes. Hackers, on the other hand, are > very open about what they discover which is why large corporations > hate them so much. Through legislation, we can turn what the hackers > do into a crime and there just might be a slim chance that we can stop > them. But that won't fix poorly designed systems whose very existence > is a violation of our privacy. > > THE DANGERS OF UNINFORMED CONSUMERS > > The concept of privacy is something that is very important to a > hacker. This is so because hackers know how fragile privacy is in > today's world. Wherever possible we encourage people to protect their > directories, encrypt their electronic mail, not use cellular phones, > and whatever else it takes to keep their lives to themselves. In 1984 > hackers were instrumental in showing the world how TRW kept credit > files on millions of Americans. Most people had never even heard of a > credit file until this happened. Passwords were very poorly guarded - > in fact, credit reports had the password printed on the credit report > itself. More recently, hackers found that MCI's Friends and Family > program allowed anybody to call an 800 number and find out the numbers > of everyone in a customer's "calling circle". As a bonus, you could > also find out how these numbers were related to the customer: friend, > brother, daughter-in-law, business partner, etc. Many times these > numbers were unlisted yet all that was needed to "verify" the > customer's identity was the correct zip code. In both the TRW and MCI > cases, hackers were ironically accused of being the ones to invade > privacy. What they really did was help to educate the American > consumer. > > Nowhere is this more apparent than in the telephone industry. > Throughout the country, telephone companies take advantage of > consumers. They do this primarily because the consumer does not > understand the technology. When we don't understand something > complicated, we tend to believe those who do understand. The same is > true for auto mechanics, plumbers, doctors, and lawyers. They all > speak some strange language that the majority of us will never > understand. So we tend to believe them. The difference with the phone > companies, and here I am referring to the local companies, is that you > cannot deal with somebody else if you happen to disagree with them or > find them untrustworthy. The phone companies have us in a situation > where we must believe what they say. If we don't believe them, we > cannot go elsewhere. > > This is the frustration that the hacker community constantly > faces. We face it especially because we are able to understand when > the local phone companies take advantage of consumers. Here are a few > examples: > > Charging a fee for touch tone service. This is a misnomer. It > actually takes extra effort to tell the computer to ignore the tones > that you produce. Everybody already has touch tone capability but we > are forced to pay the phone company not to block it. While $1.50 a > month may not seem like much, when added together the local companies > that still engage in this practice are making millions of dollars a > year for absolutely nothing. Why do they get away with it? Because too > many of us don't understand how the phone system works. I try to draw > an analogy in this particular case - imagine if the phone company > decided that a fee would be charged to those customers who wanted to > use the number five when dialing. They could argue that the five takes > more energy than the four but most of us would see through this flimsy > logic. We must seek out other such dubious practices and not blindly > accept what we are told. > > Other examples abound: being charged extra not to have your name > listed in the telephone directory, a monthly maintenance charge if you > select your own telephone number, the fact that calling information to > get a number now costs more than calling the number itself. > > More recently, we have become acquainted with a new standard > called Signalling System Seven or SS7. Through this system it is > possible for telephones to have all kinds of new features: Caller ID, > Return Call, Repeat Calling to get through a busy signal, and more. > But again, we are having the wool pulled over our eyes. For instance, > if you take advantage of Call Return in New York (which will call the > last person who dialed your number), you are charged 75 cents on top > of the cost of the call itself. Obviously, there is a cost involved > when new technologies are introduced. But there is no additional > equipment, manpower, or time consumed when you dial *69 to return a > call. It's a permanent part of the system. As a comparison, we could > say that it also costs money to install a hold button. Imagine how we > would feel if we were charged a fee every time we used it. > > The local companies are not the only offenders but it is > particularly bad in their case because, for the vast majority of > Americans, there is no competition on this level. The same complaints > are being voiced concerning cable television companies. > > Long distance telephone companies are also guilty. AT&T, MCI, and > Sprint all encourage the use of calling cards. Yet each imposes a > formidable surcharge each and every time they're used. AT&T, for > example, charges 13 cents for the first minute of a nighttime call > from Washington DC to New York plus an 80 cent surcharge. Since a > calling card can only be used to make telephone calls, why are > consumers expected to pay an extra fee as if they were doing something > above and beyond the normal capability of the card? Again, there is no > extra work necessary to complete a calling card call - at least not on > the phone company's part. The consumer, on the other hand, must enter > up to 25 additional digits. But billing is accomplished merely by > computers sending data to each other. Gone are the days of tickets > being written up by hand and verified by human beings. Everything is > accomplished quickly, efficiently, and cheaply by computer. Therefore, > these extra charges are outdated. > > SOCIAL INJUSTICES OF TECHNOLOGY > > The way in which we have allowed public telephones to be operated > is particularly unfair to those who are economically disadvantaged. A > one minute call to Washington DC can cost as little as 12 cents from > the comfort of your own home. However, if you don't happen to have a > phone, or if you don't happen to have a home, that same one minute > call will cost you $2.20. That figure is the cheapest rate there is > from a Bell operated payphone. With whatever kind of logic was used to > set these prices, the results are clear. We have made it harder and > more expensive for the poor among us to gain access to the telephone > network. Surely this is not something we can be proud of. > > A direct result of this inequity is the prevalence of red boxes. > Red boxes are nothing more than tone generators that transmit a quick > burst of five tones which convince the central office that a quarter > has been deposited. It's very easy and almost totally undetectable. > It's also been going on for decades. Neither the local nor long > distance companies have expended much effort towards stopping red > boxes, which gives the impression that the payphone profits are still > lucrative, even with this abuse. But even more troubling is the > message this is sending. Think of it. For a poor and homeless person > to gain access to something that would cost the rest of us 12 cents, > they must commit a crime and steal $2.20. This is not equal access. > > CORPORATE RULES > > Hackers and phone phreaks, as some of us are called, are very > aware of these facts. We learn by asking lots of questions. We learn > by going to libraries and doing research. We learn by diving into > phone company trash dumpsters, reading discarded material, and doing > more research. But who will listen to people like us who have been > frequently characterized as criminals? I am particularly grateful that > this committee has chosen to hear us. What is very important to us is > open communications. Freedom of information. An educated public. > > This puts us at direct odds with many organizations, who believe > that everything they do is "proprietary" and that the public has no > right to know how the public networks work. In July of 1992 we were > threatened with legal action by Bellcore (the research arm of the > Regional Bell Operating Companies) for revealing security weaknesses > inherent in Busy Line Verification (BLV) trunks. The information had > been leaked to us and we did not feel compelled to join Bellcore's > conspiracy of silence. In April of this year, we were threatened with > legal action by AT&T for printing proprietary information of theirs. > The information in question was a partial list of the addresses of > AT&T offices. It's very hard for us to imagine how such information > could be considered secret. But these actions are not surprising. They > only serve to illustrate the wide disparities between the corporate > mindset and that of the individual. It is essential that the hundreds > of millions of Americans who will be affected by today's > all-encompassing inventions not be forced to play by corporate rules. > > In 1990 a magazine similar to 2600 was closed down by the United > States government because Bell South said they printed proprietary > information. Most people never found out about this because Phrack > Magazine was electronic, i.e., only available on computer bulletin > boards and networks. This in itself is wrong; a publication must have > the same First Amendment rights regardless of whether it is printed > electronically or on paper. As more online journals appear, this basic > tenet will become increasingly critical to our nation's future as a > democracy. Apart from this matter, we must look at what Bell South > claimed - that a document discussing the Enhanced 911 system which was > worth $79,449 had been "stolen" and printed by Phrack. (Some newspaper > accounts even managed to change it into an E911 program which gave the > appearance that hackers were actually interfering with the operation > of an E911 system and putting lives at risk. In reality there has > never been a report of a hacker gaining access to such a system.) It > was not until after the publisher of Phrack was forced to go to trial > that the real value of the document was revealed. Anyone could get a > copy for around $14. The government promptly dropped its case against > the publisher who, to this day, is still paying back $100,000 in legal > fees. As further evidence of the inquity between individual justice > and corporate justice, Bell South was never charged with fraud for its > claim that a $14 document was worth nearly $80,000. Their logic, as > explained in a memo to then Assistant U.S. Attorney Bill Cook, was > that the full salaries of everyone who helped write the document, as > well as the full cost of all hardware and software used in the > endeavor ($31,000 for a Vaxstation II, $6,000 for a printer), was > perfectly acceptable. It is very disturbing that the United States > government agreed with this assessment and moved to put a pre-law > student behind bars for violating corporate rules. > > MISGUIDED AUTHORITY > > I wish I could stand before this committee and say that we have > been successful in stopping all such miscarriages of justice. While > the Phrack case may have been the most bizarre, there are many more > instances of individuals being victimized in similar manners. A > teenager in Chicago was jailed for a year for copying a file that was > worth millions, according to AT&T, but was utterly worthless and > unusable to a kid. A bulletin board operator in California, along with > his entire family, was held at gunpoint for hours while authorities > seized his equipment in an unsuccessful attempt to find child > pornography. Three hackers in Atlanta, after being imprisoned up to a > year for dialing into a Bell South computer system that had no > password, were forced to pay $233,000 in restitution so the company > could install a password system. More recently, a student at the > University of Texas at Houston was suspended from school for a year > because he accessed a file that merely listed the users of the system > (a file which the system allows all users to access). In increasing > numbers, young people are being sent to jail, not necessarily for > something they did, but rather for something they could have done in a > worst-case scenario. Again this indicates fear and misunderstanding of > technology and its applications. But this time those feelings emanate > from those in authority. > > Locally, an ominous happening occurred at a 2600 monthly meeting > last November. (These meetings occur in public areas in cities > throughout the nation on the first Friday of every month.) Shortly > after it began, the Washington meeting was broken up by Pentagon City > Mall security guards. Without any provocation, people were forced to > submit to searches and everybody's name was taken down. One of the > attendees who was writing down an officer's name had the paper ripped > from his hand, another had his film taken from his camera as he tried > to document what was going on. Upon questioning by a reporter from > Communications Daily, the mall security chief claimed that he was > acting under orders from the United States Secret Service. Subsequent > Freedom of Information Act requests by Computer Professionals for > Social Responsibility have yielded more evidence implicating the > Secret Service in this illegal and unwarranted action. Nothing of a > criminal nature was ever found in any of the bags that were searched. > But a full list of the attendees wound up in the possession of the > Secret Service. It seems ironic that while hackers are conducting an > open gathering in the middle of a shopping mall in order to share > knowledge and welcome new people, agents of the Secret Service are > lurking in the shadows trying to figure out ways to stop them. > > How can we move forward and talk about exciting new applications > of technology when we're off to such a bad start? The people that are > being arrested, harassed, and intimidated are the people who will be > designing and running these new systems. They are the ones who will > appreciate their capabilities and understand their weaknesses. Through > our short-sightedness and eagerness to listen to the loudest voices, > we are alienating the promises of the future. How many here, who grew > up in decades past, remember hearing teenagers talk of how the > government is after them, watching their every move, listening to > their phone calls, doing everything one might expect in a totalitarian > regime. Such feelings are the sure sign of an ailing society. It does > not matter if these things are not actually occurring - their mere > perception is enough to cause lasting harm and mistrust. > > PROMISE OF THE INTERNET > > The future holds such enormous potential. It is vital that we not > succumb to our fears and allow our democratic ideals and privacy > values to be shattered. In many ways, the world of cyberspace is more > real than the real world itself. I say this because it is only within > the virtual world that people are really free to be themselves - to > speak without fear of reprisal, to be anonymous if they so choose, to > participate in a dialogue where one is judged by the merits of their > words, not the color of their skin or the timbre of their voice. > Contrast this to our existing "real" world where we often have people > sized up before they even utter a word. The Internet has evolved, on > its own volition, to become a true bastion of worldwide democracy. It > is the obligation of this committee, and of governments throughout the > world, not to stand in its way. > > This does not mean we should stand back and do nothing. Quite > the contrary, there is much we have to do if accessibility and > equality are our goals. Over-regulation and commercialization are two > ways to quickly kill these goals. A way to realize them is to have a > network access point in every house. Currently, network access is > restricted to students or professors at participating schools, > scientists, commercial establishments, and those who have access to, > and can afford, local services that link into the Internet. Yes, a lot > of people have access today. But a far greater number do not and it > is to these people that we must speak. The bigger the Internet gets, > the better it gets. As it exists today, cultures from around the globe > are represented; information of all kinds is exchanged. People are > writing, reading, thinking. It's potentially the greatest educational > tool we have. Therefore, it is essential that we not allow it to > become a commodity that only certain people in society will be able to > afford. With today's technology, we face the danger of widening the > gap between the haves and the have-nots to a monumental level. Or we > can open the door and discover that people really do have a lot to > learn from each other, given the opportunity. > > It is my hope that this committee will recognize the importance > of dialogue with the American public, in order to answer the questions > so many are asking and to address the concerns that have been > overlooked. I thank you for this opportunity to express those issues > that I feel relevant to this hearing. > > ------------------------------ > > Date: Sat, 12 Jun 1993 12:30:38 EST > From: Dave Banisar > Subject: File 2--CPSR Clipper Testimony (6-9-93) in House Subcommittee > > CPSR Clipper Testimony 6/9 > > On June 9, 1993, Congressman Edward Markey, Chairman of the > House Subcommittee on Telecommunications and Finance held an > oversight hearing on Rencryption and telecommunications network > security. Panelists were Whitfield Diffie of Sun Microsystems, Dr. > Dorothy Denning, Steven Bryen of Secure Communications, Marc > Rotenberg of the CPSR Washington Office and E.R. Kerkeslager of AT&T. > > Congressman Markey, after hearing the testimony presented, > noted that the Clipper proposal had raised an arched eyebrow among > the whole committeeS and that the committee viewed the proposal > skeptically. This statement was the latest indication that the Clipper > proposal has not been well received by policy makers. Last Friday, > the Computer Systems Security and Privacy Advisory Board of NIST > issued two resolutions critical of the encryption plan, suggesting > that further study was required and that implementation of the plan > should be delayed until the review is completed. > > At the Third CPSR Cryptography and Privacy Conference on > Monday, June 7, the Acting Director of NIST, Raymond Kammer, announced > that the implementation of the proposal will be delayed and that a > more comprehensive review will be undertaken. The review is due in > the fall. Kammer told the Washington Post that Rmaybe we wonUt > continue in the direction we started ous. > > +------------------------------------------------- > > Prepared Testimony > and > Statement for the Record > of > Marc Rotenberg, director > CPSR Washington Office > on > Encryption Technology and Policy > Before > The Subcommittee on Telecommunications and Finance. > Committee on Energy and Commerce > > U.S. House of Representatives > June 9, 1993 > > SUMMARY > > The cryptography issue is of particular concern to CPSR. > During the past several years CPSR has pursued an extensive study of > cryptography policy in the United States. CPSR has organized public > conferences, conducted litigation under the Freedom of Information Act, > and has emphasized the importance of cryptography for privacy > protection and the need to scrutinize carefully government proposals > designed to limit the use of this technology. > To evaluate the Clipper proposal it is necessary to look at a > 1987 law, the Computer Security Act, which made clear that in the area > of unclassified computing systems, the National Institute of Standards > and Technology (NIST) and not the National Security Agency (NSA), would > be responsible for the development of technical standards. The Act > emphasized public accountability and stressed open decision-making. > In the spirit of the Act, in 1989 NIST set out to develop a > public key cryptography standard. According to documents obtained by > CPSR through the Freedom of Information Act, NIST recommended that the > algorithm be "public, unclassified, implementable in both hardware or > software, usable by federal Agencies and U.S. based multi-national > corporation." However, the Clipper proposal and the full-blown Capstone > configuration that resulted is very different: the Clipper algorithm, > Skipjack, is classified; public access to the reasons underlying the > proposal is restricted; Skipjack can be implemented only in > tamper-proof hardware; it is unlikely to be used by multi-national > corporations, and the security of Clipper remains unproven. > The Clipper proposal undermines the central purpose of the > Computer Security Act. Although intended for broad use in commercial > networks, it was not developed at the request of either U.S. business > or the general public. It does not reflect public goals. > The premise of the Clipper key escrow arrangement is that the > government must have the ability to intercept electronic > communications. However, there is no legal basis to support this > premise. In law there is nothing inherently illegal or suspect about > the use of a telephone. The federal wiretap statute says only that > communication service providers must assist law enforcement execute a > lawful warrant. > CPSR supports the review of cryptography policy currently > underway at the Department of Commerce. CPSR also supports the efforts > undertaken by the Subcommittee on Telecommunications and Finance to > study the full ramifications of the Clipper proposal. However, we are > not pleased about the review now being undertaken at the White House. > That effort has led to a series of secret meetings, has asked that > scientists sign non-disclosure agreements and accept restrictions on > publication, and has attempted to resolve public concerns through > private channels. This is not a good process for the evaluation of a > technology that is proposed for the public switched network. > Even if the issues regarding Clipper are resolved favorably, > privacy concerns will not go away. Rules still need to be developed > about the collection and use of transactional data generated by > computer communications. Several specific steps should be taken. > First, the FCC should be given a broad mandate to pursue privacy > concerns. Second, current gaps in the communications law should be > filled. The protection of transactional records is particularly > important. Third, telecommunications companies should be encouraged to > explore innovative ways to protect privacy. "Telephone cards", widely > available in other countries, are an ideal way to protect privacy. > > > TESTIMONY > > Mr. Chairman, members of the Subcommittee, thank you for the > opportunity to testify today on encryption policy and the Clipper > proposal. I especially wish to thank you Congressman Markey, on behalf > of CPSR, for your ongoing efforts on the privacy front as well as your > work to promote public access to electronic information. > The cryptography issue is of particular concern to CPSR. > During the past several years we have pursued an extensive study of > cryptography policy in the United States. We have organized several > public conferences, conducted litigation under the Freedom of > Information Act, and appeared on a number of panels to discuss the > importance of cryptography for privacy protection and the need to > scrutinize carefully government proposals designed to limit the use of > this technology. > While we do not represent any particular computer company or > trade association we do speak for a great many people in the computer > profession who value privacy and are concerned about the government's > Clipper initiative. > Today I will briefly summarize our assessment of the Clipper > proposal. Then I would like to say a few words about the current > status of privacy protection. > > CLIPPER > To put the Clipper proposal in a policy context, I will need to > briefly to describe a law passed in 1987 intended to address the roles > of the Department of Commerce and the Department of Defense in the > development of technical standards. The Computer Security Act of 1987 > was enacted to improve computer security in the federal government, to > clarify the responsibilities of the National Institute of Standards and > Technology (NIST) and the National Security Agency, and to ensure that > technical standards would serve civilian and commercial needs. > The law made clear that in the area of unclassified computing > systems, NIST and not NSA, would be responsible for the development of > technical standards. It emphasized public accountability and stressed > open decision-making. The Computer Security Act also established the > Computer System Security and Privacy Advisory Board (CSSPAB), charged > with reviewing the activities of NIST and ensuring that the mandate of > the law was enforced. > The Computer Security Act grew out of a concern that classified > standards and secret meetings would not serve the interests of the > general public. As the practical applications for cryptography have > moved from the military and intelligence arenas to the commercial > sphere, this point has become clear. There is also clearly a conflict > of interest when an agency tasked with signal interception is also > given authority to develop standards for network security. > In the spirit of the Computer Security Act, NIST set out in > 1989 to develop a public key standard FIPS (Federal Information > Processing Standard). In a memo dated May 5, 1989, obtained by CPSR > through the Freedom of Information Act, NIST said that it planned: > > to develop the necessary public-key based security standards. We > require a public-key algorithm for calculating digital signatures and > we also require a public-key algorithm for distributing secret keys. > > NIST then went on to define the requirements of the standard: > > The algorithms that we use must be public, unclassified, implementable > in both hardware or software, usable by federal Agencies and U.S. based > multi-national corporation, and must provide a level of security > sufficient for the protection of unclassified, sensitive information > and commercial propriety and/or valuable information. > > The Clipper proposal and the full-blown Capstone configuration, > which incorporates the key management function NIST set out to develop > in 1989, is very different from the one originally conceived by NIST. > > % The Clipper algorithm, Skipjack, is classified, > % Public access to the reasons underlying the proposal is > restricted, > % Skipjack can be implemented only in tamper-proof hardware, > % It is Unlikely to be used by multi-national corporations, and > % The security of Clipper remains unproven. > > The Clipper proposal undermines the central purpose of the > Computer Security Act. Although intended for broad use in commercial > networks, it was not developed at the request of either U.S. business > or the general public. It does not reflect public goals. Rather it > reflects the interests of one secret agency with the authority to > conduct foreign signal intelligence and another government agency > responsible for law enforcement investigations. > Documents obtained by CPSR through the Freedom of Information > Act indicate that the National Security Agency dominated the meetings > of the joint NIST/NSA Technical Working group which made > recommendations to NIST regarding public key cryptography, and that a > related technical standard for message authentication, the Digital > Signature Standard, clearly reflected the interests of the NSA. > We are still trying to determine the precise role of the NSA in > the development of the Clipper proposal. We would be pleased to > provide to the Subcommittee whatever materials we obtain. > > LEGAL AND POLICY ISSUES > There are also several legal and constitutional issues raised > by the government's key escrow proposal. The premise of the Clipper > key escrow arrangement is that the government must have the ability to > intercept electronic communications, regardless of the economic or > societal costs. The FBI's Digital Telephony proposal, and the earlier > Senate bill 266, were based on the same assumption. > There are a number of arguments made in defense of this > position: that privacy rights and law enforcement needs must be > balanced, or that the government will be unable to conduct criminal > investigations without this capability. > Regardless of how one views these various claims, there is one > point about the law that should be made very clear: currently there is > no legal basis -- in statute, the Constitution or anywhere else -- > that supports the premise which underlies the Clipper proposal. As the > law currently stands, surveillance is not a design goal. General > Motors would have a stronger legal basis for building cars that could > go no faster than 65 miles per hour than AT&T does in marketing a > commercial telephone that has a built-in wiretap capability. In law > there is simply nothing about the use of a telephone that is inherently > illegal or suspect. > The federal wiretap statute says only that communication > service providers must assist law enforcement in the execution of a > lawful warrant. It does not say that anyone is obligated to design > systems to facilitate future wire surveillance. That distinction is > the difference between countries that restrict wire surveillance to > narrow circumstances defined in law and those that treat all users of > the telephone network as potential criminals. U.S. law takes the first > approach. Countries such as the former East Germany took the second > approach. The use of the phone system by citizens was considered > inherently suspect and for that reason more than 10,000 people were > employed by the East German government to listen in on telephone calls. > It is precisely because the wiretap statute does not contain > the obligation to incorporate surveillance capability -- the design > premise of the Clipper proposal -- that the Federal Bureau of > Investigation introduced the Digital Telephony legislation. But that > legislation has not moved forward and the law has remained unchanged. > The Clipper proposal attempts to accomplish through the > standard-setting and procurement process what the Congress has been > unwilling to do through the legislative process. > On legal grounds, adopting the Clipper would be a mistake. > There is an important policy goal underlying the wiretap law. The > Fourth Amendment and the federal wiretap statute do not so much balance > competing interests as they erect barriers against government excess > and define the proper scope of criminal investigation. The purpose of > the federal wiretap law is to restrict the government, it is not to > coerce the public. > Therefore, if the government endorses the Clipper proposal, it > will undermine the basic philosophy of the federal wiretap law and the > fundamental values embodied in the Constitution. It will establish a > technical mechanism for signal interception based on a premise that has > no legal foundation. The assumption underlying the Clipper proposal is > more compatible with the practice of telephone surveillance in the > former East Germany than it is with the narrowly limited circumstances > that wire surveillance has been allowed in the United States. > > UNANSWERED QUESTIONS > There are a number of other legal issues that have not been > adequately considered by the proponents of the key escrow arrangement > that the Subcommittee should examine. First, not all lawful wiretaps > follow a normal warrant process. The proponents of Clipper should make > clear how emergency wiretaps will be conducted before the proposal goes > forward. Second, there may be civil liability issues for the escrow > agents, if they are private parties, if there is abuse or compromise of > the keys. Third, there is a Fifth Amendment dimension to the proposed > escrow key arrangement if a network user is compelled to disclose his > or her key to the government in order to access a communications > network. Each one of these issues should be examined carefully. > > > CPSR CONFERENCE > At a conference organized by CPSR this week at the Carnegie > Endowment for International Peace we heard presentations from staff > members at NIST, FBI, NSA and the White House about the Clipper > proposal. The participants at the meeting had the opportunity to ask > questions and to exchange views. > Certain points now seem clear: > > % The Clipper proposal was not developed in response to any > perceived public or business need. It was developed solely to address > a law enforcement concern. > % Wire surveillance remains a small part of law enforcement > investigations. The number of arrests resulting from wiretaps has > remained essentially unchanged since the federal wiretap law was enacted > in 1968. > % The potential risks of the Clipper proposal have not been > assessed and many questions about the implementation remain unanswered. > % Clipper does not appear to have the support of the business or > research community. > > Many comments on the Clipper proposal, both positive and > negative as well the materials obtained by CPSR through the Freedom of > Information Act, are contained in the Source book compiled by CPSR for > the recent conference. I am please to make a copy of this available to > the Subcommittee. > > > NETWORK PRIVACY PROTECTION > Communications privacy remains a critical test for network > development. Networks that do not provide a high degree of privacy are > clearly less useful to network users. Given the choice between a > cryptography product without a key escrow and one with a key escrow, it > would be difficult to find a user who would prefer the key escrow > requirement. If this proposal does go forward, it will not be because > network users or commercial service providers favored it. > Even if the issues regarding the Clipper are resolved > favorably, privacy concerns will not go away. Cryptography is a part > of communications privacy, but it is only a small part. Rules still > need to be developed about the collection and use of transactional data > generated by computer communications. While the federal wiretap law > generally does a very good job of protecting the content of > communications against interception by government agencies, large holes > still remain. The extensive use of subpoenas by the government to > obtain toll records and the sale of telephone records by private > companies are just two examples of gaps in current law. > The enforcement of privacy laws is also a particularly serious > concern in the United States. Good laws without clear mechanisms for > enforcement raise over-arching questions about the adequacy of legal > protections in this country. This problem is known to those who have > followed developments with the Privacy Act since passage in 1974 and > the more recent Video Privacy and Protection Act of 1988. I make this > point because it has been the experience in other countries that > agencies charged with the responsibility for privacy protection can be > effective advocates for the public in the protection of personal > privacy. > > RECOMMENDATIONS > Regarding the Clipper proposal, we believe that the national > review currently underway by the Computer Security and Privacy Advisory > Board at the Department of Commerce will be extremely useful and we > look forward to the results of that effort. The Panel has already > conducted a series of important open hearings and compiled useful > materials on Clipper and cryptography policy for public review. > We are also pleased that the Subcommittee on Telecommunications > and Finance has undertaken this hearing. This Subcommittee can play a > particularly important role in the resolution of these issues. We also > appreciate the Chairman's efforts to ensure that the proper studies are > undertaken, that the General Accounting Office fully explores these > issues, and that the Secretary of Commerce carefully assesses the > potential impact of the Clipper proposal on export policy. > We are, however, less pleased about the White House study > currently underway. That effort, organized in large part by the > National Security Council, has led to a series of secret meetings, has > asked that scientists sign non-disclosure agreements and accept > restrictions on publication, and has attempted to resolve public > concerns through private channels. This is not a good process for the > evaluation of a technology that is proposed for the public switched > network. While we acknowledge that the White House has been reasonably > forthcoming in explaining the current state of affairs, we do not think > that this process is a good one. > For these reasons, we believe that the White House should > properly defer to the recommendations of the Computer System Security > and Privacy Advisory Board and the Subcommittee on Telecommunications > and Finance. We hope that no further steps in support of the Clipper > initiative will be taken. We specifically recommend that no further > purchase of Clipper chips be approved. > Speaking more generally, we believe that a number of steps > could be taken to ensure that future communications initiatives could > properly be viewed as a boost to privacy and not a set-back. > > % The FCC must be given a strong mandate to pursue privacy > concerns. There should be an office specifically established to > examine privacy issues and to prepare reports. Similar efforts in > other countries have been enormously successful. The Japanese Ministry > of Post and Telecommunications developed a set of privacy principles to > ensure continued trade with Europe. The Canada Ministry of > Communications developed a set of communications principles to address > public concerns about the privacy of cellular communications. In > Europe, the EC put forward an important directive on privacy protection > for the development of new network services. > > % Current gaps in the communications law should be filled. The > protection of transactional records is particularly important. > Legislation is needed to limit law enforcement access to toll record > information and to restrict the sale of data generated by the use of > telecommunication services. As the network becomes digital, the > transaction records associated with a particular communication may > become more valuable than the content of the communication itself. > > % Telecommunications companies should be encouraged to explore > innovative ways to protect privacy. Cryptography is a particular > method to seal electronic communications, but far more important for > routine communications could be anonymous telephone cards, similar to > the metro cards here in the District of Columbia, that allow consumers > to purchase services without establishing accounts, transferring > personal data, or recording personal activities. Such cards are widely > available in Europe, Japan, and Australia. > > I thank you very much for the opportunity to appear before the > Subcommittee and would be pleased to answer your questions Computer > Professionals for Social Responsibility > > CPSR is a national membership organization, established in > 1982, to address the social impact of computer technology. There are > 2,500 members in 20 chapters across the United States, and offices in > Palo Alto, California, Cambridge, Massachusetts, and Washington DC. The > organization is governed by a board of elected officers and meetings > are open to the public. CPSR sponsors an annual meeting and the > biennial conference on Directions and Implications of Advanced > Computing. CPSR sponsored the first conference on Computers, Freedom, > and Privacy in 1991. CPSR also operates the Internet Library at > cpsr.org. The library contains documents from the White House on > technology policy and a wide range of public laws covering privacy, > access to information, and communications law and is available free of > charge to all users of the Internet. > > Marc Rotenberg is the director of the CPSR Washington office > and an adjunct professor at Georgetown University Law Center. He is > chairman of the ACM Committee on Scientific Freedom and Human Rights, > an editor for the Computer Law and Security Report (London), and the > secretary of Privacy International, an organization of human rights > advocates and privacy scholars in forty countries. He received an A.B. > from Harvard College and a J.D. from Stanford Law School, and is a > member of the bar of the United States Supreme Court. His forthcoming > article "Communications Privacy: Implications for Network Design" will > appear in the August 1993 issue of Communications o0f the ACM. > > ------------------------------ > > End of Computer Underground Digest #5.43 > ************************************ From jet at nas.nasa.gov Mon Jun 14 09:06:44 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Mon, 14 Jun 93 09:06:44 PDT Subject: request for patent info In-Reply-To: <9306141432.AA05436@soda.berkeley.edu> Message-ID: <9306141606.AA01411@boxer.nas.nasa.gov> Eric Hughes writes: > As much as we need this, we also need the actual text of the patents. > What a patent actually covers is often much narrower than what is > claimed. Anyone near a federal patent repository can easily get this information. Walk in, find the patent by number, have the nice attendant print it out on a crappy photostat machine, pay in cash, leave. No written record! Rice U. has a nice staff. (I don't know where the west coast ones are.) From mnemonic at eff.org Mon Jun 14 09:23:21 1993 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 14 Jun 93 09:23:21 PDT Subject: DH for email (re: email protection and privacy) In-Reply-To: <9306141414.AA07349@vail.tivoli.com> Message-ID: <199306141623.AA01688@eff.org> Mike McNally writes: > In light of a conversation (not a private conversation; it was at an > EFF-Austin gathering) with Mike Godwin in which he stated that the > court has ample precedent to cite you for contempt upon refusal to > produce encryption keys, I think it's clear that no decypherable > encryption scheme is really adequate to protect private materials > during a legal investigation. Similarly, I suspect that a scheme to > protect information by automatic destruction or obfuscation (as a > friend described it, "digital flash paper") would be considered > illegal obstruction of justice. > > Therefore, were I to be in possession of information that for > political or business reasons I strongly required absolute privacy, I > would resort to physical security as the closest thing to a sure-fire > solution. Back things up onto high-density tape, and keep the tapes > (*and* the tape drive, lest its presence be taken as prima facie > evidence of the existance of off-line "evidence") in some secure > place. Note that a court could cite you for contempt for not complying with a subpoena duces tecum (a subpoena requiring you to produce objects or documents) if you fail to turn over subpoenaed backups. To be honest, I don't think *any* security measure is adequate against a government that's determined to overreach its authority and its citizens' rights, but crypto comes close. --Mike From m5 at vail.tivoli.com Mon Jun 14 09:29:00 1993 From: m5 at vail.tivoli.com (Mike McNally) Date: Mon, 14 Jun 93 09:29:00 PDT Subject: DH for email (re: email protection and privacy) In-Reply-To: <199306141623.AA01688@eff.org> Message-ID: <9306141627.AA07743@vail.tivoli.com> Mike Godwin writes: > Note that a court could cite you for contempt for not complying > with a subpoena duces tecum (a subpoena requiring you to produce objects > or documents) if you fail to turn over subpoenaed backups. I understand this, but could I be cited for failure to produce evidence not known by the court to exist? (Clearly, I could be so cited if the evidence were ever discovered.) Is there a process that the court can use that says "hand over absolutely all artifacts pertinent to the case at hand known to *you*, whether such artifacts be known to the court or not." ? Or is it the case that failure on my part to offer up such evidence is inherently contemptuous? > To be honest, I don't think *any* security measure is adequate against a > government that's determined to overreach its authority and its citizens' > rights, but crypto comes close. I wholeheartedly agree; I'd of course encrypt my secret backups :-) Gee, now that I've publicized this great idea, I suppose it can never work for me. -- Mike McNally From tcmay at netcom.com Mon Jun 14 10:03:55 1993 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 14 Jun 93 10:03:55 PDT Subject: request for patent info In-Reply-To: <9306141606.AA01411@boxer.nas.nasa.gov> Message-ID: <9306141704.AA24572@netcom3.netcom.com> J. Eric Townsend writes: > Anyone near a federal patent repository can easily get this > information. Walk in, find the patent by number, have the nice > attendant print it out on a crappy photostat machine, pay in cash, > leave. No written record! Rice U. has a nice staff. (I don't know > where the west coast ones are.) Sunnyvale, CA. Near the public library off Mathilda Ave. -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 mnemonic at eff.org Mon Jun 14 10:06:44 1993 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 14 Jun 93 10:06:44 PDT Subject: DH for email (re: email protection and privacy) In-Reply-To: <9306141627.AA07743@vail.tivoli.com> Message-ID: <199306141706.AA02197@eff.org> Mike McNally writes: > I understand this, but could I be cited for failure to produce > evidence not known by the court to exist? Absolutely. And it looks very, very bad for you if the court later discovers that you were holding back. > Is there a process that > the court can use that says "hand over absolutely all artifacts > pertinent to the case at hand known to *you*, whether such artifacts > be known to the court or not." ? Yes. > Or is it the case that failure on my > part to offer up such evidence is inherently contemptuous? You're not required to go *beyond* what is specified in a subpoena. But the subpoena's specifications can be pretty broad. --Mike From marc at GZA.COM Mon Jun 14 10:43:25 1993 From: marc at GZA.COM (Marc Horowitz) Date: Mon, 14 Jun 93 10:43:25 PDT Subject: DH for email (re: email protection and privacy) In-Reply-To: <199306141623.AA01688@eff.org> Message-ID: <9306141743.AA01676@dun-dun-noodles.aktis.com> >> Note that a court could cite you for contempt for not complying >> with a subpoena duces tecum (a subpoena requiring you to produce objects >> or documents) if you fail to turn over subpoenaed backups. This is gonna sounds weird, but.... Let's say I have a (paper) document which explains how I (for example) embezzled money from Megacorp, Inc. I presume that the Fifth Amendment means I cannot be forced to produce this document. Case 1: let's say that I have the same document on disk, in the clear. Can they force me to produce that? Case 2: They sieze a disk from an associate which has the document, but it's encrypted. Can they force me to produce the key? Mike, you claim that there is precedent which says that they can. I'm curious how the Fifth Amendment allows this. I've heard you say in the past that key escrow doesn't violate the 5th because you're not disclosing anything at the time. But if the government possesses an incriminating document, wouldn't forcing me to give them the key constitute self-incrimination? Case 3: I keep all my stuff encrypted, and enter the key from (say) a smartcard of some sort when I boot up. They seize my machine, and insist that I give them the key. I refuse, because the key is stored in a cleartext document, which incriminates me in some way. (Say the key is a hash of the document itself.) Since I'm sure there's no precedent for this, what are the legal implications of seizing this document? Case 4: "I forgot." Can they do anything? Marc From peb at PROCASE.COM Mon Jun 14 11:08:25 1993 From: peb at PROCASE.COM (peb at PROCASE.COM) Date: Mon, 14 Jun 93 11:08:25 PDT Subject: DH for email (re: email protection and privacy) Message-ID: <9306141807.AA21784@banff.procase.com> >Case 4: "I forgot." This one seems to work for U.S. presidents. Paul E. Baclace peb at procase.com From peb at PROCASE.COM Mon Jun 14 11:15:13 1993 From: peb at PROCASE.COM (peb at PROCASE.COM) Date: Mon, 14 Jun 93 11:15:13 PDT Subject: Rude CryptoStacker Suggestion Message-ID: <9306141813.AA21788@banff.procase.com> >have you made sure such code doesn't exist already? In case no one has mentioned this yet: There is a Norton Utility (not free, but fairly priced) that makes a crypto disk. I saw this last summer, but disregarded it since it use the amateur "secrecy through obscurity" method. Thus, the meme is out to some degree, but not strong enough. Paul E. Baclace peb at procase.com From jet at nas.nasa.gov Mon Jun 14 11:15:19 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Mon, 14 Jun 93 11:15:19 PDT Subject: DH for email (re: email protection and privacy) In-Reply-To: <9306141743.AA01676@dun-dun-noodles.aktis.com> Message-ID: <9306141815.AA01755@boxer.nas.nasa.gov> Marc Horowitz writes: > Case 4: "I forgot." Can they do anything? "I don't recall" worked for Reagan, Bush, et al quite well. :-( From mnemonic at eff.org Mon Jun 14 11:19:55 1993 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 14 Jun 93 11:19:55 PDT Subject: DH for email (re: email protection and privacy) In-Reply-To: <9306141743.AA01676@dun-dun-noodles.aktis.com> Message-ID: <199306141820.AA03729@eff.org> Marc asks a bunch of legal questions: > This is gonna sounds weird, but.... > > Let's say I have a (paper) document which explains how I (for example) > embezzled money from Megacorp, Inc. I presume that the Fifth > Amendment means I cannot be forced to produce this document. Why presume this? Suppose the document doesn't directly incriminate you (it doesn't say "I did this crime," for example), but, taken together with other evidence the government has, does tend to incrimininate you. In some circuits, at least, production of that document can be compelled. (In others, there is a "last link" exception--the government can't compel evidence that would constitute the "last link" in proving the government's criminal case against you.) > Case 1: let's say that I have the same document on disk, in the clear. > Can they force me to produce that? Assume that the rules are the same for paper or electronic documents. > Case 2: They sieze a disk from an associate which has the document, > but it's encrypted. Can they force me to produce the key? This has never been decided, but I think that, in terms of the relevant legal precedents, they can. The rule is that you can be compelled to produce anything that is not, in itself, testimonial in nature and tending to incriminate you. An encryption key, *taken by itself*, normally doesn't tend to incriminate anyone--after all, it usually looks like gibberish. > Mike, you > claim that there is precedent which says that they can. I'm curious > how the Fifth Amendment allows this. See above. The Fifth Amendment bars compelled testimony. If what is being compelled is not testimonial in nature, it doesn't violate the Fifth. > I've heard you say in the past > that key escrow doesn't violate the 5th because you're not disclosing > anything at the time. More precisely, what I've said is that this is the argument the government would make. In spirit, I think it violates the Fifth Amendment. > But if the government possesses an > incriminating document, wouldn't forcing me to give them the key > constitute self-incrimination? Possibly, in a circuit that recognizes the "last link" rule. > Case 3: I keep all my stuff encrypted, and enter the key from (say) a > smartcard of some sort when I boot up. They seize my machine, and > insist that I give them the key. If you mean the smartcard itself, well, that can be compelled or seized. But I take it you mean the key information. > I refuse, because the key is stored > in a cleartext document, which incriminates me in some way. (Say the > key is a hash of the document itself.) There is an exception to the rule that nontestimonial stuff can be compelled, and it's called, loosely, "the production privilege"--when the very act of producing what is sought tends to incriminate you, (by showing your ownership, control, authorship, or something similar), compelled production may violate the Fifth Amendment. But your question is more on the order of "What if the key is (or is derived from) a document that says 'I did this crime'?" My answer is: "I don't know." But I should note that if you set up elaborate schemes to block a law enforcement investigation that you already know or have reason to believe is taking place, you may be creating risk of criminal liability for obstruction of justice. > Case 4: "I forgot." Can they do anything? Yes. They can conclude that you're lying and cite you for contempt or (if you say "I forgot" under oath) charge you with perjury. Remember, courts and judges *frequently* have to decide whether people are lying or not, and they could decide you're lying in this case. --Mike From m5 at vail.tivoli.com Mon Jun 14 11:22:57 1993 From: m5 at vail.tivoli.com (Mike McNally) Date: Mon, 14 Jun 93 11:22:57 PDT Subject: DH for email (re: email protection and privacy) In-Reply-To: <9306141807.AA21784@banff.procase.com> Message-ID: <9306141821.AA08042@vail.tivoli.com> peb at PROCASE.COM writes: > >Case 4: "I forgot." > > This one seems to work for U.S. presidents. My suspicion is (gee Mike, you're right! I *am* a lawyer!) that in such cases the court makes a judgement as to whether a particular claim of forgetfulness is credible. If the information in question is clearly critical to the life or livelihood of the person being subpoenaed (is there a legal term for "person being subpoenaed"?), the claim that the key has been forgotten is likely to be disbelieved. Of course, the court might say "Ok, gee, that's too bad. I guess it's OK then if we just hold these floppies under this head demagnetizer." -- Mike McNally From strick at versant.com Mon Jun 14 12:33:02 1993 From: strick at versant.com (Henry Strickland) Date: Mon, 14 Jun 93 12:33:02 PDT Subject: FORWARD: Burt Kaliski: Anderson's RSA Trapdoor Can Be Broken Message-ID: <9306141935.AA05358@versant.com> [nando] ------- Forwarded Message Date: Mon, 14 Jun 93 11:21:38 PDT From: burt at RSA.COM (Burt Kaliski) Message-Id: <9306141821.AA06771 at RSA.COM> To: rsaref-users at RSA.COM, pem-dev at TIS.COM Subject: Anderson's RSA Trapdoor Can Be Broken Sender: pem-dev-relay at TIS.COM In a recent issue of Electronics Letters, Ross Anderson proposes a trapdoor in RSA whereby a hardware device generates special RSA keys that the device's manufacturer can break easily. The following note, just submitted to EL, shows that the special keys can be broken by anyone, not just the manufacturer. The trapdoor is ineffective. - -- Burt Kaliski RSA Laboratories - ---------------------------------------------------------------------- \documentstyle[12pt]{article} \newcommand{\mat}[2] {\left( \begin{array}{#1}#2 \end{array} \right)} \begin{document} \title{Anderson's RSA Trapdoor Can Be Broken} \author{Burton S. Kaliski Jr.\thanks{RSA Laboratories, 100 Marine Parkway, Redwood City, CA 94065. Email address: {\tt burt at rsa.com}.}} \date{June 11, 1993} \maketitle \begin{abstract} The RSA trapdoor proposed in Ross Anderson's recent letter can be broken. \end{abstract} \section{Introduction} A recent letter by Ross Anderson \cite{anderson-trapdoor} proposes a ``trapdoor'' in the RSA public-key cryptosystem \cite{rsa} whereby a hardware device generates RSA primes $p$ and $p'$ in such a way that the hardware manufacturer can easily factor the RSA modulus $n = pp'$. Factoring the modulus hopefully remains difficult for all other parties. The proposed trapdoor is based on a secret value $A$ known only to the manufacturer. For 256-bit RSA primes, the secret value $A$ is 200 bits long. The device generates primes $p$ of the form \begin{equation} \label{prime-form} p = rA + q = r(q,A)A + q, \end{equation} where $q$ is at most about 100 bits long, and $r$ is 56 bits long and a function of $A$ and $q$. To factor the RSA modulus $n = pp'$, the manufacturer reduces the modulus modulo $A$ to recover the product $qq'$, following the relationship \begin{equation} \label{modulus-form} n = pp' = rr'A^2 + (rq'+r'q)A + qq'. \end{equation} The 200-bit product $qq'$ is easily factored, and the manufacturer recovers the primes $p$ and $p'$ according to Equation \ref{prime-form}. \section{Breaking the trapdoor} While the trapdoor is indeed practical, it can be broken: Factoring such ``trapped'' moduli is easy. Let $n_0, \ldots, n_k$ be a set of such moduli, and let $r_0,r_0', \ldots, r_k,r_k'$ be the corresponding parameters from Equation \ref{modulus-form}. It is easy to show the following inequalities for the given parameter lengths: \begin{equation} \left\| r_0r_0' \frac{n_i}{n_0} - r_ir_i' \right\| \le 2^{-41}, \quad 1 \le i \le k. \end{equation} Such inequalities are called ``simultaneous Diophantine approximations,'' and they are classified as ``unusually good'' if the error term is less than $n_0^{-1/k}$ \cite{lagarias-approx}. For the given parameter lengths, this is so when $k$ is 13 or more. Given a set of moduli known to have such approximations, finding the approximations is straightforward. Following techniques for breaking knapsack cryptosystems (see \cite{brickell-survey}, \cite{lagarias-approx}, \cite{lll}), one finds a set of short vectors in the lattice generated by the basis \begin{equation} \mat{ccccc} {\lambda n_0 & 0 & 0 & \cdots & 0 \\ 0 & \lambda n_0 & 0 & \cdots & \vdots \\ \vdots & 0 & \ddots & 0 & \vdots \\ 0 & \cdots & 0 & \lambda n_0 & 0 \\ - -\lambda n_1 & -\lambda n_2 & \cdots & -\lambda n_k & 1}, \end{equation} where $\lambda$ is an integer near $n_0^{-1/k}$. In most cases, the short vector \begin{equation} \mat{ccccc}{\lambda(r_1r_1'n_0-r_0r_0'n_1) & \cdots & \lambda(r_kr_k'n_0-r_0r_0'n_k) & r_0r_0'} \end{equation} is a member of the set. The secret value $A$ follows from $r_0r_0'$, since, by Equation \ref{modulus-form}, the integer nearest to $n_0/(r_0r_0')$ is $A^2$. One way to overcome this attack is to assign a different secret value to each device, a precaution Anderson has suggested for another purpose. Then a user can only factor his or her own moduli. The user does not need 14 moduli to find $A$, however. Two prime factors $p$ and $p'$ suffice, since the fraction $r'/r$ is such a good approximation to the fraction $p'/p$ that it is guaranteed to be a convergent in the continued fraction expansion of $p'/p$. The user can therefore detect a trapdoor even if the device generates each modulus with a different secret value. \section{Conclusion} The manufacturer's only recourse, at least as far as the proposed trapdoor is concerned, is for the device to generate each modulus with a different secret value and to keep the prime factors secret. In such a situation, the manufacturer may as well preload the device with the primes and escrow copies---a practical ``trapdoor'' to which all cryptosystems, not just RSA, are vulnerable. \section{Acknowledgements} Matt Robshaw offered helpful comments and suggestions. I also thank God (Col. 3:17). \bibliographystyle{plain} \begin{thebibliography}{1} \bibitem{anderson-trapdoor} Ross Anderson. \newblock A practical {RSA} trapdoor. \newblock {\it Electronics Letters}, 29(11):995, 27 May 1993. \bibitem{brickell-survey} E.F. Brickell and A.M. Odlyzko. \newblock Cryptanalysis: {A} survey of recent results. \newblock {\it Proceedings of the IEEE}, 76:578--593, 1988. \bibitem{lagarias-approx} J.C. Lagarias. \newblock Knapsack public key cryptosystems and diophantine approximation. \newblock In D. Chaum, editor, {\it Advances in Cryptology: Proceedings of CRYPTO '83}, pages~3--23, Plenum Press, New York, 1984. \bibitem{lll} A.K. Lenstra, H.W. {Lenstra Jr.}, and L. Lovasz. \newblock Factoring polynomials with rational coefficients. \newblock {\it Math. Annalen}, 261:513--534, 1982. \bibitem{rsa} R.L. Rivest, A. Shamir, and L. Adleman. \newblock A method for obtaining digital signatures and public-key cryptosystems. \newblock {\it Communications of the ACM}, 21(2):120--126, February 1978. \end{thebibliography} \end{document} ------- End of Forwarded Message From tk at reagan.ai.mit.edu Mon Jun 14 12:35:50 1993 From: tk at reagan.ai.mit.edu (Tom Knight) Date: Mon, 14 Jun 93 12:35:50 PDT Subject: request for patent info In-Reply-To: <9306141704.AA24572@netcom3.netcom.com> Message-ID: <19930614193442.0.TK@ROCKY.AI.MIT.EDU> Full text of patents and claims are available (for a fee) from Dialog Information Systems on-line. Subscribers can access it in file 654. If there are particular patents that are important and that we need full text versions of quickly, I can oblige. Also extremely useful is the cross-indexing and forward references, so that you can find all patents, e.g., which reference a particular patent as prior art. From 76630.3577 at CompuServe.COM Mon Jun 14 14:19:35 1993 From: 76630.3577 at CompuServe.COM (Duncan Frissell) Date: Mon, 14 Jun 93 14:19:35 PDT Subject: Digital Cash$$$$ Message-ID: <930614200936_76630.3577_EHK40-1@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- L;>INTERNET:cypherpunks at toad.com;Digital Cash$$$$ (J. Michael Diehl) >>>1. How does one start a digital cash economy?<<< A digital cash economy doesn't have to be separate from the regular economy. 1.) You mail cash/MO to First Digital Bank of Cyberspace (at an offshore maildrop) together with a public (unique if you like) key and anonymous email address (on Julf's remailer perhaps). 2.) The Bank opens an account denominated in the (traded) currency of your choice or a commodity (gold). There is no reason not to use existing monies to back digital cash. 3.) You request digital banknotes and the bank emails them to you as detailed in David Chaum's Scientific American article. 4.) You find someone to accept the digital cash. Initially it can be used for gambling and telecoms/storage fees, eventually buying digital goods (software, print, audio, video, VR) will be easy. Remember, within a few years 100 million homes in OECD countries will have 1.5 megabit lines into them. This is a huge market for digital entertainment. 5.) After a bit of development when the First Digital Bank of Cyberspace cuts a deal with a physical offshore bank, it can issue VISA debit cards and ATM cards in a Nome de Guerre. This is already done for large depositors, the nets make it possible to do it for all. You can then access your account from any streetcorner in the OECD. Remember money market funds are pseudo banks these days with VISA cards and check writing and all. 6.) If you want to close your account, and you can't find any way to spend your money as digital cash, you can have funds wired to a regular bank account you maintain in a Nome de Guerre, have it wired via Western Union with a code phrase because you've 'lost' your ID (for small amounts), have it wired to an out-of- country bank in your truename and go pick it up in person, arrange a gold purchase from a dealer somewhere and have the funds sent to him by wire or draft and take physical delivery of the gold. (There are many other techniques known to privacy experts). Eventually there will be plenty of moneychangers on the nets happy to take your digital cash. Most money is already digital. The digital cash technology just gives us a way to make easy financial transfers over public networks. If there is a demand for economic transactions over the nets, the money will be supplied. ****************************************************************************** * DUNCAN FRISSELL Attorney at Law, Writer, and Privacy * * CIS 76630,3577 Consultant since the Nixon * * Internet 76630.3577 at compuserve.com Administration * * or frissell at panix.com * * Easylink 62853962 * * Attmail !dfrissell * * TLX: 402231 FRISSELL NYK * * * * * Privacy Checkup still only $29.95. Buy today before price * * * * controls force me to raise my prices. * * * * * "If Mohammed A. Salameh had seen me in January, he'd be * * vacationing in Tunisia today." * * * ****************************************************************************** From jjl at Panix.Com Mon Jun 14 14:20:13 1993 From: jjl at Panix.Com (J. J. Larrea) Date: Mon, 14 Jun 93 14:20:13 PDT Subject: request for patent info In-Reply-To: <9306141606.AA01411@boxer.nas.nasa.gov> Message-ID: <199306142119.AA17206@sun.Panix.Com> Eric Hughes writes: > As much as we need this, we also need the actual text of the patents. > What a patent actually covers is often much narrower than what is > claimed. And J. Eric Townsend adds: > Anyone near a federal patent repository can easily get this > information. Walk in, find the patent by number, have the nice > attendant print it out on a crappy photostat machine, pay in cash, > leave. No written record! Rice U. has a nice staff. (I don't know > where the west coast ones are.) Ah, the things we put up with in New York... the friendly attendants at the FPR run by the New York Public Library will happily change your bills into nickels and quarters so you can print it from microfilm yourself at $0.30 per page... But, they have a free dialup to the PTO's online "USPAT" database, which I have been using for the past few months. I will be there using the system sometime during the week of June 22. It would certainly be possible for me to capture abstracts, legal info (assignees etc.), etc. on a floppy and transfer it to the c-punks archive. Depending on how busy the library happens to be, I might also be able to get the fulltext of claims, and even maybe the full disclosure statement, for a limited number of patents (it takes a *long* time to download, and anything but citations is considered bad etiquette if anyone is waiting for the single terminal). I am willing to do this (time permitting, of course), if: (1) a person of credibility can assure me that I am not violating any copyright or other legislation by doing so. (2) one or more cypherpunks takes responsibility for gathering and summarizing a list of pertinent patent numbers, and keywords for further searching (which can include any word in the fulltext, inventor's name, assignee's name, etc.) - JJ From anton at hydra.unm.edu Mon Jun 14 14:36:59 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Mon, 14 Jun 93 14:36:59 PDT Subject: NitV open again Message-ID: <9306142136.AA05402@hydra.unm.edu> Your PGP *utilities* source for the BBS side of things in back online again, though there still remain some hardware probs of nasty proportions. I have upped the online time for the ANONYMOUS, password GUEST, account so you can get the larger stuff. See .sig for info. Note that FREQing may not work after the next Fido nodelist comes out, but that will only be temporary. I have the latest PGPShell (2.1), plus some innovative Fido-tech networking crypto goodies. I'd likely UL them to soda, but I was told that if it doesn't come with source code don't bother. Slightly frustrating, but oh well that's not my site. Anyway, got lots of other such goodies too, for Unix, and about 6 other platforms, including various shell and Perl scripts, NeXT diffs, etc. Disclaimer: Due to legal threats from RSADSI/PKP, I am not able to provide PGP itself. Anyone know if it would be legal to provide it in "kit form" (source code)? -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From anton at hydra.unm.edu Mon Jun 14 14:58:09 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Mon, 14 Jun 93 14:58:09 PDT Subject: funky wierdmail Message-ID: <9306142158.AA06863@hydra.unm.edu> Anyone got any idea why I keep getting mail like this? It appears to be a bounce of some sort. Dunno which list (if any) it is coming from, but many mailwizzes seem to be reading, so I am hoping no one will mind the bandwidth use... This is the WHOLE message, it's just header and no body. I get several of them per day, starting about 5 days ago. Quoth uucp at attmail.com, verily I saith unto thee: > From uucp at attmail.com Sun Jun 13 18:38:55 1993 > id ; Sun, 13 Jun 1993 18:38:53 -0600 > Message-Id: <9306140038.AA02312 at hydra.unm.edu> > From: uucp at attmail.com > Date: 14 Jun 93 00:30:46 GMT > To: anton at hydra.unm.edu > Report-Version: 2 > Confirming-Mts-Message-Id: > Confirming-Ua-Content-Id: > Original-Date: Mon Jun 14 00:30:46 GMT 1993 > Not-Delivered-To: mhs!wu/O=duncan_frissell/DD.ELN=62896145 due to 05 Unavailable User Agent > Content-Type: text > > -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton at hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) From wcs at anchor.ho.att.com Mon Jun 14 16:59:32 1993 From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com) Date: Mon, 14 Jun 93 16:59:32 PDT Subject: DH for email (re: email protection and privacy) Message-ID: <9306142224.AA14117@anchor.ho.att.com> peb at PROCASE.COM writes: > > >Case 4: "I forgot." > > > > This one seems to work for U.S. presidents. Yes, but in Reagan's case it was quite believable that he had forgotten; you, on the other hand, are presumed to be competent :-) Bill From bbyer at BIX.com Mon Jun 14 17:53:26 1993 From: bbyer at BIX.com (bbyer at BIX.com) Date: Mon, 14 Jun 93 17:53:26 PDT Subject: CERT: the letter from CERT to berkeley.edu admin Message-ID: <9306142046.memo.62427@BIX.com> In-Reply-To: <9306081620.AA07331 at soda.berkeley.edu> > Here, in its almost full glory, is the letter that CERT sent to the > admin at berkeley. I've removed the addressee, since there's no need > to involve that person. I have not, however, removed the name of the > sender. > ... > > We have been passed information that indicates that the anonymous FTP > archive on the following host(s) may be in use by intruders for ^ > illegal trading of commercial software: > > >>>>>>> soda.berkeley.edu /pub/cypherpunks > > We have not confirmed this information, nor have we identified that > the anonymous FTP configuration on the above-listed host(s) is open > for abuse. ^ > > ... This look suspiciously like a form letter. The possible plurals ("(s)") and the fact that the site name is in a "list type" format indicate this is probably a form letter. This is even more disturbing; do they have a form letter because they use it often or do they have a daemon that searches for highly undesirable things such as ftp sites with lots of encryption related things and automatically fires off this harassing form letter? Ben Byer From gnu at cygnus.com Mon Jun 14 18:09:45 1993 From: gnu at cygnus.com (gnu at cygnus.com) Date: Mon, 14 Jun 93 18:09:45 PDT Subject: Kahn Sees On-Going Battle On Cryptography 06/14/93 Message-ID: <9306150109.AA21678@cygnus.com> From: newsbytes at clarinet.com Newsgroups: clari.nb.general Subject: Kahn Sees On-Going Battle On Cryptography 06/14/93 PALO ALTO, CALIFORNIA, U.S.A., 1993 JUN 14 (NB) -- David Kahn, author of "The Codebreakers", speaking at the Third CPSR Cryptography Conference, told those assembled that he sees an on- going battle between government and privacy advocates over personal and business uses of cryptography. Kahn began by saying "My thesis is that the growth of cryptography follows the growth of communication. When there was little literacy, writing itself was a form of cryptography" "A great leap forward came in World War I -- the use of radio brought the need for greater use of codes to insure the privacy of messages. In the fall out after the war, the use of cipher machines was attempted but this approach was not really practical until computers came along," he added. According to Khan, in recent times, interest in cryptography has grown dramatically. "When the RSA algorithm was mentioned in Scientific American, there were 5,000 requests for reprints of the article; the story "Ultra Secret" about the breaking of the Germans' code raised interest and threats such as computer "hackers", viruses and cellular phone fraud raised additional interest in cryptography and the protection of privacy," he said. Kahn then moved to his Antithesis: "(The) Government wants to stop the movement toward privacy. (The) Government wants to know about criminal and terrorists. It tries to accomplish this objective through such things as export controls and the Clipper & Capstone chips," he told the audience. "The Government sees its activity. not as an additional intrusion into individual privacy. but as an attempt to maintain the present state. However, the domain of individual rights has been expanding -- the Miranda warnings, abortion decisions and the more strident avocation of privacy rights are examples of this trend," he said. "The Government moves are trying to block the advance of privacy rather than intrude into present rights. Export limits inhibits business expansion," he added. Kahn concluded: "Now we have to look for the synthesis. It's a matter of "privacy is good" and "business profits are good" versus "security is good." The question that must be answered is how to balance these goods. Do we give up the first for the second?" "The World Trade Center bombing shows that terrorism is here and is a concern. Government wants to hold back technology. This can't be done forever but can be done for a while. Government will argue that the temporary holding back will save some lives and properties," he said. In the question and answer period that followed, Bill Murray, consultant to Deloite and Touche, commented: "When the government wants us to give up the right to private communications, it must show us the danger (that warrants it). If drug dealers and terrorists are the problem, it should be demonstrated that drug dealers and terrorists are abusing private communications." In response to a Newsbytes question as to whether the triumph of the expansion of privacy rights over government concerns was inevitable, Kahn said: "Privacy is to powerful a force to be stopped. It will eventually prevail." Ross Stapleton, a Central Intelligence Agency (CIA) analyst, commented: "These changes in information may cause a rethinking of the concept of national sovereignty. Governments have always have tried to control the flow of information; with the new technology and communications capabilities, they cannot. control it any longer." Murray said: "We cannot control it but we can criminalize it and that would be a mistake. By criminalizing drugs, we have destabilized society. There is so much illegal money from this policy that courts, law enforcement departments and legislatures have been corrupted." Asked by Newsbytes if he saw illegal money growing if the government tries to rein in the growth of cryptography or tries to make wiretapping more pervasive, Murray said: "No, it's not analogous in the money sense. But the criminalizing of anything without real justification causes destabilization." (Barbara E. McMullen & John F. McMullen/19930614/Press Contact: David Banisar, Computer Professionals For Social Responsibility, 202-544-9240 (voice); 202-547-5481 (fax); banisar at washofc.cpsr.org on the Internet) "Copyright 1993 by (I have no idea who). Reposted with permission from the ClariNet Electronic Newspaper newsgroup clari.nb.general. For more info on ClariNet, write to info at clarinet.com or phone 1-800-USE-NETS." From Brian.Hawthorne at East.Sun.COM Mon Jun 14 18:57:45 1993 From: Brian.Hawthorne at East.Sun.COM (Brian Holt Hawthorne - SunSelect Engineering) Date: Mon, 14 Jun 93 18:57:45 PDT Subject: DH for email (re: email protection and privacy) Message-ID: <9306141918.AA26700@sea.East.Sun.COM> > Let's say I have a (paper) document which explains how I (for example) > embezzled money from Megacorp, Inc. I presume that the Fifth > Amendment means I cannot be forced to produce this document. Bad assumption. Written documents, even if written by you and even if it incriminates you, can be subpoenaed. I forget the case that set the precedent for this, but it had to do with someone's diary. From gnu Mon Jun 14 20:31:23 1993 From: gnu (John Gilmore) Date: Mon, 14 Jun 93 20:31:23 PDT Subject: 2600 testimony to Markey's subcommittee In-Reply-To: <9306141559.AA01370@boxer.nas.nasa.gov> Message-ID: <9306150331.AA08630@toad.com> I was at the subcommittee hearing last Wednesday when "Emmanuel Goldstein" testified, and I took notes. It is true that two committee members (about half of the total who were present) focused on 2600 as being a handbook for crime. Don Delaney, who was also on the panel, giving good evidence about the extent and organization of phone fraud in New York City, noted that the First Amendment had already been abridged to protect kids from pornography, and proposed a law that would make it a crime to sell security-related information to juveniles. Subcommittee Chairman Markey told a long rambling story about people going down Maple St. rattling the doorknobs and why that was a bad thing. He compared 2600 to people who rattle the doorknobs and then post on the bulletin board downtown, "The door to 123 Maple St. is unlocked". Rep. Fields said to "Emmanuel" that it was "frightening that someone like you thinks there's a protected right to violate someone's privacy." The ironic thing is that another panelist, John J. Haugh, heads a consulting firm that publishes details about similar topics. He's the editor and principal author of a two volume reference work, _Toll Fraud and Telabuse_, published by his company in early 1992. He's also the editor of a national newsletter, _Telecom & Network Security Review_, also published by his company, with subscribers in 49 states and 18 countries. Mr. Haugh did not get hectored by the panel. But Mr. Haugh charges $170/year for six issues of his newsletter, and wore a suit to the hearing. When the same information is published at 2600 prices, packaged for more adventurous people, it is "troubling". My opinion is that when the privacy and security of society depends on those doors being locked, then yes, we ought to have whole squads of Boy Scouts, cops, hackers, and ordinary citizens rattling those doorknobs hourly and daily. And when we find one open, we should let the world know, because the privacy and security of the world depends on it. This applies to information like, "if you tune an ordinary radio to these frequencies, you can hear everyone's phone calls." If the info is suppressed, the problem will never be fixed, because not enough public pressure will be brought to bear on those responsible for fixing it. John Gilmore PS: The first half of the hearing was on encryption and Clipper, and I am pleased to say that the subcommittee took the *right* stance on that issue -- that the Clipper proposal was trouble and that fundamental rights, upon which our society is based, were at stake. From stig at netcom.com Tue Jun 15 01:36:40 1993 From: stig at netcom.com (Stig) Date: Tue, 15 Jun 93 01:36:40 PDT Subject: Steganography and Steganalysis In-Reply-To: <9305252227.AA27968@toad.com> Message-ID: <9306150837.AA16621@netcom.netcom.com> In <9305252227.AA27968 at toad.com>, John Gilmore wrote... > My favorite scheme was to encode messages in trailing spaces and/or tabs > in netnews messages. You could also put internal tabs in place of spaces. > > In fact, you could do this with news messages that flow "through" your > site, (if the messages aren't protected with a crypto checksum), so that > you would not be the message's sender (and it wouldn't be addressed to anyone > either -- recipients get very good privacy). > > This would be one way for a Unix "worm" program to report back to its > master...and/or receive instructions. > > John Gilmore > > PS: You could put short interesting stuff just in your message-ID's! > Not to mention the low order bits of timestamps (exactly *what* second > did it arrive, now?). /* Jonathan Stigelman, Stig at netcom.com, PGP public key by finger */ /* fingerprint = 32 DF B9 19 AE 28 D1 7A A3 9D 0B 1A 33 13 4D 7F */ From stig at netcom.com Tue Jun 15 01:40:10 1993 From: stig at netcom.com (Stig) Date: Tue, 15 Jun 93 01:40:10 PDT Subject: Digital cash software In-Reply-To: <9306140709.AA05436@toad.com> Message-ID: <9306150840.AA16772@netcom.netcom.com> In <9306140709.AA05436 at toad.com>, John Gilmore wrote... > I spoke with David Chaum, the inventor of digital money, last week at > the cryptography meetings in DC. He is willing to give us a noncommercial > license to use his digital money patents, and copies of some of his > software for digital cash, for us to deploy somehow, and start using. > What constitutes 'noncommercial'? I mean, we are talking about cash... Stig /* Jonathan Stigelman, Stig at netcom.com, PGP public key by finger */ /* fingerprint = 32 DF B9 19 AE 28 D1 7A A3 9D 0B 1A 33 13 4D 7F */ From pcw at access.digex.net Tue Jun 15 05:36:39 1993 From: pcw at access.digex.net (Peter Wayner) Date: Tue, 15 Jun 93 05:36:39 PDT Subject: 2600 testimony to Markey's subcommittee Message-ID: <199306151236.AA29913@access.digex.net> Of course, it seems perfectly obvious to Markey that 2600 is a "handbook on crime", but EG should have turned around and pointed out that he's just transmitting information on the world and there is nothing wrong with that. Gosh, if there was then Congressional Hearings and C-Span should be rated R to prevent the little whippersnappers from seeing and hearing demonstrations like the one that John Gage gave the committee several weeks ago. One person commented that Time magazine's latest article on Crack was practically a "How-To" guide. It satisfied the "Enquiring Minds" that wanted to know just what those people did with the magic crystals. Another friend informs me that Pornography is often transmitted with the label "For Scientific Research purposes only." Apparently, the law contains some exception for Doctors and Biologists. Hmmm. I wonder where Masters and Johnson fit in here. -Peter Wayner From nowhere at bsu-cs.bsu.edu Tue Jun 15 08:34:30 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Tue, 15 Jun 93 08:34:30 PDT Subject: REMAIL: X-Discard header line added Message-ID: <9306151537.AA07449@bsu-cs.bsu.edu> In an effort to make creating more traffic for the Cypherpunks remailers easier, I have added a feature to my remailer. Whenever it receives a message that would otherwise be remailed but contains a header line saying "X-Discard:" it will discard the message and act as though it got remailed. If all of the Cypherpunks remailers supported an automatic discard feature, we could setup cron jobs or whatever kind of software we want to send "junk mail" to the remailers that does not get forwarded on. An idea I just had was to make the X-Discard have a counter. If the number is greater than zero, decrement it and forward the message to another known remailer. If it is less than one or non-numeric, discard the message. Right now, it just discards whatever message has that header. Example Message: ==================================== From: nobody at no.com To: nowhere at bsu-cs.bsu.edu Subject: Test :: Request-Remailing-To: bob&tom at bit.bucket.net X-Discard: Please! Test Message ==================================== Chael -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at BSUVC.BSU.EDU, chall at bsu.edu (317) 776-4000 from 8 am - 5 pm CST From hughes at soda.berkeley.edu Tue Jun 15 09:04:47 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 15 Jun 93 09:04:47 PDT Subject: request for patent info In-Reply-To: <199306142119.AA17206@sun.Panix.Com> Message-ID: <9306151600.AA08672@soda.berkeley.edu> The main rationale behind granting patent monopoly is for the disclosure of the technique to the public. As such, patents are public record. There is no danger of violating copyright by publishing patents, already public information. Here is RSADSI's patent portfolio: Public Key Cryptographic Apparatus and Method ("Hellman-Merkle") No. 4,315,552 Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig") No. 4,434,414 Cryptographic Apparatus and Method ("Diffie-Hellman") No. 4,200,770 Cryptographic Communications System and Method ("Rivest-Shamir-Adelman") No. 4,405,829 Method For Identifying Subscribers And For Generating And Verifying Electronic Signatures In A Data Exchange System ("Schnorr") No. 4,995,082 In my own opinion, the RSA and DH patents are relatively strong, given that they cover particular algorithms and not whole classes of techniques. The key word here is relative; they might not hold themselves, but they are certainly much more likely to hold that some of their others. PKP makes the following statement. This is right out of RFC-1421, one of the Privacy Enhanced Mail (PEM) documents. "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." It is my opinion that this statement is false, and not only false, but an improper extension of patent monopoly. The weakest link is the Hellman-Merkle patent, which PKP uses to claim all public key cryptography. Public key cryptography as such is certainly not patentable, since it is merely a collection of characteristics of specific systems; public key cryptography is not a specific process or method, but a collection of such processes and methods. Only specifics are patentable. Public key cryptography is an idea, and ideas are not patentable. The next weakest link is the Hellman-Pohlig patent, which is, I believe, that which PKP uses to claim that all uses of the discrete log problem (e.g. El-Gamal) are also covered. Here again, the use of an item without reference to a specific process or machine is not patentable. The specific use of exponentiation in the H-P patent is for an RSA pseudofield (i.e. mod pq), but with exponent two. As such, if we are going to prioritize patents, I would gather them in the order indicated. As far as doing forward references, The H-M patent is likely the most interesting, since it will lead to many other patent public key ciphers. The RSA patent is likely the next, because it is so widely known and mathematically simple. Eric From i6t4 at jupiter.sun.csd.unb.ca Tue Jun 15 09:10:48 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Tue, 15 Jun 93 09:10:48 PDT Subject: REMAIL: X-Discard header line added In-Reply-To: <9306151537.AA07449@bsu-cs.bsu.edu> Message-ID: On Tue, 15 Jun 1993, Chael Hall wrote: > An idea I just had was to make the X-Discard have a counter. If > the number is greater than zero, decrement it and forward the message > to another known remailer. If it is less than one or non-numeric, > discard the message. Right now, it just discards whatever message > has that header. Seems like a very good idea, at least for the short term, to generate traffic. Just make sure that you do not accept a value for X-Discard that is too large, or else you'll find the same message floating around (Internet Worm sytle) when you *don't* need any extra traffic! If you wanted to really have fun, you could also add X-Discarded-By to keep a list of all sites the message has visitied, and make sure the same message doesn't cycle through the same site too many times. -- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger i6t4 at unb.ca | (506) 457-1931 ^{1024/746EBB 1993/02/23} From mccoy at ccwf.cc.utexas.edu Tue Jun 15 09:42:56 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Tue, 15 Jun 93 09:42:56 PDT Subject: REMAIL: X-Discard header line added In-Reply-To: <9306151537.AA07449@bsu-cs.bsu.edu> Message-ID: <199306151642.AA07985@tramp.cc.utexas.edu> > > In an effort to make creating more traffic for the Cypherpunks > remailers easier, I have added a feature to my remailer. Do you mean easier to create more flow to thwart analysis or easier for an observer to determine which messages it does not need to examine after reaching a certain line in the header. This seems like a nice effort, but will not deter traffic analysis in the slightest. Headers are always unencrypted, so anyone watching the flow will be able to write a 3 line perl script to filter out all of these messages and there is nothing a header line can do to hide this discard information. What might be more usefull is a counter that signals the remailer system to stop passing a message and unwrap part of the message and act upon the instructions there; thus the counter would let tell the system how long to bounce the message around internally and when the counter hits zero it could send the message on to the target. For example you could create a little MIME x-anon-remailer body part that contains lines with the the final destination wrapped in the remailer pubkeys. When the counter hits zero the remailer checks the x-anon-remailer body part of the line that matches its pubkey, decrypts that line to get the final address and then sends the message on. In this sort of system all you would really need to do is send someone a message with your destination address wrapped in one anon remailer pubkey. When Alice replies to Bobs message she includes the x-anon-remailer body part which has the line provided by Bob (or several it Bob provides more than one). Alice sends this message to any remailer entry point and the message gets bounced around the system until the counter hits 0. At this point the remailer checks to see if it can decrypt any of the destination lines, if not it ups the counter by one (and maybe sets a TTL counter so that messages that have destination keys corrupted do not float forever...) and tosses it back into the system, if it can decrypt one of the destination keys it sends the message off to the address Bob has provided inside the destination key (Bob could even have the destination key send it the message into another remailer system if he is sufficiently paranoid). This would make traffic analysis much harder because once the message enters the remailer system it bounces around so much; the remailers become a black box that deliver the message without really knowing anythign about it until the last phase of delivery. This would also not waste bandwidth moving useless messages around. jim From hughes at soda.berkeley.edu Tue Jun 15 10:02:24 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 15 Jun 93 10:02:24 PDT Subject: request for patent info In-Reply-To: <9306141704.AA24572@netcom3.netcom.com> Message-ID: <9306151658.AA10959@soda.berkeley.edu> >Sunnyvale, CA. Near the public library off Mathilda Ave. Do they have electronic access at this library, or is it paper only? I know they have a fax service for which they charge, but is there downloadable text available? As much as we need the text of the patents, we also need to gather them in electronic form. I thank those who have offered to do so. Eric From hughes at soda.berkeley.edu Tue Jun 15 10:16:12 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 15 Jun 93 10:16:12 PDT Subject: REMAIL: X-Discard header line added In-Reply-To: <199306151642.AA07985@tramp.cc.utexas.edu> Message-ID: <9306151711.AA11398@soda.berkeley.edu> >Headers are always >unencrypted, so anyone watching the flow will be able to write a 3 line >perl script to filter out all of these messages and there is nothing a >header line can do to hide this discard information. The cypherpunks remailers use a little invention called 'header pasting' where header fields may be added into the header after receipt but before processing. These pasted header fields may in addition be put inside encryption wrappers, thus hiding them from the outside world. 'Discard' headers may use this technique. Eric From falcor at agora.rain.com Tue Jun 15 11:21:19 1993 From: falcor at agora.rain.com (Andy Burt) Date: Tue, 15 Jun 93 11:21:19 PDT Subject: digcash Message-ID: If anyone out there has a non-PS FAQ on digcash, I'd appreciate it. Thanx! -- ----------------------------------------------------------------------------- // Falcor, aka // InterNet: falcor at agora.rain.com // "Curiouser and // // Andy Burt // FidoNet: 1:105/354.0 // curiouser!"-Alice, // // // PGP2.2 PublicKey Avail On Request // Lewis Carroll // ---------------------------------------------------------------------------- From nowhere at bsu-cs.bsu.edu Tue Jun 15 12:36:23 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Tue, 15 Jun 93 12:36:23 PDT Subject: REMAIL: X-Discard header line added In-Reply-To: <199306151642.AA07985@tramp.cc.utexas.edu> Message-ID: <9306151939.AA13767@bsu-cs.bsu.edu> >will not deter traffic analysis in the slightest. Headers are always >unencrypted, so anyone watching the flow will be able to write a 3 line >perl script to filter out all of these messages and there is nothing a >header line can do to hide this discard information. Eric has already addressed this; I intend to make my remailer PGP capable soon. If not the one on bsu-cs, the new one will have PGP as soon as I can get to it. >paranoid). This would make traffic analysis much harder because once the >message enters the remailer system it bounces around so much; the remailers >become a black box that deliver the message without really knowing anythign >about it until the last phase of delivery. I'm not sure what you mean about bouncing it around to different remailers, because if there are a lot of remailers, it could take a long time before it finally gets to the appropriate one that can decrypt the destination information (perhaps longer than the TTL and therefore it does not get delivered). With encryption, the remailers don't have to know the recipient until the last phase anyway. In addition, they may not know the contents of the message either. >This would also not waste bandwidth moving useless messages around. Right now, we have plenty of bandwidth because the remailers don't get much use. ALL: Which is better: X-Discard or X-TTL? I can easily change it to X-TTL. Chael -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at BSUVC.BSU.EDU, chall at bsu.edu (317) 776-4000 from 8 am - 5 pm CST From strick at versant.com Tue Jun 15 12:37:56 1993 From: strick at versant.com (Henry Strickland) Date: Tue, 15 Jun 93 12:37:56 PDT Subject: MEDIA: Steven Levy on 91.7 re Cypherpunks (already happened) Message-ID: <9306151940.AA03720@versant.com> Steven Levy was interviewed on FM91.7 (san francisco public radio, I forget the call letters) this morning. My patch cable isnt working for some reason, or I would have caught it in a ulaw file. I don't know the name of the show, or if they will rebroadcast it, but if you're interested, you might try to track it down. As one might expect, he did a good job of introducing some hard-edge issues in fairly-mainstream-but-technical media... strick From 76630.3577 at CompuServe.COM Tue Jun 15 13:15:29 1993 From: 76630.3577 at CompuServe.COM (Duncan Frissell) Date: Tue, 15 Jun 93 13:15:29 PDT Subject: digital cash Message-ID: <930615194400_76630.3577_EHK24-1@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- >>>The legal issues involved in setting up a real world money system are enormous.<<< No need. This is the advantage of piggy backing a digital cash application onto an existing offshore financial institution. It is true that if I sat in the US and started to offer digital cash accounts I would be subject to a lot of regulation. DC would probably be held to be a 'security' and there are all sorts of financial regulations involved. It might be possible to get a regulatory waiver for an experimental system if we got an academic partner like the Iowa Political Stock Market which also traded 'securities' with account sizes up to $1,000. On the other hand, other jurisdictions are not as regulated as the US is. Generally, solicitations for unregistered securities cannot be directed to Americans except in international publications. I would advocate that all physical mail involved in such an application be sent and received overseas (The City of London would be convenient) and that all email be sent via Julf's remailer. We could also start an internet DC email group (as a feedback and semi-advertising medium) sent from Finland. (Julf willing of course.) It would be interesting to see the litigation about whether or not such a publication is a "domestic" publication. It should be easy to find non-US residents to be the nominal "publishers." Now all we need is a banking haven jurisdiction with good internet connections... I *have* been looking. Duncan Frissell -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLB36L4VO4r4sgSPhAQFGswQA3JTCDiFHPfazuWYo8+4BALg4cvGFWVXq mBJYhx7avEWUYIqZOK5b/XinmmJvoPNxAIKhjk/bNDOxq21kAKE/29PPygQgSXt8 uQPcG45MB5tBwS6fBNuSG/4uljiPveAYvD5xU0JuOGev03Zd8FOV9tvRsBiYGudn eGeH96j0Oxc= =wVQT -----END PGP SIGNATURE----- From nowhere at bsu-cs.bsu.edu Tue Jun 15 13:21:12 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Tue, 15 Jun 93 13:21:12 PDT Subject: REMAIL: X-TTL functional Message-ID: <9306152024.AA14776@bsu-cs.bsu.edu> I should know by now that whenever I get an idea and send it to the list it ends up getting lots of addons and changes from other list members. So.... I added an X-TTL field to the header. It reads it, decrements it, and writes it. If it's in the message received, it will be decremented and passed on. If it isn't in the message, it will be set to one then later decremented (last stop). If it should be zero when it arrives, it will be swallowed up. Messages that get sent will have a header field of X-TTL with a value of zero or greater. Note that it shows up as X-Ttl in ELM, but doesn't matter in the software because it converts everything to lowercase then checks it against its keyword list. The X-TTL field can be either in the main header or in the pasted "::" header block. I suppose that if the TTL is greater than zero when it goes to send, the remailer should throw in another remailer's name at random and make up its own "::" header block, but that is for later... Chael -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at BSUVC.BSU.EDU, chall at bsu.edu (317) 776-4000 from 8 am - 5 pm CST From mccoy at ccwf.cc.utexas.edu Tue Jun 15 14:54:03 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Tue, 15 Jun 93 14:54:03 PDT Subject: REMAIL: X-Discard header line added In-Reply-To: <9306151939.AA13767@bsu-cs.bsu.edu> Message-ID: <199306152153.AA08290@tramp.cc.utexas.edu> [...] > >paranoid). This would make traffic analysis much harder because once the > >message enters the remailer system it bounces around so much; the remailers > >become a black box that deliver the message without really knowing anythign > >about it until the last phase of delivery. > > I'm not sure what you mean about bouncing it around to different > remailers, because if there are a lot of remailers, it could take a long > time before it finally gets to the appropriate one that can decrypt the > destination information (perhaps longer than the TTL and therefore it does > not get delivered). With encryption, the remailers don't have to know the > recipient until the last phase anyway. In addition, they may not know the > contents of the message either. I set the "breakout counter" at 10 and throw it into any port on the remailer web. It bounces around 10 times and then the "deliver this damn message" flag gets tripped and the TTL counter starts. The TTL counter is actually the number of hops from this point on that the message will traverse looking for someone who can decode the encrypted destination address before the message dies or is otherwise checked for problems. It could take a long time to deliver the message, but time latency is another possible means of confounding traffic analysis. What I was basically thinking was that the breakout counter tells the message how many times to randomly bounce around the internal structure of the remailer web (and hopefully becoming lost in the clutter) before it tries to find someone who can deliver it; the TTL would be used once the breakout counter had hit zero and would try to keep a message from bouncing around forever if there is an addressing problem. This would obviously increase the complexity of the system and require a collection of remailers scattered across the net, but it seems to me to have the advantages of providing more security as the number of remailers grows and to allow bepopel to set up thier own forwarding and addressing that is independant of the remailer system (you generate your own destination certificates and can string together whatever you want in the destination, even another hop back into the remailer system.) It may be overly complex, but it just seemed to me that it might offer the possiblity of truly untracable mail: two messages sent into the same entry port with the same destination certificates at the same time could end up coming out of two different exit ports on the black box depending on how they bounced around inside the system. If you want someone to be able to send you a reply to an anonymous message you give them a destination certificate that contains the destination you want the message sent to wrapped in various remailer pubkeys (one or more, it is up to you). They do not need to know where the message is going, they just attach the certificate to thier message and drop it into _any_ remailer and know that it will either get to the destination or get bounced back to them. A distributed anonymous remailer system of sorts... jim From zane at genesis.mcs.com Tue Jun 15 15:08:49 1993 From: zane at genesis.mcs.com (Sameer) Date: Tue, 15 Jun 93 15:08:49 PDT Subject: REMAIL: X-Discard header line added In-Reply-To: Message-ID: In message , Nickey MacDonald writes: > > Seems like a very good idea, at least for the short term, to generate > traffic. Just make sure that you do not accept a value for X-Discard that I don't understand what the point is in adding unnecessary, junk traffic to the remailers. Please explain. Peace, -- | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/ From bbyer at BIX.com Tue Jun 15 17:53:46 1993 From: bbyer at BIX.com (bbyer at BIX.com) Date: Tue, 15 Jun 93 17:53:46 PDT Subject: Timothy C. May:superhacker Message-ID: <9306152043.memo.64107@BIX.com> In-Reply-To: <01GZ6EDS7DHK003YG5 at vax1.tcd.ie> > Why doesn't Tim and anyone else who suspects that they have reached > the much-sought status of "superhacker on gov't files not just write > to their local friendly federal government office and ask for a copy > of their own records? > > Of course any interesting information they've got is likely to be classified, > but at least you'll find out whether any such information is stored on the > files. > > Of course, requesting your own government file is likely to draw attention > to yourself, so it's probably best not to do so unless you're sure that > they already know that you know-that-they-know-something. Yes, acoording to a 2600 article (admittedly not the best source), requesting a file on yoursself causes one to be created if one does not exist. Ben Byer From steven at well.sf.ca.us Tue Jun 15 19:38:20 1993 From: steven at well.sf.ca.us (Steven Levy) Date: Tue, 15 Jun 93 19:38:20 PDT Subject: on the radio Message-ID: <93Jun15.193753pdt.13987-4@well.sf.ca.us> >Steven Levy was interviewed on FM91.7 (san francisco public radio, I >forget the call letters) this morning. My patch cable isnt working for >some reason, or I would have caught it in a ulaw file. >I don't know the name of the show, or if they will rebroadcast it, but >if you're interested, you might try to track it down. I think the name of the show was TechAmerica, or something like that, a show syndicated on public radio. I did the interview about a month ago, me in Amherst, a fairly sharp interviewer in San Francisco. Steven From bear at eagle.fsl.noaa.gov Tue Jun 15 19:40:11 1993 From: bear at eagle.fsl.noaa.gov (Bear Giles) Date: Tue, 15 Jun 93 19:40:11 PDT Subject: Timothy C. May:superhacker Message-ID: <9306160237.AA20240@eagle.fsl.noaa.gov> Ben Byers writes: In-Reply-To: <01GZ6EDS7DHK003YG5 at vax1.tcd.ie> >> Of course, requesting your own government file is likely to draw attention >> to yourself, so it's probably best not to do so unless you're sure that >> they already know that you know-that-they-know-something. > >Yes, acoording to a 2600 article (admittedly not the best source), >requesting a file on yourself causes one to be created if one does >not exist. Naturally they'll open a file on you to document the fact that you requested information under the FOIA and to file a copy of the information returned to you. Will they start an investigation on the basis of the fact that you requested information under the FOIA? How many people with rather, shall we say, unusual ideas do you think have pestered the CIA or NSA with FOIA requests? Of course, if you admit you learned about this on a cryptoanarchist e-mail list... :-) Bear Giles From mdiehl at triton.unm.edu Tue Jun 15 19:49:30 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 15 Jun 93 19:49:30 PDT Subject: alt.whistleblowing-cypherpunk FAQ In-Reply-To: <9306140621.AA29371@longs.lance.colostate.edu> Message-ID: <9306160249.AA18896@triton.unm.edu> According to L. Detweiler: > > Mr. Diehl: > If you had taken the time to read any significant portion of > alt.whistleblowing traffic, I would imagine you would have stumbled on > messages where I presented an outline/preliminary FAQ and an anonymous > posting described precisely how to use Julf's remailer to send traffic I read the entire newsgroup! All 27 articles. In these articles, I counted exactly ONE from you, and it had nothing to do with what you describe above. > (which were posted under a week ago). I take great offense at your > hasty, flippant denigration of it so far as a `flamefest'. While of Then, IMHO, you are easily offended. But, lets look at what I was refering to: Several messages in alt.whistleblowing.... Drasticly condensed to save BW. From mlshew at dixie.com Tue Jun 15 19:57:37 1993 From: mlshew at dixie.com (Mark Shewmaker) Date: Tue, 15 Jun 93 19:57:37 PDT Subject: Rude CryptoStacker Suggestion Message-ID: On Mon, 14 Jun 1993, RYAN Alan Porter wrote: >On Mon, 14 Jun 1993, Mark Shewmaker wrote: > >I don't consider us without options, I just have yet to see a program that >I would trust my data with. > >Besides, I wouldn't consider it a waste of effort even if there were such >a system out there (which I doubt) Well then I have doubts about your doubts: Even I've got a few ways of getting transparent compression or encryption on my own system (amiga), most of them simply device drivers or some other standalone sets of code one would then to use to mount a (virtual) partition, and there's also a more standardized compression/encryption modular system to do the same thing (sort of), just like you talk about later. That's why I keep thinking that for PC's and freely distributable source code for encrypting file systems, that by now someone *must* have already invented the wheel. (Although you could still invent the radial tire, so to speak, and make the original idea more usable.) >Anyway, thanks for the suggestion; I would be interested in any parallel >systems which anyone might happen to stumble upon. Seeing as you had previously said: >The sources for bare network redirectors and block device drivers are, >indeed, in wide supply. I guess I really should upload some of the amiga code then, even though a great deal of it will absolutely useless to you, (but I must admit it would be kinda cool if pc's and amigas could both access the same compressed/encrypted xpk files.) If it's really just the encryption part per se that you are missing, then they might be helpful to your project. I'll write up a description, plagiarizing the readme files somewhat, and upload a few of the archives to Eric's site. >The more people who know how to implement good encryption, the more >widespread other cypher code will become. Very true. (I'm always annoyed when I download a new "security" type program, only to find it lets you encrypt/decrypt with any of ten proprietary methods, numbered one through ten. Absolutely useless. And of course the scums never include the source. Grrr.) >(Oh also, have I come off lately as being incredibly overflamesensitive, >or are you just a very cautionary guy? I can understand it if I have >projected a flameshield attitude, but I'm really not that bruisable...) "Jane, you ignorant slut." (Implied smileys for the SNL-impaired.) Partly I'm cautionary, trying to be polite, tit for tat and all that, but also I don't like being the 100th person whining about your project, (especially knowing next to nothing about DOS systems), while people who think it's a neat idea keep quiet. Plus I overdid the cautiousness a bit. (And I've got this pet peeve about people re-introducing obvious ideas in sci.crypt, and similar places.) -Mark Shewmaker From julf at penet.FI Tue Jun 15 21:26:54 1993 From: julf at penet.FI (Johan Helsingius) Date: Tue, 15 Jun 93 21:26:54 PDT Subject: digital cash In-Reply-To: <930615194400_76630.3577_EHK24-1@CompuServe.COM> Message-ID: <9306160611.aa19291@penet.penet.FI> > Generally, solicitations for unregistered securities cannot be directed to > Americans except in international publications. I would advocate that all > physical mail involved in such an application be sent and received overseas > (The City of London would be convenient) and that all email be sent via > Julf's remailer. We could also start an internet DC email group (as a > feedback and semi-advertising medium) sent from Finland. (Julf willing of > course.) It would be interesting to see the litigation about whether or > not such a publication is a "domestic" publication. It should be easy to > find non-US residents to be the nominal "publishers." I'd be more than happy to participate in this! Julf From mdiehl at triton.unm.edu Tue Jun 15 20:48:05 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 15 Jun 1993 21:48:05 -0600 (MDT) Subject: Digital Cash$$$$ In-Reply-To: <930614200936_76630.3577_EHK40-1@CompuServe.COM> from "Duncan Frissell" at Jun 14, 93 04:09:37 pm Message-ID: <9306160348.AA20651@triton.unm.edu> According to Duncan Frissell: > A digital cash economy doesn't have to be separate from the regular economy. > 1.) You mail cash/MO to First Digital Bank of Cyberspace (at an offshore > maildrop) together with a public (unique if you like) key and anonymous email > address (on Julf's remailer perhaps). Then DC is actually backed by "legal" currency? Then, what's to keep someone from opening a digital bank, and takeing the money and runing? > 4.) You find someone to accept the digital cash. Initially it can be used > for gambling and telecoms/storage fees, eventually buying digital goods > (software, print, audio, video, VR) will be easy. Remember, within a few > years 100 million homes in OECD countries will have 1.5 megabit lines into > them. This is a huge market for digital entertainment. OECD? Obviously, DC can lead to quite a few opportunities for corruption, taxes for example. This will hinder (or help, in Washington D.C! ;^]) the spread of DC. Is there any arguements for DC, to offer to counter this major drawback? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From nobody at eli-remailer Tue Jun 15 22:07:41 1993 From: nobody at eli-remailer (nobody at eli-remailer) Date: Tue Jun 15 22:07:41 PDT 1993 Subject: REMAIL: X-TTL and X-Discard Message-ID: <9306160508.AA23770@toad.com> -----BEGIN PGP SIGNED MESSAGE----- I don't see that X-TTL is very useful as currently proposed. As I see it, I would have to create something like this: ======================================= :: X-TTL: 5 Request-Remailing-To: remailer1 :: Request-Remailing-To: remailer2 :: Request-Remailing-To: remailer3 :: Request-Remailing-To: remailer4 :: Request-Remailing-To: remailer5 Dummy message to be sent. ======================================= (Or an equivalent structure could be set up with nested PGP encryptions.) This would go through remailers 1, 2, 3, 4, and 5, decrementing the X-TTL field each time, and after the last one when it was 0 the message would be deleted. The X-TTL is not very convenient in this case since you still have to come up with a path for sending your message which is at least as long as the X-TTL value. It seems to me that the X-Discard idea is simpler; you can just put the X-Discard in the command block for the last remailer, and you don't have to count them. What is needed to make X-TTL useful is for the remailer to choose another remailer as its destination, and ideally to encrypt the message before sending it. This way X-TTL can be used to insert a random remailer path of n hops in the middle of a sender-constructed remailing path. This leads to a system where the remailer decrypts an incoming message, reads the X-TTL value, decrements it, re-encrypts the message for the next remailer in the chain, and sends it. The X-TTL value is never exposed to outsiders. At one point I wrote a modification to my remailer to cause it to encrypt any message which it sent to another remailer which supported PGP. But I decided that this didn't really help security enough to be worthwhile. It would be much better to encourage users to encrypt their messages themselves in a nested fashion so that no remailer sees any more information than the bare minimum necessary. Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLB5mUKgTA69YIUw3AQHlRwQAmQ4t6ZcSNbieK4Y8ywj2t1vT1WR9amsY RB1H/cBGfIsVZOcpFb7K5OLrwhTh+aIO6b7sUzXVBsbsgNKLtv0yPjracDpPH5y1 EJ6U9k+74mXDpxl7vo4tqFUiEFd3s3I6by/TjmVAtKy8eX1+o83yo0BJgt9YgNSr psi8xbAFGUI= =4DtE -----END PGP SIGNATURE----- From fergp at sytex.com Tue Jun 15 20:39:20 1993 From: fergp at sytex.com (Paul Ferguson) Date: Tue, 15 Jun 93 23:39:20 EDT Subject: YAA (yet another article) Message-ID: <0BX85B2w165w@sytex.com> ComputerWorld June 14, 1993 Volume 27, Number 24 pages 73,74 Enterprise Networking Commentary All Eyes On Clipper by Gary H. Anthes If any conclusion can be drawn from the cacophony of conflicting views put forth at a recent public hearing on government-sponsored encryption technology, it is that the Clinton administration should slow down and take a closer look at Clipper. Clipper is the government's attempt to give law enforcers the ability to unscramble coded messages from suspected criminals while guaranteeing constitutional safeguards to legitimate users. To do that, a secret algorithm embedded in a chip will use encryption/decryption keys maintained "in escrow" by two government-approved agencies and subject to use in wiretaps only via court order. The first image brought to mind when presented with the key-escrow concept is that of a digital Big Brother, able to siphon off electronic secrets from anyone not in favor with the establishment. Stanford University Professor Martin E. Hellman says former Attorney General John Mitchell was in the habit of handing down blank but signed wiretap authorizations, 40 to 50 at a pop, rather than personally reviewing each request as required by law. "Two escrow authorities do little good if only one court order is required," Hellmman contends. The government has done little so far to put those fears to rest or to From jthomas at kolanut.mitre.org Wed Jun 16 06:08:13 1993 From: jthomas at kolanut.mitre.org (Joe Thomas) Date: Wed, 16 Jun 93 06:08:13 PDT Subject: REMAIL: X-TTL and X-Discard Message-ID: <9306161306.AA09342@kolanut> Hal wrote: > > What is needed to make X-TTL useful is for the remailer to choose another > remailer as its destination, and ideally to encrypt the message before > sending it. This way X-TTL can be used to insert a random remailer path of > n hops in the middle of a sender-constructed remailing path. This leads to > a system where the remailer decrypts an incoming message, reads the X-TTL > value, decrements it, re-encrypts the message for the next remailer in the > chain, and sends it. The X-TTL value is never exposed to outsiders. > > At one point I wrote a modification to my remailer to cause it to > encrypt any message which it sent to another remailer which supported > PGP. But I decided that this didn't really help security enough to > be worthwhile. It would be much better to encourage users to encrypt > their messages themselves in a nested fashion so that no remailer sees > any more information than the bare minimum necessary. Rolling your own encryption wrapper for the remailer chain you're sending through is a Good Thing, but your modification would be useful if you think of the cypherpunk remailer network as a "back end" for an anonymous/pseudonymous server like Julf's. Ideally, a pseudonym server will only keep an encrypted remailer chain for a user's return address (along with the unencrypted adress of the first remailer on the chain). The nymserver _doesn't_know_ what remailers are in the chain, so it can't encrypt the message with each of their public keys. But if the server can include a header line inside the encryption envelope that tells the remailer to encrypt with the next remailer's key, we can be sure that an adversary is still unable to match up incoming and outgoing messages. Setting up a pseudonym server with this kind of encrypted return address is good, of course, if you're worried about its database being seized. Without the cooperation of each remailer in the chain, the database doesn't give an adversary anything useful. And since now we've got TTL as another use for a next-step-encryption feature in the remailers... I'd better go get those remailer scripts and a UUCP feed for my new Linux box. Joe From mulivor at orion.crc.monroecc.edu Wed Jun 16 07:00:37 1993 From: mulivor at orion.crc.monroecc.edu (mulivor at orion.crc.monroecc.edu) Date: Wed, 16 Jun 93 07:00:37 PDT Subject: MACWORLD article Message-ID: <9306161400.AA10411@toad.com> In case this hasn't been mentioned here: There's a sizeable story in the July issue of MACWORLD magazine called "Privacy in Peril." It's a general roundup on electronic privacy. I didn't notice any reference to Clipper or digital currency. See pp. 118-130. Carry on, patriots. Phil From nobody at alumni.cco.caltech.edu Wed Jun 16 07:33:23 1993 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Wed, 16 Jun 93 07:33:23 PDT Subject: fast des Message-ID: <9306161432.AA00270@alumni.cco.caltech.edu> how fast is fast des these days? (i have measured over 2 mbps on decent workstations.) i was in a meeting today attended by someone from nsa who said that 2.4 gbps des chips exists today. (he got real silent after blurting this out. hmm.) 2.4 gbps is 37.5 million des per sec. it is probably not much challenge to put together a 65,536 element machine, which would run at 2.5 trillion des per sec. if i have my arithmetic right, this could exhaustively test the space of 56 bit keys in about eight hours. From smb at research.att.com Wed Jun 16 08:15:48 1993 From: smb at research.att.com (smb at research.att.com) Date: Wed, 16 Jun 93 08:15:48 PDT Subject: fast des Message-ID: <9306161515.AA12958@toad.com> how fast is fast des these days? (i have measured over 2 mbps on decent workstations.) i was in a meeting today attended by someone from nsa who said that 2.4 gbps des chips exists today. (he got real silent after blurting this out. hmm.) 2.4 gbps is 37.5 million des per sec. it is probably not much challenge to put together a 65,536 element machine, which would run at 2.5 trillion des per sec. if i have my arithmetic right, this could exhaustively test the space of 56 bit keys in about eight hours. I don't know of any 2.4 gbps DES chips, but DEC has built a 1 gbps chip. They've even published a technical report on it, though I don't have the number handy. But there's more to know than simply the raw speed. First of all, most real DES chips -- i.e., those designed for encryption, rather than brute-force cryptanalysis -- are optimized for encrypting large blocks of data. Key-loading is a different operation, and that might not go nearly as fast. Any hardware assists (i.e., DMA) would be for the data, not for the next key to use on the same block of data. Second, what does this chip cost? If it costs, say, 10x what the DEC chip costs, it's not cost-effective; you can build your DES-cracker more cheaply with the slower chips. (The DEC TR gave cost figures for DES-cracking...) From newsome at Panix.Com Wed Jun 16 08:44:55 1993 From: newsome at Panix.Com (Richard Newsome) Date: Wed, 16 Jun 93 08:44:55 PDT Subject: Digital cash Message-ID: <199306161544.AA14392@sun.Panix.Com> I have a friend who is working on developing a digital cash-like electronic payments system that would be connected to real financial institutions. He says that tthis system will essentially make the entire Internet a single ATM. I don't know any more about this as he is being very tight-lipped about this project. From 72550.1614 at CompuServe.COM Wed Jun 16 09:05:33 1993 From: 72550.1614 at CompuServe.COM (Craig Ellis) Date: Wed, 16 Jun 93 09:05:33 PDT Subject: unsubscribe Message-ID: <930616154636_72550.1614_FHG29-1@CompuServe.COM> Please take me off the cypherpunks mailing list. Thank you. From eichin at cygnus.com Wed Jun 16 09:06:59 1993 From: eichin at cygnus.com (Mark Eichin) Date: Wed, 16 Jun 93 09:06:59 PDT Subject: fast des In-Reply-To: <9306161432.AA00270@alumni.cco.caltech.edu> Message-ID: <9306161606.AA29187@cygnus.com> >> SUB: fast des >> how fast is fast des these days? (i have measured over 2 mbps >> on decent workstations.) On that note, what's the best available software implementation? The best one I've run across is the Ferguson code (both small and fast, uses some clever tables rather than big ones.) _Mark_ MIT Student Information Processing Board Cygnus Support From jazz at hal.com Wed Jun 16 09:18:58 1993 From: jazz at hal.com (Jason Zions) Date: Wed, 16 Jun 93 09:18:58 PDT Subject: YAA (yet another article) In-Reply-To: <1vm73lINN97i@hal.com> Message-ID: <9306161618.AA00319@jazz.hal.com> >ComputerWorld >June 14, 1993 >Volume 27, Number 24 >pages 73,74 > >However, a summary of some of those wiretaps, provided by the Federal >Bureau of Investigation, might cause even the most wary to warm up a >little closer to Clipper: > >* A wiretap led to the arrest and conviction of a "sexually deviant > serial murderer" who had operated in New Jersey and New Mexico. As an individual, who would he be talking to via Clipper? His victims? Not bloody likely. High-tech protection doesn't fall under the MO of this kind of killer. >* Another wiretap enabled authorities to thwart Chicago's "El Rukns > street gang" from a Libyan government-sponsored attempt to shoot > down a U.S. commercial airliner with a military weapons system. They find these all the time through other mechanisms. >* The entire leadership of the Mafia's Colombo family was convicted > with the help of wiretaps. Legalize drugs and prostitution and the Mafia will dry up and blow away. Besides, these guys have enough money to have purchased and used private scrambling gear anyway; the fact that they haven't (leading to their capture) leads one to believe they wouldn't use Clipper anyway. If the current leadership is smarter, they'll be smart enough to use non-Clipper gear anyway, eliminating the advantage Clipper gives to the Justice Dept. >Hellman has an ingenious idea that might appeal to those concerned >about civil liberties. He would require not one but three judges to >authorize a Clipper wiretap. A judge could answer the request with >"Yes," "No or "Oh, my God!" The latter means, "This looks like an >attempted abuse of power, as in Watergate." > >If a Clipper tap request got even one "Oh, my God!" decision, the >target of the wiretap would be notified. Because that is the last thing >the requestor would want, it would serve as a powerful check on >frivolous or improper requests. I gotta admit that I kinda like this. I should point out, though, that it ought to be applied regardless of the wiretapping technology applied; that is, this mechanism should be used today for all court-authorized wiretaps. From O1DSH at VM1.CC.UAKRON.EDU Wed Jun 16 09:54:21 1993 From: O1DSH at VM1.CC.UAKRON.EDU (David Heck) Date: Wed, 16 Jun 93 09:54:21 PDT Subject: unsubscribe Message-ID: <9306161654.AA16306@toad.com> Please remove me from the mailing list, I'm going to be gone for awhile, completely unplugged...ahhhhh...I'll catch up when I get back. Thanks, David From pmetzger at lehman.com Wed Jun 16 10:47:01 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 16 Jun 93 10:47:01 PDT Subject: YAA (yet another article) In-Reply-To: <9306161618.AA00319@jazz.hal.com> Message-ID: <9306161746.AA02809@snark.shearson.com> Jason Zions says: > >* A wiretap led to the arrest and conviction of a "sexually deviant > > serial murderer" who had operated in New Jersey and New Mexico. > > As an individual, who would he be talking to via Clipper? His victims? Not > bloody likely. High-tech protection doesn't fall under the MO of this kind > of killer. Look, lets get real here. Wiretaps ARE an effective mechanism for law enforcement -- no question about it. The issue is not the effectiveness of wiretaps. Its the overall effect on society. Torture, believe it or not, is a very effective way of police to get information. Our society bans it. Every mechanism that is useful is not acceptable. Stopping crypto to allow wiretaps forces every person in society to give up their privacy, which probably costs billions of dollars and thousands of lives, for the sake of only a small amount of money and lives saved. Outlawing strong privacy might stop some mafiosi -- but it will allow others to rake in billions via wirefraud and dozens of other mechanisms. It also likely won't stop the mafiosi and terrorists since they will get strong cryptosystems anyway for virtually no cost. What do they care that they are breaking the law? Perry From pmetzger at lehman.com Wed Jun 16 10:51:50 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 16 Jun 93 10:51:50 PDT Subject: on the radio In-Reply-To: <93Jun15.193753pdt.13987-4@well.sf.ca.us> Message-ID: <9306161750.AA02825@snark.shearson.com> Steven Levy says: > > > >Steven Levy was interviewed on FM91.7 (san francisco public radio, I > >forget the call letters) this morning. My patch cable isnt working for > >some reason, or I would have caught it in a ulaw file. > > >I don't know the name of the show, or if they will rebroadcast it, but > >if you're interested, you might try to track it down. > > I think the name of the show was TechAmerica, or something > like that, a show syndicated on public radio. Technation. > I did the interview > about a month ago, me in Amherst, a fairly sharp interviewer in > San Francisco. I believe that this is already on line via Internet Talk Radio. Perry From phiber at eff.org Wed Jun 16 11:10:40 1993 From: phiber at eff.org (Phiber Optik) Date: Wed, 16 Jun 93 11:10:40 PDT Subject: WORD... Message-ID: <199306161811.AA20516@eff.org> I was just curious... I saw the WordPerfect crack files on soda, and I'm interesting in knowing if anyone knows where I can find a utility that can crack Microsoft WORD encryption. If you don't have an actual utility, but you know how they encrypt, that's fine too. Thanks. From tcmay at netcom.com Wed Jun 16 11:42:27 1993 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 16 Jun 93 11:42:27 PDT Subject: WORD... Message-ID: <9306161842.AA07762@netcom.netcom.com> Phiber Optik writes: >I was just curious... I saw the WordPerfect crack files on soda, and I'm With the hypodermic syringes being found in Pepsi cans, the "crack files on soda" phrase takes on new meaning. I wonder if the media knows? -Tim May From nobody at pmantis.berkeley.edu Wed Jun 16 11:45:06 1993 From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu) Date: Wed, 16 Jun 93 11:45:06 PDT Subject: YAA (yet another article) Message-ID: <9306161846.AA15062@pmantis.berkeley.edu> Really from: dmandl at lehman.com > From: "Perry E. Metzger" > > Torture, believe it or not, is a very effective way of police to get > information. Our society bans it. But keep in mind that it's still used often enough, just not usually against anyone with the power or credibility to speak out about it. Don't you remember the Queens police precinct that got involved in that stun-gun scandal a few years ago? --Dave (trying to give some extra business to the anonymous remailers). From sneal at muskwa.ucs.ualberta.ca Wed Jun 16 11:49:58 1993 From: sneal at muskwa.ucs.ualberta.ca (Sneal) Date: Wed, 16 Jun 93 11:49:58 PDT Subject: Patent libraries Message-ID: <9306161849.AA16059@muskwa.ucs.ualberta.ca> Re west coast patent libraries: The two that I've personally used are the Sunnyvale patent library (which Tim May mentioned in an earlier post) and the one at University of Washington in Seattle. The Sunnyvale library is the more complete, with all patents (microfilm for older ones, paper for newer) and gazettes availble. UW only goes back to the mid-sixties or so, but I suspect this will cover all crypto patents. Eric asks: >Do they have electronic access at this library, or is it >paper only? I know they have a fax service for which they charge, >but is there downloadable text available? Both libraries mentioned above have CD-ROM facilities which you can browse onsite. To the best of my recollection, though, the CDs only include abstracts and licensing information, and not the full text of the patents. I'll likely be back in the Sunnyvale area sometime in the next couple of months, but in the meantime, someone might want to verify my recollections about the CD-ROM info. The CD-ROM reader at the Sunnyvale library seems to be heavily utilized, so you might want to call ahead and book some time on it. If you want to check out the UW library and you're not familiar with the area, stop at the UW Visitor's Centre first, or risk getting lost in a strange and bizarre environment. Canadians looking for patent info... don't bother, unless you're in the Ottawa/Hull area, are near a university that has the stuff on CD, or have sufficient connections to get the stuff through CTIS at a reasonable price. Our government (now headed by the flakiest female PC politician this side of Hilary Clinton ) seems to have granted exclusive rights to patent distribution to some bogus little microfiche company in Hull (MicroMedia) that wants some ungodly per-page charge for copying. -- Steve From anton at hydra.unm.edu Wed Jun 16 12:31:21 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Wed, 16 Jun 93 12:31:21 PDT Subject: Bidzos responds to "sellout" cry! Message-ID: <9306161931.AA06662@hydra.unm.edu> I expressed my displeasure over PKP/RSA's apparent support for Clipper/ Capstone/Key Escrow to RSA's head, Jim Bidzos. Here's his reply. Quoth Jim Bidzos, verily I saith unto thee: > From jim at RSA.COM Wed Jun 16 13:03:04 1993 > id ; Wed, 16 Jun 1993 13:03:01 -0600 > Date: Wed, 16 Jun 93 12:01:09 PDT > From: jim at RSA.COM (Jim Bidzos) > Message-Id: <9306161901.AA16476 at RSA.COM> > To: anton at hydra.unm.edu > In-Reply-To: Stanton McCandlish's message of Sun, 13 Jun 1993 23:01:03 -0600 (MDT) <9306140501.AA13212 at hydra.unm.edu> > Subject: hmph > > > RSA/PKP supporting Clipper? Where did you hear that? (It's untrue.) > For a year and a half, we have been claiming that DSS is covered by > patents we hold. NIST has finally stopped fighting, and asked for > licensing terms. We provided them. Hardly "support for Clipper." > > --Jim > > -- Stanton McCandlish * Space Migration * Networking * ChaOrder * NO GOV'T. * anton at hydra.unm.edu * Intelligence Increase * Nano * Crypto * NO RELIGION * FidoNet: 1:301/2 * Life Extension * Ethics * VR * Now! * NO MORE LIES! * Noise in the Void BBS * +1-505-246-8515 (24hr, 1200-14400, v32bis, N-8-1) * From nobody at rosebud.ee.uh.edu Wed Jun 16 12:56:32 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Wed, 16 Jun 93 12:56:32 PDT Subject: Digital Cash Message-ID: <9306161956.AA22233@toad.com> -----BEGIN PGP SIGNED MESSAGE----- Responding to Mike Diehl's comments about digital cash: It is not really the right question to ask what digital cash "is". It is better to ask how it might work, what it could be. Digital cash is basically just a cryptographic technology that provides tokens, messages, bit patterns, etc. which are (A) unforgeable, (B) verifiable (by the institution that issues them, at least), and (C) untraceable. What you do with this technology is then limited only by your imagination. Eric Hughes has pointed out that you can use it for things having nothing to do with cash. Use it to represent fuel in a space game and this way people can transfer fuel but can't create more. Use it for anything for which you want the quantity to be conserved. If we want to use it as a substitute for cash, though, Mike asks what gives it value. There are many possible answers. One is, as Duncan suggested, to allow digital cash to be exchanged for regular cash. But this is not the only possibility. Eric pointed out that it could be used as a "play money" in a game, such as a Multi User Dungeon (MUD), allowing cash to be transfered between games. Another possibility would be for a company to issue "digital coupons" good for discounts off of its software products when you order them by email. This would give the coupons value and they could be used as the cash in a barter network, perhaps. Conceivable, a government might issue digital cash in parallel with its paper cash. It would then give it backing in the same way that the paper cash is backed; among other things, you can pay your taxes in digital cash. This is probably not too likely among the big countries but there are many countries in the world. In some areas of rural England, "scrip" is used by barter networks to help stimulate the local economies. A twenty-first century equivalent could use digital cash. Mike also asks what would prevent the digital cash "bank" from just absconding with the money, assuming that the digital cash was backed by regular cash. The answer is presumably the same things that stop a regular bank from doing this. If the cash is legal in the country of issue, laws will allow prosecution of bankers who steal. In the more anarchic world of international finance, people already face the problem of safeguarding their overseas investments. I know of a non-profit organization that lost several hundred thousand dollars in an overseas investment a few years ago (money it could hardly afford to lose) due to fraud. There are no certainties, but you can take some care. Invest only a small amount at first, then gradually increase your investment as you gain confidence. Choose a bank which has been in business for many years. Look at the reputations of the people behind the bank - have they had previous positions of responsibility and trust? These are all the kinds of things which you should do anyway, and they should work just as well for a digital cash bank as for any other case where you have to trust someone with your money. Mike asks what the benefits and purpose would be for digital cash. I see the main benefit as allowing electronic transactions with greater protection for consumer privacy. Presently when you make an electronic transaction (purchasing something from a catalog over the telephone, for example, or buying gas with your ATM card), you as the consumer have to trust a lot of people. The catalog company gets your credit card number, and you have to trust that none of the people who see it will use it illicitly, or sell the number to criminals. The credit card company itself gets a full record of the transaction, and you have to trust that they will treat this information as confidential, not sell your name to a mailing list of people who like to purchase certain kinds of items, and safeguard it so that computer criminals and snoopy investigators can't violate your privacy. Similarly, with the ATM transaction, you are trusting the bank, the point-of-sale vendor, and many other people to keep your Personal Identification Number (PIN) secret, and also to safeguard the records of your transaction. With digital cash and a smartcard, you should be able to engage in these kinds of transactions with no organization or institution able to violate your privacy or steal your money. You can protect yourself, rather than having to trust others. This puts more power into the hands of the consumer. Granted, in today's political climate, empowering individuals is perhaps not as persuasive an argument as we might wish. But I am optimistic that as people begin to learn that there is an alternative to trusting VISA (through such means as Chaum's article in Scientific American, for example) and as the inevitable horror stories continue to spread about ATM fraud, credit card fraud, and invaded privacy, political support for this proposal will grow. I do think that in an increasingly networked world people are going to be more jealous about guarding the privacy they have left. In this sense, digital cash may be the wave of the future. Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLB8c1qgTA69YIUw3AQHdJwP9EUJ+KqQzg4/1i46ojlSqKyZtyCL0CELB kvol3Ipupae5d1NKg87sZHwNZMo/7FQQxQ2B89qNUPaJlx4Au3HdTjsSj85JwvQ7 aC7pGttnG9fdE957FAoXvwR1szDs3D6NDYttBqp6IUsmfdNaId31NiR2QEgj1Rj/ nAYPWrgbGCE= =+9VM -----END PGP SIGNATURE----- From marc at GZA.COM Wed Jun 16 13:07:51 1993 From: marc at GZA.COM (Marc Horowitz) Date: Wed, 16 Jun 93 13:07:51 PDT Subject: Bidzos responds to "sellout" cry! In-Reply-To: <9306161931.AA06662@hydra.unm.edu> Message-ID: <9306162007.AA02747@dun-dun-noodles.aktis.com> > RSA/PKP supporting Clipper? Where did you hear that? (It's untrue.) Quote this paragraph: PKP will also grant a license to practice key management, at no additional fee, for the integrated circuits which will implement both the DSA and the anticipated Federal Information Processing Standard for the "key escrow" system announced by President Clinton on April 16, 1993. I'm not going to respond directly to him, since I don't know if you want him to know you reforwarded his mail. However, I would make the argument that if RSA really didn't want the clipper chip, they would license it to NIST in such a way that "all implementations based on our patents will be made available in software source form for non-commercial use". I'm sure legal language can be constructed which would prohibit hardware-only implementations. I couldn't write it though. Marc From 0005533039 at mcimail.com Wed Jun 16 13:13:36 1993 From: 0005533039 at mcimail.com (Giuseppe Cimmino) Date: Wed, 16 Jun 93 13:13:36 PDT Subject: YAA (yet another article) Message-ID: <95930616191659/0005533039ND2EM@mcimail.com> PC Week - June 14, 1993 "Clipper security scheme criticized" By Kimberly Patch A proposed National Security Agency standard for voice and data encryption is not winning votes among U.S. executives concerned with security issues. Executives attending hearings held by the federal Computer Systems Security and Privacy Advisory Board earlier this month said the proposed Clipper chip encryption standard does not meet their technical or export needs. Under the Clipper guidelines, PCs would be outfitted with a board that contains the encryption chip, while the U.S. government would be privy to a pair of software "escrow keys" used to unlock the encryption. Although the Clipper chip uses an 80-bit encryption scheme, executives said it would be more expensive and slower than more popular software encryption schemes. Moreover, some expressed concern about its security since NSA is keeping the details of how it works secret. "Why would any law-abiding corporation buy equipment that has escrow keys that [allow] the government to [decrypt information] whenever they want without telling the corporation?" asked Ed Zeitler, a vice president at Fidelity Investments, a financial-services firm in Boston. An NSA spokeswoman in Fort Meade, MD., defended the scheme, claiming the keys would be protected and law-enforcement agencies would have to go through a formal legal process to decrypt messages. "People will only have access if they have a legal need for it," she said. Corporate users, however, objected. "[The government] wants [the Clipper standard] to be widely used so that law-enforcement people can listen in on things that are used by criminals," said Steven Walker, president of Trusted Information Systems, Inc., a Boston software company. "The criminals will find some other way to do it, which is the irony of this. It's not going to accomplish what [that government] wants, no matter what." One problem with today's encryption business is that U.S. firms are restrained from exporting software that offers powerful encryption capabilities, the executives said. Currently, U.S. firms can only export products that use a 40-bit key, which would take a fast computer about two and a half weeks to crack, said Zeitler. By contrast, the Data Encryption Standard -- a 56-bit key scheme not approved for export -- would take the same computer 2,200 years to crack, while the proposed Clipper chip, an 80-bit scheme, would take even longer. From newsham at wiliki.eng.hawaii.edu Wed Jun 16 14:01:38 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Wed, 16 Jun 93 14:01:38 PDT Subject: Link protocol Message-ID: <9306162101.AA24381@toad.com> I just uploaded ami-link1.0lha ami-link1.0-src.lha link1.0.tar.Z link.readme to the soda.berkeley.edu cypherpunks/incoming directory. link.readme says: ---------------------- Link1.0 -------- Link is a protocol designed to provide a secure link over a serial channel. At this time there are ends only for Amiga and Unix. The protocol grabs input bytes, encrypts them with DES and frames them in packets for transfer over a serial channel. The protocol also allows transfers of random DES keys over the channel encrypted with the RSA algorithm. Key exchange happens automatically at startup (in the future there will be options to change keys mid-session). The client end written for Amiga is a vt100 terminal emulator. The server end written for Unix opens a pty and executes a shell. link1.0.tar.Z : This file contains the protocol engine and server to be run on the Unix end. Also contains docs on the protocol engine. Tested on HPUX and SunOS (compiled and tested minimally on an Ultrix at one point in time) ami-link1.0.lha : This file contains the protocol engine and client to be run on the Amiga end. Contains minimal docs pertaining to setup. ami-link1.0-src.lha : Contains the source for the amiga end. From mrrm at well.sf.ca.us Wed Jun 16 14:28:52 1993 From: mrrm at well.sf.ca.us (Marianne Mueller) Date: Wed, 16 Jun 93 14:28:52 PDT Subject: Draft Solaris Teleservices API doc, anon ftp Message-ID: <93Jun16.142816pdt.13877-2@well.sf.ca.us> FYI From: stoltz at denwa.Eng.Sun.COM (Ben Stoltz) Newsgroups: comp.dcom.isdn,sun.tstech,sun.audio,sun.sw.arch,sun.telco Subject: Draft Solaris Teleservices API document is available for anonymous ftp Date: 11 Jun 1993 18:10:29 GMT A PostScript version of the Solaris Teleservices 1.0 API Programming Guide is available for anonymous ftp from sunsite.unc.edu in the directory /pub/sun-info/white-papers/API_xtel.tar.Z If you have any comments or suggestions, please send email to xtel-api-comments at denwa.Eng.Sun.COM. Marketing inquiries should be directed to bob.mckee at Eng.Sun.COM (415)336-4840. The IAFA info follows: Document-Name: API_xtel Title: Solaris Teleservices 1.0 API Programming Guide Authors: Jonathan Chang UMTV18-217, Sun Microsystems, Inc., 2550 Garcia Ave. Mountain View, CA 94043-1100 Revision-Date: June 7, 1993 Category: Programming Guide Abstract: This manual is for C++ programmers who are developing Solaris Teleservices (XTEL) applications. A good understanding of the UNIX(tm) operating system and the C++ programming language are required. Example programs are provided that illustrate the concepts in the text. The manual explains how to use XTEL to write applications that: o Place or answer multiple calls o Hold, drop, conference and transfer calls o Provide access to data channels o Enable security and sharing of calls between processes. Format: PostScript Citation: Solaris Teleservices 1.0 API Programming Guide, Draft June 7 1993, SunSoft, Inc. Publication-Status: draft Keywords: Teleservices, Telephony, ISDN, POTS, voice, API, C++ Size: 90 pages From tk at reagan.ai.mit.edu Wed Jun 16 15:00:07 1993 From: tk at reagan.ai.mit.edu (Tom Knight) Date: Wed, 16 Jun 93 15:00:07 PDT Subject: fast des In-Reply-To: <9306161515.AA12958@toad.com> Message-ID: <19930616211451.5.TK@ROCKY.AI.MIT.EDU> Date: Wed, 16 Jun 1993 11:09 EDT From: smb at research.att.com .... 2.4 gbps is 37.5 million des per sec. .... arithmetic right, this could exhaustively test the space of 56 bit keys in about eight hours. I don't know of any 2.4 gbps DES chips, but DEC has built a 1 gbps chip. .... Key-loading is a different operation, and that might not go nearly as fast. Any hardware assists (i.e., DMA) would be for the data, not for the next key to use on the same block of data. Usually the limiting factor is examining the decrypted data for statistically significant patterns indicating that you have the correct key. The fast DES chips don't help with this at all. A known plaintext attack, of course, doesn't have this problem, but these are probably of limited interest in real applications. From hibbert at memex.com Wed Jun 16 15:36:31 1993 From: hibbert at memex.com (Chris Hibbert) Date: Wed, 16 Jun 93 15:36:31 PDT Subject: FOIA Kit [long] Message-ID: <9306162148.AA24767@memexis.memex.com> A few weeks people were talking here about filing FOIA and Privacy Act requests to find out what info the gov't has on them. Here's a kit on how to file FOIA requsts. It's a relatively standard kit that the Fund for Open Information and Accountability has been making available for years. This version was posted to alt.privacy by Paul Ferguson. He had this advice in addition to what's in the kit: "FOIA requests submitted to either the FBI or CIA concerning an individual (including self) must be notarized to ensure identity." here 'tis: FOIA FILES KIT - INSTRUCTIONS USING THE FREEDOM OF INFORMATION ACT REVISED EDITION Fund for Open Information and Accountability, Inc. 339 Lafayette Street, New York, NY 10012 (212) 477-3188 INSTRUCTIONS The Freedom of Information Act entitles you to request any record maintained by a federal Executive branch agency. The agency must release the requested material unless it falls into one of nine exempt categories, such as "national security," "privacy," "confidential source" and the like, in which case the agency may but is not compelled to refuse to disclose the records. This kit contains all the material needed to make FOIA requests for records on an individual, an organization or on a particular subject matter or event. HOW TO MAKE A COMPLETE REQUEST Step 1: Select the appropriate sample letter. Fill in the blanks in the body of the letter. Read the directions printed to the right of each letter in conjunction with the following instructions: For organizational files: In the first blank space insert the full and formal name of the organization whose files you are requesting. In the second blank space insert any other names, acronyms or shortened forms by which the organization is or has ever been known or referred to by itself or others. If some of the organization's work is conducted by sub-groups such as clubs, committees, special programs or through coalitions known by other names, these should be listed. For individual files: Insert the person's full name in the first blank space and any variations in spelling, nicknames, stage names, marriage names, titles and the like in the second blank space. Unlike other requests, the signatures of an individual requesting her/his own file must be notarized. For subject matter or event files: In the first blank space state the formal title of the subject matter or event including relevant dates and locations. In the second blank space provide the names of individuals or group sponsors or participants and/or any other information that would assist the agency in locating the material you are requesting. Step 2: The completed sample letter may be removed, photocopies and mailed as is or retyped on your own stationary. Be sure to keep a copy of each letter. Step 3: Addressing the letters: Consult list of agency addresses. FBI: A complete request requires a minimum of two letters. Sen done letter to FBI Headquarters and separate letter to each FBI field office nearest the location of the individual, the organization or the subject matter/event. Consider the location of residences, schools, work and other activities. INS: Send a request letter to each district office nearest the location of the individual, the organization or the subject matter/event. Address each letter to the FOIA/PA office of the appropriate agency. Be sure to make clearly on the envelope: ATTENTION--FOIA REQUEST. FEE WAIVER You will notice that the sample letters include a request for fee waiver. Many agencies automatically waive fees if a request results in the release of only a small number of documents, e.g. 250 pages or less. Under the Act, you are entitled to a waiver of all search and copy fees associated with your request if the release of the information would primarily benefit the general public. However, in January 1983, the Justice Department issued a memo to all federal agencies listing five criteria which requesters must meet before they are deemed entitled to a fee waiver. Under these criteria, a requester must show that the material sought to be released is already the subject of "genuine public interest" and "meaningfully contributes to the public development or understanding of the subject"; and that she/he has the qualifications to understand and evaluate the materials and the ability to interpret and disseminate the information to th public and is not motivated by any "personal interest." Finally, if the requested information is already "in the public domain," such as in the agency's reading room, no fee waiver will be granted. You should always request a waiver of fees if you believe the information you are seeking will benefit the public. If your request for a waiver is denied, you should appeal that denial, citing the ways in which your request meets the standards set out above. MONITORING THE PROGRESS OF YOUR REQUEST Customarily, you will receive a letter from each agency within 10 days stating that your request has been received and is being processed. You may be asked to be patient and told that requests are handled cafeteria style. You have no alternative but to be somewhat patient. but there is no reason to be complacent and simply sit and wait. A good strategy is to telephone the FOIA office in each agency after about a month if nothing of substance has been received. Ask for a progress report. The name of the person you talk with and the gist of the conversation should be recorded. try to take notes during the conversation focusing especially on what is said by the agency official. Write down all the details you can recall after the call is completed. Continue to call every 4 to 6 weeks. Good record keeping helps avoid time-consuming and frustrating confusion. A looseleaf notebook with a section devoted to each request simplifies this task. Intervening correspondence to and from the agency can be inserted between the notes on phone calls so that all relevant material will be at hand for the various tasks: phone consultations, writing the newsletter, correspondence, articles, preparation for media appearances, congressional testimony or litigation, if that course is adopted. HOW TO MAKE SURE YOU GET EVERYTHING YOU ARE ENTITLED TO ... AND WHAT TO DO IF YOU DO NOT After each agency has searched and processed your request, you will receive a letter that announces the outcome, encloses the released documents, if any, and explains where to direct an appeal if any material has been withheld. There are four possible outcomes: 1. Request granted in full: This response indicates that the agency has released all records pertinent to your request, with no exclusions or withholdings. The documents may be enclosed or, if bulky, may be mailed under separate cover. This is a very rare outcome. Next Step: Check documents for completeness (see instructions below). 2. Requested granted in part and denied in part: This response indicates that the agency is releasing some material but has withheld some documents entirely or excised some passages from the documents released. The released documents may be enclosed or, if bulky, mailed under separate cover. Next step: Check documents released for completeness (see instructions below) and make an administrative appeal of denials or incompleteness (see instructions below). 3. Request denied in full: This response indicates that the agency is asserting that all material in its files pertaining to your request falls under one or the nine FOIA exemptions. These are categories of information that the agency may, at its discretion, refuse to release. Next step: Make an administrative appeal (see instructions below). Since FOIA exemptions are not mandatory, even a complete denial of your request can and should be appeals. 4. No records: This response will state that a search of the agency's files indicates that it has no records corresponding to those you requested. Next step: Check your original request to be sure you have not overlooked anything. If you receive documents from other agencies, review them for indications that there is material in the files of the agency claiming it has none. For example, look for correspondence, or references to correspondence, to or from that agency. If you determine that there are reasonable grounds, file an administrative appeal (see instructions below). HOW TO CHECK FOR COMPLETENESS Step 1: Before reading the documents, turn them over and number the back of each page sequentially. The packet may contain documents from the agency's headquarters as well as several field office files. Separate the documents into their respective office packets. Each of these offices will have assigned the investigation a separate file number. Try to find the numbering system. Usually the lower right hand corner of the first page carries a hand-written file and document number. For instance, an FBI document might be marked "100-7142-22". This would indicate that it is the 22nd document in the 7142nd file in the 100 classification. As you inspect the documents, make a list of these file numbers and which office they represent. In this way you will be able to determine which office created and which office received the document you have in your hand. Often there is a block stamp affixed with the name of the office from whose files this copy was retrieved. the "To/From" heading on a document may also give you corresponding file numbers and will help you puzzle out the origin of the document. When you have finally identified each document's file and serial number and separated the documents into their proper office batches, make a list of all the serial numbers in each batch to see if there any any missing numbers. If there are missing serial numbers and some documents have been withheld, try to determine if the missing numbers might reasonably correspond to the withheld documents. If not, the release may be incomplete and an administrative appeal should be made. Step 2: Read all the document released to you. Keep a list of all document referred to the text--letters, memos, teletypes, reports, etc. Each of these "referred to" documents should turn up in the packet released to you. If any are not in the packet, it is possible they may be among those document withheld; a direct inquiry should be made. In an administrative appeal, ask that each of these "referred to" documents be produced or that the agency state plainly that they are among those withheld. Of course, the totals of unproduced vs. withheld must be within reasons; that is, if the total number of unproduced documents you find referred to the text of the documents produced exceeds the total number of documents withheld, the agency cannot claim that all the referred to documents are accounted for by the withheld category. You will soon get the hand of making logical conclusions from discrepancies in the totals and missing document numbers. Another thing to look for when reading the released documents if the names of persons or agencies to whom the document has been disseminated. the lower left-hand corner is a common location for the typed list of agencies or offices to whom the document has been directed. In addition, there may be additional distribution recorded by hand, there or elsewhere on the cover page. There are published glossaries for some agencies that will help in deciphering these notations when they are not clear. Contact FOIA, Inc., if you need assistance in deciphering the text. Finally, any other file numbers that appear on the document should be noted, particularly in the subject of the file is of interest and is one you have not requested. You may want to make an additional request for some of these files. HOW TO MAKE AN ADMINISTRATIVE APPEAL Under the FOIA, a dissatisfied requester has the right of administrative appeal. the name and address of the proper appeal office will be given to you by each agency in its final response letter. This kit contains a sample appeal letter with suggesting for adapting it to various circumstances. However, you need not make such an elaborate appeal; in fact, you need not offer any reasons at all but rather simply write a letter to the appeals unit stating that "this letter constitutes an appeal of the agency's decision." Of course, if you have identified some real discrepancies, you will want to set them for fully, but even if you have not found any, you may simply ask that the release be reviewed. If you are still dissatisfied after the administrative appeal process, the FOIA gives you the right to bring a lawsuit in federal district court on an expedited basis. SAMPLE FBI REQUEST LETTER Date: To: FOIA/PA Unit Federal Bureau of Investigation This is a request under the Freedom of Information Act. I request a complete and thorough search of all filing systems and locations for all records maintained by your agency pertaining to and/or captioned: ______ _____________________________________________________ [describe records desired and/or insert full and _____________________________________________________ formal name] _____________________________________________________ _____________________________________________________ including, without limitations, files and documents captioned, or whose captions include _____________________________________________________ [insert changes in name, commonly used names, _____________________________________________________ acronyms, sub-groups, and the like] _____________________________________________________ _____________________________________________________ This request specifically includes "main" files and "see references," including, but not limited to numbered and lettered sub files, "DO NOT FILE" files, and control files. I also request a search of the ELSUR Index,a nd the COINTELPRO Index. I request that all records be produced with the administrative pages. I wish to be sent copies of "see reference" cards, abstracts, search slips, including search slips used to process this request, file covers, multiple copies of the same documents if they appear in a file, and tapes of any electronic surveillances. I wish to make it clear that I want all records in you office "identifiable with my request," even though reports on those records have been sent to Headquarters and even though there may be duplication between the two sets of files. I do not want just "interim" documents. I want all documents as they appear in the "main" files and "see references" of all units of your agency. If documents are denied in whole or in part, please specify which exemption(s) is(are) claimed for each passage or whole document denied. Please provide a complete itemized inventory and a detailed factual justification of total or partial denial of documents. Give the number of pages in each document and the total number of pages pertaining to this request. For "classified" material denied please include the following information: the classification (confidential, secret or top secret); identity of the classifier; date or event for automatic de-classification, classification review, or down-grading; if applicable, identity of official authorizing extension of automatic de-classification or review; and if applicable, the reason for extended classification. I request that excised material be "blacked out" rather than "whited out" or cut out and that the remaining non-exempt portions of documents will be released as provided under the Freedom of Information Act. Please send a memo (copy to me) to the appropriate units in your office to assure that no records related to this request are destroyed. Please advise of any destruction of records and include the date of and authority for such destruction. As I expect to appeal any denials, please specify the office and address to which an appeal should be directed. I believe my request qualifies for a waiver of fees since the release of the requested information would primarily benefit the general public and be "in the public interest." I can be reached at the phone listed below. Please call rather than write if there are any questions or if you need additional information from me. I expect a response to this request within ten (10) working days, as provided for in the Freedom of Information Act. Sincerely, name: _______________________________________________ address: ____________________________________________ ____________________________________________ telephone: __________________________________________ signature: __________________________________________ SAMPLE AGENCY REQUEST LETTER DATE: TO: FOIA/PA Unit This is a request under the Freedom of Information Act. I request a complete and thorough search of all filing systems and locations for all records maintained by your agency pertaining to and/or captioned ______________________________________________________ [describe records desired and/or insert full and ______________________________________________________ formal name] ______________________________________________________ ______________________________________________________ including, without limitation, files and documents captioned, or whose captions include: ______________________________________________________ [insert changes in name, commonly used names, ______________________________________________________ acronyms, sub-groups and the like] ______________________________________________________ ______________________________________________________ I also request all "see references" to these names, a search of the ELSUR Index or any similar technique for locating records of electronic surveillance. This request is also a request for any corresponding files in INS Headquarters or regional offices. Please place any "missing" files pertaining to this request on "special locate" and advise that you have done this. If documents are denied in part or whole, please specify which exemption(s) is(are) claimed for each passage or whole document denied. Please provide a complete itemized inventory and detailed factual justification of total or partial denial of documents. Specify the number of pates in each document and th total number of pages pertaining to this request. For classified material denied, please include the following information: the classification rating (confidential, secret, or top secret); identify the classifier; date or event for automatic de-classification, classification review or downgrading; if applicable, identify the official authorizing extension of automatic de-classification or review; and, if applicable, give the reason for extended classification. I request that excised material be "blacked out" rather than "whited out" or cut out. I expect, as provided by the Freedom of Information Act, that the remaining non-exempt portions of documents will be released. Please send a memo (copy to me) to the appropriate units in your office or agency to assure that no records related to this request are destroyed. Please advise of any destruction of records and include the date of and authority for such destruction. As I expect to appeal any denials, please specify the office and address to which an appeal should be directed. I believe my request qualifies for a waiver of fees since the release of the requested information would primarily benefit the general public and be "in the public interest." I can be reached at the phone listed below. Please call rather than write if there are any questions or if you need additional information from me. I expect a response to this request within ten (10) working days, as provided for in the Freedom of Information Act. Sincerely, name: _______________________________________________ address: ____________________________________________ ____________________________________________ telephone: (___)_______________________________________ signature: __________________________________________ SAMPLE ADMINISTRATIVE APPEAL LETTER Date: To: FOIA/PA Appeals Office RE: Request number [Add this if the agency has given your request a number] This is an appeal pursuant to subsection (a)(6) of the Freedom of Information Act as amended (5U.S.C. 552). On [date], I received a letter from [name of official] of your agency denying my request for [describe briefly the information you are after]. This reply indicated that an appeal letter could be sent to you. I am enclosing a copy of my exchange of correspondence with your agency so that you can see exactly what files I have requested and the insubstantial grounds on which my request has been denied. [Optional paragraph, to be used if the agency has withheld all or nearly all the material which has been requested]: You will note that your agency has withheld the entire (or nearly the entire) document (or file, or report, or whatever) that I requested. Since the FOIA provides that "any reasonably secregable portion of a record shall be provided to any person requesting such record after deletion of the portions which are exempt," I believe that your agency has not complied with the FOIA. I believe that there must be (additional) secregable portions which do not fall within FOIA exemptions and which must be released. [Optional paragraph, to be used in the agency has used the (b)(1) exemption for national security, to withhold information] Your agency has used the (b)(1) exemption to withhold information [I question whether files relating to events that took place over twenty years ago could realistically harm the national security.] [Because I am familiar with my own activities during the period in question, and know that none of these activities in any way posed a significant threat to the national security, I question the designation of my files or portions of my file as classified and exempt from disclosure because of national security considerations.] [Sample optional argument to be used if the exemption which is claimed does not seem to make sense; you should cite as many specific instances as you care to of items withheld from the documents that you have received. We provide two examples which you might want to adapt to your own case.] "On the memo dated _____________ the second paragraph withheld under the (b)(1) exemption appears to be describing a conversation at an open meeting. If this is the case, it is impossible that the substance of this conversation could be properly classified." Or, "The memo dated _____ refers to a meeting which I attended, but a substantial portion is deleted because of the (b)(6) and (b)(7)(c) exemptions for unwarranted invasions of personal privacy. Since I already know who attended this meeting, no privacy interest is served by the withholding." I trust that upon examination of my request, you will conclude that the records I requested are not properly covered by exemption(s) [here repeat the exemptions which the agency's denial letter claimed applied to your request] of the amended FOIA, and that you will overrule the decision to withhold the information. [Use if an itemized inventory is not supplied originally] If you choose instead to continue to withhold some or all of the material which was denied in my initial request to your agency, I ask that you give me an index of such material, together with the justification for the denial of each item which is still withheld. As provided in the Act, I will expect to receive a reply to this administrative appeal letter within twenty working days. If you deny this appeal and do not adequately explain why the material withheld is properly exempt, I intend to initial a lawsuit to compel its disclosure. [You can say that you intend to sue, if that is your present inclination; you may still decide ultimately not to file suit.] Sincerely yours, name: ____________________________________________ address: ____________________________________________ ____________________________________________ signature: ___________________________________________ [Mark clearly on envelope: Attention: Freedom of Information Appeals] FBI ADDRESSES AND PHONE NUMBERS FBI Headquarters, J. Edgar Hoover Bldg, Washington, D.C., 20535, 202-324-5520 (FOI/PA Unit) Field Offices Albany, NY 12207, U.S. Post Office and Courthouse, 518-465-7551 Albuquerque, NM 87101, Federal Office Bldg., 505-247-1555 Alexandria, VA 22314, 300 N. Lee St., 703-683-2681 Anchorage, AK 99510, Federal bldg., 907-272-6414 Atlanta, GA 30303, 275 Peachtree St. NE, 404-521-3900 Baltimore, MD 21207, 7142 Ambassador Rd., 301-265-8080 Birmingham, AL 35203, Room 1400, 2121 Bldg. 205-252-7705 Boston, MA 02203, J.F. Kennedy Federal Office Bldg., 617-742-5533 Buffalo, NY 14202, 111 W. Huron St., 716-856-7800 Butte, MT 59701, U.S. Courthouse and Federal Bldg., 406-792-2304 Charlotte, NC 28202, Jefferson Standard Life Bldg., 704-372-5485 Chicago, IL 60604, Everett McKinley Dirksen Bldg., 312-431-1333 Cincinnati, OH 45202, 400 U.S. Post Office & Crthse Bldg., 513-421-4310 Cleveland, OH 44199, Federal Office Bldg., 216-522-1401 Columbia, SC 29201, 1529 Hampton St., 803-254-3011 Dallas TX 75201, 1810 Commerce St., 214-741-1851 Denver, CO 80202, Federal Office Bldg., 303-629-7171 Detroit, MI 48226, 477 Michigan Ave., 313-965-2323 El Paso, TX 79901, 202 U.S. Courthouse Bldg., 915-533-7451 Honolulu, HI 96850, 300 Ala Moana Blvd., 808-521-1411 Houston, TX 77002, 6015 Fed. Bldg and U.S.Courthouse, 713-224-1511 Indianapolis, IN 46202, 575 N. Pennsylvania St., 317-639-3301 Jackson, MS 39205, Unifirst Federal and Loan Bldg., 601-948-5000 Jacksonville, FL 32211, 7820 Arlington Expressway, 904-721-1211 Kansas City, MO 64106, 300 U.S. Courthouse Bldg., 816-221-6100 Knoxville, TN 37919, 1111 Northshore Dr., 615-588-8571 Las Vegas, NV 89101, Federal Office Bldg., 702-385-1281 Little Rock, AR 72201, 215 U.S Post Office Bldg., 501-372-7211 Los Angeles, CA 90024, 11000 Wilshire Blvd, 213-272-6161 Louisville, KY 40202, Federal Bldg., 502-583-3941 Memphis, TN 38103, Clifford Davis Federal bldg., 901-525-7373 Miami, FL 33137, 3801 Biscayne Blvd., 305-573-3333 Milwaukee, WI 53202, Federal Bldg and U.S. Courthouse, 414-276-4681 Minneapolis, MN 55401, 392 Federal Bldg., 612-339-7846 Mobile, AL 36602, Federal Bldg., 205-438-3675 Newark, NJ 07101, Gateway I, Market St., 201-622-5613 New Haven, CT 06510, 170 Orange St., 203-777-6311 New Orleans, LA 70113, 701 Loyola Ave., 504-522-4671 New York, NY 10007, 26 Federal Plaza, 212-553-2700 Norfolk, VA, 23502, 870 N. Military Hwy., 804-461-2121 Oklahoma City, OK 73118, 50 Penn Pl. NW, 405-842-7471 Omaha, NB 68102, 215 N. 17th St., 402-348-1210 Philadelphia, PA 19106, Federal Office Bldg., 215-629-0800 Phoenix, AZ 85004, 2721 N. central Ave., 602-279-5511 Pittsburgh, PA 15222, Federal Office Bldg., 412-471-2000 Portland, OR 97201, Crown Plaza Bldg., 503-224-4181 Richmond, VA 23220, 200 W. Grace St., 804-644-2531 Sacramento, CA 95825, Federal Bldg., 916-481-9110 St. Louis, MO 63103, 2704 Federal Bldg., 314-241-5357 Salt Lake City, UT 84138, Federal Bldg., 801-355-7521 San Diego, CA 92188, Federal Office Bldg., 619-231-1122 San Francisco, CA 94102, 450 Golden Gate Ave., 415-552-2155 San Juan, PR 00918 U.S. Courthouse and Fed. Bldg., 809-754-6000 Savannah, GA 31405, 5401 Paulson St., 912-354-9911 Seattle, WA 98174, 915 2nd Ave., 206-622-0460 Springfield, IL 62702, 535 W. Jefferson St., 217-522-9675 Tampa, FL 33602, Federal Office Bldg., 813-228-7661 Washington, DC 20535, 9th and Pennsylvania Ave. NW, 202-324-3000 FEDERAL AGENCIES (SELECTED ADDRESSES) Central Intelligence Agency: Mr. John H. Wright Information and Privacy Coordinator Central Intelligence Agency Washington, DC 20505 Federal Bureau of Investigation: Federal Bureau of INVESTIGATION J. Edgar Hoover Building 9th and Pennsylvania Avenue, N.W., Washington, DC 20535 ATTN: FOIA/PA Section National Security Agency: Director, NSA/CSS 9800 Savage Road Fort George G. Meade, Maryland 20755-6000 ATTN: FOIA/N5 For those who live in The Commonwealth of Virginia, this is the address of the Richmond field office: Federal Bureau of Investigation 111 Greencourt Road Richmond, Virginia 23228 ATTN: FOIA/PA Section Civil Service Commission Appropriate Bureau (Bureau of Personnel Investigation, Bureau of Personnel Information Systems, etc.) Civil Service Commission 1900 E Street, N.W. Washington, D.C. 20415 202-632-4431 Commission on Civil Rights General Counsel, U.S. Commission on Civil Rights 1121 Vermont Ave., N.W. Room 600 Washington, D.C. 20415 202-254-6610 Consumer Product Safety Commission Office of the Secretary Consumer Product Safety Commission 1111 18th St., N.W. Washington, D.C. 20207 202-624-7700 Department of Defense/Dept. of Air Force Freedom of Information Manager Headquarters, USAF/DADF Washington, D.C. 20330-5025 202-697-3467 From hibbert at memex.com Wed Jun 16 17:36:14 1993 From: hibbert at memex.com (Chris Hibbert) Date: Wed, 16 Jun 93 17:36:14 PDT Subject: Census and privacy In-Reply-To: <9305142234.AA20885@toad.com> Message-ID: <9306170012.AA24905@entropy.memex.com> In the list of questions that the Digital Privacy and Security Working Group sent to the white house was this one: >> 38. How will the government ensure that unanticipated uses of >> the escrow database are prevented in the long term? (E.g., the >> Census database was supposed to stay confidential for 75 years, but >> was released during World War Two to allow Japanese-Americans to be >> imprisoned without cause. What protections are in place to make >> sure that this never happens again? I believe this account of the use of the census is incorrect. I don't have documentation, but the version I know doesn't require anyone to break any laws, and is just as invasive of privacy. Given that, I think it's a stronger argument against the census, but possibly a weaker example for clipper. As I've heard it, the Selective Service got lists from the Census of how many people of Japanese descent lived in each census tract. This information is publicly available, and doesn't require anyone breaking any laws or promises to the public. The Census makes summaries of all the information they collect available, usually at the level of census tracts. Armed with such a list, the SS could go door to door in any neighborhood in which they hadn't yet found enough Japanese-Americans. I don't believe that people should respond to the census, given that the information can be abused in this way, according to the strictest interpretation of the assurances given to the public. The only valid purpose of the census is to count citizens and apportion congressional districts. Any other purpose makes it less likely that the original purpose will be served well. Chris From M..Stirner at f28.n125.z1.FIDONET.ORG Wed Jun 16 17:54:05 1993 From: M..Stirner at f28.n125.z1.FIDONET.ORG (M. Stirner) Date: Wed, 16 Jun 93 17:54:05 PDT Subject: yaa (yet another arti Message-ID: <455.2C1F9199@shelter.FIDONET.ORG> > Another wiretap enabled authorities to thwart Chicago's "El Rukns > street gang" from a Libyan government-sponsored attempt to shoot > down a U.S. commercial airliner with a military weapons system. Uu> They find these all the time through other mechanisms. This episode was hilarious. An imprisoned El Rukun was conducting gang business via jailhouse payphone. One chuckly FBI agent was "decoding" the simple slang-code by which the goons communicated. After _three months_ he figured out enough of the code to bring an indictment. Some of the more amusing of these sophisticated subterfuges: Peanut = Jimmy Carter Hollywood = Ronald Reagan Roman = Policeman Change = Kill Our Friend = Qadaffi Long Demonstration = Shotgun It's interesting to note the length of time required for this "plaintext" to be decoded in an urgent matter of national security. . ~ . M. ********************************************************************* * - 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 prz at columbine.cgd.ucar.EDU Wed Jun 16 18:06:18 1993 From: prz at columbine.cgd.ucar.EDU (Philip Zimmermann) Date: Wed, 16 Jun 93 18:06:18 PDT Subject: Need consulting work Message-ID: <9306170107.AA05669@columbine.cgd.ucar.EDU> Hello Cypherpunks. I'm looking for some more consulting work in data security. Anyone have any leads? You can respond by email or phone. Thanks. -Philip Zimmermann 303 541-0140 From whitfield.diffie at Eng.Sun.COM Wed Jun 16 19:28:04 1993 From: whitfield.diffie at Eng.Sun.COM (whitfield.diffie at Eng.Sun.COM) Date: Wed, 16 Jun 93 19:28:04 PDT Subject: Second epistle of Whit apostle to Congress Message-ID: <9306170230.AA03298@ushabti.Eng.Sun.COM> Here is what I told Markey's telecommunications committee last Wednesday about the business impact of key escrot. What follows has been corrected for a major error for which I apologize to CPSR. I had carelessly cited EFF as the extractor of some documents under FOIA. It also makes some minor corrections; the changes are shown at the end. Whit TESTIMONY BEFORE THE HOUSE SUBCOMMITTEE ON TELECOMMUNICATIONS AND FINANCE 9 June 1993 The Impact of Regulating Cryptography on the Computer and Communications Industries Whitfield Diffie Distinguished Engineer Sun Microsystems, Inc. I'd like to begin by expressing my thanks to Chairman Markey, the other members of the committee, and the committee staff for giving us the opportunity to appear before the committee and express our views. We stand at a moment in history when an amazing coincidence of developments in technology and world politics is showing us opportunities in both business and personal life that no one could have anticipated. These developments rest on two closely related cornerstones: communication and internationalism. Business today is characterized by an unprecedented freedom and volume of travel by both people and goods. It is an era of rapid inexpensive transportation coupled with declining trade barriers. All this movement is made possible, however, by the reality of instant telecommunication between places thousands of miles apart, conveying voices, images, and data wherever they are needed. Ease of communication, both physical and electronic, has ushered in an era of international markets and multinational corporations. No country is large enough that its industries can concentrate on the domestic market to the exclusion of all others. When foreign sales rival or exceed domestic ones, the structure of the corporation follows suit with new divisions placed in proximity to markets, materials, or labor. The result is a world in which much of the population enjoys a standard of material wealth and freedom of action previously unknown. It is also a world in which no company, community, or country can afford not to compete in the global market. Security of communication and computing is essential to this telecommunication driven environment. The communication system must ensure that orders for goods and services are genuine, guarantee that payments are credited to the proper accounts, and protect the privacy of business plans and personal information. In the past, these diverse assurances have been provided by an ad hoc patchwork that has evolved slowly over the century and a half since the invention of the telegraph, but two factors are now making that patchwork obsolete. The first is the rise in importance of intellectual property. Much of what is now bought and sold is information that varies from computer programs to surveys of customer buying habits. Information security has become an end in itself rather than just a means for insuring the security of people and property. The second is the universal demand for mobility in communications. Traveling corporate computer users sit down at workstations they have never seen before and expect the same environment that is on the desks in their offices. They carry cellular telephones and communicate constantly by radio. They haul out portable PCs and dial their home computers from locations around the globe. With each such action they expose their information to threats of eavesdropping and falsification barely known a decade ago. It is the lack of security for these increasingly common activities that we encounter when we hear that most cellular telephone calls in major metropolitan areas are overheard or even recorded by eavesdroppers with scanners; that a new computer virus is destroying data on the disks of PCs; or that industrial spies have broken into a database half a world away. In this troubling scenario, however, there is a large ray of hope. Most of the technology to provide the needed protection is already available in the form of contemporary cryptography and its allied disciplines. Some of it has existed for nearly fifty years; some dates from the last five. It isn't in widespread use, but it does exist. Why then are proper security measures not incorporated in every cell phone, laptop, and workstation? Part of the answer is economic. Collecting intelligence by spying on information is so hard to detect that most users are unaware that they are suffering from it and unwilling to pay to protect themselves. Another lies in a unique problem of implementing security standards: security mechanisms are designed to block access to everyone who does not conform exactly to their demands. This makes them very unforgiving of that flexibility at the margins that makes much of standardization possible. Compounding these internal difficulties is one that is entirely external: a regulatory structure that goes back to the cold war and does not recognize the realities of the present situation. In the United States, export control has been the major barrier. Companies are deterred from building proper security mechanisms into their products because to do so will limit their exports and subject them to tedious administrative procedures required to comply with the law. The alternatives are to support two versions of each product, one for domestic use and one for export or to dilute the security measures in all products to a level whose export the government permits. At Sun Microsystems, approximately half our customers are outside the United States. Were we to build a workstation and an operating system embodying the best security we know how to provide and the security that we believe is needed, we would not be permitted to export them. This would present us with insuperable problems in maintaining distinct but somehow compatible domestic and foreign product lines. Not least of the consequences is that we are unable to provide security features that elements of the U.S. Government would like in the systems they buy, because that market does not come close to making up for the one we would have to forgo. I believe we are typical of computer companies in these respects. Digital Equipment after having made some outstanding contributions to network security, appears to have abandoned its lead in the field. Export issues were cited when it discontinued development of an operating system designed to achieve an National Computer Security Center A1 rating some five years back and I suspect they may have played a role in its larger retreat from security as well. We have also suffered from the government's failure to take the lead in championing security standards, both domestic and international. The first proposed federal standard in the area of public key cryptography has appeared only after such techniques had been employed for more than a decade and does not conform to the conventional practice that has evolved both in the U.S. and abroad. Some have even suggested that the government has actively worked to block standardization citing the United States failure to vote for its own national cryptographic standard (DES) in the International Standards Organization and material on the working relationship between NIST and NSA recently released to the Computer Professionals for Social Responsibility under the Freedom of Information Act. Now we are faced with the greatest challenge to our ability to secure the personal and business communications of the modern world that we have yet encountered. The administration proposes to adopt as a federal standard a system that is not only secret, but incorporates provisions for the government secretly to decode any person's communications when it deems this necessary for law enforcement or national security purposes. The effect is very much like that of the little keyhole in the back of the combination locks used on the lockers of school children. The children open the locks with the combinations, which is supposed to keep the other children out, but the teachers can always look in the lockers by using the key. The stated objective is to require the use of equipment based on these new `key escrow' chips for certain communications within the government and between the government and business. If they are successful in their objective, the latter provision could force the inclusion of these chips in all devices used, for example, to communicate with the government about contracts or taxes. What would be the effect of such broad inclusion? We have been assured by NIST that the finished chips, once their key escrow provisions have been programmed, will be available without restriction for incorporation in any piece of domestic equipment, but it is hard to see how either the security or wiretap objectives could be achieved if this were the case. It appears more likely that key escrow chips will be available only to companies that agree to employ them in approved ways. Probably this will be done by using existing regulatory machinery (called the Type II Commercial COMSEC Endorsement Program) that requires the manufacturers to submit their designs to NSA for approval. Were this to happen, the nation's computer manufacturers would be trapped in a regulatory web more confining than any we have seen so far. If we at Sun were required by customers' needs to communicate with the government to put the key escrow chip on the mother board of our machine and by regulations to have the board design approved, the government would have effective control of our development cycle. One of the requirements that would likely be imposed in these circumstances would be that we not offer any other security mechanisms that could be used to defeat the escrow provisions. This would mean we could not even maintain compatibility with our existing product line. It seems especially unlikely that customer acceptance of a chip explicitly designed to provide only partial security could ever be achieved other than by the coercive force of regulations. Nor does it seem likely that a system to which the U.S. held the keys would ever be accepted by more than a handful of other countries. They do not need it to achieve security, because an understanding of cryptography is now global and developing rapidly. Faced with a choice between secret U.S. technology known to embody a compromise and foreign systems of published function that at least claim not to, customer response seems hardly in doubt. The result may give the government a devastating choice: accept the import of foreign technology, losing both market share and the new law enforcement capability or forbid the import of foreign cryptographic systems altogether. In the latter case, the U.S., currently a leader in computers and software, seems likely to become a backwater, cut off from one of the most profitable segments of the global economy. Another problem presented by the key escrow technology is cost. No matter how essential it may be, security is still difficult to sell and extremely price sensitive. To require that cryptography not merely be isolated in hardware (by and large a good security practice) but that that hardware be a tamper resistant chip entirely dedicated to one security function will push the prices of many products and features beyond the reach of their potential markets. Cryptography can perfectly safely be embodied in microcode, implemented in cells incorporated in multi-function chips, or programmed on dedicated, but standard, microcontrollers at a tiny fraction of the tens of dollars per chip that Clipper is predicted to cost. The effect of giving the government and one or a small number of companies a monopoly control over an essential technology is also troubling to contemplate. The present key escrow chips operate in the megabit range. Can companies depend on NSA to have hundred megabit or gigabit chips available just when they are needed or might U.S. companies miss critical market windows while they wait for delivery of parts over which they have no control? Will there come a time, as occurred with DES, when NSA wants the standard changed even though industry still finds it adequate for many applications? If that occurs will industry have any recourse but to do what it is told? And if this happens who will pay for the conversion? Last month, before another committee of Congress, I discussed at some length the impact that the key escrow proposal could have on personal freedom, concluding that if it is adopted, we will take a big step toward a world in which the right of private conversation belongs only to those rich enough to travel to face to face meetings. Rather than repeat those arguments, I have attached my earlier testimony as an appendix and focus here on a few essential points. It is clear that the costs of key escrow will be monumental whether measured in dollars spent for computers, squandered business opportunities, or lost liberties. Even if these costs are accepted, there remain two questions: can the law enforcement function be achieved, and is it even necessary? In a world in which cryptographic expertise is widespread and cryptography is readily implemented on small processors, rules seem no more likely to keep security out of the hands of criminals than export controls guarantee it will not be available to hostile nations. This, however, may not matter. Despite the concern of law enforcement that advancing technology will reduce the effectiveness of wiretaps, that technology has been at least as much a blessing to the police as a curse. Even ignoring the contribution of police communication systems and databases, modern telephone switches make wiretaps more effective by supplying caller ID in real time under many circumstances. In a world in which conspiracies were conducted via conference calls on secure phones, criminals could never be sure that one of the participants was not an informer recording everything in high fidelity without the risk of being caught wearing a body wire. Corrections to First Version Given to Congress line 89 unaware of that ==> unaware that line 137 Electronic Frontiers Foundation ==> Computer Professionals for Social Responsibility line 181 design cycle ==> development cycle line 213 implemented in dedicated ==> programmed on dedicated From wcs at anchor.ho.att.com Wed Jun 16 20:29:16 1993 From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com) Date: Wed, 16 Jun 93 20:29:16 PDT Subject: Digital Cash$$$$ Message-ID: <9306170234.AA14426@anchor.ho.att.com> J. Michael Diehl asks: > 1. How does one start a digital cash economy? How is the initial distribution > of currency done? This is, of course, assuming the technical stuff is taken > care of. Issuing digital cash is easy - the problem is getting someone to take it :-) Other than anonymity, the problems of starting a digicash exchange economy are pretty similar to those of starting any other private money system - governments avoid the problem by pointing guns at people (i.e. issuing fiat currency and making legal tender laws), and commodity money systems mostly avoid it by using a commodity people care about as a standard (gold, silver, cordwood, tobacco, etc. - doesn't have to be fixed value), but everybody else has to solve it somehow. (The other main issue, which someone brought up, is whether there are applicable laws like banking law or taxable transaction reporting laws that may require you to get permits or let regulators regulate you or whatever, which vary from country to country, and also depend on how you define and manage your digicash accounts.) My current involvement in token-based currencies, aside from government fiat, includes NJ parkway toll tokens, which went up in value when the toll went up, Washington DC Metro tickets, which aren't redeemable for anything, and Joe's Coffee Money at work. Joe prints it on the Macintosh, there's a box of them on the counter, you leave a dollar when you take more, the coffee's ok, profits pay for new hardware and occasional free days, and unlike the bozos who run New Jersey's highways and Arts Center, Joe's a guy you can trust :-) One way to get people to accept your digicash is to use it for convenient anonymous payment for a service, like highway tolls or subway fares, or anonymous remailer payments. Essentially, you're getting a group of vendors together, selling digibucks for cash, and distributing the cash among the vendors according to the digibucks they've received. It's not much different from other systems using tokens. As long as the vendors agree to accept tokens at the current value for an extended period of time, you don't risk much. If you ran a barter club using tokens, you could do it with digicash; the problem then is how to agree on when tokens will be generated, and by whom. One solution that would be readily accepted is to only issue tokens in return for real cash or other valuable commodities. This means everybody knows that a digibuck is worth a buck, and has a reasonable expectation that the currency won't be inflated away. For commodities, some reasonable valuation needs to be done. (ObMovieReference - the poker game in "Benny and Joon" is marvelous :-) For payment for services, it's tougher - the demand side of your market depends on how much money is floating around as well as how many people want your services, and a market that's too small won't be able to generate much. On the other hand, unless there's some way for people to perform services that become part of the bank's assets and available to creditors, it shouldn't issue more digibucks to pay for them; that's inflating the currency merely for the bank's benefit. Another way to start a digicash system is as a credit card analogue, where the bank bills the customers later and only has enough cash backing to cover the float, but that's not much different from a cash-based system except that in a pay-first cash system, it's possible for the digibank to invest the cash in an external investment, with the usual issues of risk, liquidity, etc. that normal banks have, only the account balances exist as digibucks in people's digiwallets instead of ledger entries in the bank's computer. > 2. Is digital cash supposed to be backed by actual cash on deposit at the bank? Or by a promise of future services from vendors hired by the bank (presumably for real cash), if the customers find that acceptable, but that's essentially backed by the bank's negotiable assets, including cash. > 3. How would one "get out" of such an economy if he wanted to? The ideal way is by spending all your digicash, either for the Collect the system service / product if it's a vendor-based system, or for services or products sold by other members. It's somewhat of a system failure to redeem your digicash for paper cash, unless the system is basically intended as a payment system, in which case it's fine. Or abandon your investment, or sue. > 4. If DC is to be backed by actual cash, is this really such a good idea? I once knew someone who had invested in a bank-like system that denominated its accounts in gold rather than fiat currency, and paid its depositors in gold on demand. It also paid interest, which should have been a clue.... It eventually collapsed, and turned out to be a semi-scam; it had invested most of its money in high-yield, high-risk stocks (South African gold mines,mainly, which were actually doing quite well in 1980), and when it folded he had to file SEC complaints and sue them in Federal court to get them to distribute the stocks to their creditors instead of distributing stock in a worthless subsidiary company that it had formed to take over the assets. He was successful, so he lost a lot less than he could have, but being a hard-money paranoid isn't all it's cracked up to be :-( Bill From mbriceno at ideath.goldenbear.com Wed Jun 16 23:22:08 1993 From: mbriceno at ideath.goldenbear.com (Marc Briceno) Date: Wed, 16 Jun 93 23:22:08 PDT Subject: Need hard Clipper data Message-ID: I am representing the anti-clipper side in an ongoing debate in the "Wired " conference on OneNet. The governmental lemmings question the existence of the "Law Enforcement Exploitation Field" and want citations. Would the person who posted the hard facts about Clipper please send me all the info? Thanks in advance, -Marc Briceno PGP public key From mdiehl at triton.unm.edu Wed Jun 16 23:31:08 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 16 Jun 93 23:31:08 PDT Subject: Weak stenography. Message-ID: <9306170631.AA19575@triton.unm.edu> Recent discussion reguarding court-requested plaintext has made if obvious that data conceilment techniques need to be developed before real privacy can be obtained. For the sake of discussion, lets define "weak stenography" as any data-hiding techinique which will fool all but the "informed and skilled" intruder. For example, hiding encrypted data in "hidden" files in msdog would qualify as (very) weak stenography. By "informed," I mean that the intruder has reason to think that you are hiding something. "Skilled" simply means that the intruder has the needed skills to find and verify anything you might be hiding. Now, lets say some LEA thought you had plotted to (your favorite crime here.) And that they also suspected that you had encrypted all of the needed evidence. Further, that you had hidden the data, but couldn't prove it. In order for them to get you to produce that plaintext, they would have to be able to prove that you actually had such data. The only way that I can think of for them to prove such a thing is to produce a piece of cyphertext, and prove that it is, indeed, cyphertext. Further, they would have to prove that it belongs to you. So, if the data is hidden, they have to find it before they can compel you to decrypt it. Now for a proposal: Lets say we have to binary files, one that is an executable, and the other some type of (pgp?) encrypted file. We take these two files and put the cyphertext on the end of the executable, and encode the length of the the cyphertext at the end of the resulting file. Now, lets say that we had xor'ed the cyphertext with some string before we did the concatenation. The file-size-change would be a sure tip-off, if the LEA had another copy of the executable to compare with, so assume they don't. Looking at the file with a binary editor would reveal nothing. Since the cyphertext was transformed, running the decrypter program on the file would be fruitless. Disassembling the executable might, to the real skilled, reveal something, so we can assume this is what happens. After this much work, the LEA has some kind of binary file which they now have to tie to you and prove that it contains some kind of message. BTW, you can always claim to have downloaded it from somewhere.... Now they need to figure out how you transformed your cyphertext, if they even think of that. Lets say they figure out how you did it. Now they have to find what string you used in the xor process. Give that such a string might be about 6 ascii characters, they have to look at 64^6 different strings; each time through, they have to run the decryption program to see if it recognizes the cyphertext. If they can do one such examination per second, this process will take 2.2 years! And when their done, they still have to prove you put the message there in the first place. Bummer. ;^) Is there something wrong with my reasoning? Does this sound plausable. Would it be as effective as I envision? Comments are welcome. If the response is favorable, I will try to get it coded in (portable?) C and release it. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From mdiehl at triton.unm.edu Wed Jun 16 23:54:47 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 16 Jun 93 23:54:47 PDT Subject: Weak stenography. In-Reply-To: <9306170647.AA09320@netcom3.netcom.com> Message-ID: <9306170654.AA19944@triton.unm.edu> According to Timothy C. May: > > (very) weak stenography. By "informed," I mean that the intruder has reason > > I dislike spelling flames, but you consistently misspelled > "steganography" as "stenography," which is what a secretary does. > > Thought you might want to watch out for this in future postings. You may dislike them, but I sure appreciate it. Thanx. I can do a lot of things; spelling isn't one of them. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From chaos at aql.gatech.edu Thu Jun 17 02:35:39 1993 From: chaos at aql.gatech.edu (Paul Goggin) Date: Thu, 17 Jun 93 02:35:39 PDT Subject: Binaries Message-ID: <9306170935.AA17555@toad.com> In order to equalize, what may be construed as a growing disparity between ripem and pgp availability (i.e. ripem binaries being kept online for ftp). I have taken upon myself to start collecting binaries for PGP. If you would be kind enough to email me if you would like to offer any binaries. I will check against what I already have and get back to you for retrieval. Please enclose your OS and sytem type (pretty much referring to UNIX here). For instance, -r--r--r-- 1 ftp guest 252829 Jun 17 05:05 pgp-hp720-8.07.Z -r--r--r-- 1 ftp guest 166958 Jun 17 05:00 pgp-ibm-rs6000-3.1.Z Paul -- 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:---> anonymus+4744 at charcoal.com ------------------------------------------------------------------------------ Title 18 USC 2511 and 18 USC 2703 Protected -- Monitoring Absolutely Forbidden From gg at well.sf.ca.us Thu Jun 17 03:21:59 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 17 Jun 93 03:21:59 PDT Subject: YAA (yet another article) Message-ID: <93Jun17.032128pdt.13971-1@well.sf.ca.us> Re your "I like this ("Oh My God" proposal for tap authorisations): THis gives us a possibly interesting place to start from. Sponsor and lobby for (etc) new legislation which would update the existing wiretap laws to include the Oh My God! standard. The point being to put that standard in place & let it run in test mode for a while to see how it works. If it works out well in practice, and isnt subject to "venue abuse" (judge shopping), then it could be extended to key escrow systems. However, I still have a strong preference that even an "improved" key escrow system be implemented via the free market and make provision for free choice in cyphers. -gg From mlshew at dixie.com Thu Jun 17 05:37:13 1993 From: mlshew at dixie.com (Mark Shewmaker) Date: Thu, 17 Jun 93 05:37:13 PDT Subject: Rude CryptoStacker Suggestion (LONG) Message-ID: Earlier I talked about some amiga programs I had that did compression and encryption. I've uploaded some to soda. As I've said, most of them are amiga-specific, but of course the encryption-only bits of code can still be educational to other-machine users. If not, Eric can erase them, or not make them public, which is of course okay. It's his site and all that. I figured I'd go through these files here to explain a bit of what they are and do, if nothing else, with liberal amounts of plagiarism from the readme files. This should at least prevent people from downloading interesting sounding titles for nothing. First, the list of files. Although I don't know where they'll end up, The full list of things I uploaded are: ************************************************* * * rdes.lha 25K DES encryption program * idea.lha 31K File encryption tool using IDEA * Crypt.device-1.8.lha 23K Crypting handler * crypdisk.zoo 55K Sector oriented disk encryption * xpk25dev.lha 141K Compression package, developer's additions * xpk25usr.lha 215K Compression package, user's edition * XFH134.lha 135K (De-)compressing handler, uses Xpk. * xPack_1.5.lha 9K OS 2.x Shell Interface for XPK * ************************************************* Now for the individual descriptions: ************************************************* * * rdes.lha 25K Another DES encryption program * ************************************************* Any collection of encryption programs should of course include a version of DES, so I'll start off with one. The following is taken from the RDES man file. Note the -x option. *********** * * The usage for RDES is * * RDES [-e | -d] [-x] [-b] [-m mode] [-k key] [in_file [out_file]] * * where: * * -e => encrypt the file (default) * -d => decrypt the file * * -x => add n random bytes to the end of the file, where n is * a random integer between 0 and 7 inclusive (used in * encryption mode only). * * -b => use straight DES (default is to use cipher block chaining). * -m => set `mode' bits (see below for details). * -k => set key string * *********** ************************************************* * * idea.lha 31K File encryption tool using IDEA * ************************************************* This is another one that should be easily recompilable on multiple platforms--it's straight C, and it even includes the original unix code. It is small, does IDEA encryption/decryption, and that's all. Here's the top of idea.doc. If it looks interesting you'll probably just want to get it anyway. *********** * * NAME * idea - encrypt and decrypt using IDEA * * SYNOPSIS * idea [ -e | -d ] [ -ecb | -cbcN | -cfbN | -ofbN ] * ( -k keyString | -K keyHexString ) * [ inputFile [ ouputFile ] ] * * idea [ -h | -H ] [ -tan | -abr ] * [ -k keyString | -K keyHexString ] * [ inputFile [ [ ouputFile ] hashvalFile ] * *********** ************************************************* * * Crypt.device-1.8.lha 23K Crypting handler * ************************************************* This is a device driver that you can use to mount an encrypting virtual partition as a file in top of an existing AmigaDos device. It says it's based on fdev.device -- "filesystem in a file". You can edit the virtual partition parameters however you want (such as sectors/cylinders/filesystem etc.) The encryption method is IDEA in cbc mode, which is written in 68000 assembly. ************************************************* * * crypdisk.zoo 55K sector oriented disk encryption * ************************************************* This is a sector based disk- (or AmigaDos device-) based encryption program. It works a bit differently from crypt-device, and also uses a 68000 handcoded IDEA algorithm, and it's not limited to cbc mode. It's a modification of the xpkIDEA library assembler source which will be mentioned in the next section. ************************************************* * * xpk25dev.lha 141K Compression package, developer's additions * xpk25usr.lha 215K Compression package, user's edition * XFH134.lha 135K (De-)compressing handler, uses Xpk. * xPack_1.5.lha 9K OS 2.x Shell Interface for XPK * ************************************************* * * Note: The bottom two files are updates to subparts of the top two. * (Obviously, I didn't want to modify the original distribution.) * ************************************************* The easiest way for me to describe the xpk???.lha files is to cheat, and mostly just include the overview file. Here it is, with a lot of deletions: (Including the list of way-cool authors.) *********** * * THE XPK DATA COMPRESSION PACKAGE * ================================ * * * 1. What is XPK * -------------- * * For a long time, there have been various compression programs for different * purposes on the Amiga. But every application supported only one compressor, * and most compressors were only supported by one application. XPK wants to * put an end to this: Every application with XPK interface can use very packer * with XPK interface. An XPK packer is a library with a four letter library * name. * * * 3. XPK-Compressors * ------------------ * * First a general overview of the most important packers and crypters and * their uses. [...] * - FEAL encrypts data at reasonable speed with very high safety, ie. it has * not yet been broken in the higher-round modes. Any kind of private data * is safe in the hands of FEAL. ===> [Is this still true?] ===> [Also: On the chart below, A3000 means a 25Mhz 68030 machine.] * Now for the complete overview of all existing compressors. You may not have * all of them. The meaning of the fields: * * Name: 4 letter name of the packer. * CSpd: Compression speed in K/sec on an A3000 * USpd: Decompression speed in K/sec on an A3000 * CF : Compression factor in % * Mo : This packer supports modes * Cry : This packer can encrypt * Desc: Description of the packer * * Name CSpd USpd CF Mo Cry Desc * ---- ---- ---- -- -- --- ---- * BLZW 139 364 32 + - Fast compression & decompression, usable CF * CBR0 410 1918 3 - - Byte run encoding, only for simple files (Gfx) * DLTA 104 1265 - - - Pre-processor for packing of sound samples * ENCO 393 393 - - + Sample library for cryptors * FEAL 109 109 - + + Encryption with selectable safety * HUFF 88 138 24 - - Huffman coding, low CF and speed * IDEA 90 90 - + + Safe Encryption, not too fast, many variations * IMPL 6 280 44 + - Imploder, good CF, slow compression, fast decomp * NONE 1918 2477 0 - - Do-nothing packer * NUKE 36 630 45 - - Very fast decompression, good CF & fast compression * RLEN 170 1351 4 - - Sample library for packers * SHRI 5 9 52 + - Excellent CF but low speed * VERN 861 874 - - + Less safe but very fast Vernam encryption * ---- ---- ---- -- -- --- ---- * * Also, XPK supports powerpacker.library for decompression. * *********** Note that there are multiple encrypting "compressors" there, including a blank one for an example. The distribution also contains two handlers to allow one to use these compression/encryption libraries transparently instead of semi-explicitly. One of these, XFH, (the one that Urban mentions), has been upgraded since this distribution. The latest version of which I am aware is 1.34, so I uploaded XFH134.lha also. Now to discuss some of the individual encryption libraries within this XPK distribution. I recall people having asked about what the speed of doing on-the-fly encryption would be. For Vernam encryption (Has anyone heard of this???), not only are the benchmarks not included but neither is the library nor the docs. Maybe the author didn't contact Urban for inclusion in the master archive, I dunno, I don't even have an xpkVERN.library. However, I do have numbers for FEAL and IDEA. Here are the speeds for the FEAL encryption, from a speed chart from its docfile. (I believe this is for a 25Mhz 68030 machine.) *********** * * Speed and Memoryusage * --------------------- * * Rounds Memory En-/Decryptioncryption * Usage Speed * ------ ------ ---------------------- * 4 1K 190 K/sec * 8 1K 144 K/sec * 16 1K 96 K/sec * 32 1K 58 K/sec * 64 1K 33 K/sec * *********** Here are the IDEA speeds: *********** * * The xpkIDEA implementation uses the following XPK modes for different * encryption methods: * * XPK Mode Encr. Method Nr. States 68030/25 68000/7.14 * -------- ------------ ---------- -------- ---------- * 0..25 ECB / 90 K/s 12 K/s * -------------------------------------------------------------------------- * 26 CFB 1 * . . . 87 K/s 11 K/s * . . . * 50 CFB 25 * -------------------------------------------------------------------------- * 51 OFB 1 * . . . 84 K/s 11 K/s * . . . * 75 OFB 25 * -------------------------------------------------------------------------- * 76 CBC 1 * . . . 84 K/s 11 K/s * . . . * 100 CBC 25 * -------------------------------------------------------------------------- * *********** Rather obvious possibilities for those wanting to do similar things on other machines: o Forget it, your machines are inferior pieces of... Oh sorry, I'm supposed to be being polite. Scratch that. o Scavenge source code from some of the above packages and use it in the skeletons of DOS 'redirectors' (?) o Go the whole way and implement the XPK standard on other machines. (You might want to bring get with Urban and the others though. By the way, when quoting sections of the XPK overview, I didn't inlcude the partial author list of nine people. Anyone interested in these projects do have lots of other people to talk with about the standard.) o Disassociate from the mediocritins and.. oops, there I go again. And finally, o Keep part of your mind still thinking about standards for secure data links. I have my own ideas on the subject, which should translate to other machines mostly. They are as follows: On the amiga, I think it would be best to write a driver one would use instead of the default of serial.device or whoever, to handle the encryption. It would then call serial.device or whoever to actually transmit the data. The advantage here is the modularity of having any terminal program work with this device driver, so you could at any time bring up its window on the workbench screen or a public screen, to adjust its parameters in a way independent of whatever terminal programs you might have running, if need be, or controlled with ARexx scripts or from other programs. The neat parts here are that (a), it could do compression as it goes, too, but more importantly, (b), it would be transparent to any other binary transfer protocol you'd be useing, except for speed. (Although it could somewhat make up for that by making them slightly more efficient--seeing as the encrypting device would have to do it's own error checking, dynamic transfer protocols used by the term programs would tend to use larger and larger window sizes), and (c) this could be standardized across machines, so it would also be neat if (d) the standard allowed for multiple concurrent sessions transparently, as well as file transfers, all dynamically configurable. (Not just multiple resident invocation of the same code, but one link turned into 12, like uwm, or dnet on amigas and unix.) (I'm almost making it into a terminal program itself.) One of the main things would be to make it very transparent to the other programs running--so that even if you were on some weird (but somewhat secure) network, you could run a program on this standard between your telnet on your machine and it's connection to the network. (I may be speaking nonsense here.) Whether you were really using kermit, telnet, ftp, or zmodem, the underlying connection would be secure. Anyway, I was just thinking that this might be especially cool if it were compatible across platforms. I figured I'd share those thoughts with any others thinking about secure links, to help maximize the spread of ideas. (And then Timothy Newsham uploads something along those lines even before I can post this. Sheesh! Okay, here's a way to make money by taking bets on this phenomenon: Pick a random person and a cypherpunk, and let them race, with the random person describing a neat program he'd like to have, and the cypherpunk writing it. I'd place my bets on the cypherpunk finishing first. :-) ) Hoping to add to the general confusion, -Mark Shewmaker From 76630.3577 at CompuServe.COM Thu Jun 17 05:56:02 1993 From: 76630.3577 at CompuServe.COM (Duncan Frissell) Date: Thu, 17 Jun 93 05:56:02 PDT Subject: Digital Cash$$$$ Message-ID: <930617125212_76630.3577_EHK27-1@CompuServe.COM> (J. Michael Diehl) >>>Then DC is actually backed by "legal" currency? Then, what's to keep >>>someone from opening a digital bank, and takeing the money and runing? Nothing. Just like the First National City Bank of New York or Bank Leu, Zurich. You should deal with someone with a rep and perhaps a history. Obviously the risk of fraud would be greater with a digital cash issuer completely unconnected to an existing financial institution. >>>OECD? The Organization for Economic Cooperation and Development. AKA the rich countries (plus Turkey). The 12 EEC Countries (we can all name them, can't we? %{) + Canada, US, Japan, AU, NZ, Iceland, Norway, Sweden, Finland, Austria, Switzerland, and Turkey. >>>Obviously, DC can lead to quite a few opportunities for corruption, >>>taxes for example. This will hinder (or help, in Washington D.C! ;^]) >>>the spread of DC.Is there any arguements for DC, to offer to counter >>>this major drawback? That's not a bug that's a *feature*. Those are the main arguements in *favor* of DC. The main argument that DC can use against D.C. is that conventional regulatory techniques have been obsoleted by the nets, downsizing effects *all* sorts of institutions not just corporations, and the denizens of the District had better start figuring out what they will do when they are forced to get honest work. Duncan Frissell Laws are local, communication is universal. From 76630.3577 at CompuServe.COM Thu Jun 17 06:33:17 1993 From: 76630.3577 at CompuServe.COM (Duncan Frissell) Date: Thu, 17 Jun 93 06:33:17 PDT Subject: Contempt of court Message-ID: <930617132906_76630.3577_EHK27-1@CompuServe.COM> >>>Note that a court could cite you for contempt for not complying >>>with a subpoena duces tecum (a subpoena requiring you to produce objects >>>or documents) if you fail to turn over subpoenaed backups. Assume that your application is running (mirrored) on five machines in five different jurisdictions and the machines will lock out one or more of their number if they receive a panic code, or one goes offline unexpectedly, or is not accessed in exactly the right way, you could easily respond to a subpoena duces tecum by stating truthfully that the requested records are not (or are no longer) under your control. The machines themselves can also be protected by careful choice of location and judicious use of remailers and requirements that they only be accessed by telenetting, etc. Besides what's the big deal about contempt of court. If you are worried about doing 2 years or less, locate yourself in another jurisdiction. No need to expose your body to high risk legal regimes. Duncan Frissell "But your Honor, I'm desperately trying to *conceal* my contempt for this court." From m5 at vail.tivoli.com Thu Jun 17 06:51:32 1993 From: m5 at vail.tivoli.com (Mike McNally) Date: Thu, 17 Jun 93 06:51:32 PDT Subject: Contempt of court In-Reply-To: <930617132906_76630.3577_EHK27-1@CompuServe.COM> Message-ID: <9306171350.AA14019@vail.tivoli.com> Duncan Frissell writes: > >>>Note that a court could cite you for contempt for not complying > >>>with a subpoena duces tecum (a subpoena requiring you to produce objects > >>>or documents) if you fail to turn over subpoenaed backups. > > Assume that your application is running (mirrored) on five > machines ... I think that Mr. Frissell's suggestion falls into the category of what I've humbly termed "digital flash paper" mechanisms. In the days of yore, numbers runners and gangsters and nefarious bad guys would keep records on cellulose (?) flash paper which could be ignited and destroyed very rapidly should Elliot Ness be seen approaching the front door. Another (simpler) suggestion made by a friend was to devise motion-sensitive devices which would cause total corruption of information stored on a disk if it were moved. My highly esteemed legal opinion is that this could be considered criminal obstruction of justice, though as with the contempt of court issue such a charge might be preferrable to one of Sedition :-) -- Mike McNally From anton at hydra.unm.edu Thu Jun 17 07:10:10 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Thu, 17 Jun 93 07:10:10 PDT Subject: Jimbo B. responds again! Message-ID: <9306171409.AA13003@hydra.unm.edu> Faced with the "charge" of selling out the govt, by "supporting Clipper" (more specifically for granting a license to them to use RSA's patented encryption in the key escrow scheme [as far as I can tell; I don't read legalese too well]), RSADSI/PKP's head Jim Bidzos responds thusly: Quoth Jim Bidzos, verily I saith unto thee: > From jim at RSA.COM Wed Jun 16 15:37:37 1993 > id ; Wed, 16 Jun 1993 15:37:34 -0600 > Date: Wed, 16 Jun 93 14:35:49 PDT > From: jim at RSA.COM (Jim Bidzos) > Message-Id: <9306162135.AA17052 at RSA.COM> > To: anton at hydra.unm.edu > In-Reply-To: Stanton McCandlish's message of Wed, 16 Jun 1993 13:26:42 -0600 (MDT) <9306161926.AA06434 at hydra.unm.edu> > Subject: hmph > > > Well, I don't know where these things get discussed, but you can > certainly feel free to resend or post my email to you. I'm genuinely > confused, as I believe the situation is as simple as I put it to you. > Our claims of patent infringement by DSS, made over the last 18 > months, were well-known and publicized. NIST has capitulated. Seems > pretty straightforward to me. > > BTW, on Clipper, ATT, Motorola, IBM could have done Clipper without > ever talking to us. Contrary to popular belief, we don't dictate > terms to licensees. So, with their RSA or Diffie-Hellman licenses, > these companies could have simply replaced DES with Clipper > (continuing to use RSA for Clipper key management) and supported > Clipper without ever talking to us. (In fact, I believe this is > exactly what ATT did, as they had a DH/DES phone before they "joined" > the Clipper club.) Clipper will not fail or succeed because of any > Public-key patent license. It will go away simply because it was > ill-conceived, ill-timed, and undesirable. > > > --Jim > -- Stanton McCandlish * Space Migration * Networking * ChaOrder * NO GOV'T. * anton at hydra.unm.edu * Intelligence Increase * Nano * Crypto * NO RELIGION * FidoNet: 1:301/2 * Life Extension * Ethics * VR * Now! * NO MORE LIES! * Noise in the Void BBS * +1-505-246-8515 (24hr, 1200-14400, v32bis, N-8-1) * From tk at reagan.ai.mit.edu Thu Jun 17 07:18:41 1993 From: tk at reagan.ai.mit.edu (Tom Knight) Date: Thu, 17 Jun 93 07:18:41 PDT Subject: Contempt of court In-Reply-To: <930617132906_76630.3577_EHK27-1@CompuServe.COM> Message-ID: <19930617141632.8.TK@ROCKY.AI.MIT.EDU> I wouldn't want to encourage anyone to contempt of court, but, strictly hypothetically, there is a very simple way to answer the request to hand over keys to encrypted data. Simply assure that you have a copy of the encrypted data available, then construct one-time-pad data of the same length as the encrypted data, such that when the two are XORed, you get your choice of plaintext. Hand over the "one time pad." This argues powerfully that one might want such one time pads available and in use even if you are really using a more convenient encryption technology. Kids: don't do this at home. From hughes at soda.berkeley.edu Thu Jun 17 08:32:17 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 17 Jun 93 08:32:17 PDT Subject: fast des In-Reply-To: <19930616211451.5.TK@ROCKY.AI.MIT.EDU> Message-ID: <9306171528.AA29921@soda.berkeley.edu> >Usually the limiting factor is examining the decrypted data >for statistically significant patterns indicating that you have the >correct key. If you know that your plaintext is 7-bit ASCII, then you can reject if you see too many 8th bits set. Assuming that the size of your intercepted ciphertexts is generous, say ten blocks, then the likelihood of a false decryption which has all the 8th bits off is extremely small. Hint for implementors: don't allow such easy bit correlations in your plaintext. In any case, the point of a DES cracker is to reduce the size of the space of probable decryptions, so that more computationally expensive statistical tests of possible plaintexts may be performed on a shorter list. If your cracker can reduce the size of the probable keyspace by eight bits, then you can run, in parallel, tests which take 2^8 times as long. For example, you may be able to reject many potential plaintexts from a CBC ciphertext stream after the first block; longer tests would look at a longer stream. This is where measures of n-gram distribution really come into their own. These measures can distinguish between text types extremely finely, but are often expensive. Nevertheless, they are highly suited to automation, particularly to distinguish between different languages and to recognize non-linguistic forms such as protocol encapsulations, object code, and compressed text. Eric From jazz at hal.com Thu Jun 17 08:41:53 1993 From: jazz at hal.com (Jason Zions) Date: Thu, 17 Jun 93 08:41:53 PDT Subject: YAA (yet another article) In-Reply-To: <93Jun17.032128pdt.13971-1@well.sf.ca.us> Message-ID: <9306171541.AA09044@jazz.hal.com> > However, I still have a strong preference that even an "improved" key >escrow system be implemented via the free market and make provision for >free choice in cyphers. As do I; I think this is just another part of daily life that the government has no business being in. As for freedom of choice with respect to privacy technology, I believe that's a must. Jason From 76630.3577 at CompuServe.COM Thu Jun 17 08:44:22 1993 From: 76630.3577 at CompuServe.COM (Duncan Frissell) Date: Thu, 17 Jun 93 08:44:22 PDT Subject: Contempt of court Message-ID: <930617153447_76630.3577_EHK50-1@CompuServe.COM> >>>I think that Mr. Frissell's suggestion falls into the category of what >>>I've humbly termed "digital flash paper" mechanisms. >>>My highly esteemed legal opinion is that this could be considered >>>criminal obstruction of justice I call it a network operating system designed to cope with local security breaches. I am not required by law to keep business records in any particular jurisdiction. I am not even required to have access to everything in a business with which I am connected. >>>such a charge might be preferrable to one of Sedition :-)<<< But a charge of Sedition is such a rare honor. It's tough to get the Feds to bring one. One Sedition trial during WWII and one against White Supremicists a few years back. Feds lost both. Besides, if the system is run by non-Americans outside of the US, sedition can't apply (can it? - no treason certainly). (Mike McNally) Duncan Frissell From jka at ece.cmu.edu Thu Jun 17 08:48:07 1993 From: jka at ece.cmu.edu (Jay Adams) Date: Thu, 17 Jun 93 08:48:07 PDT Subject: fast des In-Reply-To: <19930616211451.5.TK@ROCKY.AI.MIT.EDU> Message-ID: <9306171547.AA02951@mustang.ece.cmu.edu> > I don't know of any 2.4 gbps DES chips, but DEC has built a 1 gbps > chip. > .... Key-loading is a different operation, > and that might not go nearly as fast. Any hardware assists (i.e., DMA) > would be for the data, not for the next key to use on the same block of > data. > > Usually the limiting factor is examining the decrypted data > for statistically significant patterns indicating that you have the > correct key. The fast DES chips don't help with this at all. A known > plaintext attack, of course, doesn't have this problem, but these are > probably of limited interest in real applications. If you were interested in cracking DES, I wonder if you couldn't just build the hardware out of FPGAs. That way, you could make key loading and the decrypted data test fast as well. - Jay From M..Stirner at f28.n125.z1.FIDONET.ORG Thu Jun 17 09:06:27 1993 From: M..Stirner at f28.n125.z1.FIDONET.ORG (M. Stirner) Date: Thu, 17 Jun 93 09:06:27 PDT Subject: yaa (yet another arti Message-ID: <475.2C208FF7@shelter.FIDONET.ORG> Uu> --Dave (trying to give some extra business to the anonymous Uu> remailers). I'd love to, but there hasn't been any sort of an updated description of the address syntax posted here since I got back on this list. I'd be thrilled if someone could post a current how-to for the remailers, or at least send it to me at the following address: ********************************************************************* * - 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 axelrod at s106.es.llnl.gov Thu Jun 17 09:24:41 1993 From: axelrod at s106.es.llnl.gov (Mike Axelrod 422-0929) Date: Thu, 17 Jun 93 09:24:41 PDT Subject: Contempt of court Message-ID: <9306171626.AA23636@s106.es.llnl.gov> I gather that a court can order you to produce the means to decrypt cyphertext that the court has ruled is evidence. This would imply that the giving of the means to decrypt (which could simply be the uttering of a password) is not considered testimony, because you cannot be forced to give testimony under the 5th amendment. Is there a court decision on point for this issue. In another but similar context, can a court order you to give it the combination of a safe, that contains evidence? I suspect, if that is the case, then there is no 5th amendment protection against being so ordered to produce the means to decrypt messages, documents etc. From jim at RSA.COM Thu Jun 17 09:26:10 1993 From: jim at RSA.COM (Jim Bidzos) Date: Thu, 17 Jun 93 09:26:10 PDT Subject: "RSA sells out" hue and cry In-Reply-To: <9306171208.AA11770@hydra.unm.edu> Message-ID: <9306171626.AA20285@RSA.COM> Re "source" requirements for Clipper: See my last email to you. ATT, Motorola, etc. are licensed to use RSA and Diffie-Hellman. They are free to use those techniques to manage Clipper keys, as long as they pay their royalties for those techniques, without any contact with us. Or perhaps, when we lciensed them back in the mid and late 80's, we should have limited the use of public key to key management of "future algorithms we approve of?" ********************** END FORWARD *********************************** Draw your own conclusions. I sure will. -- Stanton McCandlish * Space Migration * Networking * ChaOrder * NO GOV'T. * anton at hydra.unm.edu * Intelligence Increase * Nano * Crypto * NO RELIGION * FidoNet: 1:301/2 * Life Extension * Ethics * VR * Now! * NO MORE LIES! * Noise in the Void BBS * +1-505-246-8515 (24hr, 1200-14400, v32bis, N-8-1) * From nobody at rosebud.ee.uh.edu Thu Jun 17 09:42:42 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Thu, 17 Jun 93 09:42:42 PDT Subject: Subject lines for remailers Message-ID: <9306171642.AA00115@toad.com> Another way in which incoming and outgoing messages can be linked up in a remailer is the Subject line. Most of the remailers keep this the same for incoming and outgoing messages. Most of the remailers also have the ability to let the user change the subject line as it goes through the remailer. My "chain" program which I put on soda lets you set the subject line but only in the last remailer of the chain (so that it goes to the destination with the right subject). If more people did that and we also adopted the convention of not having a subject line at all for the mail up to that point, then all mail through the remailers would have no subject and it would all look the same. (Actually, my mailer won't conveniently let me have no subject, so I would either have to have a blank subject or some default string.) Hal Finney 74076.1041 at compuserve.com From CWHITCOM at bentley.edu Thu Jun 17 10:13:18 1993 From: CWHITCOM at bentley.edu (CWHITCOM at bentley.edu) Date: Thu, 17 Jun 93 10:13:18 PDT Subject: help on hacking Message-ID: <01GZGPCWLN32000911@bentley.edu> This is a followup to a request I sent around last week. I have a bit more information now. The request is from a major news organization that is working on a project concerning privacy. They are interested in how one gains access to private and public databases, security measures, etc. If you are interested in helping out, please contact tye at nws.globe.com. Coralee By the way, don't forget the Computers and Social Change Conference this Friday and Saturday at Roxbury Community College. There is a wide variety of workshops offered as well as lunch. For more information call Marlene Archer at 617-252-0600. From anton at hydra.unm.edu Thu Jun 17 10:16:30 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Thu, 17 Jun 93 10:16:30 PDT Subject: "RSA sells out" hue and cry (fwd) Message-ID: <9306171716.AA19271@hydra.unm.edu> More from Big Jim at RSA, criticizing the idea that RSA should have licensed "its" algorithms to NIST only on the condition that they not be used for clipper/capstone/key escrow and similar schemes ********* Quoth Jim Bidzos, verily I saith unto thee: ************** From nobody at soda.berkeley.edu Thu Jun 17 10:49:12 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Thu, 17 Jun 93 10:49:12 PDT Subject: Weak steganography Message-ID: <9306171745.AA05015@soda.berkeley.edu> -----BEGIN PGP SIGNED MESSAGE----- Responding to Mike Diehl's ideas about weak steganography: (Speaking of which, did anyone notice that there weren't any stegosaurs in Jurassic Park? Just another sign of the government crackdown on crypto?) There are a couple of problems with the idea of sticking encrypted files onto the end of executable files. The first is, to make this easy, you need a program to do it (and to "undo" it). Well, if someone steals your computer and gets access to these files, they will probably also get access to this program. This will tip them off to what you have done. This is an example of the general principle that you need to assume that your attackers know or can discover the methods you are using, but they don't know the keys. Another problem is that encrypted files look different from executable files. Encrypted files have a uniform histogram (that is, all 256 different possible byte values are equally frequent), but exe files do not. The appending of an encrypted file to an executable file will be very obvious. The exact boundary may not be immediately apparent, but it can probably be narrowed down to ten or twenty words without much effort at all. In any case, exe files which have had this treatment will stick out like a sore thumb. Last, XOR'ing a PGP file with a repeated string is probably not a very good method. PGP has a header at the front whose structure is known and which has some fixed bytes. These can be used to immediately recover some letters of your string. Given that the string is mnemonic (memorable) it may be possible to guess more of it. Again, this is basically effortless and it narrows down the search space considerably before they even start to try to break it. Of course, even if they recover the original PGP file they would then need your pass phrase to decrypt it. If you are assuming that they already had that then they didn't need to go through the rigamarole of deducing the repeated string which cloaked the PGP file; once they found an executable with a uniform histogram at the end, along with your program which creates such files, that should be enough evidence to force you to reveal the string just as you were forced to reveal your pass phrase. In sum, I don't think this approach will help much. Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLCBm8agTA69YIUw3AQFbMAQAqsZE3Zs3oC1RcTqZ+yGDv0uf0avWUI9N l7Lr+XlOxryu7m7zo7S2knZIjUMa6a0v0EolnpPw/tK0SUkqGwOBrdfkn8BNPIM6 uZe9kzhJJYbc+w+TQqPB8PoVc3ZQ78OAOwyvhdu28KwG6kXLO4mCiX9n6faIDK1I 3G4Ez8v+6Xg= =F8de -----END PGP SIGNATURE----- From nobody at rosebud.ee.uh.edu Thu Jun 17 10:50:18 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Thu, 17 Jun 93 10:50:18 PDT Subject: Contempt of court Message-ID: <9306171750.AA02648@toad.com> Personal opinions: People should not be able to be forced by a subpoena duces tecum to provide incriminating documents. The fifth amendment protection against self- incrimination normally extends to personal papers. There are cases which show that corporate officers cannot avoid turning over corporate papers even if they incriminate themselves, but personal papers are provided much wider protection. People can be forced to produce handwriting samples, where the content of what is written is not significant but the physical writing will be analyzed; they can be forced to produce breath, blood or urine samples; they can be forced to stand in a police lineup, and to repeat words which a witness may have heard a criminal make (but the words do not carry significance); they may be forced to submit to psychiatric evaluation. But none of these involve giving testimony against themselves. Producing a personal diary or notes which provide incriminating testimony should be protected by the fifth amendment. By this reasoning, someone may be able to be forced to reveal an encryption key, since that is not testimony. But if the resulting documents, when decrypted, are personal and contain damaging, incriminating statements, they would not be usable in court. To introduce them in court against the wishes of the defendant would be a clear violation of his fifth amendment rights. By the same token, people are not obligated to keep records specifically to facilitate government investigation of any crime they may have committed. (They are required to keep normal records, such as those relating to the income tax.) It is perfectly permissible for people to destroy their personal records, notebooks, mail, in any way they wish, whether those records would be of use to law enforcement or not. (This is not true, of course, after receipt of a subpoena calling for those records.) "Digital flash paper" should be perfectly legal for all record keeping, whether or not those records would have contained evidence of a crime. From newsham at wiliki.eng.hawaii.edu Thu Jun 17 11:20:22 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Thu, 17 Jun 93 11:20:22 PDT Subject: fast des In-Reply-To: <9306171547.AA02951@mustang.ece.cmu.edu> Message-ID: <9306171820.AA03851@toad.com> > > If you were interested in cracking DES, I wonder if you couldn't just > build the hardware out of FPGAs. That way, you could make key loading > and the decrypted data test fast as well. > > - Jay > I tried this on the xilinx 3090 chip. The tools to handle palasm didnt seem to be designed to handle a job that size, I had to split up the file into 3 sub parts (S boxes, key scheduler and everything else). I never got it completed but judging by some of the output I got, it wouldnt have fit on the 3090, which is quite a big FPGA. The implementation is straight forward, but there is alot of juggling you have to do to put it on a 3090 since the S boxes are slightly bigger than the CLB's tables, and you end up wasting alot of space when you just need a bunch of xor gates (2 xor's per CLB, and you need alot of XORs). Implementation with standard cell technology would probably be very easy, and save alot of space too. (routing the thing is another problem too, since there are so many permutations, I am not sure if a near-full-capacity FPGA would be able to route all the permutations) Tim From m5 at vail.tivoli.com Thu Jun 17 09:21:26 1993 From: m5 at vail.tivoli.com (Mike McNally) Date: Thu, 17 Jun 93 11:21:26 CDT Subject: Contempt of court In-Reply-To: <930617153447_76630.3577_EHK50-1@CompuServe.COM> References: <930617153447_76630.3577_EHK50-1@CompuServe.COM> Message-ID: <9306171621.AA14350@vail.tivoli.com> Duncan Frissell writes: > I call it a network operating system designed to cope with local security > breaches. I am not required by law to keep business records in any > particular jurisdiction. I am not even required to have access to > everything in a business with which I am connected. Of course you're likely to be right; my Highly Esteemed legal opinion is worth about as much as the electrons transmitting it. > But a charge of Sedition is such a rare honor ... > Besides, if the system is From tcmay at netcom.com Thu Jun 17 12:00:26 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 17 Jun 93 12:00:26 PDT Subject: Weak stegosaurs In-Reply-To: <9306171745.AA05015@soda.berkeley.edu> Message-ID: <9306171900.AA27241@netcom3.netcom.com> Hal Finney writes: > Responding to Mike Diehl's ideas about weak steganography: (Speaking of > which, did anyone notice that there weren't any stegosaurs in Jurassic > Park? Just another sign of the government crackdown on crypto?) No, the stegosaurs were not in the Jurassic Era...they were in the *Cryptozoic* Era. At least according to my copy of PGP ("Pretty Good Paleontology"). -Tim (P.S. I wonder what kind of DNA they'll get from the "Nine Princes in Amber"?) -- .......................................................................... 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 bear at eagle.fsl.noaa.gov Thu Jun 17 12:27:59 1993 From: bear at eagle.fsl.noaa.gov (Bear Giles) Date: Thu, 17 Jun 93 12:27:59 PDT Subject: Weak steganography Message-ID: <9306171924.AA13544@eagle.fsl.noaa.gov> Eric Hollander writes: >Another problem is that encrypted files look different from executable >files. Encrypted files have a uniform histogram (that is, all 256 different >possible byte values are equally frequent), but exe files do not. The >appending of an encrypted file to an executable file will be very obvious. So write an encryption routine that wastes bandwidth but outputs executable code. You could even encapsulate it within procedures which randomly call one another, to make it look more like real code. (Your encrypted data would be limited to shuffling data between registers and operations within registers, e.g.: mov ax, bx add ax, cx mov bx, dx or ax, bx It's not a crime to write bad assembler code... yet. A nice piece of misdirection would be a homebrew compiler for some really bizarre language. A compiler which produces output remarkably like the output of your encryption program. If someone asks why you are only using a small subset of the instruction set, you shrug and claim that optimized code generation is on your "to-do" list. Bear Giles From mnemonic at eff.org Thu Jun 17 13:07:56 1993 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 17 Jun 93 13:07:56 PDT Subject: Contempt of court Message-ID: <199306172008.AA00361@eff.org> Forwarded message: From pmetzger at lehman.com Thu Jun 17 13:55:53 1993 From: pmetzger at lehman.com (Perry E. Metzger) Date: Thu, 17 Jun 93 13:55:53 PDT Subject: Contempt of court In-Reply-To: <199306172008.AA00361@eff.org> Message-ID: <9306172054.AA09055@snark.shearson.com> Mike Godwin says: [Lots of stuff that add up to "Gee, what fifth amendment"] I wonder when the last remaining clause of the Bill of Rights will be declared to be meaningless tripe. FDR destroyed the 9th and 10th amendments with his threats of court packing. PC is destroying the 1st amendment. The fourth and fifth amendments are nearly gone thanks to things like the war on drugs. Lots of people have been claiming the second amendment doesn't mean what it says, and the supreme court has refused to take a case since the Miller case in the 1930s. The court recently held that you can execute a person even if there is evidence that he's innocent without giving the evidence a hearing provided he's technically exhausted his right to appeal. It seems like its only a matter of time before other than stopping the government from quartering soldiers in your home except in time of war, there will be nothing more the courts will prevent. Fun, ain't it? Perry From axelrod at s106.es.llnl.gov Thu Jun 17 14:12:07 1993 From: axelrod at s106.es.llnl.gov (Mike Axelrod 422-0929) Date: Thu, 17 Jun 93 14:12:07 PDT Subject: Contempt of Court Message-ID: <9306172113.AA24029@s106.es.llnl.gov> If the key itself had embedded testimony that was incriminating, then it is possible one could invoke the 5th amendment to avoid disclosure of the key. But, I suppose a court could do an end run around that by giving limited use immunity for the incriminating content of the key. Comments? Mike. From jazz at hal.com Thu Jun 17 14:13:23 1993 From: jazz at hal.com (Jason Zions) Date: Thu, 17 Jun 93 14:13:23 PDT Subject: fast des Message-ID: <9306172113.AA10922@jazz.hal.com> >>Usually the limiting factor is examining the decrypted data >>for statistically significant patterns indicating that you have the >>correct key. > >If you know that your plaintext is 7-bit ASCII, then you can reject if you >see too many 8th bits set. [ ... ] Hint for implementors: don't allow such >easy bit correlations in your plaintext. Run your plaintext through compress first; remove the compress header; then encrypt. Compression will screw up character frequencies (and use all eight bits) enough to make automated detection of a successfully-broken encryption really darn hard. Especially if you keep changing compression technology each message. Jazz From smb at research.att.com Thu Jun 17 14:28:09 1993 From: smb at research.att.com (smb at research.att.com) Date: Thu, 17 Jun 93 14:28:09 PDT Subject: fast des Message-ID: <9306172128.AA10049@toad.com> The DEC gigabit/second DES chip was based on the FURY VSC15K gate array from Vitesse. It's a gallium arsenide device. The full paper is ``A High-speed DES Implementation for Network Applications'', by Hans Eberle, SRC Research Report 90, DEC Systems Research Center. Abstracts are (apparently) online in pub/DEC/srcabstracts.list, on gatekeeper.pa.dec.com. You can get hard-copy by sending email to src-report at src.dec.com. Oh yeah -- he gives the search time as 16 days, for about $1M in DES chips alone, without any support circuitry. The chips are estimated to cost $300 apiece. His chip is well-suited for DES-cracking because it has a separate key-loading port, so you can change the key each cycle without slowing down the pipeline. From anton at hydra.unm.edu Thu Jun 17 14:51:38 1993 From: anton at hydra.unm.edu (Stanton McCandlish) Date: Thu, 17 Jun 93 14:51:38 PDT Subject: "RSA sells out" hue and cry (fwd) In-Reply-To: <9306172009.AA16710@smds.com> Message-ID: <9306172150.AA01239@hydra.unm.edu> This is in reference to the material direct from Jim Bidzos of RSA that I have posted, re: the charges that NSA is selling out to the Clipper scheme by licensing NIST to use their "patented algorithms" Quoth FutureNerd Steve Witham, verily I saith unto thee: > > Draw your own conclusions. I sure will. > > What the hell kind of conclusions are you drawing? Will you cut the > sniffing and say what you mean? Sniping is tiresome. Sniping that > doesn't even make a whiff of sense is doubly so because it's > confusing. Pardon my pique but there's a *real* war on. RELAX, fnerd! I almost sent you my new "Dear flamer" form letter, but I guess this deserves an answer. Please don't yell at me like this. My cautious conclusion from this and other discussions with Jim directly (at least I presume it is he; as I said before I get suspicious when the head of the worlds largest cryptography corp. does not use his own signatory authentication software), is that 1) RSADSI/PKP cares only for its bottom line. People like Jim Bidzos may care about stopping Clipper, but that is largely irrelevant in a corp. It's like your brain deciding it doesn't want food. Your body will go on craving food if you like it or not. 2) DSI is more-or-less anti-clipper, because it will hurt their biz in the long term. It is, being a typical corp., driven more by immediate profit motive; thus it calls bullshit on the Gov't violating their "patent", and thus accepting the deal when the govt "capitulates". In typical corporate double think, it does not see the blindinly obvious conflict of interests here. The weasel factor is likely the rationalization that key escrow does not equal clipper, which is true, though as we all know, they two are intertwined like snakes in a basket. 3) there is no conspiracy of PKP/RSA with NIST/NSA. It's just a product of commercial short-sightedness and even outright stupidity and illogic. 4) regardless of this, this move on the part of RSA is likely to be detrimental to the cause, and is dangerous. As for your other points: A) I am "sniffing" and I said this is a "cautious" conclusion, because all the evidence is not in. B) sniping is USEFUL. Ask any revolutionary. This is not a pitched battle, it is a guerilla war, a propaganda war, & a political cold war. C) it makes plenty of sense. My intent was to present the facts and material I find (for which I actually expected some thanks, imagine that! Who else among you bothered to make the effort to contact Big Jim personally and get their side of the story?), and to encourage people to think about it and weigh the data and "draw your own conclusions". I do not Know All in this matter, and did not wish to try to force my view on the whole. Furthermore, I think you are upset with the messenger, rather than concentrating on the message. All I am doing is saying, "Here I got this. It made me think. Look at it and think about it too." D) Yes there's a war on. But I am not Rambo, I'm the USAF journalist who doesn't feel like getting shot thank you very much ;) Note this is being passed on to the appropriate list and groups, in case others need this clarification. -- Stanton McCandlish * Space Migration * Networking * ChaOrder * NO GOV'T. * anton at hydra.unm.edu * Intelligence Increase * Nano * Crypto * NO RELIGION * FidoNet: 1:301/2 * Life Extension * Ethics * VR * Now! * NO MORE LIES! * Noise in the Void BBS * +1-505-246-8515 (24hr, 1200-14400, v32bis, N-8-1) * From kqb at whscad1.att.com Thu Jun 17 15:16:40 1993 From: kqb at whscad1.att.com (kqb at whscad1.att.com) Date: Thu, 17 Jun 93 15:16:40 PDT Subject: Weak steganography Message-ID: <9306172216.AA11412@toad.com> Hal Finney said: > Another problem is that encrypted files look different from executable > files. Encrypted files have a uniform histogram (that is, all 256 different > possible byte values are equally frequent), but exe files do not. ... I am building a "steganosaurus" and eventually will need to solve a similar problem. (A "steganosaurus" applies a primitive steganographic technique to English text by using a thesaurus to generate enough word variation to encode a hidden message.) One of the weaknesses of this "steganosaurus" is that the resulting output has statistical differences from normal English text. For example, word frequency will be skewed. Worse, I have to assume that the eavesdropper knows my steganization algorithm and can "desteganize" any innocuous-looking text I produce. That "desteganized" text will show clearly the existence of a hidden, encrypted message because, as Hal pointed out, it has a uniform histogram. What I want is a program that will transform an encrypted file to a (slightly larger) file that mimics the distribution achieved by applying the "desteganization" algorithm to normal English text that does *not* contain any hidden message. The steganization algorithm then gets applied to this stealthy, mimic file, not directly to the encrypted hidden message. By the way, since we must assume that the eavesdropper knows all our algorithms but not our secret keys, this algorithm will require a *second* secret key in addition to the secret key used in the original encryption. I'm not ready to tackle that yet. Unless I hear otherwise, I'll assume that if anyone knows how to achieve this, they're not telling... Kevin Q. Brown INTERNET kqb at whscad1.att.com or kevin_q_brown at att.com PS: I found that a simple, semi-automatic algorithm can generate a public message only 5 to 10 times as long as the hidden message. Unfortunately, the public message from my simple algorithm is almost always a bizarre, disconnected sequence of rants, which, for most people, is not normal. That is why I am building my "steganosaurus". After that I will see if combining a natural language parser with transformational grammars can produce a less primitive, more efficient "trans-steganosaurus". From fnerd at smds.com Thu Jun 17 15:29:16 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Thu, 17 Jun 93 15:29:16 PDT Subject: Stegosaurs Message-ID: <9306172126.AA17087@smds.com> Hal Finney <74076.1041 at compuserve.com> sez > (...did anyone notice that there weren't any stegosaurs in Jurassic > Park? Just another sign of the government crackdown on crypto?) No, silly! They were hiding behind treetrunks and disguising themselves as tourguides! Don't you know the first thing about stegosaurs? -fnerd quote me time to recycle some elephant jokes From tcmay at netcom.com Thu Jun 17 15:48:07 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 17 Jun 93 15:48:07 PDT Subject: Contempt of court In-Reply-To: <9306172054.AA09055@snark.shearson.com> Message-ID: <9306172248.AA19024@netcom3.netcom.com> Perry Metzger writes: ... > technically exhausted his right to appeal. It seems like its only a > matter of time before other than stopping the government from > quartering soldiers in your home except in time of war, there will be > nothing more the courts will prevent. > > Fun, ain't it? Ah, but this happens all the time! For example, at a recent dinner for Dave Nolan, founder of the Libertarian Party, a middle-aged Santa Cruz couple told us the story of how police/DEA/SWAT/BATF/not sure which "took over" all the houses on their block to wait for a suspected drug dealer to come out of his house. By "take over" I mean the middle-aged couple was awakened by knocks on the door at dawn, told they had 5 minutes to pack a few things, and then told to get out of the house, that the SWAT team was using their house as one of their command posts. Several other houses were as well. Around mid-afternoon, the blissfully-oblivious suspect wandered out into into driveway and was immediately surrounded. Now this may not be "quartering of troops," technically, in that they didn't sleep over, eat the food (so far as I know), etc., but I sure would call it something very similar. And what do you think would happen to me if I answered the door with my Heckler and Koch submachinegun, as I sometimes do (perfectly legal, since it's on my property...so long as I don't "brandish" it)? My guess is the pigs would shoot first. With the Clinton Clipper rolling along, with the New World Order looking like a liberal left police state, it's time more than ever for the long-discussed "Cypherpunks Shooting Club." Time for us to fight back. "Kill the code grabbers." -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 MAILER-DAEMON Thu Jun 17 13:05:38 1993 From: MAILER-DAEMON (Mail Delivery Subsystem) Date: Thu, 17 Jun 1993 16:05:38 -0400 Subject: Returned mail: User unknown Message-ID: <199306172005.AA00336@eff.org> ----- Transcript of session follows ----- While talking to RoseBud.EE.UH.EDU: >>> RCPT To: <<< 550 ... User unknown 550 nobody at rosebud.ee.uh.edu... User unknown ----- Unsent message follows ----- Received: by eff.org id AA00334 (5.65c/IDA-1.5/ident for nobody at rosebud.ee.uh.edu); Thu, 17 Jun 1993 16:05:38 -0400 (ident-sender: mnemonic at eff.org) From: Mike Godwin Message-Id: <199306172005.AA00334 at eff.org> Subject: Re: Contempt of court To: nobody at rosebud.ee.uh.edu Date: Thu, 17 Jun 1993 16:05:37 -0400 (EDT) In-Reply-To: <9306171750.AA02648 at toad.com> from "nobody at rosebud.ee.uh.edu" at Jun 17, 93 12:52:05 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1440 nobody writes: > People should not be able to be forced by a subpoena duces tecum to provide > incriminating documents. The fifth amendment protection against self- > incrimination normally extends to personal papers. There are cases > which show that corporate officers cannot avoid turning over corporate > papers even if they incriminate themselves, but personal papers are > provided much wider protection. This is true, but it's not precisely the issue with regard to encryption keys. > But none of these involve giving testimony against themselves. Producing > a personal diary or notes which provide incriminating testimony should > be protected by the fifth amendment. Providing the key would not be seen as legally identical to providing the unencrypted document. > By this reasoning, someone may be able to be forced to reveal an encryption > key, since that is not testimony. But if the resulting documents, when > decrypted, are personal and contain damaging, incriminating statements, > they would not be usable in court. To introduce them in court against > the wishes of the defendant would be a clear violation of his fifth > amendment rights. Unfortunately, this has not been Fifth Amendment law for a long time. If a search and seizure takes place at your house, and the investigating agents find your diary, they can use it against you. If the diary is in code, they can attempt to decode it. --Mike From fergp at sytex.com Thu Jun 17 17:41:14 1993 From: fergp at sytex.com (Paul Ferguson) Date: Thu, 17 Jun 93 17:41:14 PDT Subject: Clipper fact Message-ID: On Wed, 16 Jun 93 22:41:33 PDT, Marc Briceno wrote - > I am representing the anti-clipper side in an ongoing debate in > the "Wired " conference on OneNet. The governmental lemmings > question the existence of the "Law Enforcement Exploitation > Field" and want citations. Would the person who posted the > hard facts about Clipper please send me all the info? > Thanks in advance, I've collected about 700 kb worth of information regarding Clipper/Capstone, but this post from Dorothy Denning should be exactly what you are looking for. It was originally posted to sci.crypt and reposted to cypherpunks by Tim May. 8<------- Cut Here -------------------- From hughes at soda.berkeley.edu Thu Jun 17 18:06:27 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 17 Jun 93 18:06:27 PDT Subject: fast des In-Reply-To: <9306172113.AA10922@jazz.hal.com> Message-ID: <9306180102.AA26143@soda.berkeley.edu> > Compression will screw up character frequencies [...] enough to make >automated detection of a successfully-broken encryption really darn >hard. The question is just how hard is "really darn hard"? Compressed English text has characteristic patterns just as plain English does. The salient difference is that these patterns take longer to emerge at the same confidence level. The compressibility limit is a limit not usually reached; the difference between that limit and the actual compressed text will be non-zero. This difference manifests itself in patterns in the compressed text. Some estimates of this size are necessary in order that the designer have an assurance that automatic recognition of decrypted text is difficult. These concerns are largely obviated by using ciphers with longer key lengths, of course. Eric From wcs at anchor.ho.att.com Thu Jun 17 19:40:40 1993 From: wcs at anchor.ho.att.com (Bill_StewartHOY0021305) Date: Thu, 17 Jun 93 19:40:40 PDT Subject: fast des Message-ID: <9306180042.AA03435@anchor.ho.att.com> Steve Bellovin refers to Hans Eberle's paper on a GAs-based 1Gb/s DES chip, which is available on gatekeeper.dec.com under the SRC directory. The search time of 16 days for $1M, aka 1 day for $30M (incl. support chips), is fairly similar to Peter Wayner's Content-Addressible-Memory approach, which would cost an estimated $30M for a 1 day search. (Average search time is about half as long as exhaustive searches.) To put this in a cost-per-solution context, if you amortize over 5 years, that's about 4000 solutions, so that's a bit under $10K per solution. It's more expensive than David Sternlight's $25/solution guess, but it's interestingly small - certainly worthwhile for occasional national security applications, or robbing electronic funds transfer networks, (at least for the $1M slower version), and it's in the ballpark of the rental rate for Congressmen :-) (the Abscam folks paid $50K to Senator Harrison Williams for some light work...) Since Skipjack uses an 80-bit key, the NSA or other rich organizations with access to it ought to be able to get similar performance in 24-48 years, assuming speed doubling continues at its 1-2 year rate. We'd be better off with something with a longer key, such as triple-DES. Bill Stewart From ld231782 at longs.lance.colostate.edu Thu Jun 17 20:28:26 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Thu, 17 Jun 93 20:28:26 PDT Subject: Blasting Bidzos Blather Message-ID: <9306180328.AA15661@longs.lance.colostate.edu> The following message is FOR CYPHERPUNKS ONLY. I specifically *prohibit* further distribution past the mailing list! Please do not betray my trust! [Bidzos] >I'm genuinely > confused, as I believe the situation is as simple as I put it to you. > Our claims of patent infringement by DSS, made over the last 18 > months, were well-known and publicized. NIST has capitulated. Seems > pretty straightforward to me. The more I read from Bidzos, the less I believe he has any overall control or even awareness of the company, or is purposely duplicitous. His vague and weak defenses I find personally intelligence-insulting. DSS seemed to defy the face of all public input into the standard, which opposed the NIST algorithms (`handed down' in a dictatorial and authoritarian manner, sound familiar?) in favor of RSA. How is it that Bidzos makes no reference to this? Apologists for DSS such as Denning do so on two major grounds: 1) it is part of the larger plan involving Clipper, therefore lack of duality in encryption and authentication features (an implicit characteristic of RSA) is not a problem 2) the security is `no weaker' (cunningly disguised as to appear to say `better') than RSA. Both are noxiously misleading arguments in themselves, but are also decoys (like key escrow agencies and procedures) to the critical issues at stake. The critical point is that even the *appearance* of a `fair and impartial' standards making process was totally defied, to the point of suggesting a complete clandestine backroom collusion! (hm, sound familiar?) But gosh, I wonder how many people would have advocated RSA back then when they could predict the future: that NIST would not only embrace PKP but would award them a complete monopoly on signature standards. Somehow proponents of this new NSA-Clipper-Capstone obscenity are now pointing back to history and saying that the main objections to DSS standards were *technical* (strength of the algorithm) and *legal* (PKP patenting) and that they have been wholly ameliorated by improvements (in key size) and recent events (PKP support). This is historical revisionism at its worst! From my point of view, critical main objections were on the warped process that permitted an unpopular (and perhaps even subversive) standard be adopted! This revisionism definitely suggests something deeper and `ulterior' is going on---that a comprehensive NSA-PKP alliance is in place? > BTW, on Clipper, ATT, Motorola, IBM could have done Clipper without > ever talking to us. Contrary to popular belief, we don't dictate > terms to licensees. First, I find it absolutely ridiculous for an informed agent of PKP, and for that person to coincidentally be called the *president*, to claim that `we don't dictate terms to licensees'. This is only true in the sense that if the licensee does not agree to the terms put down by PKP, they don't get the license! Second, I would like to see PKP contracts. There are probably more clauses than a bad run-on sentence. I'll go out on a limb and wager that PKP *does* limit the use of RSA in the company's products, and that the licenses are fairly specific. It seems rather inconceivable to me that any such corporate agreement that could be so simplistically summarized as `PKP gives rights to company [x] to use RSA in *any* of their products as long as they pay [y] royalties'. The agreement is very likely product-specific and implementation-limiting. Perhaps Mr. Bidzos or representatives of companies involved would be willing to forward copies of these agreements for our consideration of Mr. Bidzos' claims, assuming they are not `classified'... Third, regardless of presence of product-specific limitations in the licenses, and even if PKP has sold licenses to companies that somehow permit them the latitude to include RSA technology in their Clipper implementations, PKP can certainly take the future stance that they will prohibit that use in future corporate contracts! If Mr. Bidzos really thinks that Clipper is `ill-conceived, ill-timed, and undesirable' perhaps he should figure out how to keep his company from supporting, nay, *promoting* and *profiting* from it. Let's look again at the announcement: >PKP will also grant a license to practice key management, at no >additional fee, for the integrated circuits which will implement >both the DSA and the anticipated Federal Information Processing >Standard for the "key escrow" system announced by President Clinton >on April 16, 1993. `at no additional fee'? What does that mean, `for free'? This apparently means Mycotronx, despite being a private company, does not need to license (read: pay for) the RSA patents on the critical key-exchange function for use in Capstone for *any* implementations (public or private), nor does any other company NSA decides to induct into its privileged enclave. Hm, I wonder how RSA's other `customers' feel about that? And why would PKP voluntarily give up this potentially valuable revenue source? Clipper implementations could be *extremely* lucrative for PKP. That they don't license them specifically, and in fact voluntarily give up the perogative to do so, suggests that they gave up something greater in return for them. Namely, the award of an official U.S. government-endorsed monopoly on DSS and arguably all valuable cryptographic techniques. By the way, let's look Mr. Bidzos' quote on Clipper. Clipper is `ill-timed'? What does this suggest, that a NSA-PKP partnership would be better served if it came out sooner or later? Clipper is `ill-conceived and undesirable'? For who? Was it that PKP perhaps didn't hear about it soon enough to rob all the tasty new cryptographic algorithm patents surrounding it, like it did with the Schnorr patent? The licensing notice (which was probably reviewed and approved by PKP representatives) refers to Clipper as `an anticipated Federal Information Processing Standard?' How, Mr. Bidzos, can this new revelation possibly be construed to indicate that Clipper `will go away'? Yes, I suppose Mr. Bellovin was right. The omnipresent underlying message here is that nothing is unethical if PKP profits from it. I advise cypherpunks not to take Mr. Bidzos' comments literally. They are, however, interesting from the perspective of the study of the speech of either an uninformed figurehead or a capitalist (or even nationalist) co-conspirator. P.S. all cypherpunks `for' an alliance with PKP, please raise your hand. I personally find the image of `lumbering but ultimately benevolent corporation' too incredible to hold in the face of recent events, and am now actually quite embarrassed to have advocated some `good faith' proposals involving the company which look naively misguided in hindsight. PKP is not going to go away when a few of its patents expire. To the contrary, it appears to be clutching everything within reach to ensure its eternal domination in the commercial cryptographic field. (sound familiar? a PKP-NSA alliance makes perfect sense.) From zane at genesis.mcs.com Thu Jun 17 21:04:36 1993 From: zane at genesis.mcs.com (Sameer) Date: Thu, 17 Jun 93 21:04:36 PDT Subject: Contempt of court In-Reply-To: <9306172054.AA09055@snark.shearson.com> Message-ID: In message <9306172054.AA09055 at snark.shearson.com>, "Perry E. Metzger" writes: > technically exhausted his right to appeal. It seems like its only a > matter of time before other than stopping the government from > quartering soldiers in your home except in time of war, there will be > nothing more the courts will prevent. > I read somewhere on the net a *very* interesting interpretation of the 3rd amendment, which cypherpunks might find interesting. It was claimed that in colonial times, the British authorities quartered troops in people's homes as a form of surveillance. E.g. Tom Jefferson is suspected of conspiring with friends to communicate privately :-), thus the local British military leader learns of this suspicion and quarters troops in Tom's home. Under this interpretation, it was claimed that the 3rd amendment provides protection from government surveillance. I think it's stretching things a bit, but a very interesting way to look at it. -- | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/ From TO1SITTLER at APSICC.APS.EDU Thu Jun 17 21:18:34 1993 From: TO1SITTLER at APSICC.APS.EDU (Kragen Sittler) Date: Thu, 17 Jun 93 21:18:34 PDT Subject: xor w/prbs Message-ID: <930617221448.c97@APSICC.APS.EDU> Some MORON wrote an article in Computer Shopper, about doing a one-time pad with a PRBS... in fact, he even challenged any cryptographers to break it. (He used a 32-bit seed for the PRBS.) He also included a number of fallacies in the article, among them that you change your algorithm when you think the enemy knows what it is, but you change your keys regularly even when you don't have any basis to think so. How *do* you break this cypher? He is generating a lot of random numbers between 0 and 255, and xor'ing each successive one with the next byte of plain- text. I know that this is a trivial cypher to break, according to PRZ at least, but how do you do it? This arrogant moron with pretensions to cryptographic knowledge needs to be corrected. (Some might say the above epithet applies to me too, to which I reply: I don't pretend to know crypto. I just read cypherpunks.) He is: David Stafford, care of Computer Shopper ONe Park Avenue New York, NY 10016 This kind of misinformation is dangerous to the public at large. The article is on page 558 af the July, 1993 Computer Shopper. It uses a random number generator, (now that I look, it's not a PRBS) from the June, 1993, Computer Shopper, by the same author. The random number generator used is like this: It uses a global variable called RandomSeed, and each time thru the random function, RandomSeed, a 32-bit long, is multiplied by 0x015a4e35, and incremented; and then the new Randomseed, modulo the largest desired return value, is returned. (Actually, mod the largest desired value +1.) a code fragment: #define MULTIPLIER 0x015a4e35L #define INCREMENT 1 long RandomSeed; int GetRandomNumber(int Range) { RandomSeed = MULTIPLIER * RandomSeed + INCREMENT; return(RandomSeed % Range); } So how do you crack this cipher without trying all the keys, guys? Kragen From bear at eagle.fsl.noaa.gov Thu Jun 17 22:37:47 1993 From: bear at eagle.fsl.noaa.gov (Bear Giles) Date: Thu, 17 Jun 93 22:37:47 PDT Subject: xor w/prbs Message-ID: <9306180534.AA01952@eagle.fsl.noaa.gov> >How *do* you break this cypher? He is generating a lot of random numbers >between 0 and 255, and xor'ing each successive one with the next byte of plain- >text. I know that this is a trivial cypher to break, according to PRZ at >least, but how do you do it? In this case, since the modulus is a small power of 2, you can do exhaustive search. There is _one_ sequence of 256 distinct values. Still want to know how long it will take to crack his ciphertext? >#define MULTIPLIER 0x015a4e35L >#define INCREMENT 1 > >long RandomSeed; > >int GetRandomNumber(int Range) > { > RandomSeed = MULTIPLIER * RandomSeed + INCREMENT; > return(RandomSeed % Range); > } > >So how do you crack this cipher without trying all the keys, guys? Since max_integer / gcd (range, max_integer) > range you can move the modulus operation around without worrying about weird effects from the finite word size. This is because the closed form of the loop is: seed[k] = (seed[0] * mult^k + incr * sum (j = 0 to k-1) of mult^j) % range which is equal to seed[k] = (seed[0] % range) * (mult % range)^k + (incr % range) * sum (j = 0 to k-1) of (mult % range)^j and the modulus operation with a power-of-2 range simply keeps the last n bits. But, this also means there are effectively only "range" possible values for the initial seed. Even if you make the increment and multiplier part of the key, they must (both?) be odd so you only have 22 bits of key. Of course at this point you can simply use the fact that this "one time pad" is actually a Vigenere cipher with 256 columns -- easy to crack if you have some insight into the nature of the plaintext (e.g., English text). For instance, 10-15 small documents (40 lines) encrypted with the same key is enough to crack it even if the multiplier and increment are unknown but constant. Bear Giles From nobody at eli-remailer Thu Jun 17 23:50:08 1993 From: nobody at eli-remailer (nobody at eli-remailer) Date: Thu, 17 Jun 93 23:50:08 PDT Subject: OTP dual decryption Message-ID: <9306180650.AA26990@toad.com> -----BEGIN PGP SIGNED MESSAGE----- Using a one-time pad for dual decryption might work like this. I have a file, D (for Dangerous), which I want to conceal. I construct a random file of the same length, K (for Key), which will be my "encryption key". I xor K and D to produce E (for Encrypted), the encrypted file. I delete D and hide K somewhere. Now, in case an intruder steals E and coerces a decryption out of me, I prepare S (for Safe), a file containing some safe plaintext. I xor S and E to produce F (for Fake), the fake key file I will be able to present. I destroy S and hide F somewhere, but perhaps not as securely as I hid K. Now, if the intruder comes, he finds E, the encrypted file. He demands the key, and I explain that the file was encrypted with a one-time pad, and here is the key, and I provide him F. He xor's F and E to find S, the safe plaintext, and I am protected. This is all well and fine, but it depends on successfully hiding K, the actual key file. But if you can successfully hide files, it seems to me that you might as well have just hidden D, the dangerous file, in the first place, in whatever hiding place you were going to use for K. Then substitute S, the safe file, for D. This is just the old idea of having two sets of books for a crooked business, one innocent and public and one incriminating but hidden. So I'm not sure the one-time pad idea really helps much since if you can meet the requirements to use it you might as well just hide your data the old-fashioned way. Are there any advantages that I'm overlooking? Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLCEucqgTA69YIUw3AQFBlAP/ZHeOKs71H2d0HD2vLwupRB/TwzuEy7dD iE91swoYo8FK5a66DAi8f2kmDIqoiPai+jieI/506zWFuHJRiCW7PLs6v8ga4Aj6 WglBJ1ksOlY74X6qrlykw3kXMjX6x8t7lbp+e6R7Fy67n6gUSGaRozyniv3JusrY c7wXxxh9rvs= =AAV7 -----END PGP SIGNATURE----- From nobody at alumni.cco.caltech.edu Thu Jun 17 23:50:08 1993 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Thu, 17 Jun 93 23:50:08 PDT Subject: Computer Shopper encryption Message-ID: <9306180648.AA04035@alumni.cco.caltech.edu> If Kragen's RNG from Computer Shopper is called repeatedly with range=256, so that the resulting values are in the range 0-255 for xor'ing, it is very weak. That will mean that the RNG will repeat with period of at most 256, and so the only question is which of the 256 possible starting points was used. In other words you only need to do 256 trial decryptions (just try seeds from 0-255) and you've got it. Using the low-order bits of an LCM RNG like this one is a bad idea. You should use the high order bits, or use a range which is not a power of 2 so you end up using all the bits. Even then LCM RNG's aren't crypto- graphically strong, although from what I have seen the techniques of breaking them are what a layman would call complicated. Compared to breaking, say, DES, though, they are no doubt trivial. Hal Finney 74076.1041 at compuserve.com From remail at tamsun.tamu.edu Fri Jun 18 00:12:47 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Fri, 18 Jun 93 00:12:47 PDT Subject: Shorter PGP keys Message-ID: <9306180712.AA27809@tamsun.tamu.edu> I was thinking of trying to come up with a short form of my PGP key. Very few people put their PGP keys into their .sig's any more because they are so lengthy. Here is my key, 1024 bits, as it would normally appear: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK----- This has a couple of signatures on it and is pretty long. I stripped the signatures, figuring that people can get them from a key server, and that helped quite a bit. Also, the "Version: 2.x" line is not currently used, and if you eliminate it you don't need the blank line after it. Also, the last line is a checksum for the key and in today's internet environment you don't have to worry about noise that much. Stripping all these gives: -----BEGIN PGP PUBLIC KEY BLOCK----- mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPg== -----END PGP PUBLIC KEY BLOCK----- This is pretty compact and wouldn't be bad in a .sig. We've gone from 12 to 6 lines. I wish there were a mode in which PGP would scan a file looking not for "-----BEGIN PGP" but rather for lines which are exactly 64 lines long and contain just the RFC1113 (or whatever it's called now) character set. I realize it would get fooled by PEM but maybe the user would only run it if he knew it was a PGP file. Then you could reduce the key to four lines. If you were willing to use a 512 bit key, good enough for casual use, you could get it down to 3 lines. This is probably an appropriate level of privacy for people on multi-user workstations (i.e. as much privacy as they can expect). Hal Finney -- 74076.1041 at compuserve.com -- Stripped PGP key: mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPg== From gg at well.sf.ca.us Fri Jun 18 02:25:06 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 18 Jun 93 02:25:06 PDT Subject: Contempt of court Message-ID: <93Jun18.022436pdt.14012-3@well.sf.ca.us> One-time pads for coerced confessions: Consider that the cyphertext of an OTP could come from *any* combination of plaintext and keystream. Okay, now you have in hand your cyphertext of an original file having to do with your lawsuit against the govt. Take that cyphertext, and get another file of equal or longer length which is completely innocuous, for instance some mild-sounding diary entries or some such. Now XOR these together, and what pops out is the *keystream* which *would have been used for encyphering the innocuous plaintext into the cyphertext you have there. Okay, now you have five files: 1) your original plaintext re your lawsuit against the govt. 2) the keystream which converted that into the cyphertext below. 3) the cyphertext. 4) the innocuous text file for instance edited journal entries. 5) the "keystream" which resulted from XORing (3) and (4), which can be claimed to be the keystream which was used to encypher (4) into (3). Okay, now Big Brother comes to get you and coerce you to decypher your file, but you don't want your attorney-client confidentiality violated, so you hand over items (3) and (5), and when Big Bro "decrypts" (3), out pops (4) thereby proving that you aren't the dastardly subversive who is trying to sue the govt...! "Dear diary..." -gg From gg at well.sf.ca.us Fri Jun 18 02:33:53 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 18 Jun 93 02:33:53 PDT Subject: "RSA sells out" hue and cry (fwd) Message-ID: <93Jun18.023323pdt.14012-2@well.sf.ca.us> I'm not so sure that all this Bidzos Biz is as evil as it may sound. Consider the management have an obligation to the stockholders to make money. Now here is a huge market. Do they turn it down on the basis of political rectitude...? Are we seriously expecting that Bidzos will refrain from tapping into this market, and refrain from charging a cent for an RSA-PGP thing...? Oh, okay, so he's supposed to go into poverty to prove his ethics. Oh, I see. Gee whiz, I thought I was the most socialistic of anyone on this list. -gg From gg at well.sf.ca.us Fri Jun 18 02:45:42 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 18 Jun 93 02:45:42 PDT Subject: Blasting Bidzos Blather Message-ID: <93Jun18.024325pdt.13995-3@well.sf.ca.us> Oh, here goes another Big Bad Corporation abusing our rights...! Well, are there any Libertarians out there who will please speak up for the right of Bidzos & co to earn a legal profit any way they see fit...? Or am I, the token leftist in the crowd, going to stick my neck out solo on this one...? Pardon my rhetoric, but I find it truly amazing how the much extolled rights of private property can suddenly become a non-issue when you consider you've found a bigger issue. Some of us feel that way about ecology. -gg From gg at well.sf.ca.us Fri Jun 18 02:46:02 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 18 Jun 93 02:46:02 PDT Subject: OTP dual decryption Message-ID: <93Jun18.024542pdt.13995-1@well.sf.ca.us> Yeah, the advantage is, if they think they've found it, they might just stop looking much further. It's a chance that might save your ass. -gg From dmandl at lehman.com Fri Jun 18 05:51:38 1993 From: dmandl at lehman.com (David Mandl) Date: Fri, 18 Jun 93 05:51:38 PDT Subject: "RSA sells out" hue and cry (fwd) Message-ID: <9306181250.AA10789@disvnm2.shearson.com> > From: "George A. Gleason" > > I'm not so sure that all this Bidzos Biz is as evil as it may sound. > Consider the management have an obligation to the stockholders to make > money. Now here is a huge market. Do they turn it down on the basis of > political rectitude...? I don't run my life based on a spreadsheet. There are plenty of very profitable things I could do that I don't because I think they're scummy. The makers of napalm didn't take "political rectitude" into account either; nor did those bastards (Dow Corning?) who knew the truth about breast implants but hid it to protect their bottom line. Sorry, but I find this attitude extremely disturbing. > Are we seriously expecting that Bidzos will refrain from tapping into this > market, and refrain from charging a cent for an RSA-PGP thing...? Oh, okay, > so he's supposed to go into poverty to prove his ethics. Oh, I see. Gee > whiz, I thought I was the most socialistic of anyone on this list. > > -gg I'm not expecting anything of the kind. I'm not a capitalist, so it's not my job to work out these contradictions. --Dave. From phred at well.sf.ca.us Fri Jun 18 06:11:07 1993 From: phred at well.sf.ca.us (Fred Heutte) Date: Fri, 18 Jun 93 06:11:07 PDT Subject: Blasting Bidzos Blather Message-ID: <93Jun18.061041pdt.13937-1@well.sf.ca.us> > PKP is not going to go away when a few of its patents expire. Right. Contracts and licensing arrangements can last much longer than patents. That's why it's so important to see the exact details of this latest deal and find out why someone in the federal bureaucracy was greasing the procurement skids. From kinney at spot.Colorado.EDU Fri Jun 18 06:13:59 1993 From: kinney at spot.Colorado.EDU (W. Kinney) Date: Fri, 18 Jun 93 06:13:59 PDT Subject: Blasting Bidzos Blather In-Reply-To: <93Jun18.024325pdt.13995-3@well.sf.ca.us> Message-ID: <199306181313.AA13845@spot.Colorado.EDU> > Oh, here goes another Big Bad Corporation abusing our rights...! Well, are > there any Libertarians out there who will please speak up for the right of > Bidzos & co to earn a legal profit any way they see fit...? Or am I, the > token leftist in the crowd, going to stick my neck out solo on this one...? Nah. You ain't alone. Why shouldn't Bidzos allow NIST a license? Seems perfectly reasonable to me. Bidzos appears to see this as unrelated to any larger policy question involving Clipper, and I agree. -- Will From smb at research.att.com Fri Jun 18 06:26:06 1993 From: smb at research.att.com (smb at research.att.com) Date: Fri, 18 Jun 93 06:26:06 PDT Subject: RRe: Blasting Bidzos Blather Message-ID: <9306181326.AA08720@toad.com> > > PKP is not going to go away when a few of its patents expire. > Right. Contracts and licensing arrangements can last much longer > than patents. > That's why it's so important to see the exact details of this latest > deal and find out why someone in the federal bureaucracy was greasing > the procurement skids. I repeat -- NIST had no choice, because PKP held all the patent cards. Even if you don't believe PKP's claim to all of public-key cryptography, both the Diffie-Hellman and Schnorr patents would most likely be infringed by DSA. You can argue with the specifics of the deal -- and with what NIST gave away in order to get the Clipper exemption through -- but they had to reach some settlement. Btw -- the deal is *not* final; the announcement is just the start of a 60-day comment period. --Steve Bellovin From phred at well.sf.ca.us Fri Jun 18 06:41:16 1993 From: phred at well.sf.ca.us (Fred Heutte) Date: Fri, 18 Jun 93 06:41:16 PDT Subject: RRe: Blasting Bidzos Blather Message-ID: <93Jun18.064055pdt.13949-2@well.sf.ca.us> I beg to differ. I know about federal procurement regs a little, having been employed by a federal contractor for a decade and being one my own personal self now. They greased this process bigtime, and it has the ugly smell of politics all over it. From 76630.3577 at CompuServe.COM Fri Jun 18 07:50:08 1993 From: 76630.3577 at CompuServe.COM (Duncan Frissell) Date: Fri, 18 Jun 93 07:50:08 PDT Subject: Contempt of court Message-ID: <930618143143_76630.3577_EHK21-1@CompuServe.COM> ("Perry E. Metzger") >>>It seems like its only a matter of time before other than >>>stopping the government from quartering soldiers in your home >>>except in time of war, there will be nothing more the courts >>>will prevent. That's the answer to the question: "The US Government violates 9 of the 10 amendments of the Bill of Rights every second of every day. What is the one Amendment of the 10 that they hold inviolate?" The Third: 3rd Amendment No soldier shall, in time of peace, be quartered in any house, without the consent of the owner; nor in time of war, but in a manner to be prescribed by law. Say, maybe that's an argument against the Clipper Chip! Aren't the NSA types sort of soldiers who want to be quartered in our telephones at our expense? Duncan Frissell Who possesses the worlds longest list of flaky legal arguments which will be an enormous source of entertainment to a federal judge some day. "Did you know that Federal Reserve Notes are not money?" ******************************************************************** * DUNCAN FRISSELL Attorney at Law, Writer, and Privacy * * CIS 76630,3577 Consultant since the Nixon * * Internet: Administration * * 76630.3577 at compuserve.com * * or frissell at panix.com * * Easylink 62853962 * * Attmail !dfrissell * * TLX: 402231 FRISSELL NYK * * * * Privacy Checkup still only $29.95. Get yours today to * * find out how to dodge federal child registration. * * * * "Register Communists Not Kids. Fight SB 732 & 733 for * * national computer registration and tracking of every * * child in America." * * * ******************************************************************** From fnerd at smds.com Fri Jun 18 08:14:48 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Fri, 18 Jun 93 08:14:48 PDT Subject: My recent flame at Stanton Message-ID: <9306181507.AA21082@smds.com> Stanton McCandlish recently quoted a rant of mine directed at him. I really thought directed it to him literally--that I mailed it to his address, not the list's. Stanton, I didn't mean to flame you in public. I apologize. This is the second time this has happened this week. I'm starting to think that when I created this "fnerd" mail account I accidentally created an alter ego--my evil twin who posts personal insults to mailing lists... I will try to be triply, not just doubly sure of what I'm doing and put lots of warnings on any such personal grouch mail: "I DIDN'T POST THIS; BETWEEN YOU AND ME; PLEASE DON'T QUOTE ME," etc. in control now--SEIG HEIL!--down! down!... --Steve Witham (aka fnerd) quote me, this WAS posted From mnemonic at eff.org Fri Jun 18 08:22:17 1993 From: mnemonic at eff.org (Mike Godwin) Date: Fri, 18 Jun 93 08:22:17 PDT Subject: Contempt of court In-Reply-To: Message-ID: <199306181522.AA06530@eff.org> Sameer, the roots of the Third Amendment are not in surveillance, but in the English Crown's desire to minimize the costs of maintaining troops abroad. --Mike > In message <9306172054.AA09055 at snark.shearson.com>, "Perry E. Metzger" writes: > > technically exhausted his right to appeal. It seems like its only a > > matter of time before other than stopping the government from > > quartering soldiers in your home except in time of war, there will be > > nothing more the courts will prevent. > > > I read somewhere on the net a *very* interesting interpretation of > the 3rd amendment, which cypherpunks might find interesting. > It was claimed that in colonial times, the British authorities > quartered troops in people's homes as a form of surveillance. E.g. Tom > Jefferson is suspected of conspiring with friends to communicate > privately :-), thus the local British military leader learns of this > suspicion and quarters troops in Tom's home. > Under this interpretation, it was claimed that the 3rd amendment > provides protection from government surveillance. > > I think it's stretching things a bit, but a very interesting way > to look at it. > > -- > | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | > | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | > | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ > \_______________________/ \______________________________________________/ > From hughes at soda.berkeley.edu Fri Jun 18 08:44:38 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 18 Jun 93 08:44:38 PDT Subject: fast des In-Reply-To: <9306180042.AA03435@anchor.ho.att.com> Message-ID: <9306181540.AA22168@soda.berkeley.edu> >To put this in a cost-per-solution context, if you amortize over 5 years, >that's about 4000 solutions, so that's a bit under $10K per solution. Here are a few assumptions that lower this estimate for the NSA. -- The NSA has it's own fab and design facilities. If you assume you want a few dozen or hundred DES cracking boxes, you can afford a fair bit of money on design; the design cost per chip drops. The more of these you have, the lower the cost per solution. -- The amortization period is longer than 5 years. From what I have heard, the NSA just keeps running most every machine it owns. -- The possibility of a trap door which gives hints about exhaustive search should not be ruled out. Suppose, for example, that all combinations of 16 bits exhibited flat distribution as 16-grams, but that certain combinations of 22 bits did not. Just to find these correlations might be an infeasible problem, but to exploit them would not be. Drop your cost estimates by 2^6 in the above example if true. -- There will be different machines designed for attacks on different types of intercepts. Known plaintext, probable plaintext, known ASCII, etc. The recognition circuitry on each of these is different and custom design would reduce silicon costs significantly. -- If you use micropipelines, you can keep the encryption circuitry constantly full, as opposed to putting in a new value after the old one pops out. If this technique is not already being used, divide cost by 16, the number of rounds of DES. -- One can design circuitry to test multiple ciphertexts on the same key at some savings in chip cost. Not useful for encryption, but useful for cracking. Call this a factor of 1.5 to 2. -- Wafer scale integration could yield some savings in die cost and packaging. Eric From huntting at glarp.com Fri Jun 18 09:30:04 1993 From: huntting at glarp.com (Brad Huntting) Date: Fri, 18 Jun 93 09:30:04 PDT Subject: fast des In-Reply-To: <9306172113.AA10922@jazz.hal.com> Message-ID: <199306181629.AA08794@misc.glarp.com> > Run your plaintext through compress first; remove the compress > header; then encrypt. Compression will screw up character frequencies > (and use all eight bits) enough to make automated detection of a > successfully-broken encryption really darn hard. Especially if you > keep changing compression technology each message. Most encryption scheams use cypher block chaining or some other mechanism where a change in one block will affect every block to come after it, no? Given this, would inserting a block of random data at the begining of the datastream help? brad From tcmay at netcom.com Fri Jun 18 09:53:52 1993 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 18 Jun 93 09:53:52 PDT Subject: Blasting Bidzos Blather In-Reply-To: <93Jun18.024325pdt.13995-3@well.sf.ca.us> Message-ID: <9306181654.AA10641@netcom3.netcom.com> George Gleason writes: > Oh, here goes another Big Bad Corporation abusing our rights...! Well, are > there any Libertarians out there who will please speak up for the right of > Bidzos & co to earn a legal profit any way they see fit...? Or am I, the > token leftist in the crowd, going to stick my neck out solo on this one...? > > Pardon my rhetoric, but I find it truly amazing how the much extolled rights > of private property can suddenly become a non-issue when you consider you've > found a bigger issue. Some of us feel that way about ecology. I'm a card-carrying Libertarian, and I respect certain types of private property--but not others. When someone "claims" the Amazon jungle, perhaps with the blessings of a corrupt Pope, I don't. (Just and out-of-band example to quickly make the point the even Libertarians can have doubts about some property claims and even have sympathies with radical environmentalists.) The whole cloud of issues surrounding intellectual property, patents on algorithms and methods, the specifics of RSA, and so on, is a complicated set. Discussions on this list and in newsgroups makes this clear. RSADSI has licensed some of their patents to the Clipper folks. What this means is not clear to me. If Clipper (or related things) is ever _mandated_, with alternatives outlawed, then the government would effectively have granted an exclusive franchise to RSADSI, and others, sort of like _mandating_ MacDonald's hamburgers as the national standard and requiring license fees be paid to MacDonald's every time a hamburger is made or bought. So, in answer to George's question, this Libertarian is angry at the growing police state (RICO, civil forfeiture, no knock searches, the War on Drugs, national socialist health care, wars on several fronts, etc.) and fears the imminent outlawing of unapproved encryption. -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 smb at research.att.com Fri Jun 18 10:04:10 1993 From: smb at research.att.com (smb at research.att.com) Date: Fri, 18 Jun 93 10:04:10 PDT Subject: fast des Message-ID: <9306181704.AA15365@toad.com> > Run your plaintext through compress first; remove the compress > header; then encrypt. Compression will screw up character frequencie s > (and use all eight bits) enough to make automated detection of a > successfully-broken encryption really darn hard. Especially if you > keep changing compression technology each message. Most encryption scheams use cypher block chaining or some other mechanism where a change in one block will affect every block to come after it, no? Given this, would inserting a block of random data at the begining of the datastream help? Probably not. The DES-crackers are already going to be looking at a couple of blocks, because in general, the cryptanalyst won't know the IV. But not knowing it only affects your ability to decrypt the very next block; you can still get the one after it. The decrypt equation for CBC mode is P[n] <- D(C[n]) xor C[n-1] That is, without knowing the IV -- C[0] -- you can't recover P[1]. But P[2] depends only on C[2] and C[1]. If P[1] is random garbage, you've actually made life a bit easier -- the block they can't recover isn't important. From collins at newton.apple.com Fri Jun 18 10:57:41 1993 From: collins at newton.apple.com (Scott Collins) Date: Fri, 18 Jun 93 10:57:41 PDT Subject: xor w/prbs Message-ID: <9306181746.AA15078@newton.apple.com> While the pseudo-random bit sequence algorithm used in the Computer Shopper article is weak, it is important to note that the article is on the right track. However, a one time pad based on PRBS is only as secure as the PRBS itself. If the author did not state this, he was remiss. There *are* cryptographically strong pseudo-random bit generators. A one time pad based on a CSPRBS would be as secure as the underlying 'hard' problem. For example, Blum and Micali's paper "How to Generate Cryptographically Strong Sequences of Pseudo-Random Bits" (Nov. 84 SIAM), details a scheme based on the discrete log problem. Essentially, this system is based on selecting bits from successive exponentiations of a seed. If you could guess the next bit to be selected, without knowing the seed, you could reverse this into an algorithm to solve the discrete log problem. The Blum and Micali paper also references a paper by Shamir (which I have not read) called "On the generation of cryptographically strong pseudo-random sequences" 8th International Colloquium on Automata, Languages and Programming, Lecture Notes in Coputer Science, 62, Spring-Verlag, New York, 1981. The difference being that the Shamir scheme generates *numbers* while the Blum/Micali scheme generates *bits*. I try never to label anyone a moron until I am sure their stupidity is not just my failure to communicate. Scott Collins | "Few people realize what tremendous power | there is in one of these things." | -- Willy Wonka ...................................................................... Apple Computer, Inc. | phone: 408 862-0540(v), 974-6094(f) 1 Infinite Loop, MS 301-2C | AppleLink: SCOTTCOLLINS Cupertino, CA 95014 | internet: collins at newton.apple.com From kent_hastings at qmail2.aero.org Fri Jun 18 11:49:46 1993 From: kent_hastings at qmail2.aero.org (Kent Hastings) Date: Fri, 18 Jun 93 11:49:46 PDT Subject: Inviso-Crypt(r) Message-ID: <199306181849.AA16946@aerospace.aero.org> Inviso-Crypt(r) I'm proud to announce a new fuzzy-logic application that can access sub-digital biticles. These vitalistic fractional bits were never discovered before now because computer scientists are still clinging to a rigid notion of Aristotelian "A or not-A" on-off binary logic. It took a Fate magazine advertisement to inspire this scam, er- breakthrough. One of my beta testers was delighted to find his bank account dramatically compressed and his computer network rendered userless. Here is a sample of the program's output: !!! BEGIN INVISO-CRYPT(R) DATA BLOCK !!! !!! END INVISO-CRYPT DATA BLOCK !!! The preceding message may look like all spaces, but those 10 lines contain over 100 megabytes of encrypted biticles. Inviso-Crypt(r) works on graphic files, too. "+". That single character holds a 4-megabyte GIF image. Nothing works like, well, uh - nothing ... to the naked eye, of course. You've heard of Beethoven's "Emperor Concerto," this is nicknamed "The Emperor's New Code" around our data center. Our recent advance in applied cryptology works as described here or my name isn't Mr. Burns, oops, uh - Mr. Snrub, a dedicated computer scientist working at, uh - a lab very far away, on a chain of islands with affordable liability immunity and anonymous trust business structures. That'll do. This software not only does real time bit-slicing, it rolls virtual dice to generate random keys. Yes, it slices, it dices, and it will decrypt your DNA and cure cancer, colds, baldness, and all other ailments. This program is so important that my lobbyists are "passing bills" through Congress as you read this. (Ok Senator, I'm putting these bills on the trash dumpster, and when I get back, I expect them to be hauled away. Don't forget the free bar of soap to wash your hands of this whole affair. See, I DO support clean government.) Soon, Inviso-Crypt(r) will be the exclusive national standard. Why, my payroll expenses have been amazingly smaller since I printed paychecks using the Inviso-Cash(r) standard. Homer: "Hello - money, where are you?" "I like the way that Inviso-Crypt(r) works!" - Smithers.#000# From fnerd at smds.com Fri Jun 18 13:47:27 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Fri, 18 Jun 93 13:47:27 PDT Subject: Blasting Bidzos Blather Message-ID: <9306182028.AA22659@smds.com> > Oh, here goes another Big Bad Corporation abusing our rights...! Well, are > there any Libertarians out there who will please speak up for the right of > Bidzos & co to earn a legal profit any way they see fit...? I'm a libertarian. I happen to be a type of libertarian who doesn't believe in patents. So I think nobody has a "right" to use government (or any force) to enforce their patents. BUT, many people believe patents are okay, and many feel they do have a right to enforce their patents. I think the RSADSI/PKP people are like this. It's a perfectly common belief. So except for the whole patent issue, (including the validity of their particular patents), I think they have a right to sell or not sell licenses to anyone they choose. BUT, to libertarians there's a big distinction between "You have a right to..." and "It's right for you to..." It's possible they're acting within their rights (with the exception noted above) and yet doing something wrong or evil. BUT, in this case I'm not sure whether what they're doing is particularly wrong, although I haven't seen a good case one way or the other. -fnerd quote me From fnerd at smds.com Fri Jun 18 13:58:25 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Fri, 18 Jun 93 13:58:25 PDT Subject: Blasting Bidzos Blather Message-ID: <9306182053.AA22777@smds.com> Let's see if I understand L. Detweiler's recent comments: 1) PKP licensed key exchange for use with Clipper and DSS. Clipper and DSS are bad. Therefore PKP is "supporting, nay, *promoting* and *profiting* from" DSS and Clipper. a) "supporting, nay, *promoting*"--this is not good publicity against Clipper and DSS. Therefore PKP is our enemy. b) "*profiting from*"--this is dirty money, therefore PKP is dirty and we can't trust them. 2) They did it "at no additional charge." (Someone please explain relation to 1b, above.) Therefore they must be receiving some other compensation behind our backs. Therefore they're bad guys and we shouldn't trust them. 3) Bidzos says they don't dictate terms, yet their licenses DO have terms. Therefore he is lying, should not be trusted, etc. 4) They should have refused to license bad uses of "their" technology, but they didn't. Therefore they're bad, etc. Have I got that right? -fnerd quote me From karn at qualcomm.com Fri Jun 18 18:26:33 1993 From: karn at qualcomm.com (Phil Karn) Date: Fri, 18 Jun 93 18:26:33 PDT Subject: Helping from Canada re Clipper Message-ID: <9306190126.AA26864@servo> >Another argument the U.S. government is making is that they surveyed >encryption policy in various countries and "it's not beyond the pale >to limit domestic encryption -- France does it, for example". Is this an actual Administration quote? If so, they're playing with fire because France is the very same country that the US has recently accused of using its national security apparatus to spy on foreign corporations. It shouldn't be too hard to draw a link between these two policies that would cause this particular quote to blow up in the Administration's face. Phil From karn at qualcomm.com Fri Jun 18 18:26:34 1993 From: karn at qualcomm.com (Phil Karn) Date: Fri, 18 Jun 93 18:26:34 PDT Subject: Software infrastructure Message-ID: <9306190126.AA26872@servo> I'm just catching up on a very large mail backlog (much of which is Cypherpunks). Many Cypherpunks are apparently unaware of the security work going on within the Internet Engineering Task Force (IETF). Besides the infamous Privacy Enhanced Email (PEM), there are lesser known groups working on application layer security interfaces and on IP-level security (encryption and/or authentication of individual IP datagrams). Okay, I'm not saying all this work is being done right. In some cases it's not being done at all (or very slow progress is being made). In my opinion, the situation is ripe for some highly motivated Cypherpunks to read the stuff that's already been published (available from the standard FTP repositories like nic.ddn.mil), digest and critique it, and either implement the ideas that have been proposed or do them better yourself. But you should really be aware of what other work is going on in these areas before you reinvent the wheel. My personal interests and preferences lie in doing security at the IP layer. It doesn't solve all problems, but it is an approach that has been almost totally unexplored until now. And with the ever-increasing use and availability of low-cost dialup SLIP/PPP connections as an alternative to dumb terminal emulators and UUCP, I think it's a powerful technique. But I just don't have as much time to work on this as I'd like, and it would really be nice to find others to help in the effort. Phil From brendan at lisa.cygnus.com Fri Jun 18 18:35:01 1993 From: brendan at lisa.cygnus.com (Brendan Kehoe) Date: Fri, 18 Jun 93 18:35:01 PDT Subject: backpack left at Cygnus Message-ID: <9306190136.AA05971@lisa> There's a steel blue backpack in my office here at Cygnus; it's got "Kahn on Codes" in it. If it's yours, drop me a line and we can figure out a way for you to get it. Brendan -- Brendan Kehoe brendan at cygnus.com Cygnus Support, Mountain View, CA +1 415 903 1400 ``Ya know Quaker Oats make you feel good twice?'' Hmm. From lnboyd at tenet.edu Fri Jun 18 21:40:51 1993 From: lnboyd at tenet.edu (Linda Boyd) Date: Fri, 18 Jun 93 21:40:51 PDT Subject: PGP 2.3 Message-ID: <199306190439.AA20123@Alice-Thurman.tenet.edu> Help!! I don't have Usenet access, so I can't post this on the pgp newsgroup, and this is the only other place I know of to ask this... I just got pgp23.zip and pgp23src.zip from soda, and I can't make it give valid signatures with the -a option (well, actually the Armor=on line in the config.txt file)! It will work correctly if Armor=off, and if the file is also encrypted, but a straight signature with ascii armor appended to the message doesn't work. Even pgp22 gives me an invalid signature "doesn't match contents" message! Has anyone else had this problem with 2.3? I've even re- compiled with Borland C++ 3.1, and get the same problem. sean From i6t4 at jupiter.sun.csd.unb.ca Fri Jun 18 22:58:41 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Fri, 18 Jun 93 22:58:41 PDT Subject: PGP question Message-ID: I am working on an interesting application using PGP.. and I have come upon a snag. I want to have a message with more that one "pgp block" ie more than one file encrypted and then all the encrypted files concatenated as one new file. If you just use "pgp file" it tries to overwrite the same file each time. If you give it multiple -o specifications, it only takes the last one, and tries to keep overwriting it. If you use -p, it names each file based on what the original encryptor called it, but in this application that would allow for the files to still overwrite each other. What I really need is a way to specify a "base" that is modified for each output. (eg base="file" and output files become "file.1" "file.2" "file.3" etc) Is this possible... can anyone give me *any* suggestions to improve the situation... This has to be an unattended operation. -- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger i6t4 at unb.ca | (506) 457-1931 ^{1024/746EBB 1993/02/23} From davros at ecst.csuchico.edu Sat Jun 19 00:28:31 1993 From: davros at ecst.csuchico.edu (Tyler Yip - UnixWeenie (tm)) Date: Sat, 19 Jun 93 00:28:31 PDT Subject: The Computer Shopper cipher Message-ID: <9306190728.AA09090@hairball.ecst.csuchico.edu> Compared to the lines of the Computer Shopper program, how would this variant evaluate out time-complexity wise? I'm not sure how sophisticated the attacks on pseudo-random generators are. This one includes an random generator shift, based upon the random numbers. ----------------------------------------------------------------------------- #include static int seed; int rand1(int seedval) { return (seed * 183041 % 183319 + 1); } int rand2(int seed) { return (seed * 502001 % 502441 + 1); } void main(int argc, char *argv[]) { int current; FILE *input, *output; if (argc !=3) { fprintf(stderr, "Usage: %s input output\n", argv[0]); exit(1); } if ((input = fopen(argv[1], "rb")) == NULL) { fprintf(stderr, "Error opening inputfile %s\n",argv[1]); } if ((output = fopen(argv[2], "wb")) == NULL) { fprintf(stderr, "Error opening outputfile %s\n",argv[1]); } printf("Enter cipher key: "); seed = getc(stdin); current = fgetc(input); while(!feof(input)) { fputc(current ^ seed, output); current = fgetc(input); if (seed && 8) { seed = rand1(seed); } else { seed = rand2(seed); } } fclose(input); fclose(output); } -- Tyler Yip, UnixWeenie(tm) \ God put me on Earth to accomplish a certain email: davros at ecst.csuchico.edu \ number of things. Right now I am so far California State University, Chico \ behind I will never die. -Calvin & Hobbes From lnboyd at tenet.edu Sat Jun 19 01:10:49 1993 From: lnboyd at tenet.edu (Linda Boyd) Date: Sat, 19 Jun 93 01:10:49 PDT Subject: correction on pgp 2.3 problem Message-ID: <199306190808.AA28340@Alice-Thurman.tenet.edu> Please forgive me! It seems that the signature generated by the pgp 2.3 _IS_ good (according to 2.2), in any form. It's just that pgp 2.3 will not read a signature that is appended to an ascii message and ascii armored. If the signature is in a separate file, or if it isn't armored, it will read it fine. Just not a message with the signature block attached to it... So the problem is in the reading of the pgp signature block, not in the generation of the signature. I'm not very adept at programming, but am trying to work my way through it to see if I can find the problem. Sorry for the previous mistake. Again, maybe this is just my machine... sean From wet!naga Sat Jun 19 02:11:53 1993 From: wet!naga (Peter Davidson) Date: Sat, 19 Jun 93 02:11:53 PDT Subject: weak pseuodrandom number generator Message-ID: A pseudorandom number generator recently proposed here, namely: int rand1(int seedval) { return (seed * 183041 % 183319 + 1); } needs some cleaning up. It should be something like: unsigned long rand1(unsigned long n) { return ( ( ( n * 183041L) % 183319 ) + 1 ); } where n is initally set to some seed value. However, this is particularly weak, and quickly degenerates into a cycle, usually of length 208, as the following program will confirm: #include #include unsigned long a[15000]; unsigned long rand1( unsigned long n ); void main(int argc, char **argv) { unsigned int i=0, j; if ( argc < 2 ) return; a[0] = atol(argv[1]); while ( ++i < 15000 ) { a[i] = rand1(a[i-1]); for ( j=0; j Peter Davidson: thanks for the cycle tester!!!!! hadn't thought about testing a generator. As for those generators, they are seeded with the key, but, I messed it up by getting the primes in the wrong order. What characteristics of the multiplier and modulator provide large periods? -- Tyler Yip, UnixWeenie(tm) \ God put me on Earth to accomplish a certain email: davros at ecst.csuchico.edu \ number of things. Right now I am so far California State University, Chico \ behind I will never die. -Calvin & Hobbes From starr at genie.slhs.udel.edu Sat Jun 19 03:15:34 1993 From: starr at genie.slhs.udel.edu (starr at genie.slhs.udel.edu) Date: Sat, 19 Jun 93 03:15:34 PDT Subject: Violation of 3rd Amendment Message-ID: <9306191011.aa09178@genie.genie.slhs.udel.edu> I don't think it's correct to say that the 3rd amendment isn't violated. If you consider police forces standing armies and policemen soldiers, then the cases of confiscation of private homes under civil forfeiture for the occupation of cops constitutes violation of the 3rd amendment. The problem with this is that it takes some doing to persuade that police are standing armies and cops soldiers by different names. Tim Starr - Renaissance Now! Assistant Editor: Freedom Network News, the newsletter of ISIL, The International Society for Individual Liberty, 1800 Market St., San Francisco, CA 94102 (415) 864-0952; FAX: (415) 864-7506; 71034.2711 at compuserve.com Think Universally, Act Selfishly - starr at genie.slhs.udel.edu From dporter at well.sf.ca.us Sat Jun 19 03:41:07 1993 From: dporter at well.sf.ca.us (Doug Porter) Date: Sat, 19 Jun 93 03:41:07 PDT Subject: Blasting Bidzos Blather Message-ID: <93Jun19.034042pdt.13994-2@well.sf.ca.us> > NIST had no choice Pure bull puckey. First, they could have let DSA die. The commercial sector, particularly banks, would have come up with alternatives we could trust. Second, they could do what competent engineers have done for many decades: designed around inconvenient patents. Third, if they knew they weren't up to it, they could have asked for public help in that design. Fourth, they could have challenged PKP's patents on their merits. Fifth, they could have worked to get those patents declared void in the public interest. I personally don't support this one until PKP is shown to be primarily government controlled. They did none of these things. Why? Doug From gg at well.sf.ca.us Sat Jun 19 04:18:38 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Sat, 19 Jun 93 04:18:38 PDT Subject: RRe: Blasting Bidzos Blather Message-ID: <93Jun19.041815pdt.13927-1@well.sf.ca.us> Consider also the possibility that Bidzos might have felt that it was either sell it now or have it seized later. National security seizures of crypto patents are nothing new. "He who turns and sells away, will live to sell another day..." From mdiehl at triton.unm.edu Sat Jun 19 11:38:34 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Sat, 19 Jun 93 11:38:34 PDT Subject: PGP question In-Reply-To: Message-ID: <9306191838.AA25943@triton.unm.edu> According to Nickey MacDonald: > > I am working on an interesting application using PGP.. and I have come > upon a snag. I want to have a message with more that one "pgp block" ie > more than one file encrypted and then all the encrypted files concatenated > as one new file. If you just use "pgp file" it tries to overwrite the same I remember doing this once. What I did was (I think) I encrypted each file in turn and copied it to the end of the "master" file. You can then go back and wipe the temp-cypher files. When you pgp master.fil, it will extract each file in turn. And, yes, this is an automatic process. Hope this helps. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From stig at netcom.com Sat Jun 19 14:20:28 1993 From: stig at netcom.com (Stig) Date: Sat, 19 Jun 93 14:20:28 PDT Subject: Trimmed down pgp.hlp Message-ID: <9306192120.AA10808@netcom.netcom.com> I edited down the pgp.hlp file so that it's more readable (for me anyway). In case you think that the help file is less than helpful, just replace it. PGP maintainers: please add this (or an even more concise version) to the pgp distribution...contrib directory is fine. Stig ------------ Here's a quick summary of PGP v2.2 commands. pgp ciphertextfile [-o plaintextfile] decrypt or verify signature pgp -e textfile her_userid encrypt file w/ pubkey pgp -e textfile userid1 userid2 userid3 multiple recipients pgp -s textfile [-u your_userid] sign plaintext file pgp -es textfile her_userid [-u your_userid] sign, then encrypt pgp -c textfile traditional symmetric cipher only KEY MANAGEMENT: pgp -kg generate your own unique key pair pgp -ka keyfile [keyring] add new key(s) to your keyrings pgp -kx userid keyfile [keyring] extract (copy) a key from a keyring pgp -kxa userid keyfile [keyring] same, except it's ascii pgp -kv[v] [userid] [keyring] view the contents of your public ring pgp -kvc [userid] [keyring] view the "fingerprint" of a public key pgp -kc [userid] [keyring] check signatures of public keys pgp -ke userid [keyring] edit userid/pass-phrase for your keypair pgp -ke userid [keyring] edit the trust parameters for a public key pgp -kr userid [keyring] remove a key (or userid) from your pubring pgp -ks her_userid [-u your_userid] [keyring] sign/certify a public key pgp -krs userid [keyring] remove selected signatures from a pubkey pgp -kd your_userid revoke your key & issue compromise certificate pgp -kd userid disable or reenable a key on your pubring ESOTERIC USAGES: pgp -d ciphertextfile decrypt message and leave its signature pgp -sb textfile [-u your_userid] create signature separate from textfile pgp -b ciphertextfile detach signature from a signed message OTHER FLAGS -a (ascii) produce ascii radix-64 output suitable for email -m (more) read in more mode, force reading in more mode -w (wipe) erase plaintext after encrypting -f (filter) input from stdin and output to stdout -t (text) when encrypting, treat input as ascii text -p when decrypting, recover original filename Ex: pgp -feast her_userid outputfile /* Jonathan Stigelman, Stig at netcom.com, PGP public key by finger */ /* fingerprint = 32 DF B9 19 AE 28 D1 7A A3 9D 0B 1A 33 13 4D 7F */ From wet!naga Sat Jun 19 16:53:37 1993 From: wet!naga (Peter Davidson) Date: Sat, 19 Jun 93 16:53:37 PDT Subject: testing pseudorandom number generators Message-ID: Tyler Yip, UnixWeenie(tm), asks: >What characteristics of the multiplier and modulator provide large periods? The standard reference is D. Knuth, The Art of Computer Programming (as I recall), Volume II, the chapter on random numbers. Knuth gives conditions involving a, k and m for n = ( n*a + k ) mod m to have a long (or maximal) period. For the less mathematically-inclined, a pleasing and quick way to eliminate weak pseudorandom number generators is to use the generator to pick row and column pixel positions on a graphics screen. Turn on "randomly" selected pixels. If the screen does not get completely filled in a visibly random way then the generator is weak. A particularly weak generator will turn on 1% or so of the pixels then nothing further happens because it has entered a cycle. A weak generator may fill the screen with parallel lines. Writing a program to test generators in this way is a useful, easy and amusing task and is left as an exercise for the reader. Someone may be inclined to reply that this test does not show that a generator is cryptographically strong, to which the answer is: True, but it certainly eliminates the ones that aren't, and it's fun to watch the pixel display for different generators. Well, on second thought, maybe some generators that are not crypto- graphically bullet-proof might pass this test. But if some generator does not, you can throw it away immediately. From gnu Sat Jun 19 18:57:35 1993 From: gnu (John Gilmore) Date: Sat, 19 Jun 93 18:57:35 PDT Subject: that cipher I wrote (pseudo random generators) In-Reply-To: <9306190933.AA12046@hairball.ecst.csuchico.edu> Message-ID: <9306200157.AA06857@toad.com> > What characteristics of the multiplier and modulator provide large periods? Don't bother with looking for a large period (though Knuth spends about half a book on pseudorandom number generators). The problem is that the sequence is predictable. Given ten sequential values from anywhere in the sequence, I think there are algorithms that will determine the sequence. This is from dim recall of some Crypto '90 presentations. Perhaps someone has the papers in front of them, or can re-derive the results? Given plaintext XOR'd with a sequence, you can make pretty good guesses at ten values in the sequence, and if you have to try a few thousand guesses, it will still only take minutes or hours to crack. John From nobody at apsicc.aps.edu Sun Jun 20 14:31:02 1993 From: nobody at apsicc.aps.edu (nobody at apsicc.aps.edu) Date: Sun, 20 Jun 93 14:31:02 PDT Subject: basic truth Message-ID: <030620151902.63b@APSICC.APS.EDU> Make it sufficiently difficult for people to do something, and most people will stop doing it. -- Robert Sommer -Forwarded by Nobody. From zane at genesis.mcs.com Sun Jun 20 16:20:43 1993 From: zane at genesis.mcs.com (Sameer) Date: Sun, 20 Jun 93 16:20:43 PDT Subject: OTP dual decryption In-Reply-To: <93Jun18.024542pdt.13995-1@well.sf.ca.us> Message-ID: In message <93Jun18.024542pdt.13995-1 at well.sf.ca.us>, "George A. Gleason" writes: > > > Yeah, the advantage is, if they think they've found it, they might just > stop looking much further. It's a chance that might save your ass. > > -gg Wouldn't it be possible to encrypt the plaintext with DES and then when some TLA tells you to hand over they key tell them that it's an OTP and give them an OTP which produces an innocuous plaintext? Then you don't have to worry about key storage, right? (Because DES-keys are hashed from strings [right?] which can be kept in human memory.) -- | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/ From gnu Mon Jun 21 03:08:27 1993 From: gnu (John Gilmore) Date: Mon, 21 Jun 93 03:08:27 PDT Subject: Patent libraries In-Reply-To: <9306161849.AA16059@muskwa.ucs.ualberta.ca> Message-ID: <9306211008.AA00861@toad.com> Here's some info about the Sunnyvale patent library. You can walk-in and do it all yourself, for free. Bring a few rolls of dimes, since they don't make change and their copiers don't have mag-cards. Or, you can put down a deposit and have them copy patents and mail or fax them to you. I've done it both ways. It's on a back street, in an old elementary school complex. A bit hard to find. Call for directions. It's worth spending a day there e.g. looking up crypto patents, if your days aren't in short supply. I found the microcode to the 68000 in there, among other things. John Gilmore Sunnyvale Patent Information Clearinghouse 1500 Partridge Avenue, Building 7 Sunnyvale, CA 94087 +1 408 730 7290 voice +1 408 735 8762 fax Sunnyvale Patent Information Clearinghouse has a complete set of US patents and trademarks from number one to the present issue. We provide rapid document delivery at an affordable price. Orders may be phoned in during office hours (M-F, 9-5) or faxed at your convenience. Patent copy charges are: Regular charge -- $3.55 per patent, 90c/page, plus postage 24 hour turnaround Express mail -- $3.55 per patent, 90c/page, handling fee $8.60, same day service plus express charge (3pm cutoff) Fax -- same day $14.30 per patent, $1.60/page Fax -- within 2 hours $35.65 per patent, $1.60/page Special pick-up $3.55 per patent, 90c/page, handling fee $8.60 in person DEPOSIT ACCOUNT SERVICE: You must establish a deposit account before receiving patent copies. The minimum deposit is $75. On your letterhead stationary, submit names authorized to use the deposit account. Checks should be made payable to the City of Sunnyvale. -- John Gilmore gnu at toad.com -- gnu at cygnus.com -- gnu at eff.org Creating freedom, rather than longer chains, bigger cages, better meals, . . . From pcw at access.digex.net Mon Jun 21 07:53:26 1993 From: pcw at access.digex.net (Peter Wayner) Date: Mon, 21 Jun 93 07:53:26 PDT Subject: A cite desired... Message-ID: <199306211453.AA17846@access.digex.net> I remember reading that IBM originally started looking into cryptosystems like DES after they were informally tipped off that the Russians were evesdropping on their internal network. Can anyone give me a pointer to this fact? Thanks, Peter Wayner From cdodhner at indirect.com Mon Jun 21 10:57:51 1993 From: cdodhner at indirect.com (Christian D. Odhner) Date: Mon, 21 Jun 93 10:57:51 PDT Subject: No Subject Message-ID: <9306211756.AA03344@indirect.com> Just checking out a "patently false rumor" I heard about... Yeah I'll bite. Drop me a note or not... -Happy Hunting. From zane at genesis.mcs.com Mon Jun 21 11:34:40 1993 From: zane at genesis.mcs.com (Sameer) Date: Mon, 21 Jun 93 11:34:40 PDT Subject: OTP dual decryption In-Reply-To: <93Jun21.003959pdt.14001-3@well.sf.ca.us> Message-ID: In message <93Jun21.003959pdt.14001-3 at well.sf.ca.us>, "George A. Gleason" writes: > > interesting... If I understand you; it's keep your DES key in your head, and > use the DES cyphertext to create an appropriate OTP key that decrypts back > to something innocuous. good. The thing is, to make this credible, we > still need an OTP program which is in general use for communications. Yeah. OTP's seem awfully cumbersome. > > Now here's another possible problem. Let's say that They are tapping you > and grab all the cyphertext of your actual communications. Now they grab > your hard drive and what they get is a different batch of cyphertext. That > in and of itself might call up some suspicions. Any solution in sight...? Hmm? I don't understand this problem. There's only one set of cyphertext.. the actual cyphertext. Do you mean "different batch of cyphertext" as the OTP which creates the innocuous plaintext from the cyphertext? Maybe encrypt the OTP w/DES and keep it on your hard drive. When "they" snag the drive, they see the different cyphertext, you tell them that it's the OTP you used and give them the DES-key to decrypt the innocuous OTP. I sense a problem with histogram equalization, however. Is there a problem here or does OTP-encryption take care of that? -- | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/ From keenan at acs.ucalgary.ca Mon Jun 21 12:51:25 1993 From: keenan at acs.ucalgary.ca (Tom Keenan) Date: Mon, 21 Jun 93 12:51:25 PDT Subject: The other Clipper Message-ID: <9306211719.AA32503@acs3.acs.ucalgary.ca> Just to avert any confusion... I see (Communications Week, June 7, 1993, pg 1) that the code name for IBM's soon to be announced ATM (asynchronous transfer mode) switch happens (?) to be "Clipper." It's apparently based on "IBM's experimental Planet switch, a 6 gigabit per second switch that handles both variable and fixed length packets" and is in test at Rogers Communications in Toronto. (Just in case you hear communications types using the term "Clipper" in a different sense from the one usually seen on this list.) -- Dr. Tom Keenan, I.S.P. Associate Dean, R&D, Faculty of Cont. Ed. University of Calgary 2500 University Dr. NW Calgary, AB T2N 1N4 CANADA (403) 220-4715 (voice) (403) 284-5702 (fax) keenan at acs.ucalgary.ca (email) From tye at nws.globe.com Mon Jun 21 14:21:43 1993 From: tye at nws.globe.com (tye at nws.globe.com) Date: Mon, 21 Jun 93 14:21:43 PDT Subject: No Subject Message-ID: <0096E5DE60478A40.29620183@globe.com> Reporter for major metro paper is interested in help finding out anything there is to find on four prominent people who have volunteered to have their privacy breached. Financial fundamentals. Lives of crime. Aches and pains. How rich they are, where they vacation, who they socialize with. You name it, we're interested in seeing if it's out there. All for a good cause. If you're willing to advise this computer-ignorant reporter, or dig in and get the dope on these volunteers, please contact him at tye at nws.globe.com Or call at 617-929-3342. Help especially appreciated from anyone in the BOSTON area. Soon. Thanks. From jim at tadpole.com Mon Jun 21 14:21:52 1993 From: jim at tadpole.com (Jim Thompson) Date: Mon, 21 Jun 93 14:21:52 PDT Subject: Patent libraries Message-ID: <9306211509.AA04645@tadpole.tadpole.com> If there are any other Austin-based cypherpunks, UT is a federal IP depository. Jim From gnu Mon Jun 21 14:30:02 1993 From: gnu (John Gilmore) Date: Mon, 21 Jun 93 14:30:02 PDT Subject: Some FOIA results re Clipper Message-ID: <9306212130.AA19632@toad.com> Lee Tien and I have submitted a pile of FOIA requests about Clipper. Here is scanned-in text from some of the more interesting results, courtesy of Lee. Search for "required", for a mention of the proposal to require the use of Clipper. Also note that the role of the "national security community" has been deliberately withheld from the public statements (search for "mentioned"). Most agencies have not yet responded with documents. FBI is claiming it will take them a year, and we are preparing to file suit to force them to do it within 10 days like the law requires. (Our NSA suit over the same thing, is continuing through the gears of the court process.) John Gilmore [This page originally XXXXXXXXXXXXXXX TOP SECRET; now UNCLASSIFIED] OFFICE OF THE ASSISTANT SECRETARY OF DEFENSE WASHINGTON, DC 20301-3040 COMMAND CONTROL COMMUNICATIONS AND INTELLIGENCE MEMORANDUM FOR MS. JOANN H. GRUBE, NSA REPRESENTATIVE/NSC PRD-27 EXPORT CONTROL WORKING GROUP SUBJECT: Comments on PRD-27/NSA Draft (U) (U) Following are comments concerning your proposed memorandum to Jim Lewis, Department of State: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX blacked out via FOIA (b)(1) exemption. XXXXXXXXXXXXXXXXXXX (U) The assertions in this draft are merely unsupported statements. Recommend that the memorandum provide more empirical evidence to back up its assertions, and that the above comments be reflected in its contents. (signed) Daniel J. Ryan Director, Information Systems Security CLASSIFIED BY: OASD(C3I)/DIR, ISS DECLASSIFY ON: OADR [This page originally XXXXXXXX SECRET; now UNCLASSIFIED] OFFICE OF THE ASSISTANT SECRETARY OF DEFENSE WASHINGTON DC 20301-3040 COMMAND, CONTROL, COMMUNICATIONS AND INTELLIGENCE 30 APR 1993 (stamped) MEMORANDUM FOR THE ACTING ASSISTANT SECRETARY OF DEFENSE (C3I) Subject: PRD/NSC-27 Advanced Telecommunications and Encryption (U) (U) Advances in telecommunications have created the opportunity for public use of encryption to ensure the privacy and integrity of business and personal communications. These same advances threaten the capabilities of law enforcement and national security operations that intercept the communications of narcotraffickers, organized criminals, terrorists, espionage agents of foreign powers and SIGINT targets. Diverse interests are in diametric opposition with regard to industry's right to sell and the public's right to use such capabilities. A highly-emotional, spirited public debate is likely. (U) In its simplest construct, this complex set of issues places the public's right to privacy in opposition to the public's desire for safety. The law enforcement and national security communities argue that if the public's right to privacy prevails and free use of cryptography is allowed, criminals and spies will avoid wiretaps and other intercepts and consequently prosper. They propose that cryptography be made available and required which contains a "trapdoor" that would allow law enforcement and national security officials, under proper supervision, to decrypt enciphered communications. Such cryptography exists, and while there are many practical problems to be solved, this proposal is technically possible to achieve. (U) Opponents of the proposal argue that the public has a right to and an expectation of privacy, that a trapdoor system would be prone to misuse and abuse, and that the proposed solution would not work in any practical sense. They assert that people who are deliberately breaking much more serious laws would not hesitate to use cryptography that does not have a trapdoor, and that secure cryptography will inevitably be supplied by offshore companies. Thus, freedom will be lost and many tax dollars spent to no effect. (U) This situation is complicated by the existence of other interests. For example, there currently exist strict controls on the export of cryptography. The computer industry points out that it has one of the few remaining positive trade balances and that it is vital that the dominance of the American computer industry in world markets be preserved. The industry fears that this will be lost if offshore developers incorporate high-quality cryptography into their products while U.S. industry either cannot do so or suffers higher costs or delays due to requirements for export licenses. The industry argues persuasively that overseas markets (much less drug lords or spies) will not look with favor on U.S. products which have known trapdoors when offshore products which do not have them are available. In support of their argument, they note that powerful public-key cryptography developed and patented by RSA using U.S. tax dollars is free to developers in Europe, subject to royalties in the United States, and cannot be exported without expensive and time-late export licenses. These charges are true. (U) The national security community is especially interested in preventing the spread of high-quality encipherment routines overseas, and argues that more extensive use here at home will inevitably result in such a proliferation. Actually, it is too late. The Data Encryption Standard (DES) is already widely available throughout the world in both hardware and software forms, and DES software can be downloaded anywhere in the world from public bulletin boards by anyone with a PC, a MODEM and a telephone. In one recent experiment it took three minutes and fourteen seconds to locate a source-code version of DES on the INTERNET. Widespread availability of DES and RSA will enable offshore developers to provide high-quality encipherment for voice and data communications in competition with U.S. industry's products. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX blacked out via FOIA exemption (b)(1) XXXXXXXXXXX (U) Despite these concerns, the President has directed that the Attorney General request that manufacturers of communications hardware use the trapdoor chip, and at least AT&T has been reported willing to do so (having been suitably incentivised by promises of Government purchases). The Attorney General has also been directed to create a system for escrow of key material. The Secretary of Commerce has been directed to produce standards based on the use of the trapdoor chip. (U) The President has also directed that the fact that law enforcement officials will have access to the keys will not be concealed from the public. National security officials are not mentioned. (U) The new administration is committed to the development of an information superhighway and a National Information Infrastructure in support of the economy. This worthy goal is independent of arguments as to whether or not law enforcement and national security officials will be able to read at will traffic passing along the information superhighway. A full-scale public debate is needed to ascertain the wishes of U.S. citizens with regard to their privacy, and the impact on public safety of preserving privacy at the expense of wiretapping and communications intercept capabilities of law enforcement and national security personnel. It is not clear what the public will decide. In the meantime, DoD has trapdoor technology and the Government is proceeding with development of the processes needed to apply that technology in order to maintain the capability to perform licit intercept of communications in support of law enforcement and national security. (signed) Ray Pollari Acting DASD (CI & SCM) [This page originally SECRET; now UNCLASSIFIED] ASSISTANT SECRETARY OF DEFENSE WASHINGTON DC 20301-3040 May 3, 1993 COMMAND, CONTROL, COMMUNICATIONS AND INTELLIGENCE EXECUTIVE SUMMARY MEMORANDUM FOR DEPUTY SECRETARY OF DEFENSE FROM: CHARLES A. HAWKINS, JR., ACTING ASD(C3I) (initialed C. Hxxx) SUBJECT: Advanced Telecommunications and Encryption (U) PURPOSE: INFORMATION DISCUSSION: (U) In response to DEPSECDEF's tasking of 21 Apr 93 (TAB A) this information is provided. Advances in telecommunications have created the opportunity for public use of encryption to ensure the privacy and integrity of business and personal communications. These same advances threaten the capabilities of law enforcement and national security operations that intercept the communications of narcotraffickers, organized criminals, terrorists, espionage agents of foreign powers and a broad range of SIGINT targets. Diverse interests are in diametric opposition with regard to industry's right to sell and the public's right to use such capabilities. A highly-emotional, spirited public debate is likely. (U) The law enforcement and national security communities argue that if the public's right to privacy prevails and free use of cryptography is allowed, criminals and spies will avoid wiretaps and other intercepts. They propose that cryptography be made available to the public which contains a "trapdoor" that would allow law enforcement and national security officials, under proper supervision, to decrypt enciphered communications. Such cryptography exists, and while there are many practical problems to be solved, this proposal is technically possible to implement. (U) Opponents of the proposal argue that the public has a right to and expectation of privacy, that such a system would be prone to misuse and abuse, and that the proposed solution would not work in any practical sense. They assert that criminals and spies will not hesitate to use secure cryptography supplied by offshore companies. Thus, the loss of privacy would outweigh any advantages to law enforcement or national security. (U) The computer industry points out that it has one of the few remaining positive trade balances and that it is vital that the dominance of the American computer industry in world markets be preserved. The industry fears that this will be lost if offshore developers incorporate high-quality cryptography into their products while U.S. industry either cannot do so or suffers higher costs or delays due to requirements for export licenses because of strict controls of export of cryptography. The industry argues persuasively that overseas markets (much less drug lords or spies) will not look with favor on U.S. products which have known trapdoors when offshore products which do not have them are available. CLASSIFIED BY: DASD(CI&SCM) DECLASSIFY ON: OADR [This page originally XXXXXXXX SECRET; now UNCLASSIFIED] (U) The national security community is especially interested in preventing the spread of high-quality encipherment routines overseas, and argues that more extensive use here at home will inevitably result in such a proliferation. This would increase the cost of performing the SIGINT mission or decrease the amount of intelligence, or both. The Data Encryption Standard (DES) is already widely available throughout the world in both hardware and software forms, and DES software can be downloaded anywhere in the world from public bulletin boards by anyone with a PC, a MODEM, and a telephone. Thus far, widespread availability has not led to widespread use. However, widespread availability of DES and RSA will make it possible for offshore developers to provide high- quality encipherment for voice and data communications in competition with U.S. industry's products. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX blacked out under FOIA exemption (b)(1) XXXXXXXXXXXXXXXXXXXXX (U) The President has directed that the Attorney General request that manufacturers of communications hardware use the trapdoor chip. The Attorney General has also been directed to create a system for escrow of key material. The Secretary of Commerce has been directed to produce standards based on the use of the trapdoor chip. The President has also directed that the fact that law enforcement officials will have access to the keys will not be concealed from the public. National security officials are not mentioned. (U) The new administration is committed to the development of an information superhighway and a National Information Infrastructure in support of the economy. This worthy goal is independent of arguments as to whether or not law enforcement and national security officials will be able to read at will traffic passing along the information superhighway. A full-scale public debate is beginning which will ascertain the wishes of U.S. citizens with regard to their privacy and the impact on public safety of preserving privacy at the expense of wiretapping and communications intercept capabilities of law enforcement and national security personnel. It is not clear what the public will decide. In the meantime, DoD has trapdoor technology and the Government is proceeding with development of the processes needed to apply that technology in order to maintain the capability to perform licit intercept of communications in support of law enforcement and national security. Prepared by: Dan Ryan/ODASD(CI & SCM)/x 41779/28 Apr 93/OSD ------- End of Forwarded Message From gnu Mon Jun 21 14:42:04 1993 From: gnu (John Gilmore) Date: Mon, 21 Jun 93 14:42:04 PDT Subject: A public experiment in how private our lives really are Message-ID: <9306212142.AA19867@toad.com> A reported has asked me for help in finding people who will help to pentrate the privacy of four volunteers, for a major newspaper story. Any takers? Contact the reporter: Reporter for major metro paper is interested in help finding out anything there is to find on four prominent people who have volunteered to have their privacy breached. Financial fundamentals. Lives of crime. Aches and pains. How rich they are, where they vacation, who they socialize with. You name it, we're interested in seeing if it's out there. All for a good cause. If you're willing to advise this computer-ignorant reporter, or dig in and get the dope on these volunteers, please contact him at tye at nws.globe.com Or call at +1 617 929 3342. Soon. Thanks. Feel free to forward this far and wide. -- John Gilmore gnu at toad.com -- gnu at cygnus.com -- gnu at eff.org Creating freedom, rather than longer chains, bigger cages, better meals, . . . From ld231782 at longs.lance.colostate.edu Mon Jun 21 15:56:19 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Mon, 21 Jun 93 15:56:19 PDT Subject: one reaction: early FOIA results In-Reply-To: <9306212130.AA19632@toad.com> Message-ID: <9306212255.AA29611@longs.lance.colostate.edu> >The industry argues persuasively that overseas markets >(much less drug lords or spies) will not look with favor on U.S. >products which have known trapdoors when offshore products >which do not have them are available. [...] These charges are true. I'm really amazed how unbiased these letters are. In fact, maybe they were designed to be suitable for FOIA release. There is none of the one-sided propaganda tone of the Clipper announcement. Virtually all the critical arguments *against* Clipper (which can always be taken in parallel as criticisms of the current NSA role) are present -- except for the constitutionality of its introduction or enforcement. The arguments `against' are even labelled `true' and `persuasive'. I wonder if any of this means anything. It could just be a gimmick to suggest that `all concerns were fairly balanced in the proposal'. Does anyone suppose that the important military aides anticipate FOIA requests and come up with bland and benign documents to satisfy them? >The law enforcement and national security communities ... > propose that > cryptography be made available and *required* which contains a > "trapdoor" that would allow law enforcement and national security > officials, under proper supervision, to decrypt enciphered > communications. For the first time we have an official confirmation that the original intent of Clipper (or similar technology) was to make it *mandatory*. I think this is rather ironic considering many of the apologist's current main rationalizations (Denning, Sternlight, etc.) that it is a `voluntary' program. Caveat Emptor! >at least AT&T has been >reported willing to do so (having been suitably incentivised by >promises of Government purchases). `incentivised' -- a cute euphemism for collusion. I wonder to what extent they were `incentivised'. >(U) The President has also directed that the fact that law >enforcement officials will have access to the keys will not be >concealed from the public. National security officials are not >mentioned. eeks, that sounds amazingly ominous. Why would they say in one sentence `law enforcement officials have access to the keys' and then in the next `the security of the scheme for national security purposes is not revealed'? >In the meantime, DoD has trapdoor technology ... wow, they call Clipper `trapdoor technology' -- great PR, for us. >These same advances threaten the >capabilities of law enforcement and national security operations that >intercept the communications of narcotraffickers, organized >criminals, terrorists, espionage agents of foreign powers and a broad >range of SIGINT targets. `narcotraffickers' -- doesn't sound as hysterically paranoid as `drug dealers'. Also, first time I've heard SIGINT and `espionage agents of foreign powers' mentioned `officially' relative to Clipper (although of course that intent was obvious). Just another effective death threat on Clipper, because it will have the absolute *least* effect in foreign countries. >A highly-emotional, spirited public debate >is likely. hehe, it's the NSA that is highly emotional. I'd say they're shuddering and crying. OK OK, low blow, sorry. [proliferation of strong cryptography] >This would increase the cost >of performing the SIGINT mission or decrease the amount of >intelligence, or both. both. already. >Thus far, widespread availability has not >led to widespread use. hm, how could that be? It wouldn't have anything to do with draconian export regulations, would it? So, in short, we have greater confirmation of our worst fears: Clipper was not just designed to be domestic, the purveyors of Clipper were considering a *mandatory* scheme from the start, and national intelligence interests have been obscured intentionally. Also, we have many more obfuscations of who `directed' the Clipper approach -- it claims that the president did. This phrasing is very critical, understand, because the NSA has no authority to make such a proposal, and they must continue to assert that it was originated by the Executive branch for it to have any semblance of legitimacy. Note how they always evade mention of *which* president, it is just The President. (Or as Sternlight once told me, The Whitehouse.) >A highly-emotional, spirited >public debate is likely. Hm. This from a letter dated April 30, Clipper released April 16. Is this a `reaction' or an `anticipation'? This terminology overall closely mirrors the Clipper announcement. Blacked out sections presumably contain arguments on NSA capabilities relative to the new technology. Things like `the proliferation of strong cryptography is a very serious threat to the continued existence of the agency' and `a major current trend of diminuition and erosion in signal interception capabilities can be identified.' It seems to me that the next major threat will be something approximating a mandatory scheme using cloaked terminology (e.g. under the guise of `regulating the industry' and `protecting the consumer') as I wrote on sci.crypt. I think we really have to drive home the point that any mandatory scheme is fundamentally unconstitutional. This little epiphany apparently has not occured to anyone who matters in the development of Clipper policy yet. BTW what is the significance of two copies of the same letter here? p.s. special thanks to J. Gilmore for this critical information. From sommerfeld at apollo.hp.com Mon Jun 21 16:48:55 1993 From: sommerfeld at apollo.hp.com (sommerfeld at apollo.hp.com) Date: Mon, 21 Jun 93 16:48:55 PDT Subject: comments on your recent post of FOIAed documents. Message-ID: <9306212348.AA24641@toad.com> 1) The first document is particularly compelling, especially considering the apparant references to the censored paragraph in the un-censored paragraph... it makes it obvious that there are two sets of reasons for clipper; the ones that they'll admit, and the ones which are classified and which they won't admit in public. 2) The second document makes it clear that requiring the use of key escrow is a goal of law enforcement and national security. 3) The dates on the documents are dated after Ms. Denning's infamous "trial balloon".. 4) From the second document: > In one recent experiment it took three minutes and > fourteen seconds to locate a source-code version of DES on the > INTERNET. Hmm. It only took me under minute when I tried it (using the command "archie -s des.tar"). Maybe they tried it when the archie servers were overloaded :-), or maybe they counted the time needed to read the archie man page.. 5) What kind of a dork uses words like "incentivized"? - Bill From Derek_L_Davis at ccm.hf.intel.com Mon Jun 21 17:06:06 1993 From: Derek_L_Davis at ccm.hf.intel.com (Derek L Davis) Date: Mon, 21 Jun 93 17:06:06 PDT Subject: FOIA differences Message-ID: <930621171001_1@ccm.hf.intel.com> Note that the 30 APR version of the memorandum (for the acting assistant secretary of defense) and the May 3 version (from the assistant secretary of defense to the deputy secretary of defense) has some differences. In particular, the "required" reference is dropped on the second version. From bear at eagle.fsl.noaa.gov Mon Jun 21 19:13:04 1993 From: bear at eagle.fsl.noaa.gov (Bear Giles) Date: Mon, 21 Jun 93 19:13:04 PDT Subject: one reaction: early FOIA results Message-ID: <9306220209.AA27208@eagle.fsl.noaa.gov> "L. Detweiler" writes >The >arguments `against' are even labelled `true' and `persuasive'. I wonder >if any of this means anything. It could just be a gimmick to suggest >that `all concerns were fairly balanced in the proposal'. It's always a dangerous strategy to recognize your opponent has a legitimate position. If they dismissed our concerns with hand-waving they could also defuse Congressional (or other) inquiries with an appeal to authority; but with these documents they've acknowledged the legitimacy of our concerns. >Does anyone >suppose that the important military aides anticipate FOIA requests and >come up with bland and benign documents to satisfy them? You mean they _wouldn't_? Refusal to provide all documents and the dates of these documents (i.e., not during the initial design stages) suggests that they could well be covers for other documents. If nothing else, I would like to see correspondence at the same level from a year ago, back when it appeared Bush was a shoo-in for reelection. I suspect we will find a substantially different tone.... >For the first time we have an official confirmation that the original >intent of Clipper (or similar technology) was to make it *mandatory*. I don't think we have _any_ information about the *original* intent. We have some indications of what they intended after Clinton was elected, but none of these documents are from the Bush era. >>at least AT&T has been >>reported willing to do so (having been suitably incentivised by >>promises of Government purchases). > >`incentivised' -- a cute euphemism for collusion. I wonder to what >extent they were `incentivised'. Why not accept this at face value -- the government asked AT&T how many phones they would need to purchase to make it worthwhile for AT&T to make the things, AT&T gave them a number, and the government said "Okay!" >>(U) The President has also directed that the fact that law >>enforcement officials will have access to the keys will not be >>concealed from the public. National security officials are not >>mentioned. > >eeks, that sounds amazingly ominous. Why would they say in one sentence >`law enforcement officials have access to the keys' and then in the >next `the security of the scheme for national security purposes is not >revealed'? I read this as "National security officials will have access to the keys, but this will not be revealed to the public." Nothing I hadn't already assumed. :-( >`narcotraffickers' -- doesn't sound as hysterically paranoid as `drug >dealers'. No, "narcotraffickers" are the people who bring the drugs into the country. Apparently the Feds have decided to leave persecution of alleged drug dealers (note tenses) to local authorities using forfeiture laws, while the Feds concentrate on the people bringing the drugs into the country and the major distribution networks. >>Thus far, widespread availability has not >>led to widespread use. > >hm, how could that be? It wouldn't have anything to do with draconian >export regulations, would it? More likely the tendency of people to pretend "this can't happen to me!" After all, most people only deal with other residents of North America and there are no internal cryptographic restrictions. Yet. Bear Giles From dsinclai at acs.ucalgary.ca Mon Jun 21 19:54:11 1993 From: dsinclai at acs.ucalgary.ca (Douglas Sinclair) Date: Mon, 21 Jun 93 19:54:11 PDT Subject: hardware RNG Message-ID: <9306220012.AA37450@acs1.acs.ucalgary.ca> -----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, A while back there was lots of discussion in the list about hardware random number generation. The consensus was that diode white noise was the easiest thing to use. It probably is, but I havn't been able to persuade a single diode to be noisy yet. Anyhow, I turned to the simplest white noise source that I have, which happens to be a radio tuned to a dead channel. I hooked that up to a home made interface board that has previously served as a frame grabber, and wrote some software to grab random numbers. The hardware compares the signal to four known voltages, and sets the feedback pins on my printer port correspondingly. Thus, I get a nibble of information every cycle. However, it's fairly interrelated (if the high bit is set, the low ones must be set too, &c). So, this is the scheme I came up with to randomize it. Read two nibbles and concatenate them into a byte. Take the parity of this byte to give you one bit. Read eight bits this way, to make one byte. Read 128 bytes by this method, and take a MD5 hash of this data. Use the 16 byte message digest as the final random bitstream. Do this as many times as needed to get the desired number of bytes. Using the ENTROPY1 software submitted to the list by Peter Meyer, I determined that a 1000000 byte file had a relative entropy of 0.999980. This seems close enough to 1 for cryptographical use. For each bit of output, 64 bits have been read from the device. The MD5 transposition should eliminate all of the wave nature of the signal and make adjacent bytes unrelated. So, the question now is, is it safe? An obvious method of attack is to simply connect an identical device to a radio and grab identical data. However, I feel this is unfeasible. Radio noise is omnidirectional and thus (I think) should give you very different signals at different geographic locations due to the different phases of the various sources. There are too many variables in the hardware itself. What frequency is it at? What are the comparison values set to? What other method could be used to attack this except for the obvious tempest attack on the host computer? Doug -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLCZM4SEF9mfcHsd/AQGpYgP+OaJl7v7GO4SITR7nalpdU0wx6mdXHYwD CYP/u1f5BVrPfE85Thsi7beiZMp8o8aI+H5MK1uCMQ1X6pj7SOODuRXhRaXmbjnv jghthWkt19SH4AbpDz7wpV2X7BXmIO0zGBv1rZB84cBgsXQH7cmlgyUCNJP86EUq cCmt7bFSG+U= =tmPC -----END PGP SIGNATURE----- -- PGP 2.2 Key by finger From newsham at wiliki.eng.hawaii.edu Mon Jun 21 20:40:44 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Mon, 21 Jun 93 20:40:44 PDT Subject: OTP dual decryption In-Reply-To: Message-ID: <9306220340.AA02067@toad.com> > > Hmm? I don't understand this problem. There's only one set of > cyphertext.. the actual cyphertext. Do you mean "different batch of > cyphertext" as the OTP which creates the innocuous plaintext from the > cyphertext? Maybe encrypt the OTP w/DES and keep it on your hard drive. > When "they" snag the drive, they see the different cyphertext, you tell > them that it's the OTP you used and give them the DES-key to decrypt the > innocuous OTP. > I sense a problem with histogram equalization, however. Is there a > problem here or does OTP-encryption take care of that? With a OTP any plaintext can correspond with any cyphertext given: PAD (+) plaintext = cyphertext meaning PAD (+) cyphertext = plaintext and plaintext (+) cyphertext = PAD so, take your output of DES, xor its contents with desired "false plaintext" this is your false pad. store this on a seperate disk and make it look all secret-like. When feds come and take your cyphertext (which is output of DES) they ask for your key. You hand over your disk with (fake) PAD. They xor the two together to get (fake) plaintext which reads. You dont have to do this before hand either, if you have a copy of your cyphertext after the feds confiscate a copy from you you can generate pad to make it say something that will really freak them out, like something you couldnt have known prior to the seizure of the cyphertext : "I will be illegally raided on July 2, 1994, sounds sort of like '1984' to me. I wish the government would stay out of my life" > | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | peace. From TO1SITTLER at APSICC.APS.EDU Mon Jun 21 22:03:07 1993 From: TO1SITTLER at APSICC.APS.EDU (Kragen Sittler) Date: Mon, 21 Jun 93 22:03:07 PDT Subject: What is going on here? Message-ID: <930621225905.d46@APSICC.APS.EDU> From: SMTP%"Postmaster" 21-JUN-1993 22:58:06.38 To: CC: Subj: Undeliverable Mail Date: Mon, 21 Jun 1993 22:57:59 -0600 (MDT) From: Postmaster at APSICC.APS.EDU Subject: Undeliverable Mail To: Bad address -- Error -- Address refused by receiver: (550 ... User unknown) Start of returned message Date: Mon, 21 Jun 1993 22:57:54 -0600 (MDT) From: TO1SITTLER at APSICC.APS.EDU (Kragen Sittler) Message-Id: <930621225754.d46 at APSICC.APS.EDU> Subject: What? To: cdohner at indirect.com X-Vmsmail-To: SMTP%"cdohner at indirect.com" From: SMTP%"cypherpunks-request at toad.com" 21-JUN-1993 15:27:12.37 To: TO1SITTLER CC: Subj: Date: Mon, 21 Jun 93 10:56:26 MST From: cdodhner at indirect.com (Christian D. Odhner) Message-Id: <9306211756.AA03344 at indirect.com> Content-Type: text Content-Length: 123 Apparently-To: cypherpunks at toad.com Just checking out a "patently false rumor" I heard about... Yeah I'll bite. Drop me a note or not... -Happy Hunting. What are you talking about? End of returned message From phred at well.sf.ca.us Mon Jun 21 23:36:18 1993 From: phred at well.sf.ca.us (Fred Heutte) Date: Mon, 21 Jun 93 23:36:18 PDT Subject: comments on your recent post of FOIAed documents. Message-ID: <93Jun21.233550pdt.13996-1@well.sf.ca.us> I did better than that: 2 seconds flat for archie -m10 des.tar :-) From rclark at nyx.cs.du.edu Tue Jun 22 00:02:21 1993 From: rclark at nyx.cs.du.edu (Robert W. F. Clark) Date: Tue, 22 Jun 93 00:02:21 PDT Subject: FOIA request Message-ID: <9306220702.AA14470@nyx.cs.du.edu> ngs.lance.colostate.edu (L. Detweiler) says: >I'm really amazed how unbiased these letters are. In fact, maybe they >were designed to be suitable for FOIA release. There is none of the >one-sided propaganda tone of the Clipper announcement. Perhaps they were prepared. However, it seems just as likely that they realized that there would be a vast outcry over Clipper, just as there was over the "Digital Telephony" proposal. They would have to be dumber than even I consider them not even to consider the possibility of public outcry. >Does anyone >suppose that the important military aides anticipate FOIA requests and >come up with bland and benign documents to satisfy them? I'll bet they started doing this the moment that the FOIA was passed. Why wouldn't they? It's expedient. >For the first time we have an official confirmation that the original >intent of Clipper (or similar technology) was to make it *mandatory*. Yep. This particular quote ought to be distributed widely. We cypherpunks have known this since the Clipper proposal reared its monstrous head; now it's official writ, only recently declassified. Let's make the most of it. >I think this is rather ironic considering many of the apologist's >current main rationalizations (Denning, Sternlight, etc.) that it is a >`voluntary' program. Caveat Emptor! Well, as we've known, they're either shills or idiots. Perhaps both. >`incentivised' -- a cute euphemism for collusion. I wonder to what >extent they were `incentivised'. 'Incentivised' indeed. I believe that anyone capable of using such a revolting neologism is, _ipso facto_, untrustworthy. Even Hollywood people don't speak _that_ badly. [. . .] >>In the meantime, DoD has trapdoor technology ... >wow, they call Clipper `trapdoor technology' -- great PR, for us. It's pretty appalling that they even _admit_ that it is 'trapdoor' technology. However, as P. T. Barnum once said: "No one ever went broke underestimating the intelligence of the American public." They're probably planning some new crime already, realizing that Clipper will be defeated. They had Clipper in the hopper since before Digital Telephony was defeated. As Clipper makes Digital Telephony look like a schoolboy prank, prepare for something genuinely monstrous in a few months. Probably just when we start feeling a little complacent and victorious, too. [Thanks to John Gilmore repeated; the FOIA gave very useful information.] ---- Robert W. F. Clark (still waiting on the results rclark at nyx.cs.du.edu of my OWN FOIA request) clark at metal.psu.edu From rclark at nyx.cs.du.edu Tue Jun 22 00:02:57 1993 From: rclark at nyx.cs.du.edu (Robert W. F. Clark) Date: Tue, 22 Jun 93 00:02:57 PDT Subject: The Bizdos flap Message-ID: <9306220703.AA14721@nyx.cs.du.edu> bout all the Bizdos flap: It is entirely possible that PKP has no sensible alternative but to capitulate to the NSA's offer. While Bizdos himself may oppose the Clipper chip, it is obviously in PKP's best interest to accept a virtual monopoly on the crypto industry. While Bizdos' title may be "President," it is very easy for a company to remove a "President" who makes unprofitable choices. As has been said before, corporations have no truck with ethics. To expect a corporate entity to behave ethically is the same as to expect a T-cell to cease absorbing phagocytes. It ain't in its nature. If one wishes PKP to behave "ethically," it is necessary for us to make it unprofitable for PKP to behave in the manner in which it is. E. g. question their patents, bring suits against them, and otherwise make PKP's existence unprofitable. Suddenly, it will behave "ethically." Any ideas, folks? Don't expect help from Bizdos on it, though. [P. S. Ever notice that the only two people who have automatic form-letter answers to their email are Billys? Billy Idol and Billy Clinton. Fitting, somehow.] ---- Robert W. F. Clark rclark at nyx.cs.du.edu clark at metal.psu.edu From gnu Tue Jun 22 02:00:04 1993 From: gnu (John Gilmore) Date: Tue, 22 Jun 93 02:00:04 PDT Subject: hardware RNG In-Reply-To: <9306220012.AA37450@acs1.acs.ucalgary.ca> Message-ID: <9306220859.AA01020@toad.com> > persuade a single diode to be noisy yet. Anyhow, I turned to the simplest > white noise source that I have, which happens to be a radio tuned to a dead > channel. . . > What other method could be used to attack this except for the > obvious tempest attack on the host computer? Well, the most obvious is for the attacker to TRANSMIT on that frequency. Then they control the 'random' data you are getting. John From gg at well.sf.ca.us Tue Jun 22 02:42:11 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 22 Jun 93 02:42:11 PDT Subject: OTP dual decryption Message-ID: <93Jun22.024135pdt.13981-1@well.sf.ca.us> Cyphertexts: I was thinking, you do your actual comms in a PKS and then decrypt on disc and then reencrypt same over to OTP with an innocuous covertext stored alongside... oh poo, now of course; I was mistaken. You take your PKS cyphertext and generate a spurious OTP covertext from there. Okay, my error. Sorry.... -gg From gg at well.sf.ca.us Tue Jun 22 03:05:56 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 22 Jun 93 03:05:56 PDT Subject: one reaction: early FOIA results Message-ID: <93Jun22.030531pdt.13994-3@well.sf.ca.us> Re AT&T being "incentivised;" again, I'd like to suggest it's time to dis-incentivise them like right now. If you're on AT&T long distance, change your carrier. If you're using an AT&T phone system, replace it with anything else. It would be interesting to find out that magic number of phones which AT&T were promised under the Federal contract. Then we can either a) set that as a target for business phone systems getting rid of AT&T, i.e. one for one; or b) figure out what the revenues would be and get an equivalent amount in disconnected AT&T long distance (this one could be done on a gross dollar equivalent amount, assuming one year's worth of service is the relevant gross dollar value of a given client), or c) *both.* Well....? -gg From gg at well.sf.ca.us Tue Jun 22 03:09:37 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 22 Jun 93 03:09:37 PDT Subject: The Bizdos flap Message-ID: <93Jun22.030907pdt.13994-2@well.sf.ca.us> Quoting you, "If one wishes PKP to behave "ethically," it is necessary for us to make it unprofitable for PKP to behave in the manner in which it is. E. g. question their patents, bring suits against them, and otherwise make PKP's existence unprofitable. Suddenly, it will behave "ethically." That's like, if you want your kid to behave, beat him any time he misbehaves. Yeah, uh-huh. If we want PKP to behave ethically, we have to show them positive i.e. profitmaking incentives for doing so. For instance commitments to buy their products if they do (whatever). -gg From jazz at hal.com Tue Jun 22 09:55:25 1993 From: jazz at hal.com (Jason Zions) Date: Tue, 22 Jun 93 09:55:25 PDT Subject: comments on your recent post of FOIAed documents. Message-ID: <9306221655.AA29404@jazz.hal.com> >1) The first document is particularly compelling, especially >considering the apparant references to the censored paragraph in the >un-censored paragraph... it makes it obvious that there are two sets >of reasons for clipper; the ones that they'll admit, and the ones >which are classified and which they won't admit in public. I also find it interesting that, while the President directed that the fact of access to keys by Law Enforcement Officials should not be hidden from the public, the fact of access to keys by ithe intelligence community (i.e. FBI/CIA/NSA) was not to be similarly disclosed. >> In one recent experiment it took three minutes and >> fourteen seconds to locate a source-code version of DES on the >> INTERNET. > >Hmm. It only took me under minute when I tried it (using the command >"archie -s des.tar"). Maybe they tried it when the archie servers >were overloaded :-), or maybe they counted the time needed to read the >archie man page.. They probably ran the client at the far end of a 9600-baud straw on a bad archie day. >5) What kind of a dork uses words like "incentivized"? A government dork. I find it more damning that the government basically bought-off AT&T by promising them contracts; whatever happened to competetive bid? I find it highly unlikely that the contracts in question are for clipper-based phones; we already know the government doesn't plan to use clipper technology itself, since it can be suborned by LEO types. Hi, Bill! Jason "Jazz" Zions From collins at newton.apple.com Tue Jun 22 11:23:48 1993 From: collins at newton.apple.com (Scott Collins) Date: Tue, 22 Jun 93 11:23:48 PDT Subject: gov. contracts for Clipper phones Message-ID: <9306221822.AA11940@newton.apple.com> Jason Zions writes: >[...] I find it >highly unlikely that the contracts in question are for clipper-based phones; >we already know the government doesn't plan to use clipper technology >itself, since it can be suborned by LEO types. I think it *very* likely that the government would want to spy on itself just as much as it wants to spy on everybody else. Remember, the government is not a single entity -- out to get us -- but a collection of individuals, some fraction of whom are covering their butts and looking for goats at any given moment (as has been revealed to us by the media). All of whom are interested in maintaining/improving their current status. This is true at the level of the individual, the committee, the agency, the party... in fact at any identifiable organizational level, entities will engage in behavior that profits them even (or especially) at the expense of entities outside themselves. Scott Collins | "Few people realize what tremendous power | there is in one of these things." | -- Willy Wonka ...................................................................... Apple Computer, Inc. | phone: 408 862-0540(v), 974-6094(f) 1 Infinite Loop, MS 301-2C | AppleLink: SCOTTCOLLINS Cupertino, CA 95014 | internet: collins at newton.apple.com From cat at wixer.bga.com Tue Jun 22 14:28:03 1993 From: cat at wixer.bga.com (Dr. Cat) Date: Tue, 22 Jun 93 14:28:03 PDT Subject: Perspectives Message-ID: <9306222124.AA00723@wixer.bga.com> The letters John Gilmore received through FOIA are interesting. So are the reactions of the cypherpunks. I think it's valuable for society to have a group of people examine such information in an extremely skeptical manner, even bordering on paranoia. The notion that these documents are a ploy to fool people into thinking the government is aware of the problems with their proposal and has weighed them carefully is worthy of speculation. Such thoughts lead to potential avenues of investigation that may turn up useful information. But there seems to be an overabundance of such views... I think the cypherpunks can better serve society by considering ALL possibilities and investigating the more plausible ones. Including the possibilities that some of the bad guys aren't maximally devious, competent, or even bad guys. I see a lot of use of the word "they", as if the Department of Defense was part of the same group of people as NIST, NSA, the president, etc. etc. and they all are working together with the exact same set of goals and motivations. I think the situation in Washington is more complex than that. And DoD is one player I haven't heard anything previous about with regard to their stance on and involvement with Clipper. In addition to the notion that they totally support Clipper, it should be considered whether they might totally oppose it (unlikely), whether they've chosen not to be involved in the struggle over it and are simply trying to analyze its potential effects on them and disseminate the information internally to be better prepared, or whether perhaps there are differences of opinion between varying individuals in the DoD power structure. And of course, even if you label them bad guys, there's the possibility that someone wanted a summary of valid opposition arguments in order to be able to combat them more effectively, and naively failed to adequately protect them from being revealed to the opposition through the FOIA. I don't have any particular opinion as to what's going on here. I just feel I ought to say something any time I only see one point of view represented in a discussion of such a complicated issue. Particularly when such a small portion of the relevant information is, thus far, available. Dr. Cat From tribble at memex.com Tue Jun 22 15:39:10 1993 From: tribble at memex.com (E. Dean Tribble) Date: Tue, 22 Jun 93 15:39:10 PDT Subject: address chagne Message-ID: <9306222153.AA09164@memexis.memex.com> Please send mail to me now at `tribble at netcom.com` thanks, dean From eaeu362 at orion.oac.uci.edu Tue Jun 22 15:58:49 1993 From: eaeu362 at orion.oac.uci.edu (stub23) Date: Tue, 22 Jun 93 15:58:49 PDT Subject: FOIA request Message-ID: <199306222258.AA23793@orion.oac.uci.edu> the FOIA request looks very interesting and im near positive that something is on me somewhere just becuase i have the wrong type of friends who keep me in their address books but how bad will it look if i actually make the request? and will it mean that i am more likely to have people pay attention to me? and how much info shoudl i include about myself? From mulivor at orion.crc.monroecc.edu Tue Jun 22 21:51:54 1993 From: mulivor at orion.crc.monroecc.edu (mulivor at orion.crc.monroecc.edu) Date: Tue, 22 Jun 93 21:51:54 PDT Subject: Scott Collins' comments Message-ID: <9306230451.AA08776@toad.com> Scott Collins writes: Remember, the government is not a single entity -- out to get us -- but a collection of individuals, some fraction of whom are covering their butts and looking for goats at any given moment (as has been revealed to us by the media). All of whom are interested in maintaining/improving their current status. What a superb observation. As a newspaper journalist who's seen government slime up close for a while, I can tell you that this is true, true, true. The _biggest_ threat to Clipper isn't cypherpunks or other patriots; it's a bureaucratic civil war. Phil mulivor at orion.crc.monroecc.edu From rclark at nyx.cs.du.edu Tue Jun 22 22:10:42 1993 From: rclark at nyx.cs.du.edu (Robert W. F. Clark) Date: Tue, 22 Jun 93 22:10:42 PDT Subject: Corporate Ethics and the Profit Margin Message-ID: <9306230510.AA04248@nyx.cs.du.edu> rge Gleason) writes: [My suggestions on ways to make it unprofitable for PKP to behave "unethically" deleted.] >That's like, if you want your kid to behave, beat him any time he >misbehaves. Yeah, uh-huh. Unlike the child, though, a corporation is not human. In addition, it is, alas, the manner of American business of late to be reactive instead of proactive. Thus, rather than see the future catastrophe which will inevitably result if Clipper/Capstone is mandated as a standard, PKP will look toward this year's profit margin. To get the attention of an American corporation, it is regrettably necessary to "beat it every time it misbehaves." If it behaves, free market forces will take care of the reward. In the case of PKP and AT & T, though, free market forces have been subverted because they have been "incentivised" by Uncle Sam. ("Incentivised," ecch. Sounds like a suitably grisly operation, no? Ever notice that euphemisms are usually uglier than what they euphemise? Even "bribe" would sound less tawdry and criminal.) >If we want PKP to behave ethically, we have to show them positive i.e. >profitmaking incentives for doing so. For instance commitments to buy their >products if they do (whatever). Unfortunately, it's far easier for a large, diverse group to agree _not_ to purchase something than get all of them to sign a group contract to buy a certain company's merchandise. It works, too. Check out the Chavez grape boycott, and the alarming success of the Moron Majority in bullying advertisers and television networks to cancel "immoral" programming. Unless there were a "Cypherpunks procurement committee," which purchased crypto merchandise from "cypherpunk correct" dealers and resold to cypherpunks, this would be difficult to manage. It may be a good idea, but I, for one, don't have the capital to set it up; and it doesn't seem likely to happen in the immediate future. Even you, when making concrete suggestions, seem to realize that punishment and/or negative reinforcement are effective tools, as in your next message you write: >Re AT&T being "incentivised;" again, I'd like to suggest it's time to >dis-incentivise them like right now. If you're on AT&T long distance, >change your carrier. If you're using an AT&T phone system, replace it with >anything else. [Other good suggestions elided.] This is the "whack 'em when they misbehave" tactic which you seemed to oppose in your prior message. It's really the main weapon in our arsenal against corporate misbehavior. ---- Robert W. F. Clark Stop the Clipper Chip! rclark at nyx.cs.du.edu clark at metal.psu.edu From karn at qualcomm.com Tue Jun 22 22:12:19 1993 From: karn at qualcomm.com (Phil Karn) Date: Tue, 22 Jun 93 22:12:19 PDT Subject: Digital Cash$$$$ Message-ID: <9306230512.AA11503@qualcomm.com> At 04:09 PM 6/14/93 EDT, Duncan Frissell wrote: > > 1.) You mail cash/MO to First Digital Bank of Cyberspace (at an >offshore > maildrop) together with a public (unique if you like) key and anonymous >email > address (on Julf's remailer perhaps). Recall that the US has money-laundering laws that require you to file a form every time you move $10,000 or more in or out of the country. If the First Digital Bank of Cyberspace is offshore, it could come under these laws, at least with respect to priming your account with real money. It's an interesting question whether they could then get you for sending more than $10,000 of digital cash across the border without filing the form. It's even more interesting if you encrypt all these cross-border transactions... Another wonderful set of laws we can credit to the "war on drugs". Phil From mdiehl at triton.unm.edu Tue Jun 22 22:58:05 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Tue, 22 Jun 93 22:58:05 PDT Subject: PGP Menu on soda.berkeley.edu Message-ID: <9306230557.AA22297@triton.unm.edu> I have just uploaded version 1.0 of my pgp menu system for 4dos/Ndos. It presents a menu interface to all of the major pgp functions and I'm quite proud of it. It does, however, require 4dos or Norton's Ndos to run. But hey, once you use 4dos, you will never go back to regular dos. If there is positive response to this version, I will try to port it into portable C so that it can run on (anything?). Hope you enjoy it. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From karn at qualcomm.com Tue Jun 22 23:08:45 1993 From: karn at qualcomm.com (Phil Karn) Date: Tue, 22 Jun 93 23:08:45 PDT Subject: 2600 testimony to Markey's subcommittee Message-ID: <9306230608.AA14038@qualcomm.com> Having heard Markey in action (during John Gage's testimony, and again during some hearings on HDTV), and having read his atrocious "scanner bill" really drives home the old saying: a little knowledge is *dangerous*. To which I would add "especially in the hands of a politician". Phil From karn at qualcomm.com Wed Jun 23 00:05:24 1993 From: karn at qualcomm.com (Phil Karn) Date: Wed, 23 Jun 93 00:05:24 PDT Subject: YAA (yet another article) Message-ID: <9306230705.AA22288@qualcomm.com> At 11:18 AM 6/16/93 -0500, Jason Zions wrote: >Legalize drugs and prostitution and the Mafia will dry up and blow away. Amen. It was a real eye-opener to see the statistics on legal wiretaps (the ones they tell us about, anyway). The vast majority, and I do mean vast, are related to drugs. A distant second was gambling, and I think "racketeering" was in there somewhere (not sure what makes that distinct from "drugs" these days). >>Hellman has an ingenious idea that might appeal to those concerned >>about civil liberties. He would require not one but three judges to >>authorize a Clipper wiretap. A judge could answer the request with >>"Yes," "No or "Oh, my God!" The latter means, "This looks like an >>attempted abuse of power, as in Watergate." I must admit I'm disappointed to hear Hellman say something like this. Every time somebody comes up with a "new" or "improved" key escrow scheme, they give implicit approval to the whole basic idea of key escrow. Which is fundamentally unacceptable in *any* form. Although his idea may appeal to some naive people, I wonder how many have actually seen any search warrant affidavits. I read the one for Steve Jackson Games, and you certainly wouldn't know from that that they weren't all guilty as sin. Too bad it was completely defective. Do I sound like I don't place much faith in the warrant requirement acting as a meaningful safeguard? You bet! Phil From karn at qualcomm.com Wed Jun 23 00:23:02 1993 From: karn at qualcomm.com (Phil Karn) Date: Wed, 23 Jun 93 00:23:02 PDT Subject: YAA (yet another article) Message-ID: <9306230722.AA00336@qualcomm.com> At 01:46 PM 6/16/93 -0400, Perry E. Metzger wrote: >Torture, believe it or not, is a very effective way of police to get >information. Our society bans it. Every mechanism that is useful is >not acceptable. Not to dilute your argument or anything (you know I agree with it), but the reading I've done on the history of the Fifth Amendment says that one of the reasons torture was eventually banned in Western countries (through mechanisms like the American Fifth Amendment) was the growing realization that it actually was NOT particularly effective. People would falsely confess to all sorts of crimes just to get the torture to stop. Consider how many confessed witches were burned in New England. One of the problematic things about encryption (as it's usually practiced now) is that it's relatively easy to tell if an encryption key is the right one or not. This makes it tempting to resort to torture (or a "contempt of court citation", in modern terms) to extract it from an unwilling defendant. That's why both steganography and "duress key" schemes will remain important for some time, even if the 5th amendment were to be held as applicable to compelling crypto keys. You could cry "torture", while the police would claim that they discovered the key by other means (or that you disclosed it "voluntarily") and it would be your word against theirs. Phil From karn at qualcomm.com Wed Jun 23 01:15:19 1993 From: karn at qualcomm.com (Phil Karn) Date: Wed, 23 Jun 93 01:15:19 PDT Subject: Weak stenography. Message-ID: <9306230815.AA25862@qualcomm.com> One thing keeps bugging me about steganography. Let's say that "unlicensed cryptography", including the mere possession of ciphertext, is totally outlawed. You may well be able to bury encrypted data in all sorts of things (gif files, digital audio, "free" blocks on a hard disk, etc). But if you ever want to be able to retrieve it, you have to leave yourself an Achilles Heel: somewhere you need to keep a computer program, in plaintext, that you can execute to extract and decrypt the hidden ciphertext. You may be able to get away with claiming that the low order bits of your Doors tapes really *are* meaningless random bits picked up when you dubbed all your worn-out LPs to DAT, but if they find "readdat.exe" on your PC, disassemble it and discover that it's a program to extract and decrypt ciphertext from DAT tapes, you're in trouble. And if you encrypt your copy of "readdat.exe", well, you now need a plaintext decryption program to decrypt THAT. Short of devising a scheme that's so simple that you don't mind recoding it from scratch (and from memory) every time you want to extract and decrypt something, what can be done? Phil From tcmay at netcom.com Wed Jun 23 01:43:48 1993 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 23 Jun 93 01:43:48 PDT Subject: Weak stenography. In-Reply-To: <9306230815.AA25862@qualcomm.com> Message-ID: <9306230844.AA27879@netcom3.netcom.com> Phil Karn writes: ... > etc). But if you ever want to be able to retrieve it, you have to leave > yourself an Achilles Heel: somewhere you need to keep a computer > program, in plaintext, that you can execute to extract and decrypt the > hidden ciphertext. > > You may be able to get away with claiming that the low order bits of > your Doors tapes really *are* meaningless random bits picked up when you > dubbed all your worn-out LPs to DAT, but if they find "readdat.exe" on > your PC, disassemble it and discover that it's a program to extract and > decrypt ciphertext from DAT tapes, you're in trouble. And if you encrypt > your copy of "readdat.exe", well, you now need a plaintext decryption > program to decrypt THAT. > > Short of devising a scheme that's so simple that you don't mind recoding > it from scratch (and from memory) every time you want to extract and > decrypt something, what can be done? Some solutions: 1. Make programs like "readdat.exe" ubiquitous...distribute them on shareware disks, CD-ROMs, etc. Thus, many households and offices will have "readdat.exe"-like programs, whether they use them or not. Mere possession of such a program will thus not be unusual or suspicion-provoking. (This is of course one of the strategies in making PGP and related programs ubiquitous.) (Note that the storage of the _key_ is another matter, and is a problem with most crypto schemes. For data stored in low-order bits on a DAT, and retrievable with "readdat.exe," a pass-phrase of sufficient length can be used.) 2. The bit-reading program "readdat.exe" can be stored remotely, perhaps at an ftp site, so the user can retrieve it only when he needs to use it, then flush it. (I favor the "ubiquitous" route, as frequent retrievals make themselves known in other ways....and may even draw attention to a user in the first place.) -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 gg at well.sf.ca.us Wed Jun 23 03:36:09 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 23 Jun 93 03:36:09 PDT Subject: Corporate Ethics and the Profit Margin Message-ID: <93Jun23.033544pdt.14090-2@well.sf.ca.us> Re Robert. Good one there, catching me saying "positive reinforcement for PKP and negative reinforcement for AT&T." The thing is, I agree corporations don't have feelings, but Jim Bidzos *does* have feelings and he is singularly responsible as an individual, to a range of constituencies. Some of those constituencies have legal relationships such as stockholders. Others are informal, such as Us Here. But all of them come directly to HIM. That's not the case with AT&T which is a HUGE bureaucracy. If someone would find the single individual in AT&T who got them involved with the Clipper thing, we might have an interesting round of questions to ask. The thing is though, once you're dealing with a specific person, the relationship of adversariality has to be modified to take into account the respect for the individual human being. -gg From gg at well.sf.ca.us Wed Jun 23 03:39:11 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 23 Jun 93 03:39:11 PDT Subject: YAA (yet another article) Message-ID: <93Jun23.033851pdt.14087-2@well.sf.ca.us> Re Phil's criticism of warrants and the Oh My god proposal on wiretaps. It would seem that an additional safeguard can be put in place which would create some kind of liability for deliberately exaggerated warrants. One could also require the services of an investigator serving in the capacity of a public defender, who would act as devil's advocate against warrants by bringing countervailing information to bear. -gg From szabo at techbook.com Wed Jun 23 05:59:46 1993 From: szabo at techbook.com (Nick Szabo) Date: Wed, 23 Jun 93 05:59:46 PDT Subject: Weak stenography. In-Reply-To: <9306230815.AA25862@qualcomm.com> Message-ID: Phil Karn: > if they find "readdat.exe" on > your PC, disassemble it and discover that it's a program to extract and > decrypt ciphertext from DAT tapes, you're in trouble. And if you encrypt > your copy of "readdat.exe", well, you now need a plaintext decryption > program to decrypt THAT. Perhaps some hacks (ab)used by virus writers might be useful here. We might hide "readdat.exe" inside a larger "innocuous.exe" and scramble it with the "mutation engine", which creates a unique signature for each copy of readdat.exe's code (including the engine itself, which bootstraps from a very short common code sequence). The result is they have no signature to search for, even if they already have a copy of "readdat.exe" and the mutation engine. Nick Szabo szabo at techbook.com From eichin at cygnus.com Wed Jun 23 07:06:19 1993 From: eichin at cygnus.com (Mark Eichin) Date: Wed, 23 Jun 93 07:06:19 PDT Subject: Weak stenography. In-Reply-To: <9306230844.AA27879@netcom3.netcom.com> Message-ID: <9306231406.AA29189@cygnus.com> >> 1. Make programs like "readdat.exe" ubiquitous...distribute them on Well, you need a program to read your DATs and play them anyhow. What's a few extra options? Presumably it would handle various filtering and sampling anyhow; perhaps the common DAT tools or audio tools could just happen to contain a bit slicer... Still doesn't sound like it's useful for anything you need to access alot or use in the short term. Best to keep fighting for real privacy... >> I must admit I'm disappointed to hear Hellman say something like this. >> Every time somebody comes up with a "new" or "improved" key escrow scheme, >> they give implicit approval to the whole basic idea of key escrow. Which >> is fundamentally unacceptable in *any* form. It could be said that this focusses the argument on the real issue... which is *not* the technology, but the trust of government (or the need for it.) Perhaps this analogy isn't too stretched: suppose your child wants to keep a private diary. They can keep it under two locks -- but only if mother has one key and father has the other (so that if they agree that they need to see the diary, they can.) Does this seem fair itself? [too many would argue yes... that as the parents are responsible for the child, it is reasonable to do this] Does this seem like a good analogy? [perhaps closer than some would like to admit... "but mother and father are closer than any escrow agencies would be..." "oh really?" etc.] _Mark_ From M..Stirner at f28.n125.z1.RBBS-NET.ORG Wed Jun 23 07:21:16 1993 From: M..Stirner at f28.n125.z1.RBBS-NET.ORG (M. Stirner) Date: Wed, 23 Jun 93 07:21:16 PDT Subject: Origin lines in remailers Message-ID: <44.2C280DA9@wyrm.rbbs-net.ORG> In response to to call for more remailer traffic, I have been attempting to disseminate the instructions for remailer use among users not members of this list. One of the problems that has arisen is the retention of the origin lines placed at the bottom of the outgoing message by various gates & net whatnot (see bottom of this message for an example). Just before I lost access to this list a few months ago, I know that there was a discussion on how this problem could be solved with both the Cypherpunks & Penet remailers, but a conclusion had not been reached by the time I left. I did not notice a reference to this problem/solution in either the Penet or Cypherpunks remailer helpfiles (which seem to be both unchanged from earlier this year). If this problem has been solved, would some kind soul post the fix here for us? Thanks. M. ___ Blue Wave/QWK v2.12 -- M. Stirner - via RBBS-NET node 8:914/201 INTERNET: M..Stirner at f28.n125.z1.RBBS-NET.ORG From mnemonic at eff.org Wed Jun 23 07:36:54 1993 From: mnemonic at eff.org (Mike Godwin) Date: Wed, 23 Jun 93 07:36:54 PDT Subject: DH for email (re: email protection and privacy) In-Reply-To: <9306230023.AA21092@qualcomm.com> Message-ID: <199306231437.AA11378@eff.org> Phil Karn asks: > >You're not required to go *beyond* what is specified in a subpoena. > >But the subpoena's specifications can be pretty broad. > > Are you talking civil, criminal, or both? I assume you're asking about civil versus criminal contempt. My tentative answer (I can't look this up because my reference books are still packed) is both. Civil contempt, strictly speaking, is not a separate legal action--a federal judge has broad authority to impose civil-contempt sanctions on people who are noncompliant with subpoenas, who disrupt court proceedings, and so on. Criminal contempt *is* a separate legal action, and I think you can be prosecuted for intentional noncompliance with court orders, but I'd have to look up the criminal-contempt statute to be sure. --Mike From mnemonic at eff.org Wed Jun 23 08:10:59 1993 From: mnemonic at eff.org (Mike Godwin) Date: Wed, 23 Jun 93 08:10:59 PDT Subject: YAA (yet another article) In-Reply-To: <9306230705.AA22288@qualcomm.com> Message-ID: <199306231511.AA11641@eff.org> Phil Karn writes: > Do I sound like I don't place much faith in the warrant requirement acting > as a meaningful safeguard? You bet! I agree with Phil that, in practice, the warrant requirement is a very thin reed on which to base our Fourth Amendment rights. The magistrates who review warrant applications tend to accept uncritically what they're told by the government officials seeking the warrant. Hellman's proposal would address only the most obvious and most extreme abuses. --Mike From elee9sf at Menudo.UH.EDU Wed Jun 23 08:13:32 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Wed, 23 Jun 93 08:13:32 PDT Subject: REMAIL: public keys Message-ID: <199306231513.AA14546@Menudo.UH.EDU> A while ago Dave Sun suggested keeping a file containing the public keys of the remailers in an easy to get format. (I'm embarrased how long it has taken me to do this!) I recently upload the keys I have, signed by myself and occasionally others. I recently uploaded a tar-gzip file with the public keys I have, and an MSDOS zip file of the same info will follow shortly. I'd like to (at least) get the remailer operators to sign their keys. I must apologize in advance because once I went through my key ring and removed all the "unknown signator" signatures, and thus have probably erased the signatures that some put on in the first place. If this is the case, please send me the remailer keys, your public key, and I'll add them both to my ring so I won't have those errors in the future! /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From elee9sf at Menudo.UH.EDU Wed Jun 23 08:20:37 1993 From: elee9sf at Menudo.UH.EDU (elee9sf at Menudo.UH.EDU) Date: Wed, 23 Jun 93 08:20:37 PDT Subject: REMAIL: Origin lines in remailers In-Reply-To: <44.2C280DA9@wyrm.rbbs-net.ORG> Message-ID: <199306231520.AA15363@Menudo.UH.EDU> > One of the problems that has arisen is the retention of the origin lines > placed at the bottom of the outgoing message by various gates & net > whatnot (see bottom of this message for an example). Yeah, the discussion centered on whether remailers should modify text (converting tabs, crlf, strip signatures, etc.) or not. I guess it would be "best" if the remailers just pass text on through, but then some people can't help extra stuff their mail software puts in. Right now, you can form your message and encrypt it with extropia's public key - that remailer will only forward text encrypted text, so your signature will get removed. /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From bear at eagle.fsl.noaa.gov Wed Jun 23 08:50:42 1993 From: bear at eagle.fsl.noaa.gov (Bear Giles) Date: Wed, 23 Jun 93 08:50:42 PDT Subject: Digital Cash$$$$ Message-ID: <9306231547.AA13751@eagle.fsl.noaa.gov> Phil Karn writes: > >Recall that the US has money-laundering laws that require you to file a >form every time you move $10,000 or more in or out of the country. If the >First Digital Bank of Cyberspace is offshore, it could come under these >laws, at least with respect to priming your account with real money. > >It's an interesting question whether they could then get you for sending >more than $10,000 of digital cash across the border without filing the >form. It's even more interesting if you encrypt all these cross-border >transactions... This could tie a lawyer up in fits, because even if you sent digital cash across the border, you could still produce a _spendable_ copy in the originating country! In fact, you could have the same 'bill' residing on media in a dozen countries! You couldn't legally spend more than one copy of the digital cash, of course, but digital cash (unlike hard cash) can be located in several places -- and probably would be if you're talking about a substantial amount of money. >Another wonderful set of laws we can credit to the "war on drugs". Many countries restrict or monitor the flow of currency across their border; this isn't simply a result of the WoD. However, the WoD was the main reason publicly acknowledged. Bear Giles From mccoy at ccwf.cc.utexas.edu Wed Jun 23 09:37:57 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Wed, 23 Jun 93 09:37:57 PDT Subject: Digital Cash$$$$ In-Reply-To: <9306231547.AA13751@eagle.fsl.noaa.gov> Message-ID: <199306231637.AA28018@tramp.cc.utexas.edu> > From: bear at eagle.fsl.noaa.gov (Bear Giles) > > Phil Karn writes: > > > >Recall that the US has money-laundering laws that require you to file a > >form every time you move $10,000 or more in or out of the country. [...] > > > >It's an interesting question whether they could then get you for sending > >more than $10,000 of digital cash across the border without filing the > >form. It's even more interesting if you encrypt all these cross-border > >transactions... > > This could tie a lawyer up in fits, because even if you sent digital > cash across the border, you could still produce a _spendable_ copy > in the originating country! In fact, you could have the same 'bill' > residing on media in a dozen countries! Not only that, but a digital cash certificate, unlike regular cash, can be cut up into little segments that each have no value other than being random numbers. You send one segment to each of various accounts arond the world and then reconnect the segments at some site located in a country with weak banking regulations... An idea I had for this digital cash stuff that might be a little easier is to consider some of the nations within the borders of the U.S. The various Native American tribes have a degree of semi-sovereignty that may allow them to get away with something like this. This would make things easier for using this system in the U.S. because it would be fairly trivial to get the reservations on to the net if they are not already. The advantage for those running such a cyberbank is that they would get connected, and get machines to do this stuff, and the rest of us would effectively be paying them to do so :) [it probably would not be a hard sell, but the question is whether or not the various tribes have enough sovereignty to get away with it.] It is things like this that probably give regulators fits. IMHO, the real reason governments are opposed to strong cryptography is that in an information society it effectively places the population outside the control of the government, the central government becomes superfluous. jim From wcs at anchor.ho.att.com Wed Jun 23 10:40:03 1993 From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com) Date: Wed, 23 Jun 93 10:40:03 PDT Subject: Corporate Ethics and the Profit Margin Message-ID: <9306231736.AA26526@anchor.ho.att.com> gg at well.sf.ca.us writes: > Re Robert. Good one there, catching me saying "positive reinforcement for > PKP and negative reinforcement for AT&T." The thing is, I agree corporations > don't have feelings, but Jim Bidzos *does* have feelings and he is > singularly responsible as an individual, to a range of constituencies. [...] > That's not the case with AT&T which is a HUGE bureaucracy. If someone > would find the single individual in AT&T who got them involved with the > Clipper thing, we might have an interesting round of questions to ask. The > thing is though, once you're dealing with a specific person, the > relationship of adversariality has to be modified to take into account the > respect for the individual human being. A nice distinction, and possibly useful tactically. (Disclaimer: This represents about 10**-7 of AT&T's official position, i.e. I'm a stockholder like most employees, and nobody listens to me, at least not when I'm right :-) It's more than a single individual; it'd mainly be the managers of the group that makes their current line of secure phones for the government. Some of the phone models already have special government encryption chips; this is yet another design variant, and not a really major decision to make as long as there's enough tentatively-promised volume to expect a decent return on the investment. Motorola's in about the same situation. Back when the STU-III first came out, the government was talking about total sales of maybe half a million units to governments and contractors; I don't think sales were anywhere near that large... The interesting questions are whether there are any other strings attached, especially about whether that group will also attempt to market non-wiretapped phones to the public (I don't have any knowledge on that one), and also what the impact is on the parts of our "huge bureaucracy" which weren't in on the secret until we read about it in the New York Times or on the net but will be affected by it (much discussion is still going on, especially by people on standards committees which are getting pressured by the NIST and co-conspirators to specify SkipJack/escrow in industry standards.) The rest of the U.S. telecomm industry is in about the same situation. If you want to pressure AT&T or other large corporations, one popular approach is to buy stock and put a stockholder question on the ballot for the annual meeting; unfortunately the government's trying to railroad everybody into using Clipper fast enough that that's probably not practical here, but there are SEC rules on how to do it, and it does reach a lot of people and make a lot of noise if you can pull it off before it becomes moot, even if you lose (directors of large corporations almost always oppose stockholder resolutions - if do they support something, they can just do it and avoid the need for the voting process.) Having never done this myself, and don't know the costs or level of effort involved, but enough wackos put enough things on stockholder ballots that sane people like us can probably do it as well. It's important to make any ballot questions SHORT, clear to the uninitiated, positive, non-adversarial, and actionable, which ain't easy for complex topics like crypto. Bill From wcs at anchor.ho.att.com Wed Jun 23 10:59:39 1993 From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com) Date: Wed, 23 Jun 93 10:59:39 PDT Subject: Digital Cash$$$$ Message-ID: <9306231800.AA26751@anchor.ho.att.com> Do the money-laundering laws require reporting all transactions, or only movement of currency and gold? Digicash is most like EFT, which is transmitted encrypted today - does all of that have to be reported, or only the "real" paper money that backs up the numbers? As far as using digibanks on Native American territory, most of the rules restricting Federal control seem pretty flexible when the Feds want something, and even states can often get away with restricting gambling on reservations. Also, the Constitution gives CONgress the power to regulate commerce with foreign nations, Indian tribes, and between states, so they can still regulate any interactions between digibanks on Indian reservations and elsewhere. (Sigh - the Commerce Clause has been rabidly overused, but it's written in a way that lets them do nearly anything.) There's also the issue of tribal law, but most of the tribes are probably run by small numbers of reasonable people that you can talk to about things, and you can at least shop around to find them, unlike Federal bureaucracies which you're stuck with. From skyhawk at cpac.washington.edu Wed Jun 23 11:31:39 1993 From: skyhawk at cpac.washington.edu (skyhawk at cpac.washington.edu) Date: Wed, 23 Jun 93 11:31:39 PDT Subject: weak stenography and hiding readdat.exe Message-ID: <9306231831.AA04870@bailey.cpac.washington.edu> The simplest effective way I know of to hide an executable (such as readdat.exe) is to have it masquerade as another program, preferably one that is complex enough to justify its size. (You couldn't hide PGP in cat, but you could hide it in Mathematica.) You'd want the original program to be something you compile yourself, like some large X program, or gcc, or emacs. (You can hide *anything* in emacs. In fact, you can make pgp a hidden *primitive* in emacs. Hmmmmmm... Or Perl. Hmmmmmmm.....) That way you don't have a file that differs noticably from your OS release (they might check sizes and checksums), and you don't want to bother with patching a binary anyway. Then you've got the problem of invoking the alter ego of your program. Methods I've used in the past include new command-line flags, time of day, multiple "normal" invocations with slightly strange flags (this would save simple state information in /tmp), and special environment variables. To avoid leaving a trail to the hidden goodies, it's important to wipe any special arguments from argv[] (or your language's equivalent), insure that any special environment variables look completely innocent since ps(1) will display them to anyone who asks, (both assuming you're on a multiuser Unix box), and to not leave an intact .history file where some bright anti-subversive in the SS lab could see it on your confiscated hard drive, or your university's confiscated backup tapes. To make cleaning up simpler, you could hack your shell's history mechanism to not put incriminating strings into your .history. Leaving a false trail is better than simply removing the real trail, after all. (You wouldn't really need to do the same thing for your accounting log, if your machine keeps it at all, since it would only have the name of the executable. It would be important, though, that your program's public function be something that you could credibly be using 20 times a day. Compiler, linker, editor, finger, archie...) I've never had to worry about someone running a virus-style checker for naughty code, since mine's all been home-grown, but if there is a particular routine (say, pgp) that's hidden all over, Nick Szabo's excellent idea for using a virus-type mutation engine would be essential. For distribution of something like this, all we'd really need to do is co-opt some project that is distributing code on the net already, preferably something big. Then we could set up an ftp site for the binaries, for those people who don't want to bother with compiling the program. Wink wink, nudge nudge. (And many projects do this anyway.) The development of the "cover" program could go on in parallel, thus justifying continuous releases of the binaries, and the source is available (sort of) thus making the ruse that much more effective. Scott -- Scott Northrop (206)784-2083 ObVirus: The demand for obedience is inherently evil. ObVirus2: As a juror in a Trial by Jury, you have the right, power and duty to acquit the defendant if you judge the law itself to be unjust. From wcs at anchor.ho.att.com Wed Jun 23 11:31:49 1993 From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com) Date: Wed, 23 Jun 93 11:31:49 PDT Subject: Origin lines in remailers Message-ID: <9306231830.AA27125@anchor.ho.att.com> There are several possible solutions to the origin-lines problem, but they offer different benefits and place different requirements on the users; unfortunately there's been no agreement on what the users should have to do, so there's no agreement on "best" solutions. 1) Chop off anything that even *looks* signature-like, whether the user intended it or not -- I consider this ugly, evil, and unreliable, and likely to chop stuff I want kept and leave stuff I'd like chopped, but there are users out there (e.g. variants on alt.highly.personal.stuff or alt.whistleblowing) who are assumed to be computer-naive and used to this kind of automagic anonymity, and maybe they need it, especially if they don't realize that some systems *do* add them since their local system doesn't. A "Dont-Mess-With-Trailers:" header line would help a bit. I don't know how much of M. ___ Blue Wave/QWK v2.12 -- M. Stirner - via RBBS-NET node 8:914/201 INTERNET: M..Stirner at f28.n125.z1.RBBS-NET.ORG was added by the author, how much by the Blue Wave and/or 8:914/201, or even for certain whether M. Stirner is the author or merely a machine owner; I'm guessing the author, and I'm guessing everything but the initial "M." was added automagically under the machine-owner's control. 2) Cut-Here: lines of various sorts, either following a pre-specified syntax or a MIME-like flexible syntax. I like this approach, since it gives the user a reasonable level of control and very seldom guesses wrong, but there are so many standards to choose from, and a proper implementation would have to leave in the line (or add an equivalent) at each hop to avoid accretion of path-traces, and make sure it gets the correct syntax for each following remailer. And the user *does* have to explicitly request it, which some people view as a problem, especially if they don't know the characteristics of the later mail-handlers in the chain. 3) Encryption-based systems, which only retain the encrypted portion; this means the user has to know more about the remailers being used, and there has to be a standard for expressing which remailers to forward to if more than one will be used (which it probably will be, for anybody security-aware enough to really want an encrypting remailer.) It *does* give you absolute control over how much gets through, but also makes most steganography more difficult. Solving the problem for message *headers* is tougher than solving it for trailers, since you need to know how much to retain of the beginning, and need to avoid trashing the information required to successfully deliver the mail with enough information that its intended recipient can decode and use it. Bill From cel at citi.umich.edu Wed Jun 23 12:16:10 1993 From: cel at citi.umich.edu (Chuck Lever) Date: Wed, 23 Jun 93 12:16:10 PDT Subject: weak stenography and hiding readdat.exe In-Reply-To: <9306231831.AA04870@bailey.cpac.washington.edu> Message-ID: <9306231916.AA05582@toad.com> Scott Northrop writes: < The simplest effective way I know of to hide an executable (such as < readdat.exe) is to have it masquerade as another program, preferably one that < is complex enough to justify its size. (You couldn't hide PGP in cat, but you < could hide it in Mathematica.) You'd want the original program to be something < you compile yourself, like some large X program, or gcc, or emacs. (You can < hide *anything* in emacs. In fact, you can make pgp a hidden *primitive* in < emacs. Hmmmmmm... Or Perl. Hmmmmmmm.....) That way you don't have a file < that differs noticably from your OS release (they might check sizes and < checksums), and you don't want to bother with patching a binary anyway. these are interesting ideas. but it seems to me you can't beat just using a pre-existing popular application for steganography. in other words, choose an algorithm which doesn't require you to create a new program to do the job. From bear at eagle.fsl.noaa.gov Wed Jun 23 12:53:26 1993 From: bear at eagle.fsl.noaa.gov (Bear Giles) Date: Wed, 23 Jun 93 12:53:26 PDT Subject: Digital Cash$$$$ Message-ID: <9306231950.AA21578@eagle.fsl.noaa.gov> >As far as using digibanks on Native American territory, most of the >rules restricting Federal control seem pretty flexible when the Feds want >something, and even states can often get away with restricting gambling >on reservations. Also, the Constitution gives CONgress the power to >regulate commerce with foreign nations, Indian tribes, and between states, >so they can still regulate any interactions between digibanks on >Indian reservations and elsewhere. (Sigh - the Commerce Clause has been >rabidly overused, but it's written in a way that lets them do nearly anything.) This still raises some interesting possibilities: Items: Federal law requires that Indian tribes be permitted to offer all forms of gambling permitted _anywhere_ under state law. Indian reservations have a serious problem with poverty, unemployment, etc. Most gambling is hard to arrange at a distance, but it is possible to form _digital cards_ and then play any of the usual card games. Idea: An Indian tribe in an appropriate jursidiction installs a Internet node with digital cash (backed by checks, credit cards, etc) and _digital cards_. Or even a Compuserve account. (ugh). Anything, as long as the processor is located on Indian land. It offers real-time poker games. For real money. From anywhere in the world. :-) (BTW, you would _not_ offer blackjack, or only with _very_ large decks, because of the large potential for card counting programs). Just to confuse issues further, the poker software is owned by a nonprofit organization and licensed to the Indian nation with the condition that a portion of their profits go towards education. When someone claims that the tribe is offering gambling in an area where it is prohibited, you can legitimately claim that the actual processing is done on the Indian land; the only thing done in other jurisdictions is communications. Example: if a man stood just outside of the reservation and yelled instructions to a confederate at a game just inside the boundary, would that be illegal gambling _on the part of the House_? In this case, digital cash isn't _required_ since the House could simply keep accounting records directly. However, it would make it simpler for the House to honor outside bets, if a person could get a "chip" from the House, pay off a bet to a third party with the "chip", and then the third party could use the "chip" himself. Bear Giles * * Don't let them index you on a key field. Order my Special * * Report "How to Defeat a Data Base and Preserve Your Privacy" * * * ******************************************************************** From crunch at netcom.com Wed Jun 23 13:14:53 1993 From: crunch at netcom.com (John Draper) Date: Wed, 23 Jun 93 13:14:53 PDT Subject: An Awsome party coming up Message-ID: <9306232015.AA18970@netcom4.netcom.com> Greetings Cypherpunks!! We are looking for folks with laptop computers with both MS-DOS and Mac compatability to participate in an upcoming fun event to take place at Pyramid lake in Nevada. The dates are 16th thru 18th of July, where a table will be set up for those with laptops. Our purpose and goals are to make copies of PGP available to those that don't have net access, generate PGP keys, sign keys, and hand out literature to those folks interested in cryptography and the Cypherpunks cause. The event itself will offer a great time to those attending, as there will be camping, swimming, and raving, as well as other happenings to make a total memorial weekend. The event costs $30 for the weekend, and the money goes towards the Western Shoshone and Paiute Indian nation, so the money goes to a worthy cause. I am trying to set it up so that those bringing laptops and who are willing to sit at the table for a period of time, copying disks, generating PGP keys, signing keys, etc will NOT have to pay the $30. What we need from Cypherpunks: ** Make up some brocures and hand out material describing the interests of the Cypherpunks. These can be created using PageMaker, or other page layout software, and can be xeroxed for handouts. ** Volunteers who have laptops (Both Dos and Mac, and possibly others) who can make them available for key generation, PGP distributions, etc. They would NOT have to let their laptops out of their sight, but just be there for a specific time to answer questions, and do what was previous described. So, do we have any volunteers willing to participate in this rather unusual venture? For those people out of the area, and who might be planning a trek out to the west coast, this might be a great time to come. Pyramid lake is out in the Nevada Desert, there is NO shade, so tarps and other camping equipment would also be necessary and desirable. Anyone with RV's, Campers, etc would be really useful for the ocassion. So be looking forward to a great time. Bring your family and kids, I'm sure they will enjoy the happenings, as there is also swimming, horse back riding, fishing, and all of the other camping activities. Brings lots of water, ice, and drinks. Please contact me, and I'll try and put it all together. Right now, I need to collaborate and work on the wording of the brocure. Thanx John D. From pfarrell at cs.gmu.edu Wed Jun 23 18:12:21 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Wed, 23 Jun 93 18:12:21 PDT Subject: Government fear of strong crypto [was Re: Digital Cash$$$$ Message-ID: <70188.pfarrell@cs.gmu.edu> Jim McCoy writes: > IMHO, the real >reason governments are opposed to strong cryptography is that in an >information society it effectively places the population outside the >control of the government, the central government becomes superfluous. I'm not going to disagree that long term, the net makes governments obsolete, but I think that far fewer folks in the US government have _any_ understanding of the issues arround strong crypto. I spent yesterday at the "Computer Security Institute" conference in Washington (it is a commercial educational conference on computer security). Lots of government employees were there learning about security, products, etc. Most of the products were virus scanners, sigh. The "government" as a whole is not against crypto. The NSA is _very strongly_ against it. There are 60,000 or more bureaucrats in NSA that would be effectively put out of work by widespread strong crypto. All the $17 Billion that they use on signal intercepts would go to competing approachs (satelite recon, spys in the field, etc.) that are controlled by other agencies. Why? because signal intellegence is so easy now that it is extremely cheap and cost effective. Widespread strong crypto will not make evesdropping impossible, but it will make it _very_ expensive in time and money, and thus make it much less attractive. Rather than simply ranting about the evils of bureaucrats, think for a second about their motivation. There is no profit metric for bureaucrats to rely upon - they have to do their job as well as expected for the least amount of money. If they fail to deliver, they lose their jobs. (yes, they can be fired or reassigned to siberia...) So they spend all their life making sure that they do a "good enuff" job and follow all the approved actions. Having Signal intercepts work cheaply and well makes it easy to keep their jobs. I believe that the FBI and other more public agencies are simply shills for NSA. The many posting about real wiretap usage and costs simply can't support taking all the heat last year of Digital Telophony and this year over Clipper, esp. when they admit that smart crooks wouldn't bother to use Clipper. BTW, I talked to Dorothy Denning at the conference. She says that it is now called the "Key escrow chip" because of Intergraph's trademark on Clipper. I'll post more on my conversations with DE Denning later. Pat Pat Farrell Grad Student pfarrell at cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From karn at qualcomm.com Wed Jun 23 18:19:11 1993 From: karn at qualcomm.com (Phil Karn) Date: Wed, 23 Jun 93 18:19:11 PDT Subject: Weak steganography Message-ID: <9306240119.AA00555@servo> At 10:45 AM 6/17/93 -0700, Hal Finney wrote: >Another problem is that encrypted files look different from executable >files. Encrypted files have a uniform histogram (that is, all 256 different >possible byte values are equally frequent), but exe files do not. Not necessarily. If you use pklite or lzexe, you produce an automatically self-decompressing executable that will appear to have a much flatter distribution than an ordinary exe file. What we need is a crypto version of pklite - instead of (or in addition to) compressing the executable, it encrypts it and sticks a stub decryptor on the front of the executable. Each time you run it, it prompts you for a password, decrypts and decompresses the executable and runs it. Phil From karn at qualcomm.com Wed Jun 23 18:19:15 1993 From: karn at qualcomm.com (Phil Karn) Date: Wed, 23 Jun 93 18:19:15 PDT Subject: Contempt of court Message-ID: <9306240119.AA00543@servo> At 08:50 AM 6/17/93 CDT, Mike McNally wrote: In the days of >yore, numbers runners and gangsters and nefarious bad guys would keep >records on cellulose (?) flash paper which could be ignited and >destroyed very rapidly should Elliot Ness be seen approaching the >front door. Nitrocellulose. Very popular before the development of cellulose acetate, mylar and other modern polymers. It was the standard material used for movie film stock, which explains the bunker-like construction of the projection rooms in many older movie houses. Newer theaters often display signs in their projection rooms saying "Safety film only". (Now you know the meaning of the phrase "KODAK Safety Film" along the edges of your print negatives.) Today the main civilian use of nitrocellulose that I know of (other than in smokeless gunpowder) is to make ping-pong balls. Try igniting one sometime (in a safe area!) >Another (simpler) suggestion made by a friend was to devise >motion-sensitive devices which would cause total corruption of >information stored on a disk if it were moved. I've heard Gail Thackeray claim that hackers she'd raid would put big electromagnets in doorways to erase magnetic media as it was being seized. She never actually gave any proof of this, and it did always seem just a little far-fetched given the relative ease with which a hacker could just encrypt his/her incriminating data. I once asked her what she'd do once the "bad guys" started encrypting, and she said "I'm hoping you guys will tell us". (At the time I was one of the so-called "good guys", working for Bellcore.) Phil From karn at qualcomm.com Wed Jun 23 18:39:57 1993 From: karn at qualcomm.com (Phil Karn) Date: Wed, 23 Jun 93 18:39:57 PDT Subject: OTP dual decryption Message-ID: <9306240139.AA00693@servo> At , nobody at eli-remailer.toad.com wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >Using a one-time pad for dual decryption might work like this. > >I have a file, D (for Dangerous), which I want to conceal. I construct >a random file of the same length, K (for Key), which will be my "encryption >key". I xor K and D to produce E (for Encrypted), the encrypted file. I >delete D and hide K somewhere. I have a better idea. You generate your D (dangerous) file and encrypt it with IDEA or DES and a secret key K that you commit to memory. You then destroy D. If (encrypt(D,K)) is seized and you are ordered to decrypt it, then you produce a file F such that (F XOR encrypt(D,K)) produces whatever bogus plaintext you desire and hand F over to the cops claiming that it's your one-time pad. Much simpler, and no chance of them discovering your plaintext, although there's no guarantee that they won't suspect that you're still hiding something (especially if they read cypherpunks). Phil From karn at qualcomm.com Wed Jun 23 18:39:58 1993 From: karn at qualcomm.com (Phil Karn) Date: Wed, 23 Jun 93 18:39:58 PDT Subject: xor w/prbs Message-ID: <9306240139.AA00690@servo> At 10:14 PM 6/17/93, Kragen Sittler wrote: >Some MORON wrote an article in Computer Shopper, about doing a one-time pad >with a PRBS... in fact, he even challenged any cryptographers to break it. >(He used a 32-bit seed for the PRBS.) Sigh. This is starting to look like the problem that skeptic groups like the Committee for the Scientific Investigation of Claims of the Paranormal have been facing for a long time. The basic problem is that it's far easier to make a bogus claim than it is to carefully refute it. In this case, it *ought* to suffice to simply point people who make "unbreakable" but trivial ciphers at the existing volume of literature. But they can get stubborn and insist that you actually break it, not understanding that there's a big difference between a cipher that you are confident that can be cracked and a cipher in which you can place your confidence that it can't be cracked. Plus ca la change, plus ca la meme chose. Phil From dsinclai at acs.ucalgary.ca Wed Jun 23 19:49:00 1993 From: dsinclai at acs.ucalgary.ca (Douglas Sinclair) Date: Wed, 23 Jun 93 19:49:00 PDT Subject: crypto pklite In-Reply-To: <9306240119.AA00555@servo> Message-ID: <9306240247.AA16249@acs1.acs.ucalgary.ca> I have a friend who wrote a gadget called EXELOCK. It will throw a password stub into the front of an of an EXE file. Now, I'm sure it doesn't use encryption but just compares the hash of the password to a stored value. However, I'm sure an IDEA or DES version could be implemented. As for compression, no need to re-invent the wheel. Simply run pklite and then run the new EXELOCK on the result. I'll contact this person and see if I can lay my hands on the source code for the gadget. -- PGP 2.2 Key by finger From ld231782 at longs.lance.colostate.edu Wed Jun 23 21:59:33 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Wed, 23 Jun 93 21:59:33 PDT Subject: a new role for the NSA In-Reply-To: <70188.pfarrell@cs.gmu.edu> Message-ID: <9306240459.AA10744@longs.lance.colostate.edu> "Pat Farrell" >The "government" as a whole is not against crypto. The NSA is _very >strongly_ against it. There are 60,000 or more bureaucrats in NSA that would >be effectively put out of work by widespread strong crypto. All the >$17 Billion that they use on signal intercepts would go to competing >approachs (satelite recon, spys in the field, etc.) that are controlled by >other agencies. Why? because signal intellegence is so easy now that it is >extremely cheap and cost effective. Widespread strong crypto will not make >evesdropping impossible, but it will make it _very_ expensive in time and >money, and thus make it much less attractive. Hey cypherpunks, I recognize that it is critical to balance our criticisms with proposals for improvement. For example, in an earlier list of chief criticisms on Clipper I also brought up the point that a cryptographic standard developed under an impartial standards-creation process would be acceptable. Hence, let's get this into the collective psyche: NSA is definitely extremely endangered in the `signal interception' role. However, just to prove that we're not totally out to get all those black spooks, I propose that we emphasize that the NSA pursue a different role that they are in an immensely beneficial position to undertake: *promoting* cryptography use among the public and in government. Don't laugh! A very major part of NSA is dedicated to maintaining and developing the codes and machines that the rest of the military uses. The dichotomy in the two aspects of the organization was apparent with e.g. Kahn's speculation on the development of DES (make it stronger! say the makers. make it weaker! say the breakers). If we gently or jarringly prod NSA into more of the `making' instead of the `breaking' role, that would be a way of not overly offending too many bureacrats by giving them the sacred escape hatch. So: don't advocate completely dismantling the NSA. (That may happen, but if it does it will happen on its own without any encouragement.) Instead, say that in the Post Cold War era they are better suited to shift into the code*making* arena instead of the overlong insistence of the code*breaking* domination. Gosh, think of all those lonely NSA geniuses who have secure schemes but are being overruled. Imagine what this expertise could do for commercial cryptography and American technological competitiveness/supremacy if they were allowed to say `your algorithm is weak because' and not `---[CENSORED-CONFIDENTIAL-INFORMATION]---'. We have to paint ourselves as moderates before we can shine as extremists. Also, let me remind everyone to COUNTER the arguments that we now need a vast framework of intelligence gathering on `commercial espionage' -- I'm not denying that it is a problem or even an increasingly significant one, but this is *not* the role for government. That's why the word `commercial' is in there! Government involvement here will do nothing but restrain and restrict the mobility of companies involved; they have plenty of opportunities to hire deft independent consultants but a large bureacracy can do nothing for them but endanger them. * * * Satellite Torque By the way, I've been reading a lot about how satellite intelligence data is starting to get freed up based on pressure by companies such as Martin Marietta, who would like to sell the lucrative information (surprise, other countries already are and since we aren't allowed to we're dying in an important market we could potentially dominate). There is a great deal of classified satellite surveillance data out there and the fact that some of it might be on the way to being unchained is highly encouraging for the overall Cypherpunk cause. Just a little sunshine disinfectant leaking through, eh? Opening up satellite data is a way of putting more pressure on NSA, which, from what I understand, devotes a great deal of staff toward interpreting it. Or maybe that's another intelligence agency. Either way, it's a valuable wedge and torque we need to pry loose some major obstacles. If anybody is in a position to facilitate the release or dissemination of this data, go for it! * * * NSA: a big bureacracy or a bunch of bureacrats? Someone brought up the point that NSA is really just a whole lot of disconnected bureacrats who are really more interested in saving their own careers than any selfless motive such as promoting the stability of any overall government agency. This of course has relative accuracy, but either way we should try to use it as leverage against Clipper and the NSA cryptography-regulation role. I'd say the first step is to get in contact with whoever makes these policies or is involved! If we could get a list of email addresses of `VIPS in CRYPT' together to lobby, that would be stupendous. However, it seems to me that as soon as anyone tries this they are going to find out pretty fast how much of a uniform monolith the whole of NSA is. It's extremely isolated and guarded as a cohesive *whole*. But! I get the feeling there are a lot of independent *contractors* and *consultants* associated with the NSA. Anybody have any idea of how to get a list of them? We have the people from Mycotronx by name--why don't we have any email addresses? What about AT&T? Surely somebody who matters besides jim at rsa.com has an email address. Consider this the Great CypherPunk Treasure Hunt. happy hunting! From mnemonic at eff.org Wed Jun 23 22:35:44 1993 From: mnemonic at eff.org (Mike Godwin) Date: Wed, 23 Jun 93 22:35:44 PDT Subject: Contempt of Court In-Reply-To: <9306240119.AA00561@servo> Message-ID: <199306240536.AA18014@eff.org> Phil Karn writes: > At 02:13 PM 6/17/93 PDT, Mike Axelrod 422-0929 wrote: Who's this Axelrod guy? I'm Godwin. > >If the key itself had embedded testimony that was incriminating, then it is > >possible one could invoke the 5th amendment to avoid disclosure of the key. > >But, I suppose a court could do an end run around that by giving limited > >use immunity for the incriminating content of the key. Comments? > > > >Mike. I think Phil thinks we're one and the same. See below. > What I've never been able to understand about Mike's claim is why the > "fruit of the poisoned tree" principle would not apply to an encryption > key. As I understand it, this principle bars the use of any evidence > that was gathered as a direct or indirect result of inadmissable > evidence (like a warrantless search). Untrue. "Poisonous tree" doctrine applies to illegally obtained evidence, not to "inadmissible evidence" (a very different category, logically). > Mike, back at the Hackers' Conference you mentioned a Supreme Court > decision that said in passing that one could not compel a defendant to > reveal the combination to a lock, but that it wasn't a binding precedent > because it didn't relate to the case at hand. (I forget the legal term > you used). "Dicta." I'm sure Phil is referring to me, not to Axelrod, here. > Could you find and post an excerpt of this particular > decision? I've been trying to find this case, but haven't found it. --Mike From an12070 at anon.penet.fi Wed Jun 23 22:58:48 1993 From: an12070 at anon.penet.fi (an12070 at anon.penet.fi) Date: Wed, 23 Jun 93 22:58:48 PDT Subject: A Long, Personal, and Tedious Anecdote on Police Warrants & Searches Message-ID: <9306240456.AA13161@anon.penet.fi> I considered bringing up this little anecdote that happened to me in `real time' but decided against it, but now can't resist while the subject is in the list's psyche and nanosecond attention span: karn at qualcomm.com (Phil Karn) >I wonder how many have >actually seen any search warrant affidavits. I read the one for Steve >Jackson Games, and you certainly wouldn't know from that that they weren't >all guilty as sin. Too bad it was completely defective. > >Do I sound like I don't place much faith in the warrant requirement acting >as a meaningful safeguard? You bet! I write the following with some hesitation and reservation. This happened about a month ago. If anyone wants to forward this message elsewhere please check with me first. Anyway, after a long and tedious exposition I will tell you how this personal experience affected how I think of search warrants and police work. * * * SEARCH ME I had the misfortune to be in a computer lab on the night a computer was stolen. I admit the following with sheepish embarrassment: there is some possibility it happened while I was in the lab! Yes, I was writing one of those characteristically rabid letters of mine to this list, and was quite oblivous to anything outside of cyberspace. Anyway, I get a call from Officer Burke the next day. Were you in the lab? Yes. Do you remember what was going on? No. He thought the computer was stolen on Saturday night based on a `highly reliable source'. `Are you absolutely sure?' I told him I didn't remember seeing it all over the weekend (we're talking about a particular souped up 486 with the works, color monitor, huge RAM, everything but the pickles). My vague memory surely sounded less than convincing (I had been in there at various times on Friday, Saturday, and Sunday, in the period that he was considering). The lab has key card entry, and I told him his job must be easy since he knew everyone who came and went. He says, To the contrary! The doors were `propped' and friends let in friends. I told him that I didn't let anybody in and the doors were emphatically not propped (I had to use my card) all nights I went there. The system adminstrators of the lab, in their infinite wisdom, had given the officer a massive list of logins that include all *remote* logins to machines *anywhere* on the entire network (as opposed to console logins from a single lab). The cardreader logs they had were 19 and some odd minutes out of time, and the officer was trying to synchronize them with the login times. The night of his call I went back through and looked at the logs of the computer I had used to try to jog my memory. I remembered somebody *in* the lab on one of two machines who let in some other people, who may have snuck to the dastardly spot, all on a night that was very busy. The logs showed that Friday night was the busiest. This all happened after his phone call when I was able to better reconstruct what happened on given nights. I compiled and hand-edited lists of console logins from all the 5 Unix machines in the lab based on the `last' records. I called Officer Burke and told him of the person I thought let in some other people during the night (assuming he had logged in), and some vague physical descriptions of all (it all happened mostly just in my peripheral vision and awareness). Officer Burke was a bit hazy on assimilating and recording the information, and didn't seem to be able to get it all written down. He was trying to simultaneously cross reference everything I said with the reams of computer printouts in front of him. I was really surprised that he didn't seem to have been supplied with the critical information I was giving him. Why was going through all this trouble? I really wanted him to catch the culprit because this was a perfect opportunity and excuse for the local illustrious computer administration to shut down the computer labs to after hours because `someone had spoiled it for everyone' (the slimiest excuse for intolerable restrictions that is widely accepted). I suppose there were visions of Perry Mason episodes dancing around in my subconscious. Computer geek helps campus police nab computer thief. I was really convinced that there were enough `leads' to track down the computer and all that was needed was somebody clever and discriminating to piece them together. Judging the severity of the matter (the only thing I'd heard taken prior to this in the labs was hundreds of pages of paper for redundant printouts), I volunteered to stop by the police office on campus to bring along the printouts. Officer Burke agreed that it would be a good idea. So I trudge to the police office and give them a lot of helpful information on what I thought went on. I gave them excellent records which showed *console* logins (not remote logins from e.g. modem lines he had from the extremely meticulous and helpful Administration) on all the Unix machines in the lab (surprise! the Banyan Vines network was down!). Officer Burke's Sergeant was there scrutinizing my comments (his name I forget). I told them I was pretty sure the computer was stolen Friday night, despite their opinion, because I recalled being surprised by its absence on Saturday. Officer Burke reveals that they are convinced based on `other sources' that they agree with that and that the earlier source pointing to Saturday turned out to be `unreliable'. I went through a lot of trouble to draw pictures of the arrangement of the computer lab and describe the basic operation of the network for local/remote logins. Apparently I was *too* helpful. This is where it all turns from the unpleasant to the grisly. Officer Burke announces to me `You've been extremely helpful...' and I'm waiting for some lame reassurance like `we're doing the best we can'. But instead there's that ugly tone underneath that turns to `BUT if everything here is as you say it is, you won't mind us searching your residence...' Gad, my stomache lurched and my expression paled. I didn't expect to be rewarded but on the other hand, I didn't expect to be punished! I have a Mac IIsi and an ancient 286 and I had horrid visions of them carting them BOTH off because they didn't know the difference between them and a 486. At first I mumbled some shocked statements about `well, I just sort of oppose searches in general' and asked if they would be able to get a warrant. Officer Burke looked at his Sergeant and it was his turn to mumble some rationalizations. Oh, we surely could get a warrant if we needed one. No, we don't have one for this instance *but* you wouldn't and shouldn't mind *if* (that `if' was unspoken but understood!). So at this point I realized that if I said `no' I would probably not hear anything else. They also told me that they had been doing a lot of searching of other's apartments based on their voluntary submission. I got the impression this was a fairly routine process for them. In fact, they probably deal with this kind of thing all the time, with missing computer equipment all over campus. I asked them if they had pursued all their other leads (I was thinking, I would like them in my apartment as an absolute last resort). They told me they were waiting for someone to `call them back'. I had this absurd vision of the thief absconding out of town, snickering among his black friends, saying `I told him I would call him BACK! HAHAHAHA!' After a bit more of this extremely awkward back-and-forth for everyone involved, I asked them if they had any warrants they could show me. I was trying to turn this into as much as an educational experience as possible (others will recognize that truly educational experiences tend to be painful). They pull out massive file full of warrants right out of a file cabinet. I would have liked to study them very closely, but of course I had no such privilege. In the few brief instants that I peered at them I was able to make out some details. First, they were extremely specific in their wording. They named exact addresses, people, and articles that came under the search. They named the reasons for the search, the chain of evidence and suspicion that was to justify it, and all the formal legalese required. Each was a few pages long. They were printed out on a dot-matrix printer. The one I saw in particular was drug related. I can't make any quotes. I asked them what percentage of warrants were approved by the judge. Mr. Burke looked at his Sergeant and did the `well (er) we write very fine warrants' bit. (How many have been turned down?) Oh, we put a lot of effort into them to get all the details right, and we're good at it, we have a lot of experience. (In what cases have any been turned down?) We don't waste our time writing warrants that wouldn't be granted--we don't submit weak ones. (Have you *ever* had one turned down?) Finally, Officer Burke reveals to me, in however many years of his police work, that he has (ahem) never had the experience of having a warrant turned down, but that was solely evidence of his masterful warrant-writing aptitude and had no other significance. Maybe it was just my imagination but he referred to the judge involved in a way as if they were personal friends--perhaps they even played golf on Tuesdays. Ah, well, it's a small town. But the warrant spectacle was for me only a sideshow--this whole time I had uneasy visions of Steve Jackson Games dancing through my head. Finally, after telling them of my fear of them carting off my computers, Officer Burke reassured me that he had a 386 or something at home and could tell the difference between brands. They were extremely persistent. I had no idea why after all my cooperation. What thief would have the audacity to walk into the police station and talk about the night he stole it? So Officer Burke and his Sergeant stick me in the back of their police car (since I had walked) and cart me off to my apartment complex. I find it quite a surrealistic experience to be making uneasy and intermittent small-talk on 386's with Officer Burke behind a steel-and-plexiglass divider. I'm hoping that most of the neighbors have their venetian blinds drawn today. I take them to my apartment which as usual, to say the least, has that `strewn about' look (perhaps one of my deep Freudian reasons for being reluctant in the search). Upon entering the Sergeant says `Oh, my place looked a lot worse than this when I was living alone.' Officer Burke notes with some strange irony that Yep, Sure Enough, there's a Mac IIsi and a cheap 286 in the corner. I open up some of the computer boxes I use as stylish computer nerd furniture tables and settings, to show they are empty. After about 5 minutes of this they are clearly unimpressed and disappointed at the same time. While Officer Burke is looking under the kitchen sink and in the kitchen cabinets, the Sergeant says to me `so what would be your dream computer? a Mac or an IBM?' It seemed like a simple query just to distract me from the unpleasantness of two police officers breathing down my space and eyeing things such as dirty plates on the floor and dirty clothes in the corners, and disordered stacks of manuals and magazines in various stages of undress. I hesitated to think but was completely straightforward and honest in saying that I probably would prefer a Mac, namely a Quadra 950, and made some vague noises about how one's computers reflect how much money one has! Later I realized that the question could have been hardly innocent, but a way of judging whether I was lusting after a juicy 486 like the one stolen, and was glad I didn't say anything suspicious. Then again, maybe my response *was* suspicious. Officer Burke says `I guess that's about it unless...' (with a sort of dangling irony from a Perry Mason episode just before a sudden, surprising, damning revelation) and looks inside the oven, which has never held anything but two thawing pizzas and is empty at the moment. Finally, they leave, and I'm encouraged that they take the handcuffs with them without me in them. At least I had *proven* (to use their own terminology) that I wasn't guilty... I was hacking away in the same computer lab on the next night (I forget when--Tuesday?), and officer Burke and another officer came in to survey the area for the first time. They talked to some people in the lab and looked around. Officer Burke had brought with him all the logs he had been given including mine. It was at this point that I realized his version of the logs were vastly superfluous. I thought I probably got some brownie points for the extremely tight hand-edited ones I gave him (listing only the console logins to all Unix machines in the lab). I found out about his haystack versions only because he let me see them after asking rather simplistic questions of me about the network (where can people log in from?), and I realized that *he* had just realized for the first time that the Adminstration-supplied logs were far more raw data than was necessary--in fact, it was highly misleading because it listed logins from *anywhere* (modems, off campus-sites, internet connections, etc.) He talked to me some more to ask me about the details I had gone over of the people I saw let in. He sat down at the desk where the computer was stolen and went through them as I banged away on a remote computer. Finally the pair are about to leave. Officer Burke reveals that the people he talked to today and residences he searched didn't help at all, and has a very emptyhanded tone. I told him, `well, at least you have a lot of other things to look at' indicating the printouts. `No, we've hit a dead end. In fact, at this moment, I'd have to say that you're our prime suspect.' Yeeks. I was completely crestfallen, and turned away from looking at him, having a queasy replay of the gut-wrenching feelings of the earlier Residence Search Initiative. He told me that he had a 3 day vacation starting that night (as I recall, it was about 5:30 then) and hopefully some new `leads' would pop up afterwards. He and I traded some more of that halting, eerie small talk about campus computer politics and network administration jobs, and there's the brief illusion that we're just two human beings yacking. But then just before he left he said, `say, by the way, just check everything up, do your apartments have any storage facilities?' I assured him they did not, shaking my head and looking away for the third and final time. I went back to the computer and tapped the keyboard, brushed the mouse, and tried to lose myself in cyberspace. * * * In pondering the whole episode I have come to various conclusions. 1) A supremely delicate balance exists between the ability of the police to conduct meaningful investigations and the preservation of the rights of people they are investigating. It would be possible to argue based on this experience that the warrantless search is critical to their role, but on the other hand it would be equally possible to argue that it is completely useless. 2) Police do not need warrants to make searches. Probably most searches are done without them. Many people submit to them voluntarily with only the slightest hesitation. Was I perpetuating a dangerous or cavalier approach by assenting to the search? I don't know. I felt like I could remove suspicion by doing so and that their assurances were adequate... 3) I didn't gain any tangible benefit from cooperating fully with the police. To the contrary, it chewed up my time and emotions with only the effect of drawing greater suspicion to me and for all I know I am still a `prime suspect'. Your mileage may vary; I certainly don't advocate this experience as a complete disillusionment in `the process' or want it to be referred to in that way. If you do cooperate with police I urge you to have a rock-solid alibi and be absolutely certain of your facts. Lacking either makes you suspect. For me the sentence `if you are innocent you can prove it' now sounds as warped and cruelly hollow as `if you loved me you'd prove it.' 5) I certainly don't envy the job of being a policeman. In an investigation they don't know who to trust, and have to tiptoe around revealing details to get more information and not revealing details that imperil the overall investigation. Under this scenario, solid information and its knowledgeable interpretation is absolutely invaluable. 6) The policeman does not always have a great incentive to solve a case. There is no change in his salary in doing so or any other basic reward. There is probably a vague hint of promotion in consistently solving cases, but in many other cases there is probably greater incentive *not* to solve a case--the tedious legwork is diminished. 7) Probably most of the cases that *are* solved are mostly based on rock-solid information such as confessions and informant tips and not inspired sleuthing and searches. The argument could be made that this is the major legitimate role of investigative police work--following existing leads, not going on `fishing expeditions'. 8) Warrants, like any other bureacratic tool, can become meaningless under the variations of local circumstances. My impression was that they do seem to be used, but they are only used in extreme circumstances and do not form the basis of routine police work. I think the critical message is that we have to judge law enforcement techniques not by their *intent* but their actual use and effect in *practice*. 9) I still wonder if the officers would have been able to get a warrant under my circumstances. At the time I was convinced that they wouldn't have without additional evidence (of which there assurredly is none). I had in the back of my mind that I would rather have them search when I didn't expect it or through my landlord when I wasn't there. In other words, as ugly and unpleasant as it was, it could have even been far worse. Thanks for listening to all this, it is immensely therapeutic for me and hopefully some insight is contained herein to minimize a burden for you. P.S. Even though elements of this note make my identity exceedingly obvious, in interests of preserving my privacy, please refrain from speculating publicly or privately on it. Just sign me: SEARCH ME P.P.S. As of this writing, neither the thief nor the computer have been found. ------------------------------------------------------------------------- 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 mccoy at ccwf.cc.utexas.edu Wed Jun 23 23:25:25 1993 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Wed, 23 Jun 93 23:25:25 PDT Subject: Government fear of strong crypto In-Reply-To: <70188.pfarrell@cs.gmu.edu> Message-ID: <199306240625.AA19484@tigger.cc.utexas.edu> > From: "Pat Farrell" [...] > > The "government" as a whole is not against crypto. The NSA is _very > strongly_ against it. There are 60,000 or more bureaucrats in NSA that would > be effectively put out of work by widespread strong crypto. Hmmm..... actually I must disagree with this. The NSA may oppose strong crypto, but a few facts should be brought up: 1) The NSA is not chartered for domestic surveillance work. If you discover the NSA watching you within the US you can have them arrested. They are probably more interested in the systems being put in use around the world and less about systems internal to the U.S. 2) The NSA has been dealing with strong cryptography for a long time. These are the people who have been playing crypto games with "the Ruskies" since before I was born. I sincerely doubt they are losing a great deal of sleep over the fate of Clipper. They may have an interest in promoting relatively weak cryptography that will be exported and may actually favor weak crypto at home (hoping for the Beta v. VHS effect to spread this weak crypto from the U.S. to the rest of the world) but no one at Fort Meade is going to be getting a pink slip if Clipper goes down in flames. The FBI, and other domestic law enforcement agencies are probably very gung ho for weak crypto, but I just don't think that No Such Agency is going to be greatly effected by it. Thier fingerprints are all over the Clpper stuff, but seeing as how thier other mission is to develop ciphers this is only natural. Just a little thought late at night... jim > > I believe that the FBI and other more public agencies are simply shills for > NSA. The many posting about real wiretap usage and costs simply can't > support taking all the heat last year of Digital Telophony and this year > over Clipper, esp. when they admit that smart crooks wouldn't bother to use > Clipper. > > BTW, I talked to Dorothy Denning at the conference. She says that it is now > called the "Key escrow chip" because of Intergraph's trademark on Clipper. > I'll post more on my conversations with DE Denning later. > > Pat > > Pat Farrell Grad Student pfarrell at cs.gmu.edu > Department of Computer Science George Mason University, Fairfax, VA > Public key availble via finger #include > From mdiehl at triton.unm.edu Wed Jun 23 23:58:28 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Wed, 23 Jun 93 23:58:28 PDT Subject: Weak steganography In-Reply-To: <9306171745.AA05015@soda.berkeley.edu> Message-ID: <9306240658.AA15654@triton.unm.edu> According to nobody at soda.berkeley.edu: > There are a couple of problems with the idea of sticking encrypted > files onto the end of executable files. The first is, to make this > easy, you need a program to do it (and to "undo" it). Well, if someone > steals your computer and gets access to these files, they will probably > also get access to this program. This will tip them off to what you have > done. The technique I advocated was so simple, I could code it on my lunch hour at work. I did. If you didn't want to have such a thing on your machine, you could store it remotely, either on an ftp site or a local bbs. Clean up your hard disk and there is no sign of anything. > This is an example of the general principle that you need to assume that > your attackers know or can discover the methods you are using, but they > don't know the keys. If steganography is to work, we must find ways to make this "principle" invalid. Strong encryption will protect our "plain-sight-text." It falls to Data-hiding to protect our cyphertext. > Another problem is that encrypted files look different from executable > files. Encrypted files have a uniform histogram (that is, all 256 different > possible byte values are equally frequent), but exe files do not. The > appending of an encrypted file to an executable file will be very obvious. > The exact boundary may not be immediately apparent, but it can probably > be narrowed down to ten or twenty words without much effort at all. In > any case, exe files which have had this treatment will stick out like a > sore thumb. I was going to suggest, but Phil beet me to it, that we compress our executables > Last, XOR'ing a PGP file with a repeated string is probably not a very > good method. PGP has a header at the front whose structure is known and > which has some fixed bytes. These can be used to immediately recover some Well, we could do a lot of things here. We could have the option of xor'ing, adding, or subtracting.... We could add random bytes to the cyphertext, at offsets we specify and memorize.... I still think this could be done, and that it would work. If anyone else shares my enthusiasm, I'll try to get it coded up +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From nobody at shell.portal.com Thu Jun 24 00:05:29 1993 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Thu, 24 Jun 93 00:05:29 PDT Subject: Testing remailers Message-ID: <9306231925.AA00271@jobe.shell.portal.com> This is a remailer test. This message has just passed through 16 remailers. Sorry for the waste of bandwidth. Have a nice day. From hkhenson at cup.portal.com Thu Jun 24 00:05:33 1993 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Thu, 24 Jun 93 00:05:33 PDT Subject: Timothy C. May:superhacker Message-ID: <9306170149.1.15731@cup.portal.com> A lot of people are afraid to ask if the goverment keeps files on them-- because they would be disapointed to find out that they have never done anything to warrant the government opening a file on them. I have never asked the feds, but I had an interesting experience with what a reporter had been given suposedly from a local police file. During a time I was starting a business (and had no time for such nonsense even if I had been so inclined) they had me pegged as the leader of a local group of eco terriorist who were buring down houses to contain "urban sprawl." I felt the file (I did not get a copy) was real, because I could remember a few things from several years previous I had done while under survailance, but, gad, I didn't even *know* any of the bozos who were eventually caught. At least in that case, the quality of the data in my file was complete nonsense. Keith From pcw at access.digex.net Thu Jun 24 05:53:23 1993 From: pcw at access.digex.net (Peter Wayner) Date: Thu, 24 Jun 93 05:53:23 PDT Subject: a new role for the NSA Message-ID: <199306241253.AA00313@access.digex.net> Many people have pointed out, perhaps correctly, that strong crypto could mean the end of the line for many of the workers at the NSA. If I was in charge of the NSA, I would argue to my budget-dispensing superiors that all of the strong crypto just meant that I needed a bigger budget to scan for data. So the terrorists get crypto terminals? Well, they probably won't have a Tempest class machine so there is plenty of SIGINT that can still be done. There are plenty of opportunities to target people and their communications links with localized bugs. It just requires some more money. I've often wondered whether the NSA's presumed approach of acting as a huge vacuum cleaner for data was the best way of gathering intelligence. It may have been in the 1960's and earlier when transmission rates were relatively expensive and people didn't call long distance unless their was a death in the family. Now, though, the sheer volume of data has exploded. Vaccuumming it all in and sorting it out in the buildings at Fort Meade must be much less cost effective-- no matter how many voice recognition computers that they have. Today, information is much, much cheaper than it used to be. Intelligence is just as expensive as ever. Incidentally, Bill Safire wrote a great piece on this a year or so ago. He argued that it was time for the Spy agencies to go back to Mata Hari type shenanigans because the magic window of SIGINT was about to be closed again. If anyone could dig it up, I would appreciate the reference. -Peter Wayner From 76630.3577 at CompuServe.COM Thu Jun 24 06:12:31 1993 From: 76630.3577 at CompuServe.COM (Duncan Frissell) Date: Thu, 24 Jun 93 06:12:31 PDT Subject: Fermat Vindicated Maybe Message-ID: <930624130945_76630.3577_EHK41-1@CompuServe.COM> >From today's NYT: Dr. Wiles [Andrew Wiles of Princeton University] presented his results this week at a small conference in Cambridge, England, his birthplace, on "Padic Galois Representations, Iwasawa Theory and the Tamagawa Numbers of Motives." He gave a lecture a day on Monday, Tuesday, and Wednesday with the title "Molecular Forms, Elliptic Curves and Galois Representations." There was no hint in the title that Fermat's last theorem would be discussed, Dr. Ribet said. "As Wiles began his lectures, there was more and more speculation about what it was going to be," Dr. Ribet said. The audience of specialists in these arcane fields swelled from about 40 on the first day to about 60 today [23 June]. Finally, at the end of his third lecture, Dr. Wiles concluded that he had proved a general case of the Tatiyama conjecture. Then, seemingly as an afterthought, he noted that that meant that Fermat's last theorem was true. Q.E.D. Duncan Frissell The bulk of whose experience with Fermat consists of a close reading of "Mathmateca Fantasia" and other maths science fiction as an adolescent. Loved the 5 color map theorem as well. From nobody at rosebud.ee.uh.edu Thu Jun 24 09:22:37 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Thu, 24 Jun 93 09:22:37 PDT Subject: Weak steganography Message-ID: <9306241622.AA11117@toad.com> -----BEGIN PGP SIGNED MESSAGE----- Several people have suggested that PGP or some similar public-key program could be used to exchange encrypted email, then a "fake" one-time pad file could be created to transform the PGP file into a safe plaintext. If your files were seized and the keys demanded, you could supply the fake OTP file as the key which would "decrypt" the PGP file to the safe text. Unfortunately, this doesn't presently work with PGP. PGP puts a header at the front of encrypted file which identifies it as a PGP file. This includes information about whether the file is RSA or IDEA encrypted, and if it is RSA encrypted it includes information about which key(s) it is encrypted with. If files are saved like this, there will be no question that they are actually PGP files, and not the output of a one-time pad. Any attempt to produce a OTP key file which leads to a safe plaintext will be a transparent fabrication. And, of course, PGP's ASCII encoding, which would usually be used for email, boldly displays the "-----BEGIN PGP MESSAGE-----" at the top. If the files were saved in this format it would be a further giveaway. People have called for PGP to have a "stealth" mode in which it would save files without these headers. This would require the user to know which files were truly PGP encrypted, what the encryption algorithm was, and of course the key. If this were implemented it would make PGP files much less recognizable and the "fake OTP key" approach would be workable. Another approach for now would be to super-encrypt the PGP file with some other system. A simple XOR with a repeated random bit pattern (produced by hashing a user pass phrase) which is longer than the PGP header would be adequate, since the non-header portion of a PGP file should be random. Or you could use one of the widely-available DES encryption utilities, since these don't produce any headers, as far as I know. But this would complicate the process of decrypting the file. PGP's IDEA-encrypted files, which you create with the "-c" switch to PGP, put only a five-byte header on: a type byte, and a four-byte file length. This information is redundant and it should be very easy for PGP to recon- struct it if it were removed. RSA encryption headers will be harder to remove, particularly because of the lack of a key ID to tell which secret key to decrypt with. We would just try the default key, I guess. But this would require a more extensive set of changes to PGP. Hal Finney hfinney at shell.portal.com -----BEGIN PGP SIGNATURE----- iQCVAgUBLCmngKgTA69YIUw3AQGDWgP/U/HwP5gwPXn3GZgH3SH3zjnrKd8dHPqn y2OVF7xqiaVPuV5VF/UBGzFcPgfb/DuamIEr/aQmAMX2BlVktQ/fGaluZ8wvIbs/ QlQcsp+BH9AAb0BcojQ6rmwtf8A5c/3VkuGUSvyRGEX1PecdwoW8Eh/FEIfeU/WE njvIwmn92aY= -----END PGP SIGNATURE----- From gnu Thu Jun 24 09:33:36 1993 From: gnu (John Gilmore) Date: Thu, 24 Jun 93 09:33:36 PDT Subject: Perspectives In-Reply-To: <9306222124.AA00723@wixer.bga.com> Message-ID: <9306241633.AA11443@toad.com> I agree with der Cat; the paranoia here is getting excessive. I think it's most likely that the documents we received were genuine, and an attempt of someone in the Secretary of Defense's staff to explain the situation to policy-people in that office who had not kept track of what was going on. There's a lot more for the Secretary of Defense to do than to watch domestic entryption debates, and falsify documents about them just in case someone requests them under FOIA. John From dporter at well.sf.ca.us Thu Jun 24 09:56:13 1993 From: dporter at well.sf.ca.us (Doug Porter) Date: Thu, 24 Jun 93 09:56:13 PDT Subject: Government fear of strong crypto Message-ID: <93Jun24.095545pdt.13970-1@well.sf.ca.us> Jim McCoy says: > The NSA is not chartered for domestic surveillance work. This statement keeps showing up. If there is any support for it I'd like to hear it. We know it was not true as far back as twenty years ago, from July 1, 1969 to October 1973. For details on the MINARET Charter see page 150 of "The National Security Agency and Fourth Amendment Rights", and pages 323 and 324 of "The Puzzle Palace". NSA has a long history of ignoring whether they are chartered for an activity, of course. Doug From pcw at access.digex.net Thu Jun 24 10:30:58 1993 From: pcw at access.digex.net (Peter Wayner) Date: Thu, 24 Jun 93 10:30:58 PDT Subject: Government fear of strong crypto Message-ID: <199306241730.AA29024@access.digex.net> I seem to remember that Pres. Reagan authorized the NSA to help domestic law enforcement officials when "lives were at stake." But I don't have a citation. -Peter Wayner From warlord at MIT.EDU Thu Jun 24 12:18:42 1993 From: warlord at MIT.EDU (Derek Atkins) Date: Thu, 24 Jun 93 12:18:42 PDT Subject: Weak steganography In-Reply-To: <9306241622.AA11117@toad.com> Message-ID: <9306241918.AA26021@toxicwaste.MEDIA.MIT.EDU> Hal said: > Unfortunately, this doesn't presently work with PGP. PGP puts a > header at the front of encrypted file which identifies it as a PGP > file. This includes information about whether the file is RSA or IDEA > encrypted, and if it is RSA encrypted it includes information about > which key(s) it is encrypted with. First, this is only true when the file is ASCII armored. You can easily convert the file from armor to binary once you receive it and then keep it in binary form. Second, if the file is encrypted, it only contains the KeyID(s) of the recipient(s) in plain text, not the sender. > RSA encryption headers will be harder to remove, particularly because of > the lack of a key ID to tell which secret key to decrypt with. We would > just try the default key, I guess. But this would require a more extensive > set of changes to PGP. This is not necessrily true. I've been thinking of a way to try this. Don't forget, you only have a limited number of secret keys to try, so you try them all. How many keys could you have? 10, maybe? At most? I, personally, only have one secret key. I could try it, and if it fails, I know I couldn't read the file.... Basically, Hal, you are stretching the "problem" further than it needs to go, IMHO. Relax a little and take a look at what you have at your fingertips. :-) -derek From karn at unix.ka9q.ampr.org Thu Jun 24 13:51:50 1993 From: karn at unix.ka9q.ampr.org (Phil Karn) Date: Thu, 24 Jun 93 13:51:50 PDT Subject: Triggerfish Message-ID: <9306241957.AA04530@unix.ka9q.ampr.org> I just posted this to the CU (Computer Underground) digest in response to a most interesting series of items about the newsletter Full Disclosure's public mention of a Harris Corporation device marketed to law enforcement agencies for intercepting cellular telephone conversations named "Triggerfish". Harris responded with an amazing threat to sue the newsletter for a variety of offenses, including trademark infringement (for merely mentioning the product in a brief "new products" editorial). The CU digest can be read on the usenet newsgroup comp.society.cu-digest; the issue in question is Volume 5, Issue 46. Phil To: tk0jut2 at mvs.cso.niu.edu Reply-To: karn at servo.qualcomm.com Subject: Re: Cu Digest, #5.46 In CU Digest 5.46: |> Harris Law Enforcement Products |> |> TRIGGERFISH has a number of cellular phone based applications: |> determining a suspects phone number, dialed number recorder, and |> wiretapping. According to Harris, ``for the first time, law |> enforcement is not at a disadvantage in tracking the high-tech |> criminal.'' Additionally, the unit ``collects and integrates all |> relevant data, including voice, directly from the ether.'' |> Reprinted from Full Disclosure, Box 903, Libertyville, Illinois 60048 I find the phrase "directly from the ether" *most* illuminating given a rather heated exchange I had with Mr. Jim Kallstrom of the FBI at the recent CPSR Cryptography Conference in Washington DC earlier this month. Kallstrom is the FBI's chief public advocate for their "Digital Telephony Initiative". Among other things, they want the ability to intercept suspects' cellular telephone calls at the MTSO (switch). Only with a valid warrant, naturally. At the meeting, I made the following comments. I had seen the standards-setting process for the new digital cellular telephone systems from the inside as they related to security and privacy. And I was wondering why the government (specifically NSA, through its export control reviews) was so strongly opposed to meaningful air link encryption, even if the encryption were to stop at the switch as it would have to in order to be compatible with existing telephones on the land side of a cellular call. Such encryption would secure the air link, the most easily intercepted portion of a cellular telephone call, while leaving the conversation in the clear at the MTSO where it could be tapped, if necessary. In a private conversation, one of the senior members of the committee who didn't want his name mentioned told me why. "It's very simple", he said. "Anybody can intercept the radio link. It's easy. But tapping a call at the switch requires the cooperation of the telephone company, and they generally require warrants. And law enforcement says that sometimes, warrants are, well, just too damn inconvenient." This really set Kallstrom off. He shouted me down, attacking my unwillingness to name my source. I challenged him, unsuccessfully, to back up *his* shrill claims for the absolute necessity of Digital Telephony with anything more than handwaving. After tempers cooled a bit, in a one-on-one conversation during a break, he insisted to me that the FBI was never interested in intercepting the air link portion of cellular calls - "too difficult, too labor-intensive", he said. He agreed that he'd like to see cellular air links encrypted. They only wanted the capability to tap in at the switch, and he couldn't care less if the air link were securely encrypted (though he still wanted the keys to be escrowed for some reason...hmmm...) Perhaps it was a desperate attempt to maintain this "we're not interested in the air link" fiction that triggered Harris's silly overreaction to the public mention of TRIGGERFISH. Phil From kellyg at sco.COM Thu Jun 24 14:37:12 1993 From: kellyg at sco.COM (Kelly Goen) Date: Thu, 24 Jun 93 14:37:12 PDT Subject: Government fear of strong crypto Message-ID: <9306241425.aa09999@vishnu.sco.com> From mail.netcom.com!toad.com!cypherpunks-request Wed Jun 23 23:23:59 1993 Return-Path: Message-Id: <199306240625.AA19484 at tigger.cc.utexas.edu> Subject: Re: Government fear of strong crypto To: cypherpunks at toad.com Date: Thu, 24 Jun 1993 01:25:13 -0500 (CDT) From: Jim McCoy Cc: pfarrell at cs.gmu.edu In-Reply-To: <70188.pfarrell at cs.gmu.edu> from "Pat Farrell" at Jun 23, 93 07:29:41 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2400 > From: "Pat Farrell" [...] > > The "government" as a whole is not against crypto. The NSA is _very > strongly_ against it. There are 60,000 or more bureaucrats in NSA that would > be effectively put out of work by widespread strong crypto. Hmmm..... actually I must disagree with this. The NSA may oppose strong crypto, but a few facts should be brought up: 1) The NSA is not chartered for domestic surveillance work. If you discover the NSA watching you within the US you can have them arrested. They are probably more interested in the systems being put in use around the world and less about systems internal to the U.S. According to the Bill of Rights Foundation Booklet "CIA OFF CAMPUS" Ex-President Reagan signed in 1981 Executive order # 12333 Which permits the CIA to operate domestically against US citizens if it is believed that said citizen is either an agent of a foreign power or acting on behalf of same. Since this definition has been used during COINTELPRO to allow one to have associates /friends that are foreign born to cause one to be subject to a whole range of unconstitutional activities performed by said agencies. BTW ANY federal intelligence agencie will act as a "cutout" for situations where the prime agency cannot operate legally but another can. I believe a FOIA is in order to find out if E.O. #12333 allows the entire national security apparatus to operate or only the CIA... Unhappily yours kelly > I believe that the FBI and other more public agencies are simply shills for > NSA. The many posting about real wiretap usage and costs simply can't > support taking all the heat last year of Digital Telophony and this year > over Clipper, esp. when they admit that smart crooks wouldn't bother to use > Clipper. Entirely True...! From pcw at access.digex.net Thu Jun 24 14:57:27 1993 From: pcw at access.digex.net (Peter Wayner) Date: Thu, 24 Jun 93 14:57:27 PDT Subject: Karn's note... Message-ID: <199306242157.AA26979@access.digex.net> On Over-the-air encryption... If anyone wants to read Tom Clancy's latest book, _Clear and Present Danger_ about a set of covert operations against drug kingpins in South America, they will note that he mentions a magic box that will scan the airwaves for voices on the cellular channels. This allows the protagonists to follow the conversations of the kingpins as they hop from limo to limo using a different phone with each conversation. Does TriggerFish do this? My theory is that the 260-bit repeated XOR code was proffered because it wouldn't interfere with algorithms that were doing simultaneous voice recoginition. It is, after all, just the equivalence of doing a discrete convolution across the signal. I believe that this should be easy to handle with a few clever signal processing algorithms designed for noise reduction. I don't know this with any stretch of confidence so I would like to be disabused of this idea if it's harder than all of that. --Peter From karn at qualcomm.com Thu Jun 24 15:33:15 1993 From: karn at qualcomm.com (Phil Karn) Date: Thu, 24 Jun 93 15:33:15 PDT Subject: Karn's note... Message-ID: <9306242232.AA08245@servo> I tend to doubt that the spooks have voice recognition technology in regular widespread use, at least not the kind of ultra sophisticated stuff that AI types seem to dream about. It's possible that they use less sophisticated stuff as a "pre filter" (compress out silence, perhaps distinguish male from female voices, etc), but I'm sure that the bulk of the work is still very labor intensive. Tens of thousands of clerks, intercept operators and natural language translators have long been employed by the NSA and there don't seem to be mass layoffs of these sorts of people around Fort Meade. And sophisticated voice recognition really isn't necessary when you consider all of the information that cell phones and base stations emit that is almost trivially processed automatically by an intercept device: electronic serial numbers, Mobile Identification Numbers (telephone numbers), handoff messages, channel assignment messages, etc. It's no big deal at all to build boxes that automatically intercept all calls made to or from a specific phone, assuming you have an RF path to the target (e.g., from a car tailing a suspect). As a manufacturer of cellular telephones, we have such a box (commercially made by IFR) in our lab. We use it to test our phones in their FM/analog mode. The spooks (NSA and otherwise) simply cannot be uninterested in boxes like these -- and in preserving their capabilities. One point I keep making about Clipper: it makes this sort of automated identity tracking as easy on regular telephone lines as it already is on cellular, because the chip serial number in the Law Enforcement Block can be decrypted with just the (common) Family Key - you don't need the escrowed keys. And sometimes simple traffic analysis can be almost as deadly as getting the actual contents of a conversation. Phil From pcw at access.digex.net Thu Jun 24 15:51:28 1993 From: pcw at access.digex.net (Peter Wayner) Date: Thu, 24 Jun 93 15:51:28 PDT Subject: Karn's note... Message-ID: <199306242251.AA02335@access.digex.net> I believe the novel implied that the magic box didn't do voice recognition in the sense of identifying the words being spoken. It just said, "Hey, that sounds like Bob Smith on line 42." The point was that these guys were jumping around from phone to phone. But, I agree with you that traffic analysis should be much easier now with all of the ID tags. I think the Clancy box would be too much overkill because people really don't use that many telephones during the day. Especially now that they call carry pocket cellular phones. -Peter From kellyg at sco.COM Thu Jun 24 16:14:30 1993 From: kellyg at sco.COM (Kelly Goen) Date: Thu, 24 Jun 93 16:14:30 PDT Subject: Karn's note... Message-ID: <9306241603.aa11010@vishnu.sco.com> From toad.com!cypherpunks-request Thu Jun 24 15:34:07 1993 Return-Path: Date: Thu, 24 Jun 93 15:32:54 -0700 From: karn at qualcomm.com (Phil Karn) Message-Id: <9306242232.AA08245 at servo> To: cypherpunks at toad.com, pcw at access.digex.net Subject: Re: Karn's note... I tend to doubt that the spooks have voice recognition technology in regular widespread use, at least not the kind of ultra sophisticated stuff that AI types seem to dream about. It's possible that they use ln. Much Deleted... \ Hi Phil... All the reports I have seen on the widespread phone tapping and voice recognition by the NSA allegedly was in reference to Operation HARVEST According to private estimates immense intel value results even if the recog phase gets 15-20% accuracy on most? speakers... for phrases such as Spook, espionage,drugs etc... Most of the references I saw to HARVEST were published by the Bill of Rights foundation in various of their books and phamplets and reports from the Church Subcommittee hearings on intelligence activities during the earlier abuses of COINTELPRO, with a few references in "The Puzzle Palace" by Cliff Bamford. I also saw some refeneces about 5 years ago in comp.dcom.telecom... as to these kind of operations. Do they really do it??? hmm dont know but I am not taking any chances!! :) Phil From peb at PROCASE.COM Thu Jun 24 16:27:21 1993 From: peb at PROCASE.COM (Paul Baclace) Date: Thu, 24 Jun 93 16:27:21 PDT Subject: Karn's note... Message-ID: <9306242327.AA02594@banff.procase.com> >sounds like Bob Smith on line 42 This is speaker recognition, not voice recognition. It turns out that the problem is solved in a very different way for each; voice recognition, in order to be speaker independent, must throw out the information that makes it possible to do speaker recognition (and vice versa: the latter does not need some of the information that the former needs). This is used in "roving wiretaps" that apparently are used infrequently as they scan whole exchanges or number sets (e.g., all payphones in some city). The idea is to capture phone calls from the suspects that are savvy enough to know that they are being tapped. At least one Mob boss was caught this way (in Los Angeles, I think, about 4-5 years ago). Paul E. Baclace peb at procase.com From M..Stirner at f28.n125.z1.RBBS-NET.ORG Thu Jun 24 17:32:16 1993 From: M..Stirner at f28.n125.z1.RBBS-NET.ORG (M. Stirner) Date: Thu, 24 Jun 93 17:32:16 PDT Subject: Remailer origin lines Message-ID: <47.2C2951B0@wyrm.rbbs-net.ORG> * Reply to msg originally in CYPHERPUNKS Uu> 1) Chop off anything that even looks signature-like, whether the Uu> user intended it or not -- I consider this ugly, evil, and Uu> unreliable, and likely to chop stuff I want kept and leave stuff I'd Uu> like chopped. Yes, this seems fraught with problems. Uu> A "Dont-Mess-With-Trailers:" header line would help a bit. I agree. Uu> I don't know how much of Uu> M. Uu> ___ Blue Wave/QWK v2.12 Uu> -- Uu> M. Stirner - via RBBS-NET node 8:914/201 Uu> INTERNET: M..Stirner at f28.n125.z1.RBBS-NET.ORG Uu> was added by the author, how much by the Blue Wave and/or Uu> 8:914/201, or even for certain whether M. Stirner is the author or Uu> merely a machine owner; I'm guessing the author, and I'm guessing Uu> everything but the initial "M." was added automagically under the Uu> machine-owner's control. The BlueWave blurb was added by the program & can be stripped by re-editing the message before upload. Everything else is out of my control completely & added automagically by the host or the UUCP gateway. The sucker stays, no matter what I do. Some anonymity! Uu> 2) Cut-Here: lines of various sorts, either following a pre-specified Uu> syntax or a MIME-like flexible syntax. I like this approach, since Uu> it gives the user a reasonable level of control and very seldom Uu> guesses wrong, but there are so many standards to choose from, and a Uu> proper implementation would have to leave in the line (or add an Uu> equivalent) at each hop to avoid accretion of path-traces, and make Uu> sure it gets the correct syntax for each following remailer. And Uu> the user does have to explicitly request it, which some people Uu> view as a problem, especially if they don't know the characteristics Uu> of the later mail-handlers in the chain. I, personally, could live with it just to get the remailers to be truly anonymous. The rest of the user input is not especially easy anyway, particularly if accessing internet via a gateway. Another line wouldn't kill me. Uu> 3) Encryption-based systems, which only retain the encrypted portion; Uu> this means the user has to know more about the remailers being Uu> used, and there has to be a standard for expressing which remailers Uu> to forward to if more than one will be used (which it probably will Uu> be, for anybody security-aware enough to really want an encrypting Uu> remailer.) As an interrim measure I guess this is what I'll have to do, but as an early PGP partisan, I've had enough PGP experience not to be turned off by the extra trouble. Most casual users would be. In any case, I think that this is undoubtedly the most user-labor-intensive solution. Uu> Solving the problem for message headers is tougher than solving it Uu> for trailers. In that case, let's have this solved by Monday. 8-) ********************************************************************* * - 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 RBBS-NET node 8:914/201 INTERNET: M..Stirner at f28.n125.z1.RBBS-NET.ORG From ld231782 at longs.lance.colostate.edu Thu Jun 24 18:00:09 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Thu, 24 Jun 93 18:00:09 PDT Subject: NSA expert diagnosis: manic hypercryptophobia In-Reply-To: <199306240625.AA19484@tigger.cc.utexas.edu> Message-ID: <9306250059.AA06932@longs.lance.colostate.edu> Well, I promise not to rant as long as no one goes soft on Clipper and the NSA. Unfortunately for the cause, I've been busy lately. Jim McCoy posts some (ahem) interesting opinions on the NSA: > 1) The NSA is not chartered for domestic surveillance work. If > you discover the NSA watching you within the US you can have > them arrested. They are probably more interested in the > systems being put in use around the world and less about > systems internal to the U.S. they are not `chartered' per se but as Bamford makes clear everyone from the director and all the way down thinks that they live in a sort of extra-legal limbo. The NSA has a Napoleonic complex and delusions of grandeur that it is the fourth branch of the U.S. government--the Police Branch (with additional powers to make policy submissions on the level of the Executive branch). The vague and secret laws supposedly `governing' them do nothing to restrain them. There is even a law that exempts NSA from certain laws unless specifically mentioned! And tell me, who's job is it to arrest a corrupt police officer? (A: the American public.) `They are probably more interested in systems in use around the world than in the U.S...' well, this is a rather strange comment. It reflects both a false dichotomy and a true mutual exclusion. NSA and its members think that what happens in their bunker and the U.S. is universal. It has a very imperialistic and egotistical view regarding its sovereign cryptographic role, you understand. The argument that what happens in the U.S. cryptographic arena is relevant to the world at large is wrong for precisely the reasons the NSA believes in it and right for precisely the reasons they fear. Namely, yes, if U.S. exports strong cryptography it will penetrate the world faster. That is how the U.S. *does* matter. If the U.S. lags behind from absurd and asphyxiating regulations, we will find ourselves inundated by superior products from the outside by countries that don't have bizarre taboos against strong cryptography and secure protections for the privacy of their citizens. That is how the U.S. *doesn't* matter. Either way, the proliferation of strong cryptography is inevitable. The NSA believes that strong cryptography will be restricted internationally to the point that the U.S. quashes it. The truth is that the U.S. will be quashed internationally to the point that it restricts strong cryptography. > 2) The NSA has been dealing with strong cryptography for a long > time. These are the people who have been playing crypto games > with "the Ruskies" since before I was born. I sincerely doubt > they are losing a great deal of sleep over the fate of Clipper. > ... no one at Fort Meade is going to be getting a pink slip if Clipper goes down in flames. That's the problem. They should be, if they were truly accountable for their actions and not insulated and inbred bureacrats. Where are the rolling heads? Clipper is an unadulterated fiasco in every respect except in bringing greater public attention to unconscionable clandestine machinations in our government and cryptographic technology. For the former, please spare us the depraved exhibitions. For the latter, far more ethically superior demonstrations are possible. (To say the least for both.) >The FBI, and other domestic law enforcement agencies are probably very gung >ho for weak crypto, but I just don't think that No Such Agency is going to >be greatly effected by it. Thier fingerprints are all over the Clpper >stuff, but seeing as how thier other mission is to develop ciphers this is >only natural. Fingerprints? More like a blaring signature in neon or spraypainted graffiti. Clipper as `only natural'? I suppose in the way one would consider a stillborn monster `natural'. NSA will not be affected by strong cryptography if it doesn't spread, that's correct. But that's like saying Communists would be unaffected if they could prevent the spread of technology. The spread of strong cryptography worldwide to the great detriment of signal interception is absolutely inevitable. Clipper only shows that NSA has deluded itself seriously enough to fail to recognize this basic truth to the point of investing huge sums of money, expertise, and audacity in an illegitimate project doomed to failure by its fundamental premise: that a government can control *any* technology (let alone a powerful emerging one) to perpetuate its own warped agenda and status quo. P.S. the `beta vs. VHS' reference is nothing but NSA propaganda and the terminology of apologists and spooks, and I hold it against you for using it. In only one way is it apt: the government is hoping they can entrench their inferior VHS standard by market momentum and black behind-the-scenes machinations despite the technical superiority of competitors. Well, sometimes inferior standards win out in the marketplace, but only temporarily and never indefinitely. And no government proposed VHS, or they would have been either laughed or chased off the face of the earth. From huntting at glarp.com Thu Jun 24 19:51:25 1993 From: huntting at glarp.com (Brad Huntting) Date: Thu, 24 Jun 93 19:51:25 PDT Subject: Government fear of strong crypto In-Reply-To: <9306241425.aa09999@vishnu.sco.com> Message-ID: <199306250251.AA01259@misc.glarp.com> > According to the Bill of Rights Foundation Booklet "CIA OFF CAMPUS" > Ex-President Reagan signed in 1981 Executive order # 12333 Which > permits the CIA to operate domestically against US citizens if > it is believed that said citizen is either an agent of a foreign power > or acting on behalf of same. I seem to remember that at about this time, the entire inteligence community (part or all of the NSA, DEA, DOE, DOJ, CIA, DOD, and the Treasury Dept) was reorganized and placed under something called just "Central Inteligence" (CI). Or is this just mistacken beurocratic trivia? brad From huntting at glarp.com Thu Jun 24 20:26:37 1993 From: huntting at glarp.com (Brad Huntting) Date: Thu, 24 Jun 93 20:26:37 PDT Subject: a new role for the NSA In-Reply-To: <199306241253.AA00313@access.digex.net> Message-ID: <199306250326.AA01446@misc.glarp.com> > If I was in charge of the NSA, I would argue to my budget-dispensing > superiors that all of the strong crypto just meant that I needed > a bigger budget to scan for data. Indeed, the NSA's opposition to crypto (be it bad standards or arcane export regulations) has one clear intent: to keep down the cost of wiretaping. Wiretaping makes it easier for "law enforcement" to identify and take action against undesirable elements. Be it communists, environmentalists, unsanctioned drug dealers, civil rights activists, union leaders, guerila heating engineers, or just some poor bloke who blew the whistle on the wrong multinational; wiretaping facilitates not only finding them and finding what to charge them with. brad From ld231782 at longs.lance.colostate.edu Thu Jun 24 22:13:14 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Thu, 24 Jun 93 22:13:14 PDT Subject: Denning on Clipper review panel Message-ID: <9306250513.AA09659@longs.lance.colostate.edu> Denning says she is on the Clipper review panel which has just started. Also, noises about international Clipper cooperation from NIST. Finally the cypherpunk poster's earlier comment about the absurdity of French collaboration left to the imagination is brought to life... From: philip at charon.cto.citicorp.com (Philip Gladstone) Newsgroups: sci.crypt,alt.privacy.clipper Date: 23 Jun 1993 17:53:19 -0400 >According to Lynn McNulty (of NIST) ... > >Also, the civilian review of the Skipjack algorithm has started (on Monday). >2 people are from academia, and 3 from private industry. One of the DOE >national labs is represented (but I don't know whether this counts as academia >or private industry). Dorothy Denning is one member (according to her). >McNulty wouldn't reveal any names. > >Also, McNulty beleives that escrowed keys would be made available to >foreign law enforcement organizations if requested. The following >scenario springs to mind: > > French LE to FBI: We have one suspect from the WTC bombing > under surveillance in Paris. He uses a > clipperphone to communicate. Can we have > the keys to chip ID 145632? > FBI to French LE: Are you working with the French Secret Service > who is trying to tap the phones of corporate > America? > French LE to FBI: NON! > FBI to French LE: Do you promise that the chip ID > 145632 really is in Paris and is not in the > phone of ? > French LE to FBI: OUI! > FBI to French LE: OK - the key is 0b5e7f186ac85e5fb934. > >I'm not trying to pick on the french, but one of the purposes of the >Clipper (sorry Key Escrow) Chip is to protect against foreign >commercial espionage. From nobody at shell.portal.com Thu Jun 24 22:17:27 1993 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Thu, 24 Jun 93 22:17:27 PDT Subject: Chained remails Message-ID: <9306250503.AA27769@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- M. Stirner, , writes: > Gee, am I amazed. An anonymous post claims to have been routed via > SIXTEEN (presumably cypherpunks) remailers. Using the posted list of > "active" cypherpunks remailers & the revised remailer manual, I have > been unable to get simple > > To: remailer at wherever.doodah.edu > > :: > Request-Remailing-To: > > test messages to run through any but a couple (9, 10 & 12 I believe). I > have _never_ been able to get any of the "insects @ Berkeley" remailers > to go with the standard syntax...or otherwise. The problem may be the Fidonet addressing. Many times I have tried to send mail to people with mailing addresses like M's, and not had the mail get through. I don't know what the rules are but perhaps some systems can get it and some can't. I'd suggest to M. that he take one of the systems that does respond to his remailing requests, and have that be the LAST one in a chain of two. So, he could send to, say, hh at cicada.berkeley.edu, and follow that with elee7h5 at rosebud.ee.uh.edu. Perhaps this would get through: To: hh at cicada.berkeley.edu :: Request-Remailing-To: elee7h5 at rosebud.ee.uh.edu :: Request-Remailing-To: M..Stirner at f28.n125.z1.FIDONET.ORG Even if cicada can't mail to him, perhaps it can mail to rosebud which can then mail to Fido. Hal Finney hfinney at shell.portal.com -----BEGIN PGP SIGNATURE----- iQCVAgUBLCpauqgTA69YIUw3AQEoYwP/TUiqRu8OHgA61WM6HVtrZ/CE37hXjVY7 WM7sN+RkUlO+1QTeZKi2r0gEy/CGKnZiMTbEHYHcWK486tIbDZIDXqdRoZigEemH 5jwComG9Vv6wPMFyhcLQkejgSX7nN0UU4TGzdOOq2kRyiplTysLd+1pqPyUzpsbU qR9lO8ZjVPY= -----END PGP SIGNATURE----- From wmo at rebma.rebma.mn.org Thu Jun 24 22:47:36 1993 From: wmo at rebma.rebma.mn.org (Bill O'Hanlon) Date: Thu, 24 Jun 93 22:47:36 PDT Subject: Remailer at rebma.mn.org Message-ID: My apologies to anyone who has tried to use the anonymous remailer at rebma.mn.org in the past several weeks. I upgraded the system, and forgot, apparently, to test out the remailer. No one reported that the remailer wasn't working, and it didn't occur to me to test it until today. I imagine that people who weren't successful were experimenters who chalked up the failure to something they'd done wrong. It's working again, now. Here's the PGP key. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKQ== =/qHx -----END PGP PUBLIC KEY BLOCK----- From rclark at nyx.cs.du.edu Fri Jun 25 01:43:51 1993 From: rclark at nyx.cs.du.edu (Robert W. F. Clark) Date: Fri, 25 Jun 93 01:43:51 PDT Subject: Thanks, anon Message-ID: <9306250844.AA10053@nyx.cs.du.edu> n12070 at anon.penet.fi (Anonymous dude) writes: >I considered bringing up this little anecdote that happened to me in >`real time' but decided against it, but now can't resist while the >subject is in the list's psyche and nanosecond attention span: Thanks. I'm geographically and culturally isolated in Indiana. You warn that your article is tedious, but it is no such thing. Thanks for posting it. It is perversely pleasing to me to know someone else on the list went through this sort of cop crap. Of course, I was at least technically in violation of the law, but hey. They went after practically everyone I knew, for the vile crime of having me in their address books. I wrote an article about that experience which should appear in the next Phrack. So that you won't feel that your anecdote was tedious, which it certainly was not, you might want to check mine out (it clocks in at about five to six times as long as yours.) >Thanks for listening to all this, it is immensely therapeutic for me >and hopefully some insight is contained herein to minimize a burden for you. Thanks for sending it out; it was nicely written, and concise. Bet they never see the computer again, though. Either someone ripped it off for their personal use, or for quick cash, and in either case they would have got them by now. They may just have hassled you as a last resort when the trail went cold. Police are, indeed, ungrateful brutes of the worst dye. Well, good luck, and I hope all that nasty stuff is over for you. Cop betrayals and "investigations" usually leave a bitter taste in the mouths of their targets, especially since cops can get nasty when they're not finding anything. Ah well. ---- Robert W. Clark rclark at nyx.cs.du.edu PGP signature available by mail or finger From gg at well.sf.ca.us Fri Jun 25 02:47:40 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 25 Jun 93 02:47:40 PDT Subject: Triggerfish Message-ID: <93Jun25.024716pdt.14146-3@well.sf.ca.us> On-the-air interception *is* too labor intensive, relatively speaking, given that a cellular call originating or terminating at a given switch can pass through a number of individual cells, each of which would need to be monitored. However, that does not negate the potential usefulness of on-air interception as an *intelligence-gathering* tool from which the results can be fed into the process of getting a warrant to tap at the switch. The problem of maintaining privacy can be and in fact *is* effectively solved though. A couple of companies are making cellular to 2500-set adapters which basically allow any regular single-line device to be plugged in and transmit via cellular. This obviously includes standard modems, plus or minus the problems associated with variable transmission quality over the airwaves. So any regular cryptosystem that can work on analog lines should be applicable here. If anyone out there is further interested in these cellular-to-single-line-device adaptors, email me and I can get prices and specifications. -gg From karn at qualcomm.com Fri Jun 25 03:21:16 1993 From: karn at qualcomm.com (Phil Karn) Date: Fri, 25 Jun 93 03:21:16 PDT Subject: Weak stenography. Message-ID: <9306251019.AA13652@servo> Tim May: >Some solutions: >1. Make programs like "readdat.exe" ubiquitous...distribute them on >shareware disks, CD-ROMs, etc. Thus, many households and offices will >have "readdat.exe"-like programs, whether they use them or not. Mere I like this idea, as long as the mere possession of such programs isn't also criminalized. Don't laugh -- the government actually seems to think that they can enforce laws banning the mere private possession of certain types of bit patterns, like child pornography. I have about two dozen CD-ROMs on my shelf, containing the usual oodles of gigabytes of stuff. Mostly mirrors of anonymous FTP archives and shareware BBSes. So far I have read only a tiny fraction of the bits on those disks, and I expect I'll never read much more. There's no reasonable way I could be expected to know if there isn't a contraband file or two buried in all those gigabytes. But consider the Akron BBS operator who got busted for a file that somebody had uploaded to his machine, transferred off to backup and forgotten. I wonder how many similar files have already made it to CD-ROM? Makes me kind of wish I had bought all my computer equipment and software anonymously, for cash... Phil From karn at qualcomm.com Fri Jun 25 03:29:06 1993 From: karn at qualcomm.com (Phil Karn) Date: Fri, 25 Jun 93 03:29:06 PDT Subject: DH for email (re: email protection and privacy) Message-ID: <9306251027.AA13692@servo> Phil Karn asks: > >You're not required to go *beyond* what is specified in a subpoena. > >But the subpoena's specifications can be pretty broad. > > Are you talking civil, criminal, or both? Mike Godwin replies: I assume you're asking about civil versus criminal contempt. Me again: No, I was actually asking about the differences between subpoenas in civil and criminal cases. Since the 5th amendment specifically mentions criminal cases, I presume that means it can't shield you in a civil case (unless perhaps the same information could also implicate you in a crime.) Phil From nobody at alumni.cco.caltech.edu Fri Jun 25 05:32:09 1993 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Fri, 25 Jun 93 05:32:09 PDT Subject: Chained remails Message-ID: <9306251230.AA10558@alumni.cco.caltech.edu> M..Stirner at f28.n125.z1.fidonet.org (M. Stirner) sez: > > Gee, am I amazed. An anonymous post claims to have been routed via > SIXTEEN (presumably cypherpunks) remailers. Using the posted list of > "active" cypherpunks remailers & the revised remailer manual, I have > been unable to get simple > > To: remailer at wherever.doodah.edu > > :: > Request-Remailing-To: > > test messages to run through any but a couple (9, 10 & 12 I believe). I > have _never_ been able to get any of the "insects @ Berkeley" remailers > to go with the standard syntax...or otherwise. > > Are most remailers down on any given day? Could Mr. Sixteen Jumps do it > twice in a lifetime? Well, I really used only 5 different remailers, total of 16 hops. I Should haf made that clearer. The ones I used were: hh at pmantis.berkeley.edu hh at cicada.berkeley.edu hh at soda.berkeley.edu hal at alumni.caltech.edu hfinney at shell.portal.com This message will go through 24 hops, just for the heck of it. ....Mr. Funn From 76630.3577 at CompuServe.COM Fri Jun 25 12:22:17 1993 From: 76630.3577 at CompuServe.COM (Duncan Frissell) Date: Fri, 25 Jun 93 12:22:17 PDT Subject: SEARCH ME Message-ID: <930625191757_76630.3577_EHK47-1@CompuServe.COM> (an12070) It is rarely to one's advantage to "assist the police." In fact in British English the sentence "Fred C. Schwartz is assisting the police in their investigation" means that Fred C. Schwartz is the prime suspect. (Trivia contest for ex right wing nuts - Who was Fred C. Schwartz?) My search warrant story need not use penet.fi. In the early 80's I was residing in a rented house in a city located in a region of the country that was once Democratic Farm Labor Party territory. Being an inveterate reader of the newspaper, I was one day surprised to discover that our house was to be searched by the authorities at some point in the next few weeks. Specifically, the article said that the houses on block of street were going to be searched as part of a survey to determine how many had illegal basement drains. Apparently the criminals who had constructed much of the housing in that neighborhood in the 1920s had connected basement drains to the *storm sewers* from whence who knows what hideous substances could drain into the navigable waters of the United States without undergoing tertiary, secondary, or even primary treatment. What's more, they had not complied with the Water Quality Act of 1970, as amended. Who could believe that such evil exists in the human heart. My wife (who in many ways was just the sort of female Kipling had in mind when he penned 'Deadlier Than the Male') and I decided to resist this search. Since I was away during the day, it would fall to here to deal with the authorities. In due course, a sewer inspector rang our doorbell. My wife demanded to see his warrant. He was shocked and mortified. He tried to talk her into allowing the search. He used primate arguments like "everyone else is letting us in." My wife used Northern European arguments like "I'm not everyone else." He went away. Over the next few weeks, various bureaucrats called my wife and tried to get her to change her mind. They said, "You're not going to force us to waste all that time and money and get a warrant, are you?" She replied, "Consider it a valuable education on the 4th amendment." Eventually, they showed up with a warrant and some cops just in case we resisted. My wife took her time reading the warrant. It said they could search the basement so she led them around to the back door and led them down to the basement where they discovered our criminal drain. If I hadn't been working 70 hours a week, maybe I would have had fun and tried to quash (not squash) the warrant and explored the modern case law involving regulatory searches - a nasty area. When we told our neighbors what we had done they said that they didn't know that one could resist a warrantless search. A good time was had by all. Quo warranto? This was also a town where the public and catholic schools all ended summer vacation on the same day. After that day, my youngest daughter was going about from place to place without apparent lawful occupation when an officious intermeddler asked her why she wasn't in school. She then told her questioner what I had told her to say, "My father doesn't believe in your schools, he says that they are all dominated by communists." Shuts them up every time. Duncan Frissell Who is writing this in the terrorist capital of the US - Jersey City, NJ - but who has been denied a tactically necessary assault rifle by Governor Jim Florio. When amonium nitrate and diesel fuel in a 16 to 1 ratio are outlawed only outlaws (and farmers) will have amonium nitrate and diesel fuel in a 16 to 1 ratio. From talon57 at well.sf.ca.us Fri Jun 25 12:27:36 1993 From: talon57 at well.sf.ca.us (Brian D Williams) Date: Fri, 25 Jun 93 12:27:36 PDT Subject: triggerfish Message-ID: <93Jun25.122707pdt.13989-3@well.sf.ca.us> Phil Karn posted; In CU Digest 5.46: |> Harris Law Enforcement Products |> |> TRIGGERFISH has a number of cellular phone based applications: |> determining a suspects phone number, dialed number recorder, and |> wiretapping. According to Harris, ``for the first time, law |> enforcement is not at a disadvantage in tracking the high-tech |> criminal.'' Additionally, the unit ``collects and integrates all |> relevant data, including voice, directly from the ether.'' |> Reprinted from Full Disclosure, Box 903, Libertyville, Illinois 60048 It would be child's play for the NSA to accomplish this from orbit.....hmmmmm I wonder what they call it? Brian D Williams From jet at netcom.com Fri Jun 25 12:36:49 1993 From: jet at netcom.com (J. Eric Townsend) Date: Fri, 25 Jun 93 12:36:49 PDT Subject: USAF Incident Summary Message-ID: <9306251937.AA17842@netcom4.netcom.com> A couple of somewhat interesting crypto tidbits. ------- Start of forwarded message ------- [From the NIST Security Bulletin Board] FROM: AFCSC/SRM 250 Hall Blvd, Suite 347 San Antonio TX 78243-7063 SUBJ: THE CONNECTION Information Letter AFOSI COMPUTER CRIME CASES by TSgt Dwayne L. Thomas AFCSC/SRME Destruction of Government Property, Unauthorized Access to Material, Violation of Article 134 of UCMJ Location: CONUS Motive: Personal revenge and vandalism Duty Position: Systems Administrator, Military An investigation was initiated after a CONUS-based research center had reported that various files contained in the center's mainframe computer had been altered. The subject (a Sgt assigned as the Systems Administrator) had created a program that only he was able to access. This resulted in the subject being able to access, extract, and subsequently delete information without being detected. Being the Systems Administrator, the subject had enough knowledge of the passwords, audit trails, and software to manipulate information at will. After the investigation began, subject admitted fixing the computer so that no one else could access the subject's personal program. The subject was upset with upper management for not giving the amount of recognition due for creating another program for the center's use. Subject stated that months had been spent working on this program. Subject also felt pressured because past job performance and two altercations at the NCO Club might cause denial of reenlistment. Subject also was a co-owner in a failing carpet and upholstery cleaning business and stated that building a program that only one person could run would make the subject important to the mission and increase chance for reenlistment. Subject was fined 1 month's pay, denied reenlistment, and given a bad conduct discharge. BOTTOM LINE: It is vitally important that no one person have all the knowledge about how to operate a system because if one day that person is sick, quits, or dies, the organization will be in a world of trouble. Some ways to prevent this are by assigning a primary and alternate administrator, having continuity books available, and having training sessions. Remember, computers are dumb machines and are only as smart as the person who's programming them. Wrongful Use and Conversion of Government Computer, Theft of Government Property, Copyright Violation, Violation of Title 18 of U.S. Code 641 Location: CONUS Motive: Personal financial gain Duty Position: Functional User, Military An investigation was initiated after it was discovered that a SSgt assigned to the Base Data Processing Facility had been misusing government resources for personal profit. The subject was working part time for a local contractor and was making profit by making illegal copies of government purchased software. The subject would take pieces of equipment from the duty section and provide it to the contractor. The subject would copy the government software and provide one copy to the contractor and keep one copy so that it could be replicated and sold for more money. After the investigation began, the subject admitted making copies of the government software and contacting other companies to see if they wanted to purchase copies of the stolen software. Subject also admitted bringing disks in from home and running them on the government systems for evaluation. Subject felt that even though violations had occurred, accountability was questionable because security briefings on the legalities involved with copying government software had not been provided. The extra money had helped the subject with a bad financial situation. The subject resigned from his part-time job, was fined 2 months' pay, given a letter of reprimand, and placed on a control roster. BOTTOM LINE: Even though the Air Force purchases large amounts of software from various companies, it is still subject to copyright laws the same as any individual. We must continue to educate all our personnel that this is a very, very serious offense and complacency is not an acceptable excuse. Also, the risk of introducing viruses from unauthorized software onto a computer system can completely halt an operation. Never allow unauthorized software into your duty section. Remember, taking chances like this with the security of your system is like having a friend with a drinking problem and for his/her birthday you give him/her a shopping spree at a liquor store--it's a no-win situation! COMSEC INCIDENTS by Mr Richard L. Davis AFCSC/SRMP The total number of physical and cryptographic COMSEC incidents reported within the Air Force for the following past 2 years were: CY91 - 480 CY92 - 364 This Trend Summary will compare CY91 with CY92 COMSEC incidents and the previous 6 months with the past 6 months. Data on practices dangerous to security (PDS) will also be included in this summary. The total number of COMSEC incidents reported for the Jan-Jun 92 time frame was 191 as compared to the Jul-Dec 92 total, which was 173. This is a decrease of 18 incidents. The total and type of COMSEC incidents that occurred in CY91 and CY92 are: Type Of Incident 1991 1992 Physical 432 330 Cryptographic 48 34 Total: 480 364 PDSs 74 116 Physical, cryptographic, and PDS COMSEC incidents are categorized into the following types and totals (comparing the past 6 months with the previous 6 months): Physical Categories: Jan-Jul 92 Jul-Dec 92 Totals Loss Control Of COMSEC 53 63 116 Permanent Loss 49 32 81 Unsecured Safes/Workcenters 20 15 35 Destruction Irregularities 19 17 36 Lost Two-Person Integrity 7 14 21 Unauthorized Access/Use 13 4 17 Damaged Packages 4 6 10 Unauthorized Shipping Mode 5 4 9 Unauthorized Reproduction 2 2 4 Facility Construction 1 0 1 Totals: 173 157 330 Cryptographic Categories: Used Superseded Material 1 1 2 Extended Crypto Period 9 8 17 Unauthorized Use Of Material 6 3 9 Unauthorized Maint Performed 2 4 6 Totals: 18 16 34 PDSs: Inadvertent Destruction 18 37 55 Inadvertent Opening 5 5 10 Physical Loss 3 9 12 Destruction Irregularities 13 6 19 Unauthorized Viewing 1 2 3 Material Pulled from Canister 1 0 1 Unauthorized Shipping Mode 2 0 2 Damaged Packages 1 0 1 Loss of Control of COMSEC 4 6 10 Forced Entry Into Safe 0 1 1 Unauthorized Reproduction 2 0 2 Totals: 50 66 116 Now that you have seen the total breakdown of all the COMSEC incidents of the past 2 years and the two 6-month periods, let's compare the previous 6 months with the past 6 months and show some of our major problems (by categories) that have been and still are the leading factors within the COMSEC incident world. Loss of control of COMSEC has been the front-runner of COMSEC incidents in the past 3 years. If you noticed, during the Jan-Jun time frame, there were 53 incidents and in Jul-Dec there were 63. This was an increase of 10 reported incidents. We are supposed to decrease incidents--not increase them. The same types of occurrences are still happening as before, just different personnel are losing the handle. Material is still being left unattended in hallways, government vehicles, and any place you can think of. As you can see, there were 116 incidents of this type in 1992. We had 116 people go "brain dead" for some reason. This can be the only logical reason for leaving their COMSEC material unsecured/unattended. Permanent loss of COMSEC material is still the second runner-up. There was a decrease of 17 incidents when comparing the two 6-month periods. During the first 6 months, there were 49 COMSEC incidents; and during the latter 6 months, there were 32, with a grand total of 81 for the year. People are very, very careful not to lose their money or paycheck, so why can't they apply the same rules and hard-nosed controls when it comes to protecting their COMSEC? The primary reason for lost COMSEC material is not paying attention to details. Unsecured safe/workcenter incidents decreased by five in the latter 6 months as compared to the first 6 months. There were 20 reported incidents in the first 6 months, while 15 incidents were reported for the latter months. People are still not checking their safes at the end of the day. They are assuming it's locked or secured. One day their assumptions will prove them wrong. The COMSEC Managers must instill in all their users to take that extra minute to check safes and stop the rushing. Remember, speed can cause a COMSEC incident. Destruction irregularities decreased by two for this reporting period. There were 19 incidents for the last reporting period as compared to 17 incidents this period. Single signatures on destruction reports at the users' level, material claiming to be destroyed but later found intact, and falsification of signatures on destruction reports are some of the reasons for the 36 incidents for the year. Loss of two-person integrity was on the down swing, but somehow it's back again and on the increase. The first 6 months there were only seven incidents of this type reported. However, for the last 6-month period, we doubled, with a total of 14 incidents. Even though the total count for 1992 was 21 as compared to 29 for 1991, each 6-month period should show some type of decline, not double its quantity from the last reporting period. It shows we completely fell off track and must get back to where we started the first 6 months. COMSEC users must be retrained on two-person integrity procedures. Unauthorized access/use showed a definite decline for this period as compared to the last reporting period. For this period there were only four incidents compared to 13 for the first reporting period. This low count of incidents can be contributed to unauthorized personnel being stopped at the door, individuals being checked before any material is handed to them, and using the proper material for the right purpose. Damaged packages were due mostly to the inner wrapper splitting open from the heavy weight of the material or to overpacking. There was a total of six incidents for this period as compared to our incidents for the latter period. The grand total for the year was 10 incidents. Unauthorized shipping mode for this period accounted for four incidents, and the latter 6 months had five incidents. Even though there were only 10 incidents for the year, shipping COMSEC material by the correct mode of transportation is a must. Unauthorized reproduction remained the same for both periods with two incidents each. Users are beginning to understand that they must obtain the controlling authorities' approval prior to any reproduction. Use of superseded material also remained the same for both reporting periods with one incident each. Users must check their COMSEC material before it's put into effect. Extended crypto period had a total of 17 violations for the year. There were nine incidents for the first 6 months, while for the latter months there were eight incidents. Both terminal ends are held responsible for incidents of this type. It seems that the one end is waiting for the other to make the call, but somehow no one calls until after the grace period. Unauthorized use of COMSEC material declined by three this reporting period. The majority of these incidents were caused by individuals accidentally using the wrong COMSEC material on equipment not authorized for its use. This type of incident could be totally eliminated if individuals took the time to check the COMSEC material before inserting it into the equipment. Unauthorized maintenance performed on COMSEC equipment is a definite, "no-no," so why do Mr Goodwrenchs who work on cars, coffee pots, and toasters think they are crypto maintenance personnel? There was a total of six incidents for the year. During the last 6 months, we had four personnel who thought they were maintenance personnel. Please inform them to leave COMSEC equipment alone. PDSs are on the rise. Even though no case numbers are assigned to these incidents, they show the Air Force's weakness in handling their COMSEC material. Please notice the category Inadvertent Destruction. People are destroying material with their eyes shut. Perhaps they figure since it's the end of the month, they must destroy something. COMSEC material should be checked more than once before it is put into destruction status. Make sure the right material is being destroyed. All COMSEC incidents could be prevented if everyone followed established procedures and rules for protecting COMSEC material. Also, retraining some of our COMSEC users is a must because the majority of COMSEC incidents are caused by the users. Every effort must be made to continue educating every user within the Air Force. Every COMSEC Manager knows who his/her weak links are. As managers, you must go directly to those weak links and strengthen them with knowledge about COMSEC. If we all work together and continuously educate all COMSEC users, COMSEC incidents will be reduced considerably. ------- End of forwarded message ------- From peb at PROCASE.COM Fri Jun 25 12:53:23 1993 From: peb at PROCASE.COM (Paul Baclace) Date: Fri, 25 Jun 93 12:53:23 PDT Subject: triggerfish Message-ID: <9306251953.AA02713@banff.procase.com> > to accomplish this from orbit How big and sensitive would an antenna need to be in orbit to accomplish this? It would have to be sensitive to 1 watt transmitters. They send up many polar orbit satellites which are not too far away, so that could be a big help. Paul E. Baclace peb at procase.com From M..Stirner at f28.n125.z1.FIDONET.ORG Fri Jun 25 13:33:00 1993 From: M..Stirner at f28.n125.z1.FIDONET.ORG (M. Stirner) Date: Fri, 25 Jun 93 13:33:00 PDT Subject: Deniable fed assets Message-ID: <650.2C2A54D4@shelter.FIDONET.ORG> * Reply to msg originally in CYPHERPUNKS Uu> BTW ANY federal Uu> intelligence agencie will act as a "cutout" for situations where the Uu> prime agency cannot operate legally but another can. This is absolutely true; I personally performed technically illegal domestic intelligence-gathering services [relatively benign] under an identical arrangement for several years. Based on some eighteen years of personal experience, I will attest to the fact that _any_ legal or constitutional safeguard against the invasion of privacy will be routinely ignored by virtually any law enforcement or intelligence agency if it suits their purposes & is within their abilities. ********************************************************************* * - 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 cestes at argos5.DNET.NASA.GOV Fri Jun 25 13:37:26 1993 From: cestes at argos5.DNET.NASA.GOV (Chris Estes) Date: Fri, 25 Jun 93 13:37:26 PDT Subject: Orbiting antennas Message-ID: <9306252026.AA24642@east.gsfc.nasa.gov> Paul Baclace asks about receiving data on a polar oribiting spacecraft. That's what my company does for a living. I'm not a radio specialist, and not involved in the design of the on-board instrumentation, but the gear is not to sophisticated. We transmit in the 401 Mhz area, the antenna on the spacecraft is a simple, omnidirectional affair, that I don't have any handy specs for. It's about a meter long and 8cm in diameter; what's inside? I don't know. We typically hit the spacecraft with one watt (at an altitude of 870km), but have one guy who is able to get it at 150 milliwatts (!). I haven't been following the thread, but if you're thinking about phone-type systems, remember that with polar orbiters, you're only going to have about a 15 minute window during which the spacecraft will be overhead. Unless you're doing store and forward messaging, the sender and receiver of the signal have to be in the footprint at the same time. I hope that's relevant (I should do a better job of keeping up!) -Chris Estes- cestes at argos5.dnet.nasa.gov From karn at qualcomm.com Fri Jun 25 14:06:44 1993 From: karn at qualcomm.com (Phil Karn) Date: Fri, 25 Jun 93 14:06:44 PDT Subject: triggerfish Message-ID: <9306252106.AA17092@servo> >How big and sensitive would an antenna need to be in orbit to accomplish >this? It would have to be sensitive to 1 watt transmitters. They >send up many polar orbit satellites which are not too far away, so that >could be a big help. Sensitivity is not the issue. Two 1-watt walkie-talkies, one in (low) orbit and one on the ground, can (and do) communicate with each other as long as the earth isn't standing in the way. It's done on the ham radio bands on just about every space shuttle mission (like the one currently underway). Higher orbits require better antennas, but they're no big deal. The real problem with a space-based cellular telephone surveillance system is interference - the best spot beam antenna you can make would still take in *many* ground transmitters on the same channel in a place like New York City. From orbit, you see everything, whether you want to or not. This is borne out again and again with tapes from the shuttle. Often you hear nothing at all because there are so many ground stations all transmitting at the same time that none of them are recoverable. Some hams run ungodly amounts of power to get through, not because it's required for the distance to be traveled, but to stand far enough above everybody else that they can capture the shuttle's receiver. Both these systems and cellular telephones use the same modulation method - FM. Phil From axelrod at s106.es.llnl.gov Fri Jun 25 17:42:46 1993 From: axelrod at s106.es.llnl.gov (Mike Axelrod 422-0929) Date: Fri, 25 Jun 93 17:42:46 PDT Subject: Contempt of Court Message-ID: <9306260044.AA28615@s106.es.llnl.gov> You do have me confused with Mike Godwin. I did write: > >If the key itself had embedded testimony that was incriminating, then it is > >possible one could invoke the 5th amendment to avoid disclosure of the key. > >But, I suppose a court could do an end run around that by giving limited > >use immunity for the incriminating content of the key. Comments? But the rest of your questions refer to Mike Godwin. My guess is that one could be compelled to reveal the combination to a lock because the combination is not testimony. I'm sure that govenment lawyers would argue that a key is not testimony, just as a combination to a safe is not testimony. Perhaps some research would turn up the answer to this question. There is also the matter of discovery in civil actions. If one had financial records in encrypted form, a court could order you disclose the key under the threat of civil contempt. Civil contempt can be worse than criminal contempt. The court can ruin you financially and keep you in jail until you comply with the order. Mike. From newsham at wiliki.eng.hawaii.edu Fri Jun 25 19:08:12 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Fri, 25 Jun 93 19:08:12 PDT Subject: term for ibm Message-ID: <9306260208.AA14613@toad.com> I needed to do some DOS programming at work, and used the 'MCOMM' serial package. It comes with a demonstration program called 'smalterm.exe' I read through it a few times and it dawned on me how easy it would be to hook it up to LINK (link encryption). The problem is that the package is (c) and shareware. Furthermore none of the documents say anything about the status of the demo programs. I estimate it would take 30 minutes to an hour to get encryption up and running with that term program. Does anyone know of a small terminal program that has a few essential features, with good modularity? One that is publically available or we could use with the authors blessings? ... From mdiehl at triton.unm.edu Fri Jun 25 21:03:14 1993 From: mdiehl at triton.unm.edu (J. Michael Diehl) Date: Fri, 25 Jun 93 21:03:14 PDT Subject: term for ibm In-Reply-To: <9306260208.AA14613@toad.com> Message-ID: <9306260403.AA08675@triton.unm.edu> According to Timothy Newsham: > I needed to do some DOS programming at work, and used > the 'MCOMM' serial package. > It comes with a demonstration program called 'smalterm.exe' > I read through it a few times and it dawned on me how easy > it would be to hook it up to LINK (link encryption). > The problem is that the package is (c) and shareware. Furthermore > none of the documents say anything about the status of the > demo programs. I estimate it would take 30 minutes to an > hour to get encryption up and running with that term program. Well, I have to suggest telix. ;^) Telix has built in hooks for external protocols which you could use to impliment your encryption link. It has a very good script language. Further, I have been using it for some time now and think I am pretty good with it. I could help you get it going. > Does anyone know of a small terminal program that has > a few essential features, with good modularity? One that > is publically available or we could use with the authors > blessings? Telix is relatively small, has many features, and the script language is very modular. It isn't src distribution, though. Still it's a thought. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl at triton.unm.edu | But, I was mistaken. |available| | mike.diehl at fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+ From hkhenson at cup.portal.com Fri Jun 25 21:05:20 1993 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Fri, 25 Jun 93 21:05:20 PDT Subject: triggerfish Message-ID: <9306251518.1.29858@cup.portal.com> Brian D Williams wrote (re TRIGGERFISH): > It would be child's play for the NSA to accomplish this from >orbit.....hmmmmm I wonder what they call it? My guess would be that it can't be done. Just getting up in a light aircraft with a cell phone is instructive. With every cell site in 50 miles being about the same distance (even from LEO) I don't think you could pick out a single conversation. On the other hand, with enough directionality . . . . nah, the antenna would be a monster. Keith From zane at genesis.mcs.com Sat Jun 26 11:41:43 1993 From: zane at genesis.mcs.com (Sameer) Date: Sat, 26 Jun 93 11:41:43 PDT Subject: Remailer origin lines In-Reply-To: <47.2C2951B0@wyrm.rbbs-net.ORG> Message-ID: In message <47.2C2951B0 at wyrm.rbbs-net.ORG>, M. Stirner writes: > > Uu> A "Dont-Mess-With-Trailers:" header line would help a bit. > > The BlueWave blurb was added by the program & can be stripped by > re-editing the message before upload. Everything else is out of my > control completely & added automagically by the host or the UUCP > gateway. The sucker stays, no matter what I do. Some anonymity! > How about a header line such as: X-Cut-End-Lines: 6 Which would instruct the remailer to cut the last six lines off the mail message as it receives it. Thus a user could figure out how many lines at the end of his message is added on without his control and instruct the remailer to cut out that amount of lines. -- | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/ From nobody at rosebud.ee.uh.edu Sat Jun 26 12:06:01 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Sat, 26 Jun 93 12:06:01 PDT Subject: chained remails Message-ID: <9306261905.AA09976@toad.com> * Reply to msg originally in CYPHERPUNKS Uu> The problem may be the Fidonet addressing. Many times I have tried to Uu> send mail to people with mailing addresses like M's, and not had the Uu> mail get through. I don't know what the rules are but perhaps some Uu> systems can get it and some can't. Note that _this_ message goes through an RBBS/UUCP gate. The problem remains, however. On the other hand, I just noted a sheepish message about the remailer at rebma.mn.org being ill for the past couple of weeks, which would explain my failures with that system. Uu> I'd suggest to M. that he take one of the systems that does respond to Uu> his remailing requests, and have that be the LAST one in a chain of Uu> two. So, he could send to, say, hh at cicada.berkeley.edu, and follow Uu> that with elee7h5 at rosebud.ee.uh.edu. Perhaps this would get through: An interesting experiment I shall try today, perhaps with this very message. Thank's, Hal, for the input. I should like to see these remailers popularized, along with encryption, as one of the best political moves we cypherpunks can make. De-glitching them for broader use may be a thankless task, but would be worth it if it results in their general use. Uu> -----BEGIN PGP SIGNATURE----- P.S.: Have you heard anything of the alleged bug with version 2.3 being unable to verify plaintext PGP signatures? ********************************************************************* * - 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 RBBS-NET node 8:914/201 INTERNET: M..Stirner at f28.n125.z1.RBBS-NET.ORG From nobody at soda.berkeley.edu Sat Jun 26 12:06:17 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Sat, 26 Jun 93 12:06:17 PDT Subject: No Subject Message-ID: <9306261902.AA02316@soda.berkeley.edu> * Reply to msg originally in CYPHERPUNKS Uu> It is rarely to one's advantage to "assist the police." In fact in Uu> British English the sentence "Fred C. Schwartz is assisting the police Uu> in their investigation" means that Fred C. Schwartz is the prime Uu> suspect. Rather like "very tired" when used to describe the public appearance of an MP as in, "...Sir Henry appeared very tired." The term "very tired" apparently is the pervasive newspaper euphemism for "very drunk." Uu> My wife (who in many ways was just the sort of female Kipling had in Uu> mind when he penned 'Deadlier Than the Male')... Splendid finds, these, when one can keep them in alliance. It's always a joy to introduce them to firearms. Uu> In due course, a sewer inspector rang Uu> our doorbell. My wife demanded to see his warrant. He was shocked Uu> and mortified. Uu> Over the next few weeks, various bureaucrats called my wife and tried Uu> to get her to change her mind. They said, "You're not going to force Uu> us to waste all that time and money and get a warrant, are you?" She Uu> replied, "Consider it a valuable education on the 4th amendment." I won't waste a great deal of time in idle & uninformed speculation, but I seem to remember that certain "public safety" types do not need a warrant to intrude. As a matter of fact, I know of instances where cops accompanied such functionaries on trumped-up "inspections" to avoid the trouble of getting warrants. . I should be pleased to hear qualified legal opinion on this. Uu> Who is writing this in the terrorist capital of the US - Jersey City, Uu> NJ - but who has been denied a tactically necessary assault rifle by Uu> Governor Jim Florio. Yes, but don't you feel _much safer_ disarmed? No? Well, be content with a nice shotgun. Uu> When amonium nitrate and diesel fuel in a 16 to 1 ratio are outlawed Uu> only outlaws (and farmers) will have amonium nitrate and diesel fuel Uu> in a 16 to 1 ratio. This shall no doubt turn up in sigs before week's end. ********************************************************************* * - 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 RBBS-NET node 8:914/201 INTERNET: M..Stirner at f28.n125.z1.RBBS-NET.ORG From nobody at soda.berkeley.edu Sat Jun 26 12:06:18 1993 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Sat, 26 Jun 93 12:06:18 PDT Subject: Remailer at rebma.mn.org Message-ID: <9306261902.AA02325@soda.berkeley.edu> * Reply to msg originally in CYPHERPUNKS Uu> My apologies to anyone who has tried to use the anonymous remailer at Uu> rebma.mn.org in the past several weeks. Uu> I imagine that people who weren't successful were Uu> experimenters who chalked up the failure to something they'd done Uu> wrong. I did, indeed! Uu> It's working again, now. Uu> Here's the PGP key. Does this remailer _require_ an encrypted header, or will it take the | | :: | Request-Remailing-To: | plaintext command? ********************************************************************* * - 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 RBBS-NET node 8:914/201 INTERNET: M..Stirner at f28.n125.z1.RBBS-NET.ORG From nobody at cicada.berkeley.edu Sat Jun 26 12:06:45 1993 From: nobody at cicada.berkeley.edu (nobody at cicada.berkeley.edu) Date: Sat, 26 Jun 93 12:06:45 PDT Subject: No Subject Message-ID: <9306261906.AA19140@cicada.berkeley.edu> * Reply to msg originally in CYPHERPUNKS > Are most remailers down on any given day? _That_ question has been partially answered in another post! Uu> Well, I really used only 5 different remailers, total of 16 hops. I Uu> Should haf made that clearer. Uu> This message will go through 24 hops, just for the heck of it. Well, it made it, I suppose. I'll try this one via the same remailers, plus another one I know to be working. ********************************************************************* * - 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 RBBS-NET node 8:914/201 INTERNET: M..Stirner at f28.n125.z1.RBBS-NET.ORG From gnu Sat Jun 26 13:40:32 1993 From: gnu (John Gilmore) Date: Sat, 26 Jun 93 13:40:32 PDT Subject: Int'l Conf on Signal Processing Apps & Tech, Santa Clara, 28Sep93 Message-ID: <9306262040.AA12510@toad.com> Folks interested in DSP's, including voice compression and encryption, fast exponentiation, etc, may want to attend this conference. Particular sessions of interest: Workshop, 27 Sep: Low Cost Speech Compression Technology for Consumer Applications. (costs extra $150) Digital Encryption System for Speech Communication over the Public Switching Telephone Network, Sofi'a Moreno Pe'rez, Rafael Sarmiento de Sotomayor, Luis Di'ez del Ri'o, Jose' Parera Bermu'dez, Marcelino Veiga Pe'rez, and Ramo'n Garcia Go'mez, E.T.S.I. de Telecomunicacio'n, Spain. Real-Time Implementation of Variable Rate QCELP Codec using TMS320C30 DSP, Kyongo Han, Byungsik Yoon, Insung Lee, and Sangwon Kang, Electronics & Telecom. Research Institute, Korea Improving the Cryptanalysis Algorithms Based Upon the Multiple Residues, S.J. Tabatabaian and G.P. Singh, University of Newcastle upon Tyne, U.K. three more papers on Speech Coding Algorithms 15 more papers on Speech Coding Implementation and about 100 other papers. Price: $495 before 25Aug93; $595 after. Students: $350 before, $425 after. DSP Associates 18 Peregrine Road Newton Centre, MA 02159 USA +1 617 964 3817 +1 617 969 6689 DSPWorld at world.std.com From MAILER-DAEMON at Panix.Com Sat Jun 26 20:34:39 1993 From: MAILER-DAEMON at Panix.Com (Mail Delivery Subsystem) Date: Sat, 26 Jun 93 20:34:39 PDT Subject: Returned mail: User unknown Message-ID: <199306261258.AA25065@sun.Panix.Com> ----- Transcript of session follows ----- While talking to toad.com: >>> RCPT To: <<< 550 ... User unknown 550 cyhperpunks at toad.com... User unknown ----- Unsent message follows ----- Received: by sun.Panix.Com id AA25038 (5.65c/IDA-1.4.4 for cyhperpunks at toad.com); Sat, 26 Jun 1993 08:58:20 -0400 From: Harry Shapiro Message-Id: <199306261258.AA25038 at sun.Panix.Com> Subject: Re: Government fear of strong crypto To: kellyg at sco.com (Kelly Goen) Date: Sat, 26 Jun 1993 08:58:19 -0400 (EDT) Cc: cyhperpunks at toad.com In-Reply-To: <9306241425.aa09999 at vishnu.sco.com> from "Kelly Goen" at Jun 24, 93 02:25:06 pm Reply-To: habs Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 325 a conscious being, Kelly Goen wrote: > > 1) The NSA is not chartered for domestic surveillance work. I figure this means the FBI has an office at the NSA and has NSA staff members working under contract to the FBI so that while the NSA is ot overseeing domestic interception their staff is doing it for the FBI. /hawk From pfarrell at cs.gmu.edu Sun Jun 27 10:37:01 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Sun, 27 Jun 93 10:37:01 PDT Subject: term for ibm Message-ID: <49011.pfarrell@cs.gmu.edu> In Message Fri, 25 Jun 1993 16:07:03 -1000 (HST), Timothy Newsham writes: >The problem is that the package is (c) and shareware. Furthermore >none of the documents say anything about the status of the >demo programs. I estimate it would take 30 minutes to an >hour to get encryption up and running with that term program. > >Does anyone know of a small terminal program that has >a few essential features, with good modularity? One that >is publically available or we could use with the authors >blessings? The Microsoft C/C++ compilers come with the source code for a simple windows based terminal program. While it is copyrighted, it is all over the planet. In Timmothy Mann's book: Windows Programmer's Guide to Serial Communications, isbn 0-672-30030-3, are sample code for a mid-level terminal program (complete with xmodem). The source is in the book and on a diskette. There are _no_ copyright messages in the sources. The book itself, is of course, copyrighted. In Mark Nelson's book: Serial Communications: a C++ Developer's Guide isbn 1-55851-281-0, are sample code (and diskette)in C++ for DOS, Windows, FOSSIL, and pure UART drivers and a terminal program (complete with ZModem). The code _does not work_ for Windows, but works fine with DOS. Again, no copyright messages in the source code. Kermit (anon-ftp from watsun.cc.columbia.edu) is a free, source available terminal program. Copyrighted Columbia, but enhancements encouraged. Kermit's modularity is at best marginal. Nelson's code is very good. Mann's is acceptable. The Windows TTY is acceptable, but being a Windows program, hardly counts as "small" The Microsoft Visual Control Pack for Visual Basic and Visual C++ includes a "serial control" that should handle most of the hard work in building a terminal program. I can't get it to work from MSVC, and can find no one else on the planet that can either. But if you wanted to start in Visual Basic, I expect that a simple terminal program is no more than a day's work. Pat p.s. I'm using a hacked version of MS TTY as the starting point for my WinPOP mail client. If you think I've spend several hundred dollars looking for working code to build upon, you're right. Pat Farrell Grad Student pfarrell at cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From M..Stirner at f28.n125.z1.RBBS-NET.ORG Sun Jun 27 11:33:58 1993 From: M..Stirner at f28.n125.z1.RBBS-NET.ORG (M. Stirner) Date: Sun, 27 Jun 93 11:33:58 PDT Subject: remailer origin lines Message-ID: <70.2C2D7E4E@wyrm.rbbs-net.ORG> * Reply to msg originally in CYPHERPUNKS Uu> How about a header line such as: Uu> X-Cut-End-Lines: 6 Uu> Which would instruct the remailer to cut the last six lines Uu> off the mail message as it receives it. Thus a user could figure out Uu> how many lines at the end of his message is added on without his Uu> control and instruct the remailer to cut out that amount of lines. The number of lines added seems to vary with the gating. I'm sort of leaning toward a ........8<....(cut here).....8<....... kind of solution; I mean, I know for a fact where I stopped, so anything beyond that ought to be eaten by the remailers, IMHO. There is probably a good argument against that solution, but I can't think of it offhand. ********************************************************************* * - 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 RBBS-NET node 8:914/201 INTERNET: M..Stirner at f28.n125.z1.RBBS-NET.ORG From nobody at rosebud.ee.uh.edu Sun Jun 27 12:29:10 1993 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Sun, 27 Jun 93 12:29:10 PDT Subject: Remailer ping test Message-ID: <9306271929.AA17347@toad.com> I tried pinging all the remailers on the latest copy I have of Karl's remailer list (except extropia, which I know only accepts encrypted messages). I sent to each: :: Request-Remailing-To: hfinney at shell.portal.com then a short test message. I only heard back from 8 of them, to wit: hfinney at shell.portal.com Sun Jun 27 08:48:08 1993 hh at soda.berkeley.edu Sun Jun 27 08:48:15 1993 remail at tamsun.tamu.edu Sun Jun 27 08:48:38 1993 nowhere at bsu-cs.bsu.edu Sun Jun 27 08:48:43 1993 phantom at u.washington.edu Sun Jun 27 08:48:40 1993 elee7h5 at rosebud.ee.uh.edu Sun Jun 27 08:48:56 1993 hal at alumni.cco.caltech.edu Sun Jun 27 08:48:59 1993 dis.org!remailer at merde.dis.org Sun Jun 27 09:17:24 1993 I did not hear back from the following remailers. Perhaps their operators could check on them, or notify Karl if they are no longer operating. 1: hh at pmantis.berkeley.edu 2: hh at cicada.berkeley.edu 6: remail at tamaix.tamu.edu 7: ebrandt at jarthur.claremont.edu 9: remailer at rebma.mn.org 14: 00x at uclink.berkeley.edu Hal hfinney at shell.portal.com From bear at eagle.fsl.noaa.gov Sun Jun 27 16:49:27 1993 From: bear at eagle.fsl.noaa.gov (Bear Giles) Date: Sun, 27 Jun 93 16:49:27 PDT Subject: Landlords accepting search warrants.... Message-ID: <9306272345.AA18589@eagle.fsl.noaa.gov> An anonymous writer wrote: >9) I still wonder if the officers would have been able to get a warrant >under my circumstances. At the time I was convinced that they wouldn't >have without additional evidence (of which there assurredly is none). >I had in the back of my mind that I would rather have them search when >I didn't expect it or through my landlord when I wasn't there. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This keeps popping up, probably due to old _Dragnet_ episodes... As I understand contract law regarding leases, a landlord _cannot_ grant permission for a police search unless the lease is in default. Or, more precisely, if they did you could sue them for "breach of contract" and extract pretty hefty penalties. Perhaps California leases have some standard clause which permits this, but in general a "lease" transfers all "non-freeholder" property rights, except for those explicitly -returned- within the contract. That means the tenant is the property owner for all intents and purposes except for "freeholder" rights (e.g., a tenant can't sell the property). Bear Giles From tk at reagan.ai.mit.edu Sun Jun 27 19:25:47 1993 From: tk at reagan.ai.mit.edu (Tom Knight) Date: Sun, 27 Jun 93 19:25:47 PDT Subject: SEARCH ME In-Reply-To: <930625191757_76630.3577_EHK47-1@CompuServe.COM> Message-ID: <19930628022527.3.TK@ROCKY.AI.MIT.EDU> Date: Fri, 25 Jun 1993 15:17 EDT From: Duncan Frissell <76630.3577 at compuserve.com> When amonium nitrate and diesel fuel in a 16 to 1 ratio are outlawed only outlaws (and farmers) will have amonium nitrate and diesel fuel in a 16 to 1 ratio. If you're going to be cool and make ANFO, you gotta spell it rite: Ammonium nitrate. Don't leave your correct name and address on the rental car, either. Kids: Don't do this at home. From M..Stirner at f28.n125.z1.FIDONET.ORG Mon Jun 28 01:00:13 1993 From: M..Stirner at f28.n125.z1.FIDONET.ORG (M. Stirner) Date: Mon, 28 Jun 93 01:00:13 PDT Subject: Remailer ping test Message-ID: <705.2C2EA0A7@shelter.FIDONET.ORG> * Reply to msg originally in CYPHERPUNKS Uu> I tried pinging all the remailers on the latest copy I have of Uu> Karl's remailer list (except extropia, which I know only accepts Uu> encrypted messages). I sent to each: Uu> :: Uu> Request-Remailing-To: hfinney at shell.portal.com Uu> then a short test message. Uu> I only heard back from 8 of them, to wit: Uu> hfinney at shell.portal.com Sun Jun 27 08:48:08 1993 Uu> hh at soda.berkeley.edu Sun Jun 27 08:48:15 1993 Uu> remail at tamsun.tamu.edu Sun Jun 27 08:48:38 1993 Uu> nowhere at bsu-cs.bsu.edu Sun Jun 27 08:48:43 1993 Uu> phantom at u.washington.edu Sun Jun 27 08:48:40 1993 Uu> elee7h5 at rosebud.ee.uh.edu Sun Jun 27 08:48:56 1993 Uu> hal at alumni.cco.caltech.edu Sun Jun 27 08:48:59 1993 Uu> dis.org!remailer at merde.dis.org Sun Jun 27 09:17:24 1993 I have had problems with getting the same test routed through hh at soda and phantom at u.washington. I have not tried dis.org! yet. Uu> I did not hear back from the following remailers. Perhaps their Uu> operators could check on them, or notify Karl if they are no longer Uu> operating. Uu> 1: hh at pmantis.berkeley.edu Uu> 2: hh at cicada.berkeley.edu Uu> 6: remail at tamaix.tamu.edu Uu> 7: ebrandt at jarthur.claremont.edu Uu> 9: remailer at rebma.mn.org Uu>14: 00x at uclink.berkeley.edu #6 has worked for me. The others have not, though the hh at _berkeley remailers will sometimes work if the message is first bounced through another reliable remailer. Why this should be, I know not. Sending the PGP-encrypted message & header to remail at extropia.wimsey.com seems to work very well for losing those stupid footer IDs, & is usually my first leg of multiple-bounce test transmissions. BTW, I note that hal at alumni.caltech.edu has a different address in the first batch of successful remailers. The address hal at alumni.caltech.edu has worked well. Uu> Hal Uu> hfinney at shell.portal.com Thanks for your efforts! ********************************************************************* * - 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 nobody at pmantis.berkeley.edu Mon Jun 28 05:30:19 1993 From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu) Date: Mon, 28 Jun 93 05:30:19 PDT Subject: Remailer at rebma.mn.org Message-ID: <9306281231.AA19866@pmantis.berkeley.edu> > * Reply to msg originally in CYPHERPUNKS > > Uu> My apologies to anyone who has tried to use the anonymous remailer at > Uu> rebma.mn.org in the past several weeks. > > Uu> I imagine that people who weren't successful were > Uu> experimenters who chalked up the failure to something they'd done > Uu> wrong. > > I did, indeed! > > Uu> It's working again, now. > > Uu> Here's the PGP key. > > > Does this remailer _require_ an encrypted header, or will it take the > | > | :: > | Request-Remailing-To: > | > plaintext command? >From dmandl at lehman.com: It is indeed working OK now. Encryption is not required. Good to see this remailer back up, especially because it introduces a long delay, making traffic analysis more difficult. FYI, sending a message to myself (in NYC) through this remailer, it took about 15 hours for it to come back. This is either very good or very bad depending on your purposes. Bad for urgent messages, good for more...er...sensitive applications. --Dave. From nobody at alumni.cco.caltech.edu Mon Jun 28 05:46:57 1993 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Mon, 28 Jun 93 05:46:57 PDT Subject: Remailer ping test Message-ID: <9306281245.AA14406@alumni.cco.caltech.edu> > I did not hear back from the following remailers. Perhaps their operators > could check on them, or notify Karl if they are no longer operating. > > 1: hh at pmantis.berkeley.edu > 2: hh at cicada.berkeley.edu > 6: remail at tamaix.tamu.edu > 7: ebrandt at jarthur.claremont.edu > 9: remailer at rebma.mn.org > 14: 00x at uclink.berkeley.edu > > Hal > hfinney at shell.portal.com From: dmandl at lehman.com This is distressing. I just used some of these (1, 2, and 9, which has just been brought back up) with no problems. Have any of these remailers been going up and down? I've found service to be a bit unpredictable in the past. It's a pain to have to test remailers first before each use, and I can't ping from my site, which makes things even more inconvenient. Has anyone else experienced intermittent problems with these reamailers? Is there any reason why they should work from some sites and not others? --Dave. From pat at tstc.edu Mon Jun 28 06:39:17 1993 From: pat at tstc.edu (Patrick E. Hykkonen) Date: Mon, 28 Jun 93 06:39:17 PDT Subject: triggerfish In-Reply-To: <9306251518.1.29858@cup.portal.com> Message-ID: <9306281338.AA27091@tstc.edu> > > It would be child's play for the NSA to accomplish this from > >orbit.....hmmmmm I wonder what they call it? > > On the other hand, with enough directionality . . . . nah, the > antenna would be a monster. Actually, no it wouldn't. A yagi antenna at 800 Mhz is not very large at all. A 16 element at that frequency would probably be less than 5 feet long. Beans for a satellite to carry into orbit today. Of course the problem then is the beam will provide a fairly wide "spot" on the surface of the Earth that will still cover several cell sites. Although come to think of it, narrowed to area to adjacent sites you'll not have to contend with hearing two sites on the same frequency due to coordination. -- 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 V:(817) 867-4830 F:(817) 799-2843 From elee9sf at Menudo.UH.EDU Mon Jun 28 08:08:24 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Mon, 28 Jun 93 08:08:24 PDT Subject: REMAIL: problems Message-ID: <199306281508.AA26337@Menudo.UH.EDU> There must be some correlation between my weekend trips and other events. Last time I went out of town was "Cliper weekend" :-) I've tested the remailers with unencrypted requests, and have received these replies (within seconds, I might add): soda.berkeley.edu cicada.berkeley.edu pmantis.berkeley.edu bsu-cs.bsu.edu alumni.caltech.edu rosebud.ee.uh.edu mead.u.washington.edu shell.portal.com tamsun.tamu.edu tamaix.tamu.edu <-- note, 'Return-Path: remail at tamaix.tamu.edu' 'From: remail at tamsun.tamu.edu' just in case you see the from line and think tamaix isn't working So I'll wait for the others (rebma, extropia, utter, uclink, jarthur) and then try them all with encrypted requests. A while ago I had a script test all the remailers once a week - I wasn't able to have a cron entry, but I used the 'at' command to schedule the mailing of prepared messages and itself every week. Maybe I'll start that up again since it would help isolate problems if a remailer doesn't respond, especially if twice in a row. /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From ebrandt at jarthur.Claremont.EDU Mon Jun 28 08:16:53 1993 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Mon, 28 Jun 93 08:16:53 PDT Subject: Remailer ping test In-Reply-To: <9306271929.AA17347@toad.com> Message-ID: <9306281516.AA13805@toad.com> > 7: ebrandt at jarthur.claremont.edu Something came through here at "Sun Jun 27 08:44:41 PDT 1993", which is close to the stamps on the other messages you sent. Perhaps it didn't make it back to you? If you want to try it again with full logging, tell me and I can turn it on. Incidentally, there have been a couple of messages to the list with the stigmata of my remailer, but the address "eli-remailer at toad.com". Is the list software doing anything that could account for this? > Hal Eli ebrandt at jarthur.claremont.edu From honey at citi.umich.edu Mon Jun 28 09:06:06 1993 From: honey at citi.umich.edu (peter honeyman) Date: Mon, 28 Jun 93 09:06:06 PDT Subject: Geer Zolot White Paper: Clipper Initiative Message-ID: <9306281606.AA15299@toad.com> ------- Forwarded Message Geer Zolot White Paper: Clipper Initiative On April 16, 1993, the U.S. Government issued a "Public Encryption Management" directive, requesting that communications vendors install into their products chips that implement a secret algorithm with controversial key-escrow facilities. These chips (called "Clipper" and "Capstone") stem from work by the NSA (National Security Agency) and its contractors; they implement the SKIPJACK algorithm, which is classified SECRET and is therefore not available for public review. For more information on the initiative, consult the National Institute of Standards and Technology (NIST) Computer Security BBS at 301.948.5717 or via Internet ftp to csrc.ncsl.nist.gov in the /pub/nistnews directory. The Government states that one motivation for this initiative is to allow authorized wiretapping of encrypted communications by escrowing the keys corresponding to individual components. A pair of "entities" (choices not announced) will have responsibility for keeping keys secure and releasing them only to government officials who have received legal authorization to perform a wiretap. The Government recommends use of the chips instead of already existing cryptographic algorithms, such as the secret-key DES algorithm (a Federal Information Processing Standard and the basis of Kerberos and other network security tools) and the public-key RSA algorithm. Since DES and RSA have been subject to public scrutiny, experts have tested and confirmed their strength, which has led to their adoption within internationally-agreed networking standards; since SKIPJACK is secret and can never receive this scrutiny, it is unlikely that it will ever have such acceptance. Further, DES and RSA can run in both hardware and software, which satisfies performance and system integration requirements; the Government has limited Clipper/Capstone to hardware, which restricts the range of systems that may use it. For now, the Government is recommending that equipment vendors use the chips on a voluntary basis; however, some observers regard the initiative as an attempt to establish a precedent that could later lead to governmental restrictions on the availability and use of open cryptographic systems. This could limit innovation in cryptographic technology. Further, user organizations could lose control over protecting and managing the keys on which their security depends. This summer, the Government plans inter-agency discussions of future policies in this area; observers have noted that policy development should also reflect private sector interests. Concerns about personal privacy raise additional controversy. Significant debate on these topics is likely in upcoming months. Geer Zolot Associates believes that availability of open and exportable cryptography serves our clients' interests. Because of this, we are concerned about the implications of the "Public Encryption Management" initiative, and of its possible chilling effect on development, availability, and use of cryptographic technology. The initiative raises many issues, including: o If the Government mandates enclosing cryptography in hardware modules, this will surely delay the vital process of enhancing the security of today's distributed computing base--it could even prevent some systems from being secured at all. We want to avoid the prospect of our clients being forced to choose between systems that satisfy their operational needs and other systems containing Government-provided hardware encryption components. o Introducing a requirement for procurement, integration, and use of special-purpose components (which manufacturers must separately handle and program on a per-unit basis) will increase the cost of security integration. o If flaws in the hardware-implemented Clipper/Capstone cryptographic algorithms ever come to light, users of the chips will have been subjected to a data compromise from which no clear recovery path exists. o It appears that gaining access to a Clipper/Capstone chip's escrowed keys, through whatever means (authorized or unauthorized), may reveal the contents of all its encrypted traffic (past, present, and future). Effectively, this is analogous to binding an unchangeable password into hardware, an undesirable characteristic. o It appears unlikely that international telecommunications users and providers will reach uniform agreement on an encryption technology whose algorithms are known only to the US Government. As a result, the initiative may force companies engaging in international commerce to use and support different encryption systems, depending on the parties involved in the communication. Such a course of action will lead to increased costs in hardware, software, user training, and systems management. We invite and encourage you to consider the Government initiative, including its impact on your organizations and distributed system security plans, and that you submit comments to your representatives. If your business plans rely on open cryptographic systems, based on publicly documented algorithms and available in hardware or software form, we encourage you to make this clear to your representatives. If you wish to share any of your comments or observations with us, we would welcome them. Further, we are happy to serve as an organizer for assembling and coordinating such information. Please indicate whether we may identify your organization (specifically or generically) as the information's source. John Linn & Dan Geer ------- End of Forwarded Message this is forwarded to the cypherpunks mailing list with dan geer's permission. peter From gnu Mon Jun 28 09:10:48 1993 From: gnu (John Gilmore) Date: Mon, 28 Jun 93 09:10:48 PDT Subject: 1st Amendment vs. ITAR: bibliography Message-ID: <9306281610.AA15456@toad.com> We sent this off to the State Dept. today. law office of Lee Tien 1452 Curtis Street Berkeley, California 94702 _______________ tien at well.sf.ca.us voice: (510) 525-0817 fax: (510) 525-3015 June 28, 1993 Clyde Bryant Foreign Affairs Officer Compliance Division Bureau of Politico-Military Affairs Office of Defense Trade Controls U.S. Department of State PM/ODTC SA-6 Rm. 200 Washington, DC 20522 Dear Mr. Bryant: Mr. Dan Cook told my client, Mr. John Gilmore, that you and the Compliance Division of the Office of Defense Trade Controls are presently reviewing aspects of the International Traffic in Arms Regulations (ITAR) with respect to First Amendment questions. My client volunteered to send some law review articles in order that all relevant materials be available to you in this review. I am pleased to provide you with some materials which you may find useful in your review. They address First Amendment and other constitutional issues raised by the Arms Export Control Act, the ITAR, and the Export Administration Act. We believe that information about cryptography, including research papers, discussion of cryptographic algorithms, and implementations in source-code form, is protected speech within the meaning of the First Amendment. We also believe that the export controls of the ITAR violate the First Amendment because they infringe the rights of cryptographers to speak and publish freely. The licensing procedure amounts to prior restraint. The laws and regulations are vague and overbroad. I have enclosed the following materials: 1. Ferguson, Scientific Inquiry and the First Amendment, 64 CORNELL L.REV. 639 (1979) 2. Note, National Security Controls on the Dissemination of Privately Generated Scientific Information, 30 U.C.L.A. L. REV. 405 (1982) 3. Cheh, Government Control of Private Ideas -- Striking a Balance Between Scientific Freedom and National Security, 23 JURIMETRICS J. 1 (1982) 4. Greenstein, National Security Controls on Scientific Information, 23 JURIMETRICS J. 50 (1982) 5. Alexander, Preserving High-Tech Secrets: National Security Controls on University Research and Teaching, 15 LAW & POL'Y IN INT'L BUS. 173 (1983) 6. Wilson, National Security Control of Technological Information, 25 JURIMETRICS J. 109 (1985) 7. John Harmon, Assistant Attorney General, Office of Legal Counsel, Department of Justice, Memorandum to Dr. Frank Press, Science Advisor to the President, Re: Constitutionality Under the First Amendment of ITAR Restrictions on Public Cryptography (May 11, 1978). This memorandum was reprinted in The Government's Classification of Private Ideas: Hearings before a Subcomm. of the House Comm. on Government Operations, 96th Cong., 2d Sess., 268-84 (1980). These hearing transcripts were accompanied by a House Report. House Comm. on Gov't Operations, The Government's Classification of Private Ideas, H.R. REP. NO. 1540, 96TH CONG., 2D SESS. (1980). We strongly recommend that you read both the hearing transcripts and the summary report. We hope that these materials will assist you in formulating a constitutional export control policy for scientific research in general and for cryptography in particular. Please do not hesitate to contact me if you wish to engage in further exchanges. Sincerely, Lee Tien Attorney at Law On behalf of Mr. John Gilmore cc: Mr. Daniel Cook Mr. John Gilmore From marc at GZA.COM Mon Jun 28 09:37:48 1993 From: marc at GZA.COM (Marc Horowitz) Date: Mon, 28 Jun 93 09:37:48 PDT Subject: Geer Zolot White Paper: Clipper Initiative In-Reply-To: <9306281606.AA15299@toad.com> Message-ID: <9306281637.AA05896@dun-dun-noodles.aktis.com> FYI, several long-time cypherpunks are employees of Geer Zolot, and were involved in writing the White Paper. I hope you all like it :-) Marc From warlord at MIT.EDU Mon Jun 28 16:03:06 1993 From: warlord at MIT.EDU (Derek Atkins) Date: Mon, 28 Jun 93 16:03:06 PDT Subject: My Thesis Presentation... CHARON... Message-ID: <9306282257.AA06812@toxicwaste.MEDIA.MIT.EDU> You are invited to attend my Thesis Presentation, entitled "Charon: Kerberos Extensions For Authentication Over Secondary Networks" Date: Wednesday, June 30, 1993 Time: 12:30 - 2pm Place: MIT Room E40-382 (1 Amherst, Cambridge) You can pick up a PostScript copy of my Thesis either on Athena: attach warlord; cd /mit/warlord/Thesis/Thesis; more thesis.ps or via anonymous ftp to toxicwaste.mit.edu:/pub/charon/thesis.ps.Z Hope to see you there. Please forward this as you see fit. -derek Abstract In this thesis, I describe extensions to the Kerberos Authentication System to enable a secure method of Authentication over multiple networks. Kerberos was designed with a fully-connected IP network in mind, however when you add dialup capabilities to the picture, Kerberos doesn't expand to secure the whole connection. Charon was created to tackle this problem. It was developed to provide a way to securely authenticate to a login server over a modem connection, without allowing a passive attacker to gain enough information to impersonate the user. This means that a user can log into a Kerberized host without typing his password in clear-text over the phone. In addition, no modifications to the login server's base operating system need to be made in order to accomplish this. From friedman at gnu.ai.mit.edu Mon Jun 28 14:25:32 1993 From: friedman at gnu.ai.mit.edu (Noah Friedman) Date: Mon, 28 Jun 93 17:25:32 edt Subject: Digital Signature Scandal Message-ID: <9306282125.AA13550@nutrimat.gnu.ai.mit.edu> [The following is an official announcement from the League for Programming Freedom. Please redistribute this as widely as possible.] Digital Signature Scandal Digital signature is a technique whereby one person (call her J. R. Gensym) can produce a specially encrypted number which anyone can verify could only have been produced by her. (Typically a particular signature number encodes additional information such as a date and time or a legal document being signed.) Anyone can decrypt the number because that can be done with information that is published; but producing such a number uses a "key" (a password) that J. R. Gensym does not tell to anyone else. Several years ago, Congress directed the NIST (National Institute of Standards and Technology, formerly the National Bureau of Standards) to choose a single digital signature algorithm as a standard for the US. In 1992, two algorithms were under consideration. One had been developed by NIST with advice from the NSA (National Security Agency), which engages in electronic spying and decoding. There was widespread suspicion that this algorithm had been designed to facilitate some sort of trickery. The fact that NIST had applied for a patent on this algorithm engendered additional suspicion; despite their assurances that this would not be used to interfere with use of the technique, people could imagine no harmless motive for patenting it. The other algorithm was proposed by a company called PKP, Inc., which not coincidentally has patents covering its use. This alternative had a disadvantage that was not just speculation: if this algorithm were adopted as the standard, everyone using the standard would have to pay PKP. (The same patents cover the broader field of public key cryptography, a technique whose use in the US has been mostly inhibited for a decade by PKP's assiduous enforcement of these patents. The patents were licensed exclusively to PKP by the Massachusetts Institute of Technology and Stanford University, and derive from taxpayer-funded research.) PKP, Inc. made much of the suspect nature of the NIST algorithm and portrayed itself as warning the public about this. On June 8, NIST published a new plan which combines the worst of both worlds: to adopt the suspect NIST algorithm, and give PKP, Inc. an *exclusive* license to the patent for it. This plan places digital signature use under the control of PKP through the year 2010. By agreeing to this arrangement, PKP, Inc. shows that its concern to protect the public from possible trickery was a sham. Its real desire was, as one might have guessed, to own an official national standard. Meanwhile, NIST has justified past suspicion about its patent application by proposing to give that patent (in effect) to a private entity. Instead of making a gift to PKP, Inc., of the work all of us have paid for, NIST and Congress ought to protect our access to it--by pursuing all possible means, judicial and legislative, to invalidate or annull the PKP patents. If that fails, even taking them by eminent domain is better (and cheaper in the long run!) than the current plan. You can write to NIST to object to this giveaway. Write to: Michael R. Rubin Active Chief Counsel for Technology Room A-1111, Administration Building, National Institute of Standards and Technology Gaithersburg, Maryland 20899 (301) 975-2803. The deadline for arrival of letters is around August 4. Please send a copy of your letter to: League for Programming Freedom 1 Kendall Square #143 P.O.Box 9171 Cambridge, Massachusetts 02139 (The League for Programming Freedom is an organization which defends the freedom to write software, and opposes monopolies such as patented algorithms and copyrighted languages. It advocates returning to the former legal system under which if you write the program, you are free to use it. Please write to the League if you want more information.) Sending copies to the League will enable us to show them to elected officials if that is useful. ===================================================================== APPENDIX G: THE LETTERS I INTEND TO SEND ======================================== - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr Ross N. Williams Rocksoft Pty Ltd (ACN 008-280-153). 16 Lerwick Avenue Hazelwood Park 5066 Australia Net : ross at guest.adelaide.edu.au. Fax : +61 8 373-4911 (C/-Internode Systems) Work : +61 8 379-9217 Michael R. Rubin Acting Chief Counsel for Technology Room A-1111 Administration Building National Institute of Standards and Technology Gaithersburg, MD 20899 4 August 1993. Dear Mr Rubin, As a concerned member of the Australian public, and as a director of an Australian software company, I am writing in response to the notice "Notice of Proposal for Grant of Exclusive Patent License" published by NIST in the U.S. Federal Register, Vol. 58, No. 108, dated June 8, 1993 under Notices and relating to U.S. Patent Application No. 07/738.431 and entitled "Digital Signature Algorithm." This notice affects myself and my company in its relationship to the US commercial environment and because of the propagation of patent claims internationally. The notice states that: >The prospective license will be granted unless, within sixty (60) >days of this notice, NIST receives written evidence and argument >which established that the grant of the license would not be >consistent with the requirements of 35 U.S.C. 209 and 37 CFR 404.7. I am writing because I believe that the license is NOT consistent with the requirements of 35 U.S.C. 209. Here's why. In 35 U.S.C. 209. part (c)(1), the requirements specify a list of conditions (A)..(D) all of which must be met before a U.S. Federal agency may grant an exclusive or partially exclusive license. Part (A) says: >(A) the interests of the Federal Government and the public will >best be served by the proposed license, in view of the applicant's >intentions, plans, and ability to bring the invention to practical >application or otherwise promote the invention's utilization by >the public; I do not wish to debate this clause as satisified or not satisifed except to note that this clause defines NIST's primary goal as the public benefit, not the private. >(B) the desired practical application has not been achieved, or is not >likely expeditiously to be achieved, under any non-exclusive license >which has been granted, or which may be granted, on the invention; There is no reason why the DSA standard should not be widely implemented without the benefit of any patents at all. I am aware of the potential conflict that prospective implementers might have with Public Key Partners (PKP) of Sunnyvale California. However, I believe that this problem should be resolved by the free market and the patent system rather than by NIST. >(C) exclusive or partially exclusive licensing is a reasonable and >necessary initiative to call forth the investment of risk capital and >expenditures to bring the invention to practical application or >otherwise promote the invention's utilization by the public; and The history of innovation and technology diffusion in the computing industry clearly indicates that, in the absence of PKP, there would be no requirement to boost risk capital with the use of patents in order to diffuse the technology. As soon as a technologically workable standard is proclaimed, it will be adopted. In particular, the cost of implementing the standard in software is likely to be less than $30,000. As a result there will soon be many implementations. >(D) the proposed terms and scope of exclusivity are not greater than >reasonably necessary to provide the incentive for bringing the invention >to practical application or otherwise promote the invention's >utilization by the public. It is clause (D) to which I mainly take exception. In (A) I asserted that the goal of NIST should be the public good. In (B) and (C) I asserted that for a much-awaited cheap-to-implement standard such as the DSA, patents are not required in order to attract risk capital. These two clauses in combination with (D) imply that NIST should be doing its best to deliver the standard into the public domain, and if this is not possible, licensing it in the least-restrictive manner possible. Under the current proposal, NIST will license the DSA patent to PKP indefinitely; that is, until it runs out in the year 2010. However, PKP's patents, (which in the light of (A),(B), and (C) should be the sole motivation for the license proposal) expire in 1997 or soon after. This flies in the face of clause (D) which permits NIST to grant at most only the minimum reasonable license, in this case a license lasting only until 1997, after which the DSA patent should be placed in the public domain. This argument applies independent to any arguments stating that PKP have committed to behave in a certain "limited" way once granted the DSA patent licence; my argument applies to the time period over which the patent license is granted not the manner in which PKP conduct themselves during the period in which it is granted. Ideally thought, NIST should not grant DSS to PKP at all. I hope that the above provides a convincing argument that NIST would not be complying with the requirements of 35 U.S.C. 209.(c)(1)(D) if it executed the proposed license. --O-- There are many alternatives to the proposed license that NIST could pursue. For example, NIST could simply issue a general public license to DSA. Or NIST could use it's patent powers to impose the following condition on all implementors: Condition: All implementations of the DSA must be constructed in accordance with <> so that DSA can be quickly and cheaply replaced with other algorithms at a later date. If this move were adopted now, it would pave the way for RSA in 2000, or perhaps for an even better, hitherto uncreate, algorithm. Other, more aggressive strategies exist that could solve the problem too, the extreme being the taking of PKPs patents by "eminant domain". However, I realize that this would be extreme and am writing primarily to submit the objections given above. In addition to the above, I enclose three letters applying for: 1) A license of DSA for myself to use DSA. 2) A license of DSA for myself to implement and distribute DSA for free. 3) An unlimited commercial license for my company Rocksoft Pty Ltd, or failing this a non-commercial license. I would like to end this letter on a lighter note... During times of drought a farmer noticed that his cow was looking a bit thin so he sent his son out with the cow to find some nice green grass to munch on so that the cow would grow fat and yield lots of milk. The son walked the cow for miles and miles (making the cow even thinner in the process), but couldn't find any grass (this is actually the Australian outback). In the end he found a nice green paddock and set the cow grazing. Later the son returned to the homestead: Farmer : How'd it go son? Do we have a happy cow now? Son : Well sort of; I had trouble finding a grassy paddock. Farmer : But you found one in the end didn't you? Son : Yes, and I put the cow in the paddock. But soon another farmer came running out. He said it was his paddock --- he had rented it for three years --- and that I couldn't graze my cow there without giving him some milk. It was the only green paddock there was. Farmer : So what did you do? Son : I gave him the cow. Thank you for your kind attention. Please do not hesitate to contact me if you require any more information or clarification of the above. Yours sincerely, Ross Williams ------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr Ross N. Williams Rocksoft Pty Ltd (ACN 008-280-153). 16 Lerwick Avenue Hazelwood Park 5066 Australia Net : ross at guest.adelaide.edu.au. Fax : +61 8 373-4911 (C/-Internode Systems) Work : +61 8 379-9217 Michael R. Rubin Acting Chief Counsel for Technology Room A-1111 Administration Building National Institute of Standards and Technology Gaithersburg, MD 20899 4 August 1993. Dear Mr Rubin, I am writing in response to the notice "Notice of Proposal for Grant of Exclusive Patent License" published by NIST in the U.S. Federal Register, Vol. 58, No. 108, dated June 8, 1993 under Notices and relating to U.S. Patent Application No. 07/738.431 and entitled "Digital Signature Algorithm." The notice states that: >Applications for a license filed in response to this notice will be >treated as objections to the grant of the prospective license. >Only written comments and/or applications for a license which are >received by NIST within sixty (60) days for the publication of this >notice will be considered. As such, I would like to apply, on behalf of my company Rocksoft Pty Ltd for a license of this patent. The following information is provided in accordance with 37 CFR 404.8. (a) Identification of the invention: Title: "Digital Signature Algorithm (DSA)." Patent Application Serial Number: 07/738.431. United States Patent Number: To be issued as 5,231,668, I believe. (b) The type of license required is a commercial license requiring no royalties, OR FAILING THAT A NON-COMMERCIAL (i.e. non-profit) LICENSE requiring no royalty payments. (c) The organization applying for the license is "Rocksoft Pty Ltd", a company incorporated in Australia, whose formally registered address is c/- Nelson Wheeler 200 East Terrace Adelaide 5000 Australia whose Australian Company Number is 008-280-153, and whose postal address (please address correspondence to this address) is: 16 Lerwick Avenue Hazelwood Park 5066 Australia. (d) The representative of Rocksoft is: Name : Dr Ross N. Williams. Address: 16 Lerwick Avenue, Hazelwood Park 5066 Australia. Phone: +61 8 379-5020. (e) Rocksoft is a software consultancy employing only Ross Williams. The company has not yet successfully commercialized any products. (f) Source of information concerning availability of a license: various sources, including your Federal Register notice. (g) I am unable to determine whether Rocksoft Pty Ltd may be formally classified as a small business firm under 404.3(c). However, I would be very surprised if it is not, unless there is some requirement for it to be incorporated in the US. (h) Development plan. If a license is granted, Rocksoft will attempt to create an implementation of the DSA and either sub license it as a component or embed it in products requiring digital signatures. No plans more specific than this can be provided at this time. (1) Rocksoft expects that many hundreds of programmer hours could be committed to the project. Very little capital is available. However, if a license is secured, this may become available. (2) NO further statement on a development plan can be made at present. (3) Fields of use: Rocksoft wishes to use the technology in many diverse fields. (4) Geographic are of use: The whole world. Failing this, just Australia. (i) No previous licenses have been granted to Rocksoft under Federally owned inventions. (j) Known uses of DSA by industry or government: I have heard that ISC sells a product called dsaSIGN, and that Bellcore has implemented DSA. (k) Any other information. I am aware that one of the goals of the licensing of Federally owned inventions is to promote small business in the US and Rocksoft is a small business in Australia. I am hoping however that this application will be successful because it is an application for a non-exclusive, non-transferrable license. I understand that NIST may grant an exclusive DSA license to PKP, and that this license application will be treated as an objection to the PKP license. I would like this application to be treated as such. Thank you for your kind attention. Please do not hesitate to contact me if you require any more information or clarification of the above. Yours sincerely, Ross Williams ------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr Ross N. Williams 16 Lerwick Avenue Hazelwood Park 5066 Australia Net : ross at guest.adelaide.edu.au. Fax : +61 8 373-4911 (C/-Internode Systems) Work : +61 8 379-9217 Michael R. Rubin Acting Chief Counsel for Technology Room A-1111 Administration Building National Institute of Standards and Technology Gaithersburg, MD 20899 4 August 1993. Dear Mr. Rubin: I hereby apply for a personal license to use the Digital Signature Algorithm. 1. Title of invention: Digital Signature Algorithm (DSA). 2. Patent Application Serial Number: 07/738.431. 3. United States Patent Number: To be issued as 5,231,668, I believe. 4. Source of information concerning availability of a license: Various sources, including your Federal Register notice. 5. Name and address of applicant: Dr Ross N. Williams 16 Lerwick Avenue Hazelwood Park 5066 Australia Net : ross at guest.adelaide.edu.au. Fax : +61 8 373-4911 (C/-Internode Systems) Work : +61 8 379-9217 6. Applicant's representative: not applicable. 7. I am an Australian citizen. 8. Approximate number of persons employed: not applicable. 9. I am not a small business firm. 10. Purpose: I would like a personal license allowing me to implement and use DSA. See #12. 11. Business and commercialization: not applicable; see #10. 12. Plans: I plan to use DSA to attach digital signatures to a variety of electronic documents, primarily for authentication. I plan to use DSA implementations, initially in software but perhaps later in hardware, from a variety of potential future sources. Investments: I may spend many hours programming a DSA implementation. 13. Fields of commercialization: not applicable; see #10. 14. I am not willing to accept a license for less than all fields of use of DSA. 15. I intend to implement and use DSA throughout the world. However, failing this a license for Australia and the U.S.A. would be appreciated. Failing this, a license for just Australia would still be useful. 16. Type of license: I would like a non-exclusive license which does not require royalty payments. 17. I have never been granted a license to a federally owned invention. 18. Known uses of DSA by industry or government: I have heard that ISC sells a product called dsaSIGN, and that Bellcore has implemented DSA. 19. Other information: I understand that NIST may grant an exclusive DSA license to PKP, and that this license application will be treated as an objection to the PKP license. Please note that PKP has stated its intent to make DSA free for personal use. Therefore, if NIST grants PKP a license and PKP acts according to its stated intent, there is no harm to anyone if I am granted this personal license. However, I do not trust PKP to act according to its stated intent, and I do not want to have to apply for a license from PKP even if it is royalty-free. So I ask that you grant me a license directly. Thank you for your kind attention. Please let me know if you need more information. Yours sincerely, Ross Williams ------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr Ross N. Williams 16 Lerwick Avenue Hazelwood Park 5066 Australia Net : ross at guest.adelaide.edu.au. Fax : +61 8 373-4911 (C/-Internode Systems) Work : +61 8 379-9217 Michael R. Rubin Acting Chief Counsel for Technology Room A-1111 Administration Building National Institute of Standards and Technology Gaithersburg, MD 20899 4 August 1993. Dear Mr. Rubin: I hereby apply for an implementor's license permitting me to sublicense the use of the Digital Signature Algorithm. 1. Title of invention: Digital Signature Algorithm (DSA). 2. Patent Application Serial Number: 07/738.431. 3. United States Patent Number: To be issued as 5,231,668, I believe. 4. Source of information concerning availability of a license: Various sources, including your Federal Register notice. 5. Name and address of applicant: Dr Ross N. Williams 16 Lerwick Avenue Hazelwood Park 5066 Australia Net : ross at guest.adelaide.edu.au. Fax : +61 8 373-4911 (C/-Internode Systems) Work : +61 8 379-9217 6. Applicant's representative: not applicable. 7. I am an Australian citizen. 8. Approximate number of persons employed: not applicable. 9. I am not a small business firm. 10. Purpose: I would like a license allowing me to let others freely use my implementation of DSA, i.e., allowing me to sublicense the use of DSA at no cost. See #12. 11. Business and commercialization: not applicable; see #10. 12. Plans: I plan to create a source-code implementation of DSA in software, using computer resources which are already available to me. I plan to give this implementation to anyone who asks, and perhaps to publish this implementation via electronic or non-electronic means, for study and use by the academic and non-academic communities. I hope to have people hear about this implementation by a variety of means, including word of mouth. 13. Fields of commercialization: not applicable; see #10. 14. I am not willing to accept a license for less than all fields of use of DSA. 15. I intend to implement DSA in Australia (but distribute my implementations throughout the world). 16. Type of license: I would like a non-exclusive license which does not require royalty payments. 17. I have never been granted a license to a federally owned invention. 18. Known uses of DSA by industry or government: I have heard that ISC sells a product called dsaSIGN, and that Bellcore has implemented DSA. 19. Other information: I understand that NIST may grant an exclusive DSA license to PKP, and that this license application will be treated as an objection to the PKP license. Let me emphasize that this is not a commercial license application. I do not intend to collect any fees for the use of this implementation. Thank you for your kind attention. Please let me know if you need more information. Yours sincerely, Ross Williams ------------- ===================================================================== ------ Paul Ferguson | "Government, even in its best state, Network Integrator | is but a necessary evil; in its worst Centreville, Virginia USA | state, an intolerable one." fergp at sytex.com | - Thomas Paine, Common Sense I love my country, but I fear its government. From zane at genesis.mcs.com Mon Jun 28 18:04:25 1993 From: zane at genesis.mcs.com (Sameer) Date: Mon, 28 Jun 93 18:04:25 PDT Subject: REMAIL: problems In-Reply-To: <199306281508.AA26337@Menudo.UH.EDU> Message-ID: I've been thinking a little bit about the problems with unreliable remailers. Supposing that we can never rely on the reliability of all the remailers in a given path (because of not just bugs in the software, but political hassles) it would be good to figure out a mechanism by which a problem can be noticed. For example: supposing that I made the following mail path :: Request-Remailing-To: hh at soda.berkeley.edu :: Request-Remailing-To: remail at tamsun.tamu.edu :: Request-Remailing-To: hfinney at shell.portal.com :: Request-Remailing-To: cypherpunks at toad.com Suppose that remail at tamsun.tamu.edu wasn't working. Maybe it would be possible for the remailer to notice that the next address in the hop is a remailer, and check to see whether the next remailer is working or not. (Send a ping-message.. This would slow things down greatly, yes.) Then if the remailer isn't working, something can be done. (Maybe figure out some way of telling the originator [through encrypted return-paths] that a certain remailer isn't working) This idea (obviously) isn't fully thought out. There are some glaring problems with the system in that it would end up destroying a good deal of the anonymity in the system. It might be possible, however, to modify this idea to make it workable. It is definitely likely, in my mind, that remailers will continue to be unreliable as long as net-anonymity is a controversial topic. -- | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/ From jthomas at access.digex.net Mon Jun 28 18:36:31 1993 From: jthomas at access.digex.net (Joe Thomas) Date: Mon, 28 Jun 93 18:36:31 PDT Subject: REMAIL: problems In-Reply-To: Message-ID: On Mon, 28 Jun 1993, Sameer wrote: > I've been thinking a little bit about the problems with unreliable > remailers. > > Supposing that we can never rely on the reliability of all the > remailers in a given path (because of not just bugs in the software, but > political hassles) it would be good to figure out a mechanism by which > a problem can be noticed. I've thought about this as well. I don't think it's right to _ever_ keep return path information in a cypherpunk remailer, even for error reporting. Far better to just drop the message on the floor than provide a loophole to the anonymity of the system. That said, I think there are possible solutions to the problem of vanishing remailers. Let's say there is a method to quickly and easily verify the continuing existance (or lack thereof) of a remailer. When a remailer receives a request to send a message to another remailer, it can quickly check to see if that remailer is in operation. The question is what to do with the information if it turns out the remailer is really down. If the message is unencrypted, a smart remailer could simply skip the missing remailer or send the message on to a substitute remailer, which would then pass the message down the chain. But if the message is encrypted with each remailer's key, it is undeliverable without that remailer to decrypt it. My idea is for remailers to share their private keys using a secret-sharing protocol. When a remailer goes down, all the other remailers that hold pieces of its key would choose a replacement remailer and send it the key pieces. From then on, all mail for the missing remailer would be routed instead to its replacement remailer, which would decrypt and process it as usual. It would be quite a pain to implement, but would make large remailer nets a lot more reliable if it's done right. Joe From i6t4 at jupiter.sun.csd.unb.ca Mon Jun 28 22:31:09 1993 From: i6t4 at jupiter.sun.csd.unb.ca (Nickey MacDonald) Date: Mon, 28 Jun 93 22:31:09 PDT Subject: REMAIL: problems In-Reply-To: Message-ID: On Mon, 28 Jun 1993, Sameer wrote: > I've been thinking a little bit about the problems with unreliable > remailers. I had another suggestion that might be helpful for people that are chaining through many remailers, but it would require an addition or two to existing remailers. I'm not sure how to make clear what I mean, but lets start with a proposed sample message: :: Request-Remailing-To-Remailer: hh at soda.berkeley.edu :: Request-Remailing-To-Remailer: remail at tamsun.tamu.edu :: Request-Remailing-To-Remailer: hfinney at shell.portal.com :: Request-Remailing-To: cypherpunks at toad.com {Message body goes here} I'm sure you caught the change... You identify for the remailer when the next hop is supposed to be a remailer. Just by itself, this is of no extra help, but hopefully of little extra bother because the old style would still work. Now how do we make it more reliable? If the remailer knows that the message is going to another remailer, it can expect a 'reply' from that remailer once the message has been processed (forwarded), say within 48 hours. Give each message a serial number and the remailer a memory... If the message is not acknowledged within the timeout period, it skips a hop and goes to the next remailer (or the destination). This could also be expanded to let each remailer tell other remailers about itself... it could maintain a database of known remailers. The problem with this approach is that the remailer must store messages locally for up 48 hours (well more if all of the hops were down)... I can't see (as Sameer alluded to) a way to have reliability (which sort of implies, especially with the above approach, storage) and secrecy (which implies quick and dirty 'less safe' message handling). I have source code for serializing things (file access is what it was designed form but I have found lots of neat uses for it). It really quite simple code, and not completely portable (well it uses flock(), not all versions of un*x support flock()...) I wrote the serializer to make sure that my mail alias did not allow more than one copy of my email processing script to run at once (thus creating very nasty log file collisions!). Comments? -- Nick MacDonald | NMD on IRC i6t4 at jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger i6t4 at unb.ca | (506) 457-1931 ^{1024/746EBB 1993/02/23} From nobody at newsgate.cs.pdx.edu Mon Jun 28 23:02:59 1993 From: nobody at newsgate.cs.pdx.edu (/Dev/Null) Date: Mon, 28 Jun 93 23:02:59 PDT Subject: End to End encryption for PC AND UNIX Message-ID: <9306290605.AA12126@newsgate.cs.pdx.edu> Does anyone out there know if there is a program that will encrypt everything going over the phone line between a IBM MSDOS computer and a unix system? From jthomas at kolanut.mitre.org Tue Jun 29 05:26:56 1993 From: jthomas at kolanut.mitre.org (Joe Thomas) Date: Tue, 29 Jun 93 05:26:56 PDT Subject: REMAIL: problems Message-ID: <9306291227.AA00990@kolanut> > > I've been thinking a little bit about the problems with unreliable > > remailers. > > I had another suggestion that might be helpful for people that are > chaining through many remailers, but it would require an addition or two > to existing remailers. . . . > If the remailer knows that the message is going to another remailer, it > can expect a 'reply' from that remailer once the message has been > processed (forwarded), say within 48 hours. Give each message a serial > number and the remailer a memory... If the message is not acknowledged > within the timeout period, it skips a hop and goes to the next remailer > (or the destination). This is a serious misfeature. An essential goal of remailer design is that they be stateless. A message is forwarded, then immediately forgotten. Any historical information about messages that have gone through is a potential weakness. Message serial numbers are a perfect audit trail. > The problem with this approach is that the remailer must store messages > locally for up 48 hours (well more if all of the hops were down)... I > can't see (as Sameer alluded to) a way to have reliability (which sort of > implies, especially with the above approach, storage) and secrecy (which > implies quick and dirty 'less safe' message handling). Consider cryptographic secret-sharing protocols. If we have 20 remailers, each remailer could split his key into 20 pieces, 15 of which would be necessary to reconstruct the key. When a remailer goes down, the key could be reconstructed and given to a substitute remailer. The system can survive the loss of 5 remailers, and would require a collaboration of 15, or 3/4 of the remailer operators to intentionally break the security. Joe (working on my .sig; I don't speak for MITRE) -- Joe Thomas Say no to the Wiretap Chip! PGP key available by request, finger, or pgp-public-keys at toxicwaste.mit.edu PGP key fingerprint: 1E E1 B8 6E 49 67 C4 19 8B F1 E4 9D F0 6D 68 4B From Bernard.A.Galler at um.cc.umich.edu Tue Jun 29 07:36:11 1993 From: Bernard.A.Galler at um.cc.umich.edu (Bernard.A.Galler at um.cc.umich.edu) Date: Tue, 29 Jun 93 08:36:11 -0600 Subject: Digital Signature Scandal Message-ID: <24039642@um.cc.umich.edu> - ------- Forwarded message Received: from eff.org by um.cc.umich.edu via MTS-Net; Mon, 28 Jun 93 19:01:51 EDT Received: by eff.org id AA18269 (5.65c/IDA-1.5/ident for interesting-people-exploder); Mon, 28 Jun 1993 19:01:33 -0400 Posted-Date: Mon, 28 Jun 1993 18:59:37 -0500 Message-Id: <9306282259.AA06949 at linc.cis.upenn.edu> X-Sender: farber at linc.cis.upenn.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jun 1993 18:59:37 -0500 From: farber at central.cis.upenn.edu (David Farber) Subject: Digital Signature Scandal To: interesting-people at eff.org (interesting-people mailing list) [The following is an official announcement from the League for Programming Freedom. Please redistribute this as widely as possible.] Digital Signature Scandal Digital signature is a technique whereby one person (call her J. R. Gensym) can produce a specially encrypted number which anyone can verify could only have been produced by her. (Typically a particular signature number encodes additional information such as a date and time or a legal document being signed.) Anyone can decrypt the number because that can be done with information that is published; but producing such a number uses a "key" (a password) that J. R. Gensym does not tell to anyone else. Several years ago, Congress directed the NIST (National Institute of Standards and Technology, formerly the National Bureau of Standards) to choose a single digital signature algorithm as a standard for the US. In 1992, two algorithms were under consideration. One had been developed by NIST with advice from the NSA (National Security Agency), which engages in electronic spying and decoding. There was widespread suspicion that this algorithm had been designed to facilitate some sort of trickery. The fact that NIST had applied for a patent on this algorithm engendered additional suspicion; despite their assurances that this would not be used to interfere with use of the technique, people could imagine no harmless motive for patenting it. The other algorithm was proposed by a company called PKP, Inc., which not coincidentally has patents covering its use. This alternative had a disadvantage that was not just speculation: if this algorithm were adopted as the standard, everyone using the standard would have to pay PKP. (The same patents cover the broader field of public key cryptography, a technique whose use in the US has been mostly inhibited for a decade by PKP's assiduous enforcement of these patents. The patents were licensed exclusively to PKP by the Massachusetts Institute of Technology and Stanford University, and derive from taxpayer-funded research.) PKP, Inc. made much of the suspect nature of the NIST algorithm and portrayed itself as warning the public about this. On June 8, NIST published a new plan which combines the worst of both worlds: to adopt the suspect NIST algorithm, and give PKP, Inc. an *exclusive* license to the patent for it. This plan places digital signature use under the control of PKP through the year 2010. By agreeing to this arrangement, PKP, Inc. shows that its concern to protect the public from possible trickery was a sham. Its real desire was, as one might have guessed, to own an official national standard. Meanwhile, NIST has justified past suspicion about its patent application by proposing to give that patent (in effect) to a private entity. Instead of making a gift to PKP, Inc., of the work all of us have paid for, NIST and Congress ought to protect our access to it--by pursuing all possible means, judicial and legislative, to invalidate or annull the PKP patents. If that fails, even taking them by eminent domain is better (and cheaper in the long run!) than the current plan. You can write to NIST to object to this giveaway. Write to: Michael R. Rubin Active Chief Counsel for Technology Room A-1111, Administration Building, National Institute of Standards and Technology Gaithersburg, Maryland 20899 (301) 975-2803. The deadline for arrival of letters is around August 4. Please send a copy of your letter to: League for Programming Freedom 1 Kendall Square #143 P.O.Box 9171 Cambridge, Massachusetts 02139 (The League for Programming Freedom is an organization which defends the freedom to write software, and opposes monopolies such as patented algorithms and copyrighted languages. It advocates returning to the former legal system under which if you write the program, you are free to use it. Please write to the League if you want more information.) Sending copies to the League will enable us to show them to elected officials if that is useful. This text was transcribed from a fax and may have transcription errors. We believe the text to be correct but some of the numbers may be incorrect or incomplete. - --------------------------------------------------------------------- ** The following notice was published in the Federal Register, Vol. 58, No. 108, dated June 8, 1993 under Notices ** National Institute of Standards and Technology Notice of Proposal for Grant of Exclusive Patent License This is to notify the public that the National Institute of Standards and Technology (NIST) intends to grant an exclusive world-wide license to Public Key Partners of Sunnyvale, California to practice the Invention embodied in U.S. Patent Application No. 07/738.431 and entitled "Digital Signature Algorithm." A PCT application has been filed. The rights in the invention have been assigned to the United States of America. The prospective license is a cross-license which would resolve a patent dispute with Public Key Partners and includes the right to sublicense. Notice of availability of this invention for licensing was waived because it was determined that expeditious granting of such license will best serve the interest of the Federal Government and the public. Public Key Partners has provided NIST with the materials contained in Appendix A as part of their proposal to NIST. Inquiries, comments, and other materials relating to the prospec- tive license shall be submitted to Michael R. Rubin, Active Chief Counsel for Technology, Room A-1111, Administration Building, National Institute of Standards and Technology, Gaithersburg, Maryland 20899. His telephone number is (301) 975-2803. Applica- tions for a license filed in response to this notice will be treated as objections to the grant of the prospective license. Only written comments and/or applications for a license which are received by NIST within sixty (60) days for the publication of this notice will be considered. The prospective license will be granted unless, within sixty (60) days of this notice, NIST receives written evidence and argument which established that the grant of the license would not be consistent with the requirements of 35 U.S.C. 209 and 37 CFR 404.7. Dated: June 2, 1993. Raymond G. Kammer Acting Director, National Institute Standards and Technology. Appendix "A" The National Institute for Standards and Technology ("NIST") has announced its intention to grant Public Key Partners ("PKP") sublicensing rights to NIST's pending patent application on the Digital Signature Algorithm ("DSA"). Subject to NIST's grant of this license, PKP is pleased to declare its support for the proposed Federal Information Processing Standard for Digital Signatures (the "DSS") and the pending availability of licenses to practice the DSA. In addition to the DSA, licenses to practice digital signatures will be offered by PKP under the following patents: Cryptographic Apparatus and Method ("Diffie-Hellman") No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle") No. 4,315,552 Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig") No. 4,434,414 Method For Identifying Subscribers And For Generating And Verifying Electronic Signatures In A Data Exchange System ("Schnorr") No. 4,995,082 It is PKP's intent to make practice of the DSA royalty free for personal, noncommercial and U.S. Federal, state and local government use. As explained below, only those parties who enjoy commercial benefit from making or selling products, or certifying digital signatures, will be required to pay royalties to practice the DSA. PKP will also grant a license to practice key management, at no additional fee, for the integrated circuits which will implement both the DSA and the anticipated Federal Information Processing Standard for the "key escrow" system announced by President Clinton on April 16, 1993. Having stated these intentions, PKP now takes this opportunity to publish its guidelines for granting uniform licenses to all parties having a commercial interest in practicing this technology: First, no party will be denied a license for any reason other that the following: (i) Failure to meet its payment obligations, (ii) Outstanding claims of infringement, or (iii) Previous termination due to material breach. Second, licenses will be granted for any embodiment sold by the licensee or made for its use, whether for final products software, or components such as integrated circuits and boards, and regard- less of the licensee's channel of distribution. Provided the requisite royalties have been paid by the seller on the enabling component(s), no further royalties will be owned by the buyer for making or selling the final product which incorporates such components. Third, the practice of digital signatures in accordance with the DSS may be licensed separately from any other technical art covered by PKP's patents. Fourth, PKP's royalty rates for the right to make or sell products, subject to uniform minimum fees, will be no more than 2 1/2% for hardware products and 5% for software, with the royalty rate further declining to 1% on any portion of the product price exceeding $1,000. These royalty rates apply only to noninfringing parties and will be uniform without regard to whether the licensed product creates digital signatures, verifies digital signatures or performs both. Fifth, for the next three (3) years, all commercial services which certify a signature's authenticity for a fee may be operated royalty free. Thereafter, all providers of such commercial certification services shall pay a royalty to PKP of $1.00 per certificate for each year the certificate is valid. Sixth, provided the foregoing royalties are paid on such products or services, all other practice of the DSA shall be royalty free. Seventh, PKP invites all of its existing licensees, at their option, to exchange their current licenses for the standard license offered for DSA. Finally, PKP will mediate the concerns of any party regarding the availability of PKP's licenses for the DSA with designated representatives of NIST and PKP. For copies of PKP's license terms, contact Michael R. Rubin, Acting Chief Counsel for Technolo- gy, NIST, or Public Key Partners. Dated: June 2, 1993. Robert B. Fougner, Esq., Director of Licensing, Public Key Partners, 310 North Mary Avenue, Sunnyvale, CA 94033 [FR Doc. 93-13473 Filed 8-7-93; 8:45 am] - --------------------------------------------------------------------- Forwarded by: - -- Jim Gillogly Trewesday, 21 Forelithe S.R. 1993, 20:56 ------- End of Forwarded Message From newsham at wiliki.eng.hawaii.edu Tue Jun 29 12:11:07 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Tue, 29 Jun 93 12:11:07 PDT Subject: End to End encryption for PC AND UNIX In-Reply-To: <9306290605.AA12126@newsgate.cs.pdx.edu> Message-ID: <9306291911.AA01818@toad.com> > > Does anyone out there know if there is a program that will encrypt everything going over the phone line between a IBM MSDOS computer and a unix system? > I wrote such a program, but no MSDOS port exists. I have a Unix end that runs a shell while doing encrpytion and decryption, and an Amiga end that is built on top of a P.D. term program. Someone volunteered to do a DOS port at one point but I havent heard anything from them. I'm thinking of putting in a little time and putting together something simple just so something exists and people can see how it was done (if they care to make something with more bells and whistles). The code is on soda in one of the cypherpunks directories under the name of link1.0.tar.Z, Ami-link1.0-src.lha and Ami-link1.0.lha ... From smb at research.att.com Tue Jun 29 12:33:09 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 29 Jun 93 12:33:09 PDT Subject: Clipper vs. Russia Message-ID: <9306291933.AA02464@toad.com> According to an AP wire story, Article 23 of the draft Russian constitution says that ``Each person has the right to secret correspondence, telephone conversations, mail, telegraph and other communications.'' Shucks -- there goes another export market for Clipper... Oh yeah -- the AP explains the clause by referring to the ways that Soviet authorities used to spy on people. --Steve Bellovin From marc at GZA.COM Tue Jun 29 13:02:38 1993 From: marc at GZA.COM (Marc Horowitz) Date: Tue, 29 Jun 93 13:02:38 PDT Subject: Clipper vs. Russia In-Reply-To: <9306291933.AA02464@toad.com> Message-ID: <9306292002.AA06961@dun-dun-noodles.aktis.com> >> According to an AP wire story, Article 23 of the draft Russian >> constitution says that ``Each person has the right to secret >> correspondence, telephone conversations, mail, telegraph and other >> communications.'' That's not really too meaningful. Our Constitution provides for protection against unlawful search and seizure (comments on the reality of this to alt.flame, please :-). Does the draft Russian constitution forbid *all* tapping of mail, phones, etc? I doubt it. So that basically gives them the same protection we (nominally) have, and our government seems quite happy with Key Escrow. Marc From newsham at wiliki.eng.hawaii.edu Tue Jun 29 13:07:07 1993 From: newsham at wiliki.eng.hawaii.edu (Timothy Newsham) Date: Tue, 29 Jun 93 13:07:07 PDT Subject: End to End encryption for PC AND UNIX In-Reply-To: <9306291920.AA02902@snark.shearson.com> Message-ID: <9306292007.AA03286@toad.com> > > > > > > > > I wrote such a program, but no MSDOS port exists. I have a Unix end > > that runs a shell while doing encrpytion and decryption, and an > > Amiga end that is built on top of a P.D. term program. > > Someone volunteered to do a DOS port at one point but I havent > > heard anything from them. I'm thinking of putting in a little > > time and putting together something simple just so something exists > > and people can see how it was done (if they care to make something > > with more bells and whistles). > > The code is on soda in one of the cypherpunks directories under > > the name of link1.0.tar.Z, Ami-link1.0-src.lha and Ami-link1.0.lha > > I wnat to build a unix-unix version of this -- are the sources to both > ends in the tar file? I don't have lha... > > .pm > Yes, the .tar.Z file should have everything you want. Most of the work is already done for you. The program comes as a server (link) but there is also a test client (connect) that I wrote to test out the protocol. If you edit the makefile and include the defines DEBUG and SOCKET link and connect will be built to use a socket as I/O and will talk to each other. If you wish to use it over a serial line you can take the connect client and modify it to use a serial device instead of the socket. ... From anonymous at extropia.wimsey.com Tue Jun 29 15:33:09 1993 From: anonymous at extropia.wimsey.com (Anonymous) Date: Tue, 29 Jun 93 15:33:09 PDT Subject: REMAIL: Howto Post Anon to (almost?) any Newsgroup Message-ID: <199306292206.AA23446@xtropia> This subject came up here a few months ago. I can report that I was able to post to the rec.video.cable-tv newsgroup anonymously through the wimsey remailer plus group-name at cs.utexas.edu. Send the following to Remailer all PGP encrypted with key pub 1024/B5A32F 1992/12/13 Remailer To: group-name at cs.utexas.edu Subject: Text to appear in anonymous post to newsgroup "group-name" "Group-name" is the name of the newsgroup with dashes "-" substituted for periods ".". Where the name already contains a dash, just leave it alone. So, for example, rec.video.cable-tv becomes rec-video-cable-tv. Note that with the wimsey remailer, anything not encrypted is discarded, so no need to worry about your automatic sig. Here is how the anonymous post appears: [Newsgroup rec.video.cable-tv] Post: 614 of 619 From: anonymous at extropia.wimsey.com (Anonymous) Newsgroups: rec.video.cable-tv Subject: TCI San Jose Free(?) Extended Basic Date: 26 Jun 1993 05:50:28 -0500 Organization: UTexas Mail-to-News Gateway Lines: 34 NNTP-Posting-Host: cs.utexas.edu Here in San Jose, CA, TCI recently cut the price of "basic" cable in half, but made a corresponding increase in the fee for "extended" ... So the conclusion is, cancel extended basic immediately. At worst you're losing a vastly overpriced service; at best, you're losing nothing at all, and saving $15/month!! [end of post - no trailer] This apparently works to any newsgroup, which function Julf got in trouble for providing. Use and enjoy! We'll see what happens to UTexas or Wimsey. There is also apparently a new Julf-like forwarder that just appeared. To get more info, send a message to: anonymus+info at charcoal.com. From zane at genesis.mcs.com Tue Jun 29 17:52:19 1993 From: zane at genesis.mcs.com (Sameer) Date: Tue, 29 Jun 93 17:52:19 PDT Subject: REMAIL: problems In-Reply-To: <9306291227.AA00990@kolanut> Message-ID: In message <9306291227.AA00990 at kolanut>, Joe Thomas writes: > > Consider cryptographic secret-sharing protocols. If we have 20 remailers, > each remailer could split his key into 20 pieces, 15 of which would be > necessary to reconstruct the key. When a remailer goes down, the key could > be reconstructed and given to a substitute remailer. The system can survive > the loss of 5 remailers, and would require a collaboration of 15, or 3/4 of > the remailer operators to intentionally break the security. > > Joe This secret sharing *does* look very appealling. How would the substitute remailer be chosen? Very difficult to build, however, as it would require a great deal of similarity between remailer software. How can a key be split into 20 pieces while only requiring [any?] 15 to work? Redundancy? It would be a good idea to have two sorts of keys for each remailer, maybe. One key for normal usage and another key for communication between remailers, key-part distribution, etc. -- | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/ From fergp at sytex.com Tue Jun 29 19:43:14 1993 From: fergp at sytex.com (Paul Ferguson) Date: Tue, 29 Jun 93 19:43:14 PDT Subject: PC Week Clipper article Message-ID: I just got back from the first day of PC Expo at Javits Center here in New Yawk. (God, how I love these shows. Trinkets, trinkets and more trinkets.) To make a long story short, I picked up a copy (and renewed my subscription) of the latest PC Week. The following article shows (at least) that the Clipper/Capstone debate has not subsided, but rather, is just becoming public knowledge thanks to coverage in trade publications and popular press. This particular article is included amongst several others in a "Special Report" section in the June 28 issue of PC Week relating to Privacy in the Workplace, "Privacy issue comes of age in the networked world." Other articles in this issue include "Encryption, monitoring and E-mail spur the privacy debate," "Some companies spell it right out: We will be watching you," "Privacy Act would force firms to inform their employees about E-mail monitoring, "Electronic monitoring raises legal and societal questions, "Encryption technology is on the rise in the private sector," "UPS toes the line with its package-tracking technologies" and two side-bar articles entitled " Cellular phones: Some like'em and some don't" and "From A too Z: Privacy policies run the gamut." Cheers from Times Square, Manhattan. 8<------- Article follows --------------- PC Week Special Report "Workplace Privacy" "News Analysis" PC Week June 28, 1993 pages 207, 211 Crypto policy and business privacy The White House wants businesses to protect data but leave doors open to law-enforcement agencies by Winn Schwartau Following the Clinton administration's April 16 endorsement of the Clipper chip, law-enforcement and privacy advocates are staking out positions that will likely test the bounds of the Constitution. The Clipper chip, manufactured by Mykotronx Inc., of Torrance, Calif., and officially designated the MYK-78, contains a sophisticated encryption algorithm that protects a company's communications by scrambling the data. Announced as a joint technical effort between the NSA (National Security Agency) and NIST (National Institute for Standards and Technology), the chip is supposed to balance the needs of law enforcement with businesses' need for data privacy. The Clinton administration is encouraging American businesses to adopt Clipper to ensure their own privacy, yet still permit "lawful government electronic surveillance," according to a statement released by the White House. Third-party products that contain the Clipper chip are expected to be announced by fall. The keys to decrypting Clipper communications will be held by two independent parties, such as the Federal Reserve Board and a private company. Attorney General Janet Reno had expected to announce the holders of the keys in early May, but has delayed the announcement until midsummer, according to a spokesman at the Attorney General's office. The Clipper endeavor stems from Bush-era intelligence-agency attempts at adding legislative riders to congressional bills that would have forced telecommunications and networking companies to build in back doors for encrypted transmissions. The EFF (Electronic Frontier Foundation) and CPSR (Computer Professionals for Social Responsibility), citizen groups based in Washington, are generally credited with having such riders removed from the bills. Deep concern drives the anti-Clipper privacy advocates, many of whom focus on the integrity of the encryption key-escrow agents who will ultimately hold the keys to the U.S. digital kingdom if the proposed program is successful. Said Kevin Murray, president of Murray & Assoc., a security-consulting firm in Clinton, N.J., "I don't like Clipper at all. If you're going to offer privacy, then offer it. I've seen too many cases where secrets easily leaked out." Few, if any, businesses appear willing to sign on with the government's plan. Spearheaded by the EFF and the ACLU (American Civil Liberties Union), 31 companies sent a letter last month to the White House and Congress stating "... We believe that there are fundamental privacy and other constitutional rights that must be taken into account when any domestic surveillance is proposed." Among the companies signing the letter were AT&T, Apple Computer Inc., Digital Equipment Corp., IBM, Hewlett-Packard Co., Lotus Development Corp., MCI Communications Corp., Microsoft Corp., RSA Data Security Inc. and Sun Microsystems Inc. One area of concern among the companies is that the government intends to keep all technical information about the Clipper encryption algorithm secret. Conventional cryptological wisdom says that only after wide-spread public analysis and comment can an encryption technique be trusted. CPSR last month filed a lawsuit against the National Security Council seeking information about the Clipper chip. "The Clipper plan was developed behind a veil of secrecy," said Marc Rotenberg, director of CPSR's Washington office. "We need to know why the standard was developed, what alternatives were considered and what the impact will be on privacy. "As the proposal currently stands, Clipper looks a lot like desktop surveillance," Rotenberg said. Said Mitch Kapor, founder of Lotus and chairman of the EFF, "An [encryption] system based upon classified, secret technology will not and should not gain the confidence of the American public." On the other hand, Clipper chip supporters such as Dorothy Denning, chairman of the Computer Science Dept. at Georgetown University in Washington and a noted expert in the field of cryptography, say the key-escrow system is more than adequate to protect legitimate American interests. Padgett Peterson, information-security specialist at defense contractor Martin Marietta Corp., in Orlando, Fla., said, "I believe Clipper's going to work. The government has more to lose than we do." The Justice Department has already placed large orders with AT&T for telephones fitted with Clipper encryption chips. Said Peterson,"Soon enough, everyone will be using Clipper: doctors, lawyers and CPAs." However, the chip's use in other governmental agencies is not assured. Neither the Federal Reserve Board nor the Department of the Treasury has indicated that they will adopt Clipper. Many business executives believe the government's encouragement of voluntary adoption is only the first step in a plan drawn by the intelligence community years ago that will eventually mandate Clipper encryption for private businesses and outlaw all other forms of encryption. The ACLU, EFF, CPSR and other watchdog groups aim to ensure that the government never goes that far. American businesses that adopt Clipper encryption in their networks and communications systems will have to accept some far-reaching assumptions, according to its skeptics: - that the Clipper algorithm is robust enough to secure their corporate information assets domestically and internationally. The international security community already believes American data to be less secure than it should be and worries about leaving doors open to the United States; - that the government does not have its own back door to read encrypted communications; - that the key-escrow agents, once named, can be trusted; - that the key-escrow repository, a vault that contains the Clipper chip serial numbers and encrypting and decrypting keys, will be secure enough to withstand a dedicated attack. The Attorney General's office also plans to announce this summer what form the repository will take -- electronic or otherwise -- and how it will be secured; - that by its very use, the company is not unintentionally giving up its right to privacy or other constitutional rights; and - that purchasing machines that include the hardware-based Clipper chip is better than using currently available and field-tested software encryption techniques such as DES and RSA. The response to Clipper has been negative despite pleas from the administration that "while [other forms of] encryption technology can help Americans protect business secrets and the unauthorized release of personal information, [they] also can be used by terrorists, drug dealers and other criminals." Martin Marietta's Peterson still believes Clipper is "good enough" for business, but he is in the minority. The majority opinion holds that Clipper may be what the government wants, but it shouldn't even think about making any laws mandating its use. ------ Winn Schwartau is the executive director of INTERPACT, a Seminole, Fla., consultancy, publisher of the Security Insider Report and author of "Terminal Compromise" and "Information Warfare: How To Wage It, How To Win It." Paul Ferguson | "Confidence is the feeling you get Network Integrator | just before you fully understand Centreville, Virginia USA | the problem." fergp at sytex.com | - Murphy's 7th Law of Computing Quis Custodiet Ipsos Custodes? From fergp at sytex.com Tue Jun 29 20:04:01 1993 From: fergp at sytex.com (Paul Ferguson) Date: Tue, 29 Jun 93 20:04:01 PDT Subject: BYTE Clipper article (newsbite) Message-ID: Okay, here's another one. This time its Peter Wayner in the pages of BYTE magazine (volume 18, number 8, July 1993). 8<------ Article follows ------------- BYTE Magazine July 1993 page 36 News & Views; Data Security Clipped Wings? Encryption Chip Draws Fire Part of the Clinton administration's vision for a digital America is a fast encryption chip to help companies and individuals protect their secrets from prying eyes as voice and data messages are sent over communications wires. The catch is that this encryption chip includes a backdoor that will let law-enforcement agencies listen in. The White House believes that the hardware will protect all Americans' right to privacy while also protecting them from those who break the law. The chip is named Clipper (because Intergraph in Huntsville, Alabama, manufactures a processor with the same name, the Clipper moniker will likely be changed). It is a 12 Mbps encryption coprocessor designed by Mykotronx (Torrance, CA) and manufactured by VLSI (San Jose, CA). The chip is built in a tamper-resistant package to prevent reverse-engineering efforts to reveal the classified algorithm used inside. Along with privacy concerns that the government could abuse its ability to tap digital wires, another impediment to widespread acceptance of Clipper will be its cost. Ben Stolz, a member of the technical staff at Sun Microsystems (Mountain View, CA), says, "Our rule of thumb is that a part that costs n dollars adds 3n to 4n dollars to the final price [of a computer]." Raymond Kammer, acting director of the National Institute of Standards and Technology (Gaithersburg, MD), recently told a U.S. congressional committee that he hopes the Mykotronx chips will eventually cost $26 each if purchased in large quantities. That means a potential $75 to $100 addition to the price of each computer that uses the chip. Critics of the Clipper chip note that less expensive chips that provide DES encryption have not received widespread acceptance because software encryption, although usually slower than hardware, is less expensive. Jim Bidzos, president of RSA Data Securities (Redwood City, CA), says, "This is just another arrow aimed at preventing people from using RSA." RSA's cryptographic routines will be included in new releases of system software written by Apple and Novell and are already used in Lotus Notes. The government will undoubtedly provide a large market for the Clipper chip initially. President Clinton has already directed the U.S. Attorney General Janet Reno to purchase several thousand units for use in computers and secure phones. The impact of the chip on the rest of the world, though, will be governed by economics. Paul Ferguson | "Confidence is the feeling you get Network Integrator | just before you fully understand Centreville, Virginia USA | the problem." fergp at sytex.com | - Murphy's 7th Law of Computing Quis Custodiet Ipsos Custodes? From smb at research.att.com Tue Jun 29 20:20:52 1993 From: smb at research.att.com (smb at research.att.com) Date: Tue, 29 Jun 93 20:20:52 PDT Subject: REMAIL: problems Message-ID: <9306300320.AA15034@toad.com> How can a key be split into 20 pieces while only requiring [any ?] 15 to work? Redundancy? There are a fair number of such schemes. The best overview is in Gus Simmons' own chapter in ``Contemporary Cryptology: The Science of Information Integrity'', edited by Simmons and published last year by IEEE Press. From khijol!erc at apple.com Tue Jun 29 20:37:07 1993 From: khijol!erc at apple.com (Ed Carp) Date: Tue, 29 Jun 93 20:37:07 PDT Subject: PC Week Clipper article In-Reply-To: Message-ID: > On the other hand, Clipper chip supporters such as Dorothy > Denning, chairman of the Computer Science Dept. at Georgetown > University in Washington and a noted expert in the field of > cryptography, say the key-escrow system is more than adequate to > protect legitimate American interests. Dorothy Denning is a fucking idiot. Oh, 'scuse me ... is this a family-oriented list? ;) -- Ed Carp erc at apple.com, erc at saturn.upl.com 510/659-9560 For anonymous mailers --> anonymus+5300 at charcoal.com "I've met many thinkers and many cats, but the wisdom of cats is infinitely superior." -- Hippolyte Taine (1828-1893) From M..Stirner at f28.n125.z1.FIDONET.ORG Tue Jun 29 21:01:10 1993 From: M..Stirner at f28.n125.z1.FIDONET.ORG (M. Stirner) Date: Tue, 29 Jun 93 21:01:10 PDT Subject: Charcoal remailer Message-ID: <778.2C310523@shelter.FIDONET.ORG> Has anyone here had any experience with the "charcoal remailer," a Penet-ish looking system that I saw in another newgroup footer? The footer says to contact "anonymus+info at charcoal.com" for information, but this isn't a good address. The misspelling of anonymous is suggestive, but that's how it read... ___ 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 khijol!erc at apple.com Tue Jun 29 21:17:36 1993 From: khijol!erc at apple.com (Ed Carp) Date: Tue, 29 Jun 93 21:17:36 PDT Subject: Charcoal remailer In-Reply-To: <778.2C310523@shelter.FIDONET.ORG> Message-ID: > Has anyone here had any experience with the "charcoal remailer," a > Penet-ish looking system that I saw in another newgroup footer? > > The footer says to contact "anonymus+info at charcoal.com" for information, > but this isn't a good address. The misspelling of anonymous is > suggestive, but that's how it read... Yes. It works. Some mailers, it seems, don't like "+" in the address...:( -- Ed Carp erc at apple.com, erc at saturn.upl.com 510/659-9560 For anonymous mailers --> anonymus+5300 at charcoal.com "I've met many thinkers and many cats, but the wisdom of cats is infinitely superior." -- Hippolyte Taine (1828-1893) From ld231782 at longs.lance.colostate.edu Tue Jun 29 21:19:01 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Tue, 29 Jun 93 21:19:01 PDT Subject: LPF statement on PKP-DSS patent Message-ID: <9306300418.AA25017@longs.lance.colostate.edu> I especially like the part where they concisely summarize it all as `the worst of both worlds'... ------- Forwarded Message From 72114.1712 at CompuServe.COM Tue Jun 29 22:11:03 1993 From: 72114.1712 at CompuServe.COM (Sandy) Date: Tue, 29 Jun 93 22:11:03 PDT Subject: SEARCH ME Message-ID: <930630050650_72114.1712_FHF19-1@CompuServe.COM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort at attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cypherpunks, Duncan Frissell's experience with the "drain police" reminded me of a similar experience I had some years ago. I found out that the "building police" in Kansas City would be inspecting homes in my neighborhood looking for "code violations." I had put in some electrical plugs without benefit of an electrician. Also, I was still in law school, so naturally I felt like raising some (legal) hell with the Powers That Be. When the inspector showed up, I said "no thank you" when he asked if he could inspect my house. If I had poll-axed him, he couldn't have looked more surprised. Apparently, nobody had *ever* said "no." After he recovered, he asked me why not. I mentioned the Fourth Amendment and the -See- and -Camara- decisions in the Supreme Court. He never came back. I won't go into the embarrassing story of the one time I did cooperate with the police. Suffice it to say, I regretted it. Both events, however, have made it clear to me that it is almost always stupid to cooperate with the cops. To be truthful, I strongly considered leaving out the word *almost* in the previous sentence. I'm afraid some of you will outsmart yourself by thinking you can control a law enforcement situation with "clever" cooperation. Dream on. If you aren't a lawyer, it is very likely you will fuck yourself. But shouldn't you cooperate for the little things, especially when you know you are clean? No, no, no, for two reasons. First, I are you sure you are clean in the officials eyes? The one time I cooperated, the fact that I had 3-4 $100 bills on my dresser made it into the cops report (though he did add, "no other signs of drug dealing"). Are you *sure* you're clean? Second, it's great practice. You have a right to require a valid warrant. These guys (nominally) work for you. Enjoy yourself; make them jump through some hoops for you. Rights are like muscles, if you don't exercise them, they atrophy. Use it, or loose it! S a n d y >>>>>> Please send e-mail to: ssandfort at attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From morpheus at entropy.linet.org Tue Jun 29 22:13:42 1993 From: morpheus at entropy.linet.org (morpheus) Date: Tue, 29 Jun 93 22:13:42 PDT Subject: REMAIL: problems In-Reply-To: Message-ID: In article Joe Thomas writes: > [...] Let's say there is a method to quickly and easily >verify the continuing existance (or lack thereof) of a remailer. When a >remailer receives a request to send a message to another remailer, it can >quickly check to see if that remailer is in operation. [...] But how would this be done? The first way that comes to my mind is spooling the message in a queue of some sort, sending a "ping" message to the next remailer in the chain, and waiting x minutes for a response. If a response does arrive within x minutes, that remailer is considered alive. But what is the value of x? It can't be too short - the remailer might be on a slow link. For example, I have a remailer running on my machine, which is connected via uucp. The turnaround time of a "ping" message would vary from about 35 minutes to upwards of 13 hours (I don't connect at all from 0855 to 2205 EDT). But the longer the delay, the slower the whole chain runs. If one popular remailer goes down, all messages routed to it would be delayed at least x minutes, which is better than the bit bucket - but with x being, say, 1440 (one day) the delay would not be trival. There also might be security issues with the spooling of the messages. I just wrote a couple extra perl programs for the remailer that do part of the above. I'll try to put them on soda, called "morpheus-remailer-hack" or something similiar. They add another header (called "Request-Safe-Remailing-To for now - please send better suggestions!) that acts just like R-R-To: but spools the message and sends out a email ping, then waits to send the actual message until it gets the "ok" message back. It's slow and ugly, but it seems to work (it works with itself, anyway ;-) There's probably lots of locally-dependant stuff in it (like the MESSAGE_ID and VISIBLE_NAME enviroment variables, etc) that will need to be fixed. The big problem with it at this point is that it's useless - there isn't any code to deal with the "no response" condition. A simple script ran from the crontab could check timestamps in the spool area and do something if they were more than x minutes old - but _WHAT_ should it do? Maybe a better idea would be to add a Recipt-Requested header instead of doing the email ping, which would have the receiving remailer send back an "ok", but continue with delivery.. Then the sending remailer could delete the spooled message, otherwise if it didn't get an ok it would try again at another site. Better or worse? -- morpheus at entropy.linet.org Non serviam! Support your local police for a more efficient police state. From nobody at mead.u.washington.edu Tue Jun 29 22:20:46 1993 From: nobody at mead.u.washington.edu (nobody at mead.u.washington.edu) Date: Tue, 29 Jun 93 22:20:46 PDT Subject: Remailer Test Message-ID: <9306300520.AA49995@mead.u.washington.edu> This is a remailer test. Please forgive the waste of time/space. From TO1SITTLER at APSICC.APS.EDU Tue Jun 29 22:26:55 1993 From: TO1SITTLER at APSICC.APS.EDU (Kragen Sittler) Date: Tue, 29 Jun 93 22:26:55 PDT Subject: mailers not liking + in the address Message-ID: <930629231409.3244@APSICC.APS.EDU> There is, of course, a way around this if you have telnet... telnet to port 25 on charcoal.com, or to somewhere else if you can't reach there, and enter your message as per RFC-821, SMTP. Directions for the lazy: once you get an acknowledgement from the remote computer, type helo apsicc.aps.edu (or whatever your computer is called) It should greet you or hang up. So if it didn't hang up, type mail from: DON'T FORGET THE ANGLE BRACKETS! Then, type rcpt to: if you connected to charcoal directly, or rcpt to: <@somecomputer.com:anonymus+info at charcoal.com> where somecomputer.com is where you are connected to. (It is possible this is wrong and @somecomputer.com either: a) is not necessary or b) should appear in the mail from: line. Try it.) Then, type data and type in the From:, To: Subject:, Date:, Message-ID:, and so on fields. Send yourself a message to find out how it should look. Make the Message-ID something that will not be replicated by the computer you are on. Follow this with a blank line, and type the body of your message. Double any periods appearing alone on lines. End your message with a period alone on a line. Then type quit to close the connection. (BTW: this provides a certain amount of anonymity without need for a remailer, but it is then possible to detect which computer you are mailing from. I sent the anonymous message about people not doing something if you make it hard enough by this method, as a demo, but I kind of botched it. The message arrived, but it did not look right.) Kragen, SMTP wizard (NOT!) hee hee From tn0s+ at andrew.cmu.edu Tue Jun 29 23:29:19 1993 From: tn0s+ at andrew.cmu.edu (Timothy L. Nali) Date: Tue, 29 Jun 93 23:29:19 PDT Subject: Wired tidbit about NSA Message-ID: Here's a little something about the NSA from the latest issue of Wired: pg 25, in the middle type Clipper Purposely Clipped? Sources cloas to those in the know on Captial Hill claim that NSA deliberately sabatoged the poorly considered Clipper encryption chip (rolled out to the Net.public's dismay by the White House early this spring). The NSA, our sources say, would like nothing more than to see the the Clipper chip fail, resulting in the outlawing of encryption altogether ("Gee, we tried..."). The Electronic Frontier Foundation's response to the Clipper plan, which has been in the works for four years and was formulated by the NSA: "We should not rely on the government as the sole source for Clipper or any other chip. Rather, independent chip manufacturers should be able to produce chip sets based on open standards." ----------------------------------------------------------------- While I wouldn't take this as absolute truth yet, it is certainly food for thought. --Phelix /----- P h e l i x ' s P s y c h o t i c P h i l o s o p h i e s -----\ ***************************************************************************** Perfect Paranoia is Perfect Awareness \---------------------------------------------------------------------------/ _____________________________________________________________________________ Tim Nali \ "We are the music makers, and we are the dreamers of tn0s at andrew.cmu.edu \ the dreams" -Willy Wonka and the Chocolate Factory From ld231782 at longs.lance.colostate.edu Wed Jun 30 00:14:52 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Wed, 30 Jun 93 00:14:52 PDT Subject: remailer ideas & proposals Message-ID: <9306300657.AA26896@longs.lance.colostate.edu> The remailer details have always been one of the most persistent, relevant, and interesting aspects of this group. I'm really pleased to see e.g. Hal Finney's attempts to automate a testing process, and others' interests in methods of increasing reliability and security. Unfortunately, it seems to me the same problems keep popping up unresolved. Here are a few brief ideas. 1. `dropping' messages Here is an idea: if a remailer drops a message or forwards it successfully it could broadcast a message to a group such as misc.test. There are all kinds of problems with autoresponders replying to these kinds of messages but I think anyone who has the audacity to run an autoresponder despite no clear mandate to do so is asking for trouble anyway. Regarding traffic analysis, see below. Also, Miron Cuperman was running an anonymous pool mailing list, last I heard email pool0-request at extropria.wimsey.com with `subscribe' in the subject line to get on it. Is this still running? Is anybody playing with this? What are people doing with this anyway? Now, for some *really* radical ideas. If cypherpunk remailers were truly impervious to traffic analysis then we wouldn't *care* if detailed statistics on mail messages were broadcast to the world, because correlations would be intractable to determine so it wouldn't matter. So, I propose that remailers actually start posting to a list somewhere *all* internal traffic. This will create an excellent incentive for them to implement traffic-analysis-thwarting (TAT?) mechanisms. Of course, the mechanisms should be implemented before they start broadcasting this information! The broadcasting of this information is like built-in accountability. If people see trends they can notify operators of their weaknesses. It actually *encourages* the development of traffic analysis and thereby improved safeguards. Also, it helps us paint an excellent *overall* picture of remailer use and increase their exposure to the `unwashed masses'. BTW, I would like to see a list that keeps track of the professed `logging' practices and historical reliability of the various remailers. 2. Embedded messages I've been thinking about the whole idea of message transmission in SMTP, and it strikes me as very sloppy. We have this system where intermediate hosts can tack on junk at the beginning and ending of messages (such as `Received' lines, overflow headers, etc.) without violating any standards. I think this should change--an explicit standard handling this modification should be in place and anyone that doesn't adhere to it can be blamed for `violating the standard' and maybe even cleaning up their act. Here is one such proposed standard. I'd like to see what everyone thinks. I proposed something similar a long time ago. Here is the idea: when a message is submitted to a host, the host is responsible for maintaining a very precise map of what the message appeared as when it went `in', and what was added in the process, `out'. Here is one such way to make this explicit: Have a `x-message-format' line. The way this header works is that it represents the structure of the message in lines. Each new remailer, when it adds *anything* *anywhere* in the message is also responsible for correctly updating the x-message-format line, under the following standard. The line contains text tags, followed by a colon, followed by a number of lines representing that field in the message. Also, the use of paranthesis makes the idea of `embedding' explicit. Each level of paranthesis represents a `wrapper'. A mailer may add any number of new fields anywhere in a message and then `wrap' the whole thing in parenthesis. Fields are separated by spaces. The fields collectively name all lines in the message in sequential order. For example, the first mailer might create a root x-message-format-line like: x-message-format: (headers:4 body:10 signature:3) Then passing through one intermediate remailers, we might get a `recieved' status line added, at the *beginning*: x-message-format: (recd:1 (headers:4 body:10 signature:3)) And some goofy Fidonet gateway may find it necessary to stick something on the end: x-message-format: ((headers:4 body:10 signature:3) fidofooter:4) Of course, under the standard it would make sense to have categories of the tag specifications, so for example any tag that represents a header would have something in its text like `header' so it could be identified. We might even have text fields inside the embedded message routing structure that identify the names, errors-to emails address, etc. of the intermediate hosts. The point is that with all this the recipient has a transparently clear picture of what constitutes the original message and what was added as intermediate fluff, which currently SMTP is frighteningly and embarrassingly lax in identifying. The idea of the *original message* vs. *intermediate fluff* is absolutely critical and we deserve sophisticated protocols that preserve the distinction. (Gad, it's amazing what remailers do to messages. They will mess with lines that contain only hyphens or '>' quote any line that begins `From'. I find all this highly atrocious.) So, what does anyone think? The problems I can see are in the proliferation of tags. Maybe a central authority needed to regulate them to be sensible and unique (a registry). Also, is it the case that some headers can get too large? The solution I have for this is to break up the x-message-format line into multiple lines: x-message-format1: x-message-format2: where successive lines actually represent one level of nested parenthesis. Note: I don't know if the inherent `sloppiness' in SMTP will ever be successfully evaded given its widespread entrenchment. However, I believe protocols superior to it in that regard are inevitable in their adoption. From ld231782 at longs.lance.colostate.edu Wed Jun 30 00:21:59 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Wed, 30 Jun 93 00:21:59 PDT Subject: Kleinpaste's Charcoal anonymous server Message-ID: <9306300721.AA27192@longs.lance.colostate.edu> One person asked about the Charcoal remailer. I try to stay on top of this area of anonymity servers and have corresponded with the owner Karl Kleinpaste extensively in the past. First, I would like to encourage *everyone* who wants to create and run an anonymous server, which is time-consuming, thankless, and even painful at times, and don't want any of my comments to be construed otherwise. I think something disparaging could probably be said about any remailer operator. However, I also think that remailer policies vary and that we should keep track of the practices and reputed integrity of operators as much as possible. Under that vein I'll just make a few *candid* comments to cypherpunks on Mr. Kleinpaste. Please *do not* forward these notes anywhere. Kleinpaste started his server early this year mostly in response to alt.personals, with the death of another server, I believe. In a *very* scorching-hot incident, an estranged boyfriend posted nude pictures of his old girlfriend to alt.binaries.pictures or some other newsgroup. It is not clear to me that he used an anonymous server to do so--I believe he did not based on some testimony of others. Anyway, this caused a huge eruption as these things inevitably do, and legal action was in motion against the person in his hometown. The guy apparently *later* used Kleinpaste's anonymous server to send mail to another anonymous person who he thought worked with the girlfriend's mother. I guess there was some extortion or `threats' in the letters. Anyway, Kleinpaste gave all the persons mail to the `authorities' (despite marginal relevance to the original picture-posting) and got very emotional and wrapped up in the whole case. In fact, he acted, in my view, very paternalistic in the way a father would protect his daughter. (At one point he made the comment that the young girl had moved to a new town and `was making new friends' -- something that sounds like something one's parent's would say, eh?) BTW--the estranged boyfriend was never prosecuted apparently due to gray legal areas and prosecution cost. Kleinpaste also revealed how a person was suicidal and was posting through his server. It's not clear to me what he did but I think he said he tried to contact the person's home institution. Here is where the ethical quandaries of anonymous servers are rather intense! What should an operator do if a person, who is using the system in *trust* of their anonymity, is suicidal? Is about to commit a crime? Involved in a conspiracy? Well, I'm not advocating anything, but the stance of `unhindered carrier' is certainly the least problematic from the operator point of view. Anyway, through all this it seemed to be clear to me that Kleinpaste may be regularly reading some of the mail that is going through his server, and in any case probably keeping fairly thorough logs. Look at his policies! Essentially they are: if you don't post anything offensive, I'm behind you. If you do, I will restrict your access temporarily, permantently, or even expose you. Kleinpaste soured very seriously on the whole idea of the anonymous server and killed it. Then in the big flame wars J. Palmer started up his server and Kleinpaste appeared to want some attention that Julf & others were getting. I found it highly incongruous in the least and hypocritical at worst given some of his statements on `bastards who abuse the service' that he restarted his own -- he's one of the most strong-mouthed people on that subject. Anyway, charcoal.com seems to have been humming along for a few months now and Kleinpaste does not appear to be ready to shut it down anytime soon. It posts to a limited number of groups. He tells me that he has refused requests to `out' a particular individual in alt.personals by another prominent individual. So, I'd say that if you have his endorsement for your use of anonymity, it's a safe server. But if you're on morally gray areas in your use, by *his* definitions, then Caveat Emptor. p.s. one reference on all this is rtfm.mit.edu:/pub/usenet/news.answers/net-anonymity. I would document further these really volatile incidents (esp. the `nude picture posting') but don't have enough eye-witness accounts to do so (in particular, not my own). From ld231782 at longs.lance.colostate.edu Wed Jun 30 00:31:48 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Wed, 30 Jun 93 00:31:48 PDT Subject: PGP speech coding on SoundBlaster Message-ID: <9306300731.AA27352@longs.lance.colostate.edu> This person is very serious about developing a scrambler based on PGP and Soundblaster, topics that get banged around here alot (``...with great sound and fury, told by an idiot, signifying nothing.'') There is room for suggestions on approaches or (more importantly) volunteers in coding. He does not subscribe to the list because of volume. ------- Forwarded Message From: dorsey at lila.com (Bill Dorsey) Subject: PGP Mailing List Date: Tue, 29 Jun 1993 02:12:54 -0700 (PDT) - --- BEGIN SUMMARY --- Voice-PGP is a software package that will allow PC owners to have secure communications over insecure phone lines. It will require only that the users possess a modem capable of 9600 baud or greater and own a SoundBlaster compatible sound card. Later versions may support other sound cards. As the project stands now, I have developed a large number of speech coders of varying complexity based on coders discussed in the literature from the early 70's to the present. Although the sound quality is generally poor among the simple coders at these bit rates, they do allow computers not blessed with fast CPUs to make use of the software. The more complex coders produce sound quality equal to or better than local two-way radio communications and operate on contemporary (486 and fast 386-based) PCs. In addition to the coders, I have developed a simple user-interface and an expandable packet-based communications protocol. What remains to be done includes writing driver modules for the modem (I'll assume they are Hayes compatible) and SoundBlaster card in addition to coding up a set of functions to implement the communications protocol and hooks for encryption. Finally, I'll need to integrate all of the above together and test it out. Initial code development is being done on a Sun Sparcstation and a 486-based PC running Linux. As my DOS experience is severely limited, it is my hope that someone will come forward and volunteer to port the software to DOS. Since the code is being written with portability in mind, this should require little more than re-writing the driver modules. - --- END SUMMARY --- I hope this isn't too long. Feel free to edit/condense as you feel is appropriate. - -- Bill Dorsey "Give me your tired, your poor, I'll piss on 'em dorsey at lila.com That's what the Statue of Bigotry says." PGP 2.x public -- Lou Reed key on request ------- End of Forwarded Message From skyhawk at cpac.washington.edu Wed Jun 30 01:31:25 1993 From: skyhawk at cpac.washington.edu (skyhawk at cpac.washington.edu) Date: Wed, 30 Jun 93 01:31:25 PDT Subject: remailer ideas & proposals Message-ID: <9306300830.AA18466@bailey.cpac.washington.edu> > From: ""L. Detweiler"" > Subject: remailer ideas & proposals > > Now, for some *really* radical ideas. If cypherpunk remailers were > truly impervious to traffic analysis then we wouldn't *care* if > detailed statistics on mail messages were broadcast to the world, > because correlations would be intractable to determine so it wouldn't matter. > So, I propose that remailers actually start posting to a list somewhere > *all* internal traffic. [...] That's a big if. I think the idea is interesting, but would *very* much like to see this tested first on a set of "play" remailers, which are advertised as being for research only, don't trust them to actually work, etc. > 2. Embedded messages > > I've been thinking about the whole idea of message transmission in > SMTP, and it strikes me as very sloppy. [...] > Here is the idea: when a message is submitted to a host, the host is > responsible for maintaining a very precise map of what the message > appeared as when it went `in', and what was added in the process, > `out'. [...] > Note: I don't know if the inherent `sloppiness' in SMTP will ever be > successfully evaded given its widespread entrenchment. However, I > believe protocols superior to it in that regard are inevitable in their > adoption. MIME, in particular, solves this problem, along with many others. Three cheers for Metamail! Specifically, you can have several seperate messages within your RFC822 message, arranged hierarchially. You could have your public key, your cute .sig, your message, your signature for the message, contact information for you, a JPEG image (of your cat, say), and a sound ("meow") all in the same mail message. There is even faint hope that it would be portable. -- Scott Northrop (206)784-2083 ObVirus: The demand for obedience is inherently evil. ObVirus2: As a juror in a Trial by Jury, you have the right, power and duty to acquit the defendant if you judge the law itself to be unjust. From pbreton at cs.umb.edu Wed Jun 30 06:52:06 1993 From: pbreton at cs.umb.edu (Peter Breton) Date: Wed, 30 Jun 93 06:52:06 PDT Subject: Boston cpunx meeting? Message-ID: Are Boston area folks interested in another get together? The last one I went to (early April) was a blast... ------------------------------------------------------------------------- Peter Breton pbreton at cs.umb.edu PGP key by finger ========================================================================= From still at kailua.colorado.edu Wed Jun 30 07:02:23 1993 From: still at kailua.colorado.edu (James Still) Date: Wed, 30 Jun 93 07:02:23 PDT Subject: PGP and offline-readers Message-ID: <2C31A670@kailua.colorado.edu> >> I am getting involved in networking some local BBS' and >> message bases. I'm beta testing a privacy-oriented BBS right now that I just finished programming, called CryptoBBS and what better place to introduce/ask questions on it than among the cypherpunks! It is geared towards the hobbyist sysop with an old XT clone or something lying around as it is a mere 80K (for the floppy-sysops!) There is no logon prompt asking for name, birthdate, SSAN, and who knows what else, it goes directly onto the board. Callers wishing to post messages, are asked for an alias name to fill in the FROM: block, but real names or call-back verifiers are not supported. My hope is to offer sysop's a choice, between *choosing* to preserve privacy, rather than the current practice of obtaining personal information because the questionnaire's are preprogrammed that way. The unique feature about CryptoBBS is it's "Post Office." The P.O. allows callers to set up a p.o. box from which they can up/download any file (pgp encrypted files for instance) to any other user on the board without the sysop's approval/knowledge. It encourages and nurtures an anonymous "mail drop" community while protecting the caller's privacy. The question is, should I throw away the virtues of a lean 'n mean app at 80K by adding a dolphin or pgp to it that automatically encrypts the message base, uploaded messages, etc? Should we give the BBS caller a little credit and assume he knows to encrypt at his own machine before uploading the text? Or is the temptation to make everyone *lick and seal their message envelopes* too invasive? I know the issue of encouraging pgp use by making it as painless as possible on the end-user is nothing new around here, but as far as I know no one has ever discussed whether or not BBS's should handle the job for the caller. From gerald.dejong at canrem.com Wed Jun 30 08:15:38 1993 From: gerald.dejong at canrem.com (Gerald Dejong) Date: Wed, 30 Jun 93 08:15:38 PDT Subject: cryptomoney Message-ID: <60.230400.104.0C17CC55@canrem.com> hello folks! i brought up a question about cryptomoney, and i was sent this from a fellow called John Nieder. JN>"Digital money" is a favorite subject of the whiz kids on the usenet JN>"Cypherpunks" request. If you have access to a FIDO/UUCP gate, send a JN>request for this mailing to cypherpunks at toad.com to receive it via JN>netmail. is there something you can send me? )gdj( --- � DeLuxe� 1.21 #11557 � testosterone: my drug of choice From remail at tamsun.tamu.edu Wed Jun 30 08:23:59 1993 From: remail at tamsun.tamu.edu (remail at tamsun.tamu.edu) Date: Wed, 30 Jun 93 08:23:59 PDT Subject: Remailer ping test Message-ID: <9306301523.AA20787@tamaix.tamu.edu> [list of defunct remailers (?)] > 1: hh at pmantis.berkeley.edu > 2: hh at cicada.berkeley.edu > 6: remail at tamaix.tamu.edu > 7: ebrandt at jarthur.claremont.edu > 9: remailer at rebma.mn.org > 14: 00x at uclink.berkeley.edu > > Hal > hfinney at shell.portal.com The remailer at remail at tamaix.tamu.edu and remail at tamsun.tamu.edu are working. Must have been a temporary problem Hal. Thanks for checking it out. Carlos -- [ Carlos Macedo Gomes ][ The Message is ][: .8. :]------ [ gomes at tamu.edu ][ the Media ][ . ooo . ]000000 [ cmghelp at tamsun.tamu.edu ][ :Marshall McLuhan ][ : =o(Y)o= : ]000000 [ PGP 2.2 key by finger ][30 37 40 N, 96 20 03 W][oo .ooooo. oo]------ From O1DSH at VM1.CC.UAKRON.EDU Wed Jun 30 08:38:50 1993 From: O1DSH at VM1.CC.UAKRON.EDU (David Heck) Date: Wed, 30 Jun 93 08:38:50 PDT Subject: Speaking of get togethers.... Message-ID: <9306301538.AA06072@toad.com> While we're on the subject, is there anyone on the list in the NE Ohio area (Cleveland) interested in getting together? I'd love to go to Boston or the West Coast, but just can't swing it with my work schedule ;-) David From kent_hastings at qmail2.aero.org Wed Jun 30 09:24:29 1993 From: kent_hastings at qmail2.aero.org (Kent Hastings) Date: Wed, 30 Jun 93 09:24:29 PDT Subject: WARLOCK 4.0 Info Message-ID: <199306301621.AA23444@aerospace.aero.org> WARLOCK 4.0 Info The enclosed file is the documentation for WARLOCK 4.0, "A New Matrix-based Paradigm for Public Key Cryptography." The source code and executeable MS-DOS program are included in the shareware version, but my internet gateway complains "permission denied" if I try to send out the ZIP file. Hmm. The text file is about 43k and the ZIP is only 78k. Oh well. This is the first I've heard of WARLOCK. "NIST DSS and RSA systems suffice for authentication but are too slow for ordinary encryption/decryption functions forcing users to employ more complicated hybrid systems resulting in 'double exposure'." "WARNING: The WARLOCK cryptosystem provided herein is a copy- righted system protected by patents (awarded and pending) and is provided solely for private personal use and evaluation only, etc ..." For more info, contact WARLOCK at ACM.org. Kent - kent_hastings at qmail2.aero.org. <<<<<< Attached TEXT file follows >>>>>> .OJ OFF .UL ON WARLOCK - A New Matrix-based Paradigm for Public Key Cryptography (C) 1993 by William J. Wilson and C. Larry Craig 1. INTRODUCTION The following narrative briefly reviews the functionality of contemporary private key and public key (PK) cryptosystems in meeting current and future private sector security needs. To assist in meeting these needs, the WARLOCK paradigm for achieving matrix-based PK cryptosystems is presented and explained. Sys- tems based on this paradigm are designed as alternatives to RSA and RSA-hybrid systems by making available single, high-speed, full bandwidth systems capable of the basic cryptographic func- tions of encryption, decryption, and source authentication (digital signature). The WARLOCK paradigm is outlined in the following paragraphs with actual examples of system keys and step-by-step encryption, decryption, and authentications transformations effected by those keys. User evaluations, comments and suggestions are solicited on the WARLOCK paradigm as well as the particular WARLOCK 4.0 PC imple- mentation (available in C++ source code from file WARLOCK.CPP and in MS DOS executable code as WARLOCK.EXE). Please direct such input to WARLOCK at ACM.org or Datasec Systems, PO Box 4152, Hunts- ville AL 35815-4152, or by calling Wilson at (205) 881-8002. User suggestions and improvements will be incorporated, as appro- priate, and improved versions (as well as other implementations of the WARLOCK paradigm) will made available to interested users in the future. ***************************************************************** WARNING: The WARLOCK cryptosystem provided herein is a copy- righted system protected by patents (awarded and pending) and is provided solely for private personal use and evaluation only. Modifications to (or copies of) WARLOCK source or executable programs must retain the warning and proprietary legend displayed on the first user screen. The use of WARLOCK cryptosystems for private-sector commercial or public-sector governmental purposes is strictly prohibited with- out proper licensing arrangements. Licensing information can be obtained from the above-noted sources. ***************************************************************** 2. BACKGROUND Today's telecommunications and information system designers contemplating cryptographic technology are confronted with a relatively limited set of choices and capabilities (e.g. DES, RSA, proposed NIST DSS (Digital Signature Standard), etc.) which, even when combined in hybrid systems, are inadequate in our opinion to the complex security and authentication needs of the burgeoning information age and the even more daunting require- ments of the emerging digital multimedia revolution. For exam- ple, the NIST DSS and RSA systems suffice for authentication but are too slow for ordinary encryption/decryption functions forcing users to employ more complicated hybrid systems resulting in "double exposure". Hybrid systems typically use the DES standard which has been widely assailed for its all-too-short key length (56 bits). Nor has the proposed NIST standard met with a warm reception either since it presently provides only a time-consum- ing signature capability. In terms of variety, flexibility, speed, and selectable and provable levels of security, we feel that contemporary cryptosystems fall short of efficiently meeting the wide range of known and predicted private sector application security needs, e.g. encrypted digital voice and video, digital satellite communication, ISDN, wireless LAN's, source authentica- tion, IFF (Interrogate Friend or Foe) protocols, smart cards, and a host of other emerging applications. To meet these needs, the authors over the past several years have developed and tested scores of high-speed matrix-based PK crypto- systems beginning with a patented private-key version of the Hill cipher and culminating in the development of the WARLOCK family of PK cryptosystems. Our goal throughout has been the attainment of a single, full-bandwidth PK cryptosystem paradigm (with digi- tal signature) of sufficient simplicity, speed, and selectable levels of security for meeting current and expected cryptographic needs of the private sector. 3. THE HILL PARADIGM In 1929 Lester H. Hill proposed a unique, matrix-based, block ciphering system (1.) unlike any ever proposed before. Although manifestly linear and later shown to be susceptible of chosen plaintext attack, Hill's system represented a quantum leap in the art of cryptography providing for the first time a true block ciphering capability with strengths substantially beyond those of the polyalphabetic systems of his day. If fact, if computing (but not creating) the inverse of a matrix were as difficult as computing its permanent, Hill would have invented in a single stroke the first provably secure public key cryptosystem complete with digital signature. Notwithstanding, Hill's method, employ- ing standard matrix transformations, established a new direction whose full cryptographic potential in our opinion is still unrealized and one capable of nullifying in large measure the standard tools of conventional cryptanalysis. Apart from the issue of cryptographic strength, Hill succeeded in inventing the first two-key cryptosystem and it remained only for Hellman and Diffie to establish a rigorous mathematical paradigm (2.) for one-way, two-key public key cryptosystems and for Rivest et al. to provide the first viable example of such a system (3.). In a later development, McEliece developed a matrix-based public key system (4.) based on Goppa error correction codes. Although inefficient in terms of bandwidth and initially lacking digital signature, his system demonstrated that workable matrix-based PK systems were indeed possible. In spite of the fact that the McEliece system was recently cryptanalyzed (5.), it nevertheless represented a significant step in the evolution of matrix-based cryptosystems. Still later, Rodney Cooper extended Hill's mod 26 systems to Galois Fields GF(p) and GF(q^n) to create a cryptosystem based on matrix theory and Galois Fields (6). In essence, Cooper provided for a matrix of polynomials (subject to two moduli) to be used as an encryption key with the paramount advantage that such ma- trices can be made as large as needed to accommodate any required level of user security. In fact, Patti (7.) has implemented such extensible multi-magabit cryptokeys in PC-based extended memory in which he also concatenates random bits with the plaintext vector prior to encryption to defeat linear attacks (cited in the above reference) as well as known-plaintext and chosen-plaintext attack. Rather than trying to impress a known NP-hard problem into the service of PK cryptography as others such as Merkle et al. (8.) have attempted, we have employed a two-step process instead. In the first step, we developed weak but workable full-bandwidth PK systems with digital signature capability. In the second step, we hardened the resulting system by incorporating artificial com- plexities in the key generation, encryption, and decryption processes with the goal of attaining selectable and provable levels of security -- ideally NP-hard. Payne and McMillen's formula (9.) defines the number of nonsingu- lar nxn binary matrices possible for each dimension of n and thereby the number of reversible linear mappings of n-bit strings possible with such matrices. It is worth noting that such map- pings are a tiny subset of the full range of (2**n)! possible mappings of unique n-bit values. Unfortunately, as Chaitin has noted in another context (10.), all but a small fraction of these mappings are essentially noncomputable and can be effected only by table lookup -- as the small S-box mechanisms of DES exempli- fy. For the WARLOCK paradigm, one of the required private keys consists of a large, non-singular nxn matrix used to disguise the rectangular mxn public key. In the implementation provided here, a smaller nonsingular nxn private key matrix is also required. In the paragraphs that follow, the term "matrix" always refers to a binary matrix and all forms of the term "addition" indicated by the + symbol designate addition modulo-two (XOR operation). Supporting figures for the WARLOCK paradigm and the particular implementation are all found at the end of the paper. 4. THE WARLOCK PARADIGM Overview WARLOCK is a paradigm for a family of advanced, high-speed, full- bandwidth, matrix-based PK cryptosystems with full digital signa- ture. These systems can be operated in ordinary encryption/de- cryption mode or in superencrypted mode, (achieving encryption and authentication simultaneously) as necessary with key and block sizes incrementally selectable according to security needs. All implementations of the WARLOCK paradigm share certain common- alities: - use of a single public key K consisting of a rectangular mxn binary matrix where m>n and where n is the system block size of plaintext and ciphertext - achievement of nonlinear plaintext to ciphertext mappings such that for plaintexts A and B under key K, the follow ing is true: MAP(A,K) + MAP(B,K) <> MAP(A+B). - incorporation of secret "row identifiers" in rows of the public key (which are injected in disguised form into the ciphertext by the encryption process) allowing a private key holder to identify public key rows selected by the encryption process. - use of entropy increasing "noise bits" for selected bit positions of the public key not occupied by row identifiers - use of a secret, nonsingular nxn matrix M to disguise the public key and to serve (in inverse form) as a private key - user-selectable key and system block sizes to accommodate varying levels of security requirements - system key generation from user-supplied "key-seeds" or pass phrases of 1 to 85 bytes As the example below shows, the public key for the implementation provided here is initially constructed of two parts -- an A-part and a B-part. The A-part consists of a key-seed generated and triplicated nxn nonsingular matrix whose n dimension is exactly 1/3 the row dimension of the public key. Construction of the B-part begins with a template matrix (T- matrix) containing a diagonal of submatrices each comprised of "row identifiers" whose value and row positions uniquely identify each matrix row. In the first hardening step, the area above the diagonal is filled with key-seed generated "noise bits" and the area below the diagonal is filled with "replacement bits" con- sisting of key-seed generated but replicated row values. The A- part and the B-part are concatenated to form an mxn matrix where mn and where n is the block size of both the input plaintext and the resulting ciphertext. The purpose of row group jumbling is to disguise the original A-part and B-part row group sequence. WARLOCK encryption is accomplished by expanding an n-bit plain- text block in a nonlinear manner to form an m-bit vector which is multiplied by the public key to create an n-bit ciphertext. This multiplication is greatly hastened (as are all binary matrix multiplications) by the simple expedient of associating each bit position of the expanded vector with a row of K allowing 1-bits in the expanded plaintext vector to select corresponding rows of K which are added modulo two to produce the plaintext. In the first step of the decryption process, the ciphertext is multiplied by private key M_inverse to create the same value as if the plaintext had been multiplied by the completed T-matrix. Rows selected by the encryption process (whose row identifiers are encoded in the ciphertext) are then retrieved by a deconvolu- tion process which removes the effects of the noise bits identi- fied in the private key T-matrix. Accomplishing the inverse of the row selection process employed during encryption serves to identify the original plaintext. Like most computer-based cryptosystems, WARLOCK consists of three basic modules: a key generation module, an encryption module, and a decryption module. Digital signatures (as well as superencryp- tion) are accomplished conventionally by concatenating decryption and encryption functions employing appropriate public and private keys. WARLOCK Key Generation The WARLOCK T matrix is comprised of two major parts: an A-part and a B-part. The A-part consists of a triplicated and expanded nonsingular A matrix as shown in Figures 1. through 3. and the B- part consists of a set of rows each containing a unique 3-bit row identifiers as shown in Figure 5. Note that the triplicated rows of the A part when selected always produce a "fat bit" consisting of 000 or 111. These "fat bits" when combined with the row identifiers of the B-part in the encryption process either pre- serve the row identifier value or complement it with the result that identifiers are recovered in original or complemented form. For example, a row identifier 100 in a given ciphertext row position will be recovered either as 100 or as its complement 011 -- both identifying a particular B-part row selected in the encryption process. Row identifier values for the B-Part are chosen as shown below such that their values and their comple- ments form a unique set of unduplicated values allowing unambigu- ous row identification. 4-let Row Identifier Row Identifier Complement 1 100 011 2 010 101 3 001 110 4 111 000 In the encryption process, an information containing fat bit from the A-part consisting of 000 or 111 is always added to each 3-bit identifier value selected in the B-part. This technique not only preserves identification of the B-part row selected, but permits identification of the value of the information carrying fat bit as well. In other words, if a row identifier is recovered un- changed, its fat bit is known to be 000 otherwise its fat bit is known to be 111. Since the selection of fat bits is also deter- mined by plaintext values, fat bits are also information carry- ing. |----------| | | | B-part | | | |__________| | A-Part | |__________| WARLOCK T-matrix The A-part of the WARLOCK T-matrix is created as follows. A key- seed generated, nonsingular nxn matrix A (whose n dimension is exactly 1/3 the width of the T-matrix) and its inverse A_inverse is initially created as shown in Figures 1. and 2. The A-matrix is then triplicated to create the matrix shown in Fig. 3. As al- ready noted, triplication of the columns of matrix A produces the fat bits required by the encryption process. In the next step, shown in Fig. 4., the matrix row dimension is increased by adding each row pair of the matrix in Fig. 3. to create a third row. A fourth all-zero row is then created completing the row expansion. This last step is necessary to create A-part row groups (4-lets) that allow the row selection process (governed by plaintext values) to be identical for both the A-part and the B-part. Construction of the B-part of the T-matrix begins with an initial template containing row identifiers as shown in Figure 5. In the first hardening step, key-seed generated noise bits are added above the submatrix diagonal to produce the intermediate version shown in Figure 6. In the next step, the A-part and the B-part are joined to form a single T-matrix shown in Figure 7. To eliminate the "sea of zeroes" under the diagonal of the B-part (and to further disguise the T-matrix), a special "replacement bit or R-bit" matrix shown in Figure 8. is created with row values identical for each row 4-let. This matrix is added to the matrix in Figure 7. to produce the final T-matrix shown in Fig. 9. Not only does this step eliminate the "sea of zeroes" under the diagonal, but it also displaces and further disguises all other bits in the T-matrix. If the set of unique replacement row values in the R-matrix has been initially selected to sum to zero, the replacement row values vanish in the encryption proc- ess; otherwise their sum must be removed from the ciphertext as a special step in the decryption process. In the penultimate step of key generation, the T-matrix is multi- plied by the M-matrix in Figure 10. to produce the public key K- matrix shown in Figure 12. In the final step, this key is then key-seed jumbled in two ways: in four row groups (4-lets) and (optionally) by rows within groups. In the example below 4-lets are jumbled as follows: From To 4-let 4-let 6 1 4 2 1 3 2 4 3 5 5 6 WARLOCK Encryption Process The first encryption step consists of expanding the input plain- text block of n-bits (K-matrix column dimension) to a bit vector of m-bits (K-matrix row dimension) in accordance with the trans- lation table below. In the second and final step, this vector is then multiplied as a column vector by public key K to produce the ciphertext. Alternatively, the plaintext bit values could simply select the applicable rows of K directly as mentioned above and add them together. Expanded Plaintext Plaintext 2-bit Seg- Vector ment Segment 00 0001 01 1000 10 0100 11 0010 WARLOCK Decryption Process Decryption is a multi-step process. In the first step, the ciphertext is multiplied by private key M_inverse to produce an "unmasked version" having the same value as if the expanded plaintext had been multiplied by the T-matrix. In the second step, row identifiers of the B-part are recovered beginning with the leftmost row identifier which is always recov- ered in undisguised or complementary form (since it has not been altered by noise bits). The noise bits associated with this identifier row can now be identified using T-matrix private key information and removed from the ciphertext revealing the next leftmost row identifier in the same manner. This process is repeated iteratively until all row identifiers have been identi- fied -- in their original or complemented form. Each identifier value, thus recovered, unequivocally identifies an applicable 4- bit sector of the invoking expanded plaintext vector which, in turn, identifies a 2-bit sector of the plaintext. In addition, each recovered row identifier identifies its associated fat bit value as 000 or 111. When all row identifiers have been recovered, 2/3 of the plain- text has been decrypted. The remaining 1/3 can now be decrypted by examining fat bit values derived from the recovered identifier values themselves, i.e. for unchanged row identifiers, the ap- plicable fat bit = 000; otherwise the applicable fat bit = 111. When all fat bits have been identified, they are reduced from 3 bits to 1 bit and concatenated to form a value which is multi- plied by private key A_inverse (in Fig. 2.) to recover the re- maining 1/3 of the plaintext. In the final step of decryption, the full set of 2-bit plaintext segments are unjumbled to reverse the effects of the row 4-let jumbling of the public key. 7. WARLOCK 4.0 MANUAL EXAMPLE As an example of WARLOCK 4.0 operation, the WARLOCK 4.0 crypto- graphic keys shown in Figures 6., 11., and 12. may be used to manually encrypt and decrypt 12-bit inputs and to create and verify 12-bit digital signatures as desired. For example, to encrypt plain_text P = 001110000110 using pub- lic_key_K shown in Figure 12., accomplish the following steps: Expand plain_text P to expanded_text 000100100100000110000100. Select and add rows of public_key_K under control of 1-bits in expanded_text to produce encrypted_text as follows: bit 4 selects row 4 of K = 101000100001 bit 7 selects row 7 of K = 011110010011 bit 10 selects row 10 of K = 110011110001 bit 16 selects row 16 of K = 011000001000 bit 17 selects row 17 of K = 000010100101 bit 22 selects row 22 of K = 001001110001 encrypted_text = 010110011111 To facilitate understanding of the more complex decryption proce- dure detailed below, the following reference table is provided which relates row identifier values (as recovered) to the follow- ing necessary information: (1) row position selected within each row 4-let (2) selecting 2-bit plaintext values and (3) applicable fat bit values. Row Row Identi- Selected Selecting Associated fier Value within Plaintext Fat Bit (as recovered 4-let Value Value 100 1 01 000 011 1 01 111 010 2 10 000 101 2 10 111 001 3 11 000 110 3 11 111 000 4 00 000 111 4 00 111 The following steps detail the decryption process: A. Multiply encrypted_text 010110011111 by private key key_M_inverse shown in Figure 11. to create the initial value of reverted_text 100101101111. Note that the leftmost row identifier in bit positions 1, 5, and 9 is unaffected by noise bits and is seen to have the value 101 indicating that row 2 of the applica- ble 4-let of the public key was chosen. Accordingly, 1. Initialize the value of resultant_text with the first 2 recovered plaintext bit values, e.g. resultant_text 10. 2. Create the first iteration of intermediate_text by remov- ing from reverted_text the noise bits associated with row 2 of private key key_T_with_noise by XORing subject row 2 with the reverted_text to produce the first intermediate_text value as follows: 100101101111 (reverted_text) 011010010000 (row 2 template and noise bit values) 111111111111 (intermediate_text) This step also records the fat bits in positions 1, 5, and 9. of the intermediate_text and the reduced fat bit in position 1. B. Note that the value of the row identifier in bits 2, 6, and 10 "uncovered" by the previous step is seen to be 111 indicating that row position 4 of its respective 4-let was selected and further indicating an invoking plaintext value of 00 and an associated fat bit value of 000. Accordingly, 1. Append recovered plaintext bits 00 to the current result- ant_text value giving new resultant_text 1000. 2. Remove from the current intermediate_text value the noise bits associated with applicable row 4 of key_T_with_noise_bits by XORing subject row 4 with intermediate_text to produce a new intermediate_text value as follows: 111111111111 (current intermediate_text) 010101110110 (row 4 template and noise bit values) 101010001001 (new intermediate_text) This step also records the reduced fat bits in positions 1 and 2 of the new intermediate_text. C. The value of the third row identifier (bits 3, 7, and 11) uncovered by the previous step is seen to be 100 indicating that row 1 of its respective 4-let was invoked by a plaintext value of 01 and that its associated fat bit value is 000. Accordingly, 1. Append the recovered plaintext bits 01 to the current re- sultant_text value giving 10000. 2. Remove from the intermediate_text the noise bits associ- ated with row position 1 of private key key_T_with_noise_bits by XORing subject row 1 with the current intermediate_text to pro- duce a new intermediate_text value as follows: 101010001001 (current intermediate_text) 001000000000 (row 1 template and noise bit values) 100010001001 (new intermediate_text) This step also records the reduced fat bits in positions 1, 2, and 3 of the new intermediate_text. D. The fourth and final row identifier (bit positions 4, 8, and 12) uncovered by the previous step is seen to be 001 indicating that row 3 was selected by a plaintext value of 11 and that its associated fat bit value is 000. Accordingly, 1. Append recovered plaintext bits 11 to current resultant_text value giving 10000111. 2. Remove from the current intermediate_text value the noise bits associated with row position 3 of the subject 4-let of key_T_with_noise_bits by XORing row 3 with the current intermedi- ate_text to produce a new intermediate_text_value as follows: 100010001001 (current intermediate_text) 000000000001 (row 3 template value) 100010001000 (new intermediate_text) This step also records the final reduced fat bit in position 4 of the new intermediate_text whose current value is now seen to be 1000. D. This completed intermediate_text value 1000 will be multiplied by private key A_inverse to recover the final plaintext values (originally encoded by the A-part of the public key) as follows: 1000 x A_inverse = 1000 The recovered plaintext value 1000 is then appended to the cur- rent value of resultant_text to produce resultant_text = 100001111000. J. The completed resultant_text value 100001111000 (now seen to be a 2-bit permutation of the original plaintext) must now be unjumbled in the final decryption step by reversing the row jumbling accomplished in the last step of the key generation process (described on page 7.) as follows: Source Bit Desti- Destination Source Pair Position nation Bit Pair Position Bit Pair (resultant_ Bit Pair (decrypted_ Number text)/(value) Number text)/(value) 6 11-12 (00) 1 1-2 (00) 4 7-8 (11) 2 3-4 (11) 1 1-2 (10) 3 5-6 (10) 3 3-4 (00) 4 7-8 (00) 2 5-6 (01) 5 9-10 (01) 5 9-10 (10) 6 11-12 (10) This final permutation step produces the sought plaintext value 001110000110 completing the decryption process. Source Authentication and Superencryption To create a source authentication value S (for source authentica- tion purposes) represented by any selected 12-bit value, S must first be "decrypted" by the decryption module by the steps noted in the foregoing paragraphs to create signature value S*. When submitted to the encryption module for validation, S* produces the sought value S thereby proving unequivocally that S emanated from the private key holder. Because of the relatively high encryption and decryption speeds of WARLOCK 4.0, Alice and Bob may choose for purposes of enhanced security to exchange messages that are simultaneously encrypted and authenticated. To accomplish this, Alice and Bob first obtain each others public keys. In encrypting messages for Bob, Alice accomplishes the following: 1. Alice first "decrypts" each plaintext block using her private key to create an "authenticated version" of the plaintext. She then encrypts this version by Bob's public key to create a final ciphertext block which she transmits to Bob. 2. Bob first decrypts the ciphertext block by his private key recovering the "authenticated version". He then transforms this version to Alice's original plaintext by "encrypting" it with Alice's public key thus proving Alice to be the originator of the plaintext since she is the only holder of the private key. In encrypting messages for Alice, Bob follows the same procedure with the appropriate public and private keys. 8. SEEDING THE WARLOCK KEY GENERATION FUNCTION A basic desideratum of classic private key cryptosystems was easily generated and memorized keys to avoid a possibly compro- mising (or incriminating) recording of the key. This desideratum has all but vanished with DES and the advent of PK systems. Who, for example, can remember a thousand-bit RSA modulus or its constituent primes. Nevertheless, there are many occasions where one would not wish to transport private keys to a new operating locations, but regenerate them at their new location, use them, and destroy them. Such a capability is available through the unique WARLOCK key seeding feature which allows users to seed the key generation process with a user secret key-seed (or pass phrase) of 1 to 85 bytes (8 to 680 bits). Such a feature is typically absent from number theoretic cryptosystems such as RSA and the NIST DSS. With the WARLOCK key seeding feature, users can establish simple mnemonic seeding tokens or create elaborate- ly structured key-seeds as needed. Key seeding also facilitates the use of WARLOCK as a stream cipher where Bob and Alice at different locations independently generate a common private key based on a secret shared key-seed. Such a procedure allows then to generate and synchronize a common pseudorandom bit stream beginning with an agreed-on starting value v which is "decrypted" by the private key and the result XORed with plaintext to encrypt and decrypt in the manner of one- time pads or Vernam ciphers. The starting value v would then be incremented by +1 each iteration yielding a nonrepeating cycle of 2**n iterations where n is the system block size in bits. Key seeding also facilitates opportunistic encryption using devices such as PC's and workstations that are generally avail- able but not portable. For example, Bob could freely transport the encryption/decryption program on a 3 1/2" floppy in his shirt pocket without fear of compromising his secret key-seed. Alice could encrypt from any available PC initialized with an installed WARLOCK program. Both would enter their secret key-seed at the time of message exchange. As yet another example of the potential of key seeding, consider an environment where Bob and Alice are deployed as secret agents who must unequivocally authenticate each other's identity prior to commencing their mission. Each has memorized a key-seed given them by their faceless directors and each carries an unknown ciphertext segment as well. When they finally rendezvous in Vienna, Bob and Alice XOR the ASCII representation of their key- seeds to produce a new key-seed value which they use to generate cryptographic keys. Each then decrypts his ciphertext segment with the newly-generated keys. Bob hands his decrypted message to Alice who reads, "Of course, you know my name isn't Bob at all, it's Travis and I am pleased to meet you at last, Tatiana AKA Alice." 9. WARLOCK CRYPTOGRAPHIC STRENGTH It would be presumptuous at this point to assert that WARLOCK is categorically unassailable -- particularly in light of the vast resources of linear algebraic techniques (most of which are unknown to the authors) that might be mustered for its cryptanal- ysis. The rise and fall of numerous PK cryptosystems proposed during the last decade certainly recommend caution as well. However, based on our experience to date in making and breaking scores of matrix-based PK cryptosystems, it is our feeling that the only potentially effective assault possible against WARLOCK is the derivation of private keys (or workable alternatives) from the public key (assuming that the keys are sufficiently large to preclude other attacks). Clearly, the keys themselves cannot be exhaustively enumerated owing to their size. Simmons generalized PK system attack (11.) can be precluded in several ways. Users may choose to operate in superencrypted mode which accomplishes encryption and source authentication simultaneously or they may choose a suitably large system block size. Various kinds of pre- encryption scrambling (to increase input entropy) and post-de- cryption unscrambling may also be employed. Thus far we have been unable to cryptanalyze WARLOCK 4.0 with techniques successful against ancestors of WARLOCK. Under all the attacks that we have been able to muster, the work factor required to cryptanalyze WARLOCK 4.0 is an exponential function of block size which can be made arbitrarily large. What we are seeking from the user community is an assessment of the viability of the WARLOCK paradigm as well as a more precise quantification of the work factor required to cryptanalyze WARLOCK 4.0. 10. CONCLUSION Apart from the undecided issue of security, the WARLOCK paradigm meets our objective of providing users with single high-speed general purpose PK cryptosystems (exemplified by WARLOCK 4.0) as alternatives to number theoretic systems. We feel that WARLOCK cryptosystems can serve the security needs of private users to whom we grant free use subject to the restrictions noted in the source code and in the introduction to this paper. The WARLOCK paradigm also suggests a new direction for the development of PK systems free of the computational burden of number theoretic systems. Finally, the WARLOCK paradigm suggests a potentially fruitful direction for achieving a viable cryptographic embodi- ment of the NP-hard coding problem cited by Berlekamp et al.(12.). 11. WARLOCK 4.0 NUMBERED FIGURES Note: To facilitate de- 1000 1000 101010101010 cryption, Row 1. is row 2 1010 0110 100010001000 of Matrix A triplica- 1110 1100 001000100010 ted. Row 2 is row 1 0011 1101 000000000000 triplicated; row 3 is 001100110011 the XOR of rows 1 and Figure 1. Figure 2. 111011101110 2 and row 4 is the A-Part Private Key 110111011101 XOR of rows 1, 2, and Matrix A Matrix A_ 000000000000 3. The same process inverse using remaining row Figure 3. pairs of Matrix A is re- A-expanded peated to create A_expan- ded. 100000000000 100010101101 101101000011 010000000000 010100100010 011010010000 001000000000 001011001000 000001001110 111000000000 111111001001 110011001111 000100000000 000100101011 011000010011 000010000000 000010111111 001101110011 000001000000 000001111100 001100100110 000111000000 000111011110 010101110110 000000100000 000000100000 001000000000 000000010000 000000010001 000000100001 000000001000 000000001001 000000000011 000000111000 000000111000 001000100010 000000000100 000000000100 000100000000 000000000011 000000000010 000000010000 000000000001 000000000001 000000000001 000000000111 000000000111 000100010001 Figure 4. Figure 5. Figure 6. B-Part B-Part B-Part Initial key_T_temp- Columnar re- key_T_temp- late with arrangement late noise bits = key_T_with_ noise_bits 110000001000 101001010100 000110100011 100100111100 100000100001 010001110011 110101011011 000001101100 111010111100 001111001000 110101000010 110010110100 001000111100 110110001110 100100010001 111111110010 011000000100 101101101000 100001111010 110101000111 000000010010 111111110000 010111011110 010111011010 .OJ OFF Figure 7. Figure 8. key_M Private Key key_M_inverse 101101000011 110100100010 011001100001 011010010000 110100100010 101110110010 000001001110 110100100010 110101101100 110011001111 110100100010 000111101101 011000010011 001101010001 010101000010 001101110011 001101010001 000000100010 001100100110 001101010001 000001110111 010101110110 001101010001 011000100111 001000000000 010011011011 011011011011 000000100001 010011011011 010011111010 000000000011 010011011011 010011011000 001000100010 010011011011 011011111001 000100000000 101100110010 101000110010 000000010000 101100110010 101100100010 000000000001 101100110010 101100110011 000100010001 101100110010 101000100011 101010101010 011111101001 110101000011 100010001000 011111101001 111101100001 001000100010 011111101001 010111001011 000000000000 011111101001 011111101001 001100110011 011001110011 010101000000 111011101110 011001110011 100010011101 110111011101 011001110011 101110101110 000000000000 011001110011 011001110011 Figure 9. Figure 10. Figure 11. key_T_with_ replacement_ key_T_replaced noise (A rows (Figure 9. and B-Part XOR'd with Fi- joined) gure 10.) 11. BIOGRAPHICAL DATA William J. Wilson is an early-retiree of the Sperry half of the current UNISYS corporation. During his 23 years there, he spe- cialized in database design, information storage and retrieval, and system security. He is a member of ACM occasionally consult- ing in his areas of expertise and is also identified in the current Directory of American Fiction Writers and Poets as both a writer (science fiction and horror) and a poet. His light and satirical verse appeared frequently in DATAMATION (Churl's Garden of Verses, Solid-state Jabberwocky, Ode to the Indomitable GOTO, etc.) and other magazines. C. Larry Craig (co-inventor of WARLOCK and author of the C++ WARLOCK program) currently works as a private consultant and software designer in the fields of digital communication, commu- nication networks, and cellular and telephony applications. 12. REFERENCES 1. Hill, L. "Cryptography in an Algebraic Alphabet," Amer. Math. Monthly. 36: 306-312, 1929. 2. Diffie, W., and Hellman, M.E. "New Directions in Cryptog- raphy," IEEE Trans. Inform. Theory IT-22, 644-654, Nov. 1976. 3. Rivest, R. et al., A Method for Obtaining Digital Signa- tures and Public-key Cryptosystems, Communications of the ACM 21, pp. 120-126, Feb 1978. 4. McEleice, R.J. "A Public-key cryptosystem based on Alge- braic Coding Theory," DSN Progress Rep. 42-44, Jet Propulsion Laboratory, pp. 114-116, 1978. 5. Korzhik, V.L. and Turkin, A.I., "Cryptanalysis of McE- liece's Public-key Cryptosystem," Advances in Cryptology - Euro- crypt '91 Proceedings. 6. Cooper, R. "Linear Transformations in Galois Fields and Their Application to Cryptography," Cryptologia, Vol 4., No. 3, pp. 184-188, 1992. 7. Patti, T. "The SUMMIT Cryptosystem," Cryptosystems Jour- na, Vol 2., No. 2, 1992. 8. Merkle, C. and Hellman, M.E. "Hiding Information and Signatures in Trapdoor Knapsacks," IEEE Trans. Inform. Theory.IT- 24: pp. 525-530, 1978. 9. Payne, W.H. and McMillan, K.L., Orderly Enumeration of Nonsingular Binary Matrices Applied to Text Encryption, Communi- cations of the ACM, pp. 259-265, April 1978. 10. Chaitin, G. J. ""Randomness and Mathematical Proof," Scientific American pp. 47-52, May 1975. 11. Simmons, G.J., Forward Search as a Cryptanalytic Tool Against a Public Key Privacy Channel, Proceedings of the IEEE Symposium on Security and Privacy, April 1982. 12. Berlecamp, E.R., McEleice, R.J., and van Tilborg, H.C.A., On the Inherent Intractability of Certain Coding Problems, IEEE Trans. Inform. Theory, IT-24, pp. 384-386, May 1978. #000# From eric at Synopsys.COM Wed Jun 30 13:32:26 1993 From: eric at Synopsys.COM (Eric Messick) Date: Wed, 30 Jun 93 13:32:26 PDT Subject: Remailer pings Message-ID: <9306302032.AA23540@tiedye.synopsys.com> I've gotten responses from the following remailers: hfinney at shell.portal.com hh at soda.berkeley.edu remail at tamsun.tamu.edu nowhere at bsu-cs.bsu.edu phantom at mead.u.washington.edu elee7h5 at rosebud.ee.uh.edu hal at alumni.cco.caltech.edu dis.org!remailer at merde.dis.org hh at pmantis.berkeley.edu hh at cicada.berkeley.edu remail at tamaix.tamu.edu ebrandt at jarthur.claremont.edu remailer at rebma.mn.org And have not recieved (in two days) a response from: 00x at uclink.berkeley.edu I used the perl script appended to this message. -eric messick (eric at toad.com) #!/usr/local/bin/perl $me = "eric at synopsys.com" ; # put your email address here sub begin_mail { local ($addr, $from, $subject) = (@_); if (!open(MAIL, "| /usr/lib/sendmail '" . $addr . "'")) { &log("error", "Error sending mail to $addr") ; return; } print MAIL "To: $addr\n" ; print MAIL "From: $from\n" ; print MAIL "Reply-To: $from\n" ; print MAIL "Subject: $subject\n" ; print MAIL "\n" ; } $home = $ENV{'HOME'} ; open(REMAILERS, "$home/remail/currentremailers") || die "Can't open $home/remail/currentremailers: $!\n" ; while () { chop; ($addr) = split ; next if ($addr eq "#") ; print "$addr\n" ; &begin_mail($addr, $me, "ferd"); print MAIL "::\n" ; print MAIL "Request-Remailing-To: $me\n" ; print MAIL "\n" ; print MAIL "mailed to $addr\n" ; close MAIL; } From shipley at merde.dis.org Wed Jun 30 16:02:37 1993 From: shipley at merde.dis.org (Peter shipley) Date: Wed, 30 Jun 93 16:02:37 PDT Subject: remailer ideas & proposals In-Reply-To: <9306300830.AA18466@bailey.cpac.washington.edu> Message-ID: <9306302300.AA14856@merde.dis.org> A non-text attachment was scrubbed... Name: not available Type: text/x-pgp Size: 1100 bytes Desc: not available URL: From zane at genesis.mcs.com Wed Jun 30 16:29:10 1993 From: zane at genesis.mcs.com (Sameer) Date: Wed, 30 Jun 93 16:29:10 PDT Subject: remailer ideas & proposals In-Reply-To: <9306300657.AA26896@longs.lance.colostate.edu> Message-ID: In message <9306300657.AA26896 at longs.lance.colostate.edu>, ""L. Detweiler"" writes: > > Here is an idea: if a remailer drops a message or forwards it > successfully it could broadcast a message to a group such as misc.test. I like this idea.. How about alt.remail? And a header: :: Request-Remailing-To: remail at extropia.wimsey.com Error-ID: &DNANC*WHS If the message is dropped the remailer posts a note to alt.remail saying, "Remail message &DNANC*WHS has been dropped." Maybe some sort of ID-encryption similar to that used in Chaum's digital cash algorithim could be used for security. > > And some goofy Fidonet gateway may find it necessary to stick something on the end: > > x-message-format: ((headers:4 body:10 signature:3) fidofooter:4) > This would require that the operator of the Fidonet gateway be cypherpunk-friendly. I think it is best if all modifications/ideas be made *only* to remailers, for I doubt that we will have much control of other net-elements. -- | Sameer Parekh-zane at genesis.MCS.COM-PFA related mail to pfa at genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/ From ld231782 at longs.lance.colostate.edu Wed Jun 30 17:18:07 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Wed, 30 Jun 93 17:18:07 PDT Subject: rumors of Clipper hardware problems Message-ID: <9307010017.AA14364@longs.lance.colostate.edu> The following came from D. Farber who is closely associated with NSF Internet commitees and has been following Clipper development, as received from an anonymous informant. Items: 1. list of Clipper committee members 2. more NIST irregularities around DSS 3. Clipper: low yield, average failure in 40 hours, `substantial redesign', delayed up to a year? If anyone forwards this past cypherpunks (e.g. Usenet) take out my and D. Farber names. ===cut=here== From: farber at central.cis.upenn.edu (David Farber) Subject: technical review of the Slipjack algorithm Date: Tue, 29 Jun 1993 16:42:24 -0500 In case anyone hasn'y picked this up yet, this is the list of individuals who are participating in the technical review of the Slipjack algorithm: Dorothy Denning, Georgetown U. Walt Tubman, IBM (retired) Ernie Brickell, Sandia Labs Steve Kent, BBN Dave Mayer, AT&T According to Lynn McNulty (NIST), the group met for a few days last week with NIST and NSA representatives. They are now in the process of formulating more questions for a second meeting with the government team. No word yet on the form, content or schedule of the group's report. From: farber at central.cis.upenn.edu (David Farber) Subject: "Digital Signature Scandal" a bit more Date: Tue, 29 Jun 1993 16:40:57 -0500 During a discussion in DC today the following arose. The Federal register announcement was dated and signed on 2 June 1993 (and published on 8 June). The NIST Advisory Board mandated by the congress was meeting at NIST on 2-5 June. They were not told about the announcement even though the matter was of direct interest and importance to their assigned task. Why??? Did someone have something to hide? I hear tell also that the Clipper chip's first run of final silicon was not a winner. Chips failed after 40 hours. I also heard a rumor that the redo would [delay] things for up to a year (sounds like a long time). Any better info out there? Dave "Informant" [forwarded by D. Farber]: "My info is that there were three parallel tests; your number comes from the first, though the others were little better. Batch I n=8 mtbf= 41.5 hrs. Batch II n=11 mtbf= 49.0 hrs. Batch III n=20 mtbf= 32.0 hrs. My NSA source said that he thought that the difficulty was related to thermal issues and that if environmental issues were addressed or at least audit ed to assure proper operating environment the numbers might have been better. I have been unable to get any 'hard' info re what actually happened and what kind of a post mortem is taking place." 2. Re chip health. I heard the same story plus yield was very low. I also understand that there is substantial redesign going on because the story about defaulting to an all-0 key if the LEB were corrupted was apparently true. From shipley at merde.dis.org Wed Jun 30 17:42:08 1993 From: shipley at merde.dis.org (Peter shipley) Date: Wed, 30 Jun 93 17:42:08 PDT Subject: remailer ideas & proposals In-Reply-To: Message-ID: <9307010019.AA15108@merde.dis.org> A non-text attachment was scrubbed... Name: not available Type: text/x-pgp Size: 643 bytes Desc: not available URL: From jet at nas.nasa.gov Wed Jun 30 18:01:15 1993 From: jet at nas.nasa.gov (J. Eric Townsend) Date: Wed, 30 Jun 93 18:01:15 PDT Subject: id this chip? Message-ID: <9307010101.AA26550@boxer.nas.nasa.gov> Found this in my desk in my new cubicle. I'm not a chip head, so I have no clue as to the id of all sorts of obscure chip manus and whatnot. (I recognize hitachi, intel, motorola, that sort of thing, duh. :-) 48pin marked on top with the following text *only*. No symbols, logos, etc: CIPHER 1984 960430-004 8816 IP8073B So, what do I win? A free clipper phone? -eric